¿Cuál es la diferencia entre DNS-over-HTTPS (DoH) y DNS-over-TLS (DoT)?

DoH encapsula queries DNS en requests HTTPS en el puerto 443, haciéndolos indistinguibles del tráfico HTTPS normal. DoT usa un puerto dedicado (853) con TLS, lo que hace fácil identificar y bloquear para administradores de red. DoH es más difícil de bloquear pero también más difícil de manejar en entornos enterprise.

¿Encrypted Client Hello (ECH) reemplaza la necesidad de una VPN?

ECH encripta el campo SNI en handshakes TLS, previniendo que observadores en el path vean a qué dominio te se está conectando. Combinado con DoH, cubre los dos leaks principales de metadata en HTTPS. Sin embargo, una VPN también oculta tu IP de destino, cosa que ECH no hace. Para privacidad completa, todavía se necesita VPN o Tor.

¿Qué es Oblivious DoH y cuándo debería usarlo?

Oblivious DoH (ODoH) agrega un relay entre el cliente y el resolver, así que el resolver nunca ve la IP del cliente y el relay nunca ve el contenido de la query DNS. Utilizar cuando se necesita privacidad DNS tanto de tu path de red COMO de tu resolver DNS. El overhead de latencia es típicamente 5-15ms por query.

Stack de Privacidad DNS: DoH, DoT, DNSSEC, Encrypted Client Hello y Análisis Comparativo de Privacidad

El Problema del Leak de Metadata

Cuando visitás https://cosas-secretas.ejemplo.com, tu tráfico HTTPS está encriptado. Pero el proceso de conexión filtra metadata en múltiples puntos:

Paso 1: Resolución DNS
 Cliente → DNS del ISP: "¿Cuál es la IP de cosas-secretas.ejemplo.com?"
 DNS del ISP → Cliente: "Es 203.0.113.42"
 [LEAKEADO: El dominio que se está visitando]

Paso 2: Conexión TCP
 Cliente → 203.0.113.42: SYN
 [LEAKEADO: La IP a la que te conectás]

Paso 3: Handshake TLS
 Cliente → Servidor: ClientHello { SNI: "cosas-secretas.ejemplo.com" }
 [LEAKEADO: El dominio de nuevo, en texto plano]

Paso 4: Datos de Aplicación Encriptados
 [PROTEGIDO: El request y response HTTP real]

Tres de cuatro pase es filtran el dominio que visitás. DNS encriptado solo arregla el paso 1. ECH arregla el paso 3. El paso 2 es fundamentalmente difícil (requiere proxy, VPN, o Tor).

DNS-over-HTTPS (DoH): Lo Básico

DoH envuelve queries DNS en requests HTTPS estándar:

# Query DoH usando JSON (extensión Cloudflare/Google)
curl -s -H 'Accept: application/dns-json' \
 'https://cloudflare-dns.com/dns-query?name=example.com&type=A' | jq .

# Respuesta:
{
 "Status": 0,
 "AD": true,
 "Question": [{"name": "example.com", "type": 1}],
 "Answer": [
 {"name": "example.com", "type": 1, "TTL": 3600,
 "data": "93.184.216.34"}
 ]
}

Configurar un resolver DoH local con dnscrypt-proxy:

# /etc/dnscrypt-proxy/dnscrypt-proxy.toml
listen_addresses = ['127.0.0.1:53', '[::1]:53']
server_names = ['cloudflare', 'cloudflare-ipv6']
doh_servers = true
require_dnssec = true
require_nofilter = true
require_nolog = true

cache = true
cache_size = 4096
cache_min_ttl = 2400

# Relays Oblivious DoH
[anonymized_dns]
routes = [
 { server_name='cloudflare', via=['anon-relay-1', 'anon-relay-2'] }
]

Encrypted Client Hello (ECH): La Pieza Faltante

ECH encripta el ClientHello completo (incluyendo SNI) usando una clave pública publicada en el registro DNS del servidor:

Sin ECH:
 Cliente → Servidor: ClientHello {
 SNI: "cosas-secretas.ejemplo.com" ← VISIBLE para observador en el path
 }

Con ECH:
 1. Cliente busca registro DNS HTTPS para cosas-secretas.ejemplo.com
 → Contiene config ECH con clave pública

 2. Cliente → Servidor: ClientHello {
 SNI: "cloudflare-ech.com" ← SNI "externo" (dominio público)
 encrypted_client_hello: {
 // Encriptado con la clave pública ECH del servidor:
 inner_SNI: "cosas-secretas.ejemplo.com"
 }
 }

 El observador ve: conexión a "cloudflare-ech.com"
 El servidor desencripta: destino real es "cosas-secretas.ejemplo.com"

Oblivious DoH (ODoH): No Confíes en Nadie

DoH estándar tiene un problema de confianza: se está reemplazando a tu ISP como la entidad que ve las queries DNS con tu resolver DoH. ODoH arregla esto:

DoH estándar:
 Cliente →→ Resolver
 Resolver ve: IP del cliente + query
 Problema: resolver sabe todo

Oblivious DoH:
 Cliente → Relay → Resolver
 Relay ve: IP del cliente, pero query está encriptada al resolver
 Resolver ve: contenido de la query, pero no la IP del cliente
 ¡Nadie ve las dos cosas!

Análisis Honesto de Privacidad

Un análisis directo de qué aporta realmente cada capa:

Amenaza	DNS Plano	DoH/DoT	+ DNSSEC	+ ECH	+ ODoH
ISP ve dominios	Sí	No	No	No	No
Sniffing WiFi café	Sí	No	No	No	No
Spoofing DNS	Sí	No	No	No	No
Resolver ve queries	Sí	Sí	Sí	Sí	No
SNI filtra dominio	Sí	Sí	Sí	No	No
IP destino visible	Sí	Sí	Sí	Sí	Sí

Esa última fila es el elefante en la habitación. Incluso con el stack completo, cualquiera que pueda ver tu tráfico de red sabe la IP a la que te se está conectando. Para hosting compartido (como Cloudflare), la IP mapea a millones de sitios, así que no es muy revelador. Para sitios en IPs dedicadas, la IP de destino sola identifica el sitio.

Para el último leak restante, se necesita un proxy, VPN, o Tor. No hay solución a nivel DNS para eso.

El stack de privacidad descripto es sobre elevar el piso, hacer la vigilancia pasiva significativamente más difícil sin impactar dramáticamente la performance. No es sobre lograr anonimato perfecto. Si se necesita eso, se necesita Tor. Pero para privacidad cotidiana contra monitoreo del ISP, inspección de red corporativa, y sniffing de WiFi de cafetería, DoH + ECH + ODoH te lleva al 90% del camino con menos de 50ms de latencia agregada.

Stack de Privacidad DNS: DoH, DoT, DNSSEC, Encrypted Client Hello y Análisis Comparativo de Privacidad