Análisis comparativo de las tecnologías DoH y DoT

DNS over HTTPS (DoH) y DNS over TLS (DoT) son dos métodos comunes de transporte DNS cifrado, que implementan la transmisión segura de consultas DNS a través de diferentes pilas de protocolos. El estándar DoT está definido por RFC 7858, mientras que DoH está estandarizado por DNS Queries over HTTPS (DoH). Para comprender las diferencias esenciales entre estas dos tecnologías, es necesario analizarlas partiendo de la estructura jerárquica de los protocolos de red.

Estructura jerárquica de protocolos de red

Las pilas de protocolos de red modernas adoptan un diseño por capas, donde cada capa ofrece diferentes funciones. DNS, como protocolo de la capa de aplicación, no está vinculado a un método de transporte específico y puede ejecutarse sobre varios protocolos subyacentes.

La capa de aplicación (L7) incluye protocolos como HTTP/1.1, HTTP/2, HTTP/3, FTP y DNS. Cabe destacar que la semántica de HTTP/3 sigue estando en la capa de aplicación, siendo QUIC el transporte subyacente. La capa de seguridad se encuentra entre la capa de aplicación y la capa de transporte, e incluye principalmente TLS y sus variantes. TLS generalmente se ejecuta sobre TCP, como en HTTPS y DoT. DTLS es la versión de datagramas de TLS y puede ejecutarse sobre UDP. El protocolo QUIC es especial, ya que integra directamente el handshake y la derivación de claves de TLS 1.3 dentro del protocolo.

QUIC puede considerarse un protocolo de la capa L4.5; se basa en una extensión de UDP y proporciona capacidades tradicionales de la capa de transporte. La capa de transporte (L4) incluye TCP, UDP y QUIC. Aunque desde una perspectiva de implementación QUIC se basa en UDP, incorpora funciones como confiabilidad, control de congestión, multiplexación y handshake cifrado, por lo que en la ingeniería se trata como un protocolo independiente de la capa de transporte. La capa de red (L3) utiliza el protocolo IP (IPv4/IPv6) responsable del enrutamiento y reenvío de paquetes. La capa de enlace de datos (L2) incluye tecnologías como Ethernet y Wi-Fi (802.11).

TLS, como método de cifrado, funciona entre la capa de aplicación y la capa de transporte. Si se elimina el cifrado TLS de DoT, DoT se convierte esencialmente en DNS over TCP. Este diseño en capas hace que el cifrado sea opcional, en lugar de una restricción obligatoria del propio protocolo.

Características de Plain DNS

El DNS más común se denomina Plain DNS y puede ejecutarse sobre UDP o TCP. UDP es el método de transporte más frecuente porque el establecimiento de conexión es simple y la velocidad de la primera consulta es rápida. Sin embargo, la debilidad de UDP es que no es confiable y los paquetes se pierden fácilmente en la red. Aunque TCP requiere más handshakes y la velocidad de la primera conexión es aproximadamente un 30% más lenta que UDP, una vez establecida la conexión larga, su velocidad de respuesta es igual a la de UDP.

Los operadores de red pueden optar por descartar paquetes UDP para aliviar la presión de los dispositivos cuando la red está congestionada. En regiones donde la pérdida de paquetes UDP es grave para ciertos operadores, especificar el uso de TCP para consultas DNS puede ser más ventajoso. TCP tiene un mecanismo de retransmisión que garantiza que los datos lleguen de manera confiable incluso si se pierden paquetes, mientras que perder paquetes UDP no reduce la carga de los dispositivos de los pequeños operadores, sino que introduce más incertidumbre debido a los reintentos.

Anidamiento de la capa de aplicación

Tanto DNS como HTTP pertenecen a la capa de aplicación; DoH es esencialmente un protocolo de la capa de aplicación que anida otro protocolo de la capa de aplicación. DoH no tiene por qué ser necesariamente DNS over HTTPS; el uso de HTTP normal también es posible, pero el DoH sin cifrado son solicitudes en texto plano, por lo que no ofrece ninguna ventaja compared with Plain DNS y solo se usa en muy pocos escenarios de necesidades especiales.

Teóricamente, DNS puede transportarse sobre cualquier protocolo de la capa de aplicación; por ejemplo, DNS over FTP también es factible, siempre que se desarrollen el servidor y el cliente correspondientes. Esta flexibilidad refleja las posibilidades de combinación de protocolos de la capa de aplicación.

flowchart TD
    subgraph L7["Capa de aplicación"]
        A[DNS]
        B[HTTP]
        C[FTP]
    end
    
    subgraph Security["Capa de seguridad"]
        D[TLS]
        E[DTLS]
    end
    
    subgraph Transport["Capa de transporte"]
        F[TCP]
        G[UDP]
        H[QUIC]
    end
    
    subgraph L3["Capa de red"]
        I[IP]
    end
    
    subgraph L2["Capa de enlace de datos"]
        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

Anidamiento de la capa de transporte

El protocolo QUIC se basa en UDP y, al mismo tiempo, proporciona un servicio orientado a conexión en la capa de transporte. QUIC implementa capacidades de la capa de transporte como la orientación a conexión, el control de congestión, la retransmisión, el control de flujo, la fragmentación y el ensamblaje que ya tenía TCP. En comparación con TCP, QUIC tiene menor latencia. En comparación con UDP, QUIC es más avanzado y fiable.

Relaciones de combinación de protocolos

No hay una relación limitante inevitable entre la capa de aplicación y la capa de transporte; el cifrado se puede añadir o no. HTTP puede ejecutarse sobre TCP o sobre QUIC. DNS puede ejecutarse sobre TCP, sobre UDP o sobre QUIC.

Basándonos en estas posibilidades, se pueden resumir las siguientes relaciones de combinación. Plain DNS equivale a UDP o TCP más el protocolo DNS. HTTP/2 equivale a TCP más TLS 1.2 o TLS 1.3 y luego el protocolo HTTP. HTTP/3 equivale a QUIC más TLS 1.3 y luego el protocolo HTTP.

DoH (DNS over HTTPS) equivale a HTTP/2 o HTTP/3 más el protocolo DNS. DoT (DNS over TLS) equivale a TCP más TLS 1.2 o TLS 1.3 y luego el protocolo DNS. DoQ (DNS over QUIC) equivale a QUIC más TLS 1.3 y luego el 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álisis de rendimiento y compatibilidad

Una vez comprendida la estructura jerárquica de los protocolos, se pueden analizar las ventajas y desventajas de DoH y DoT.

La comparación entre TCP y QUIC debe discutirse combinándola con el entorno de red real de los operadores. QUIC es un protocolo más nuevo que resuelve algunos problemas de redes antiguas, pero al fin y al cabo se basa en UDP. Desde la perspectiva de la latencia de red, los protocolos basados en QUIC tienen una latencia aproximadamente un 35% menor que TCP, por lo que DNS over HTTP/3 y DoQ (DNS over QUIC) teóricamente ofrecerán un mejor rendimiento que DNS over HTTP/2 y DoT.

Sin embargo, en el entorno de red real existen problemas de latencia por retransmisión causados por la pérdida de paquetes. Los operadores pueden optar por descartar paquetes UDP cuando la red está congestionada, y QUIC será identificado como UDP y descartado. Aunque QUIC soporta retransmisión, la latencia introducida por esta puede hacer que la latencia real de QUIC sea mayor que la de TCP.

En cuanto a privacidad y seguridad, tanto DoH como DoT son tráfico cifrado y no pueden ser interceptados ni alterados. Sobre el problema del bloqueo de DoT tras ser identificado, se debe principalmente a que la configuración de DNS cifrado del sistema Android utiliza por defecto el puerto 853, lo que convierte el puerto 853 en un puerto sensible. DoT en sí es tráfico cifrado común y no se identificará como tráfico exclusivo de DNS. En realidad, cualquier puerto puede ofrecer servicio DoT; esto requiere aplicaciones de terceros en Android, mientras que iOS soporta nativamente el uso de DoH en cualquier puerto.

La escalabilidad es una ventaja importante de DoH. En comparación con el DNS encapsulado en HTTP y Plain DNS, HTTP tiene una escalabilidad claramente superior. Los proveedores pueden ofrecer innumerables servicios en el puerto 443, incluyendo DoH, y extender las funciones fácilmente. DoT y DoQ generalmente necesitan ocupar un puerto exclusivo y su capacidad de extensión se basa completamente en Plain DNS. Esta es una diferencia desde la perspectiva del proveedor; para el usuario promedio, no hay una percepción obvia por ahora.

En cuanto a la velocidad de procesamiento de solicitudes DNS, la velocidad de procesamiento de HTTP puede ser efectivamente unos pocos ciclos de reloj de CPU más lenta que Plain DNS, pero esta diferencia es despreciable en el uso real. En términos de compatibilidad, DoH puede ser más convencional porque para los proveedores DoH tiene buena escalabilidad.

El soporte actual de las plataformas principales para el DNS cifrado varía. Los navegadores con kernel Chromium soportan DoH. El sistema Windows 11 soporta nativamente DoH. El sistema Android versión 8 y superiores soporta nativamente DoT. El sistema Android versión 11 y superiores soporta nativamente DoT y DoH. El sistema macOS soporta nativamente DoT y DoH. El sistema iOS soporta nativamente DoT y DoH.

Recomendaciones de elección práctica

Para el usuario promedio, usar DoH es menos problemático que usar DoT. En comparación con DoT, DoH proporciona una latencia mejor la mayor parte del tiempo y una latencia similar una minoría de las veces. En comparación con DoQ, DoH tiene una latencia similar la mayor parte del tiempo y proporciona una latencia mejor una minoría de las veces.

Esta conclusión的前提 es que el proveedor ofrezca el servicio DNS over HTTP/3. Si el proveedor no ofrece HTTP/3, no hay una diferencia obvia entre DoH y DoT. DoH utilizará automáticamente DoH/3 para obtener una menor latencia cuando la calidad de la red sea buena, y degradará automáticamente a HTTP/2 cuando la calidad de la red sea mala. Esta capacidad adaptativa requiere que el proveedor la implemente, aunque los proveedores principales generalmente lo han hecho.

Se recomienda probar NullPrivate, que soporta DoT y DoH/3, y viene con bloqueo de anuncios y función de división de tráfico DNS de forma nativa. Si necesita despliegue propio, puede usar su librería de código abierto.

La elección del protocolo de red requiere considerar múltiples factores, incluyendo la calidad de la red del operador, la situación de soporte del proveedor y la compatibilidad del dispositivo. Para la mayoría de los usuarios, DoH es una excelente opción que equilibra rendimiento, compatibilidad y protección de privacidad.

• ←Anterior
• Siguiente→