<!-- Canonical: https://lucioduran.com/es/blog/dns-over-https-encrypted-client-hello-privacy
Language: es
Content-SHA256: 2f14c35bc2365482def61723d70b854b70f20d119936019f9b3601c751e44993
-->

Networking

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

2026-01-084 min lectura

Lucio Durán
Engineering Manager & AI Solutions Architect

También disponible en: [English](<https://lucioduran.com/blog/dns-over-https-encrypted-client-hello-privacy>)

## 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:

```bash
# 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 `](<https://github.com/DNSCrypt/dnscrypt-proxy>):

```toml
# /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](<https://cloudflare.com/>)), 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.

## Preguntas frecuentes

### ¿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.

## Tips

1. **Tip:** DoH protege las queries DNS de tu ISP, pero tu resolver (Cloudflare, Google) todavía ve todo. Si se necesita privacidad DNS real, ejecutar ` Oblivious DoH ` a través de un relay, ni el relay ni el resolver pueden vincular la IP con las queries.
2. **Tip:** Encrypted Client Hello (ECH) es la pieza faltante que DoH solo no puede resolver. Sin ECH, el SNI en el TLS ClientHello todavía filtra a qué dominio te se está conectando, incluso si las queries DNS están encriptados. Verificar en el navegador ` about:config ` por ` network.dns.echconfig.enabled `.
3. **Tip:** DNSSEC valida que los registros DNS no fueron adulterados, pero NO encripta nada, las queries y respuestas siguen siendo visibles para observadores en el path. Se necesita tanto DNSSEC (integridad) como DoH/DoT (confidencialidad) para protección completa.

- dns
- privacidad
- doh
- dot
- dnssec
- ech
- encrypted-client-hello
- networking
- seguridad

[Volver al Blog](<https://lucioduran.com/es/blog>)