Análise Comparativa das Tecnologias DoH e DoT

DNS over HTTPS (DoH) e DNS over TLS (DoT) são duas formas comuns de transmissão de DNS criptografada; elas implementam a transmissão segura de consultas DNS através de diferentes pilhas de protocolos. O padrão DoT é definido pelo RFC 7858, enquanto o DoH é padronizado pelo DNS Queries over HTTPS (DoH). Para compreender as diferenças essenciais entre essas duas tecnologias, é necessário analisar a partir da estrutura em camadas do protocolo de rede.

Estrutura em Camadas do Protocolo de Rede

A pilha de protocolos de rede moderna adota um design em camadas, onde cada camada fornece funções diferentes. Como um protocolo da camada de aplicação, o DNS em si não está vinculado a um método de transmissão específico e pode operar sobre vários protocolos de transporte.

A camada de aplicação (L7) contém protocolos como HTTP/1.1, HTTP/2, HTTP/3, FTP e DNS. Vale notar que a semântica do HTTP/3 ainda permanece na camada de aplicação, sendo o QUIC apenas o transporte subjacente. A camada de segurança está localizada entre a camada de aplicação e a camada de transporte, incluindo principalmente o TLS e suas variantes. O TLS geralmente opera sobre o TCP, como no HTTPS e DoT. O DTLS é a versão de datagrama do TLS e pode operar sobre o UDP. O protocolo QUIC é bastante especial, pois integra diretamente o handshake e a derivação de chaves do TLS 1.3 dentro do protocolo.

O QUIC pode ser visto como um protocolo de camada L4.5, baseado em uma extensão do UDP, fornecendo capacidades da camada de transporte tradicional. A camada de transporte (L4) contém TCP, UDP e QUIC. Embora do ponto de vista de implementação de engenharia o QUIC seja baseado em UDP, ele possui recursos como confiabilidade, controle de congestionamento, multiplexação e handshake criptográfico, sendo, portanto, tratado na engenharia como um protocolo de camada de transporte independente. A camada de rede (L3) usa o protocolo IP (IPv4/IPv6) responsável pelo roteamento e encaminhamento de pacotes. A camada de enlace de dados (L2) inclui tecnologias como Ethernet e Wi-Fi (802.11).

O TLS, como meio de criptografia, opera entre a camada de aplicação e a camada de transporte. Se a criptografia TLS for removida do DoT, o DoT torna-se essencialmente DNS over TCP. Este design em camadas torna a criptografia uma opção, e não uma restrição obrigatória do próprio protocolo.

Características do Plain DNS

O DNS mais comum é chamado de Plain DNS; ele pode operar sobre UDP ou TCP. O UDP é a forma de transporte mais comum, pois o estabelecimento da conexão é simples e a velocidade da primeira consulta é rápida. Mas a fraqueza do UDP é a falta de confiabilidade; é fácil que os pacotes se percam na rede. Embora o TCP exija mais handshakes e a velocidade da primeira conexão seja cerca de 30% mais lenta que o UDP, após estabelecer uma conexão longa, a velocidade de resposta é a mesma do UDP.

Os provedores de rede optam por descartar pacotes UDP quando a rede está congestionada para aliviar a pressão nos equipamentos. Para regiões onde a perda de pacotes UDP de certos provedores é grave, especificar o uso de TCP para consultas DNS pode ser mais vantajoso. O TCP possui um mecanismo de retransmissão, garantindo que os dados cheguem de forma confiável mesmo com perda de pacotes, enquanto descartar pacotes UDP não reduz a carga de equipamentos de pequenos provedores; pelo contrário, introduzirá mais incertezas devido às novas tentativas.

Aninhamento da Camada de Aplicação

O DNS e o HTTP pertencem aos protocolos da camada de aplicação; o DoH é essencialmente um protocolo da camada de aplicação aninhando outro protocolo da camada de aplicação. O DoH não é necessariamente DNS over HTTPS; usar HTTP comum também é viável, apenas que o DoH não criptografado é uma requisição em texto simples e não oferece nenhuma vantagem em relação ao Plain DNS, sendo usado apenas em pouquíssimos cenários de necessidades especiais.

Teoricamente, é possível transportar DNS sobre qualquer protocolo da camada de aplicação; por exemplo, DNS over FTP também pode ser implementado, bastando desenvolver o servidor e cliente correspondentes. Essa flexibilidade reflete as possibilidades de combinação de protocolos da camada de aplicação.

flowchart TD
    subgraph L7["应用层"]
        A[DNS]
        B[HTTP]
        C[FTP]
    end
    
    subgraph Security["安全层"]
        D[TLS]
        E[DTLS]
    end
    
    subgraph Transport["传输层"]
        F[TCP]
        G[UDP]
        H[QUIC]
    end
    
    subgraph L3["网络层"]
        I[IP]
    end
    
    subgraph L2["数据链路层"]
        J[Ethernet]
        K[WiFi]
    end
    
    A --> D
    B --> D
    C --> D
    D --> F
    E --> G
    H --> G
    F --> I
    G --> I
    H --> I
    I --> J
    I --> K
    
    style A fill:#e1f5ff
    style B fill:#e1f5ff
    style C fill:#e1f5ff
    style D fill:#fff4e1
    style E fill:#fff4e1
    style F fill:#ffe1e1
    style G fill:#ffe1e1
    style H fill:#e1ffe1

Aninhamento da Camada de Transporte

O protocolo QUIC é baseado em UDP, enquanto fornece serviços orientados à conexão na camada de transporte. O QUIC implementa capacidades da camada de transporte que o TCP já possui, como orientação à conexão, controle de congestionamento, retransmissão, controle de fluxo, fragmentação e montagem. Em comparação com o TCP, o QUIC tem latência menor. Em comparação com o UDP, o QUIC é mais avançado e confiável.

Relações de Combinação de Protocolos

Não há uma relação de restrição necessária entre a camada de aplicação e a camada de transporte; a criptografia pode ser adicionada ou não. O HTTP pode operar sobre TCP, ou sobre QUIC. O DNS pode operar sobre TCP, sobre UDP, ou sobre QUIC.

Com base nessas possibilidades, podem-se resumir as seguintes relações de combinação. Plain DNS é igual a UDP ou TCP mais o protocolo DNS. HTTP/2 é igual a TCP mais TLS 1.2 ou TLS 1.3 mais o protocolo HTTP. HTTP/3 é igual a QUIC mais TLS 1.3 mais o protocolo HTTP.

DoH (DNS over HTTPS) é igual a HTTP/2 ou HTTP/3 mais o protocolo DNS. DoT (DNS over TLS) é igual a TCP mais TLS 1.2 ou TLS 1.3 mais o protocolo DNS. DoQ (DNS over QUIC) é igual a QUIC mais TLS 1.3 mais o protocolo DNS.

flowchart LR
    subgraph DoT["DoT DNS over TLS"]
        direction LR
        T1[TCP] --> T2[TLS]
        T2 --> T3[DNS]
    end
    
    subgraph DoH2["DoH over HTTP/2"]
        direction LR
        H1[TCP] --> H2[TLS]
        H2 --> H3[HTTP/2]
        H3 --> H4[DNS]
    end
    
    subgraph DoH3["DoH over HTTP/3"]
        direction LR
        Q1[QUIC] --> Q2[TLS 1.3]
        Q2 --> Q3[HTTP/3]
        Q3 --> Q4[DNS]
    end
    
    subgraph DoQ["DoQ DNS over QUIC"]
        direction LR
        D1[QUIC] --> D2[TLS 1.3]
        D2 --> D3[DNS]
    end
    
    style T1 fill:#e3f2fd
    style T2 fill:#fff3e0
    style H1 fill:#e3f2fd
    style H2 fill:#fff3e0
    style Q1 fill:#e8f5e9
    style Q2 fill:#fff3e0
    style D1 fill:#e8f5e9
    style D2 fill:#fff3e0

Análise de Desempenho e Compatibilidade

Após compreender a estrutura em camadas do protocolo, podemos analisar os prós e contras do DoH e DoT.

A comparação entre TCP e QUIC precisa ser discutida em conjunto com o ambiente de rede real do provedor. O QUIC é um protocolo mais recente que resolve alguns problemas de redes antigas, mas afinal é baseado em UDP. Do ponto de vista da latência de rede, a latência de protocolos baseados em QUIC é cerca de 35% menor que a do TCP; portanto, o DNS over HTTP/3 e o DoQ (DNS over QUIC) são teoricamente mais performáticos que o DNS over HTTP/2 e o DoT.

No entanto, em ambientes de rede reais, existe o problema de latência de retransmissão causada pela perda de pacotes. Os provedores optam por descartar pacotes UDP quando a rede está congestionada, e o QUIC será identificado como UDP e descartado. Embora o QUIC suporte retransmissão, a latência introduzida pela retransmissão pode fazer com que a latência real do QUIC seja maior que a do TCP.

Em termos de privacidade e segurança, tanto DoH quanto DoT são tráfego criptografado e não podem ser interceptados ou adulterados. Sobre o problema do bloqueio do DoT após ser identificado, deve-se principalmente ao fato de que as configurações de DNS criptografado do sistema Android usam a porta 853 por padrão, o que torna a porta 853 uma porta sensível. O DoT em si é um tráfego criptografado comum e não é identificado como tráfego exclusivo de DNS. Na verdade, qualquer porta pode fornecer serviços DoT; no Android isso requer aplicativos de terceiros, enquanto no iOS o suporte nativo permite o uso de DoT em qualquer porta.

A escalabilidade é uma vantagem importante do DoH. Comparado ao DNS encapsulado via HTTP e ao Plain DNS, o HTTP tem uma escalabilidade significativamente melhor. Os provedores podem oferecer inúmeros serviços na porta 443, incluindo DoH, e podem estender funcionalidades convenientemente. DoT e DoQ geralmente precisam de portas exclusivas, e sua capacidade de extensão baseia-se totalmente no Plain DNS. Esta é a diferença da perspectiva do provedor; para o usuário comum, não há uma percepção óbvia por enquanto.

Quanto à velocidade de processamento de requisições DNS, a velocidade de processamento do HTTP pode de fato ser alguns ciclos de clock de CPU mais lenta que o Plain DNS, mas essa diferença é insignificante no uso real. Em termos de compatibilidade, o DoH pode se tornar mais mainstream, pois para os provedores o DoH tem boa escalabilidade.

O suporte atual de DNS criptografado nas plataformas principais varia. Navegadores com kernel Chromium suportam DoH. O sistema Windows 11 tem suporte nativo a DoH. Android 8 e versões superiores têm suporte nativo a DoT. Android 11 e versões superiores têm suporte nativo a DoT e DoH. O sistema macOS tem suporte nativo a DoT e DoH. O sistema iOS tem suporte nativo a DoT e DoH.

Recomendações de Escolha Prática

Para o usuário comum, usar DoH é menos trabalhoso do que usar DoT. Comparado ao DoT, o DoH fornece latência melhor na maior parte do tempo e latência semelhante em uma minoria do tempo. Comparado ao DoQ, o DoH tem latência semelhante na maior parte do tempo e fornece latência melhor em uma minoria do tempo.

A premissa desta conclusão é que o provedor ofereça o serviço DNS over HTTP/3. Se o provedor não oferecer HTTP/3, não há diferença óbvia entre DoH e DoT. Quando a qualidade da rede é boa, o DoH usará automaticamente DoH/3 para obter menor latência; quando a qualidade da rede é ruim, ele diminui automaticamente para HTTP/2. Essa capacidade adaptativa precisa ser implementada pelo provedor, embora os provedores principais geralmente a tenham implementado.

Recomenda-se tentar o NullPrivate, que suporta DoT e DoH/3 e vem nativamente com funções de bloqueio de anúncios e roteamento de DNS. Se precisar fazer auto-hospedagem, pode usar sua biblioteca open source.

A escolha do protocolo de rede requer uma consideração abrangente de múltiplos fatores, incluindo a qualidade da rede do provedor, o suporte do fornecedor de serviços, a compatibilidade do dispositivo, etc. Para a maioria dos usuários, o DoH é uma excelente escolha que equilibra desempenho, compatibilidade e proteção de privacidade.

• ←Anterior
• Próximo→