Menú

Inicio

Todas las páginas

Apariencia

Ubicación:🇺🇸 Estados Unidos
Sitio principal gistwillan.top
Volver al blog
Seguridad DNS · 7 min

Dos tipos de protección DNS: DNSSEC para la integridad, DNS cifrado para la privacidad

Resuelven problemas distintos y se confunden todo el tiempo: uno demuestra que la respuesta no fue alterada, el otro esconde la pregunta. Ninguno hace las dos cosas.

Un bastidor de k.root-servers.net en AMS-IX
Wikimedia Commons · CC BY-SA 3.0 Wikimedia Commons

DNSSEC y el DNS cifrado se explican juntos como si fueran dos fases de lo mismo. Defienden de ataques completamente distintos: DNSSEC del manipulado, el DNS cifrado de la observación. Uno hace que una respuesta falsa no valide; el otro mantiene una respuesta correcta lejos de cualquiera en el camino. Los costes también difieren: uno convierte una firma caducada en un fallo total de resolución, el otro concentra tu registro de consultas en unas pocas empresas. Verlos por separado es cómo averiguas cuál necesita tu zona.

Cadena de confianza DNSSEC frente a un salto DNS cifrado
Uno demuestra que la respuesta no se alteró; el otro esconde la pregunta. Ninguno hace las dos cosas.

Activar DNSSEC es uno de los pocos cambios de DNS capaz de dejar un dominio entero fuera de línea para todos los visitantes a la vez, y de hacerlo de una forma que parece que el sitio no existe. El protocolo no es complicado; la parte operativa sí.

1. La cadena, en cuatro registros

La zona contiene un registro DNSKEY, la clave pública. Cada conjunto de registros de la zona lleva un RRSIG, una firma sobre esos datos hecha con la clave privada correspondiente. La zona padre publica un registro DS, que es un hash de tu DNSKEY, y eso es lo que enlaza tu zona con la cadena global. Un resolutor validador baja desde la raíz, comprueba el DS contra tu DNSKEY y luego cada RRSIG contra esa clave. Si falta un eslabón o ha caducado, la respuesta se rechaza.

La negación de existencia también se firma, con NSEC o NSEC3. Por eso DNSSEC demuestra además que un nombre no existe, lo que suena a detalle hasta que descubres que cambia ligeramente el comportamiento de comodines y nodos no terminales vacíos.

2. Quién firma importa más que qué firmas

La firma puede vivir en dos sitios: tu proveedor de DNS firma la zona y tú publicas el DS en el registrador, o el registrador hace las dos cosas. El fallo es siempre el mismo: el DS del padre no coincide con la clave que firma la zona. Ocurre al activar la firma en el host y olvidar el DS, al migrar de proveedor y dejar el DS antiguo, o cuando una rotación de claves sale mal en un solo lado.

Antes de activar nada, escribe qué lado posee el DS y quién puede cambiarlo. Si el host de DNS y el registrador son empresas distintas —lo normal— tienes un cambio en dos pasos que debe hacerse en el orden correcto, y ningún panel lo hará por ti.

3. Dos errores que causan casi todas las caídas

  • Publicar el DS antes de que la zona esté firmada. Falla de inmediato para todo resolutor validador, que hoy es casi todo internet. Hazlo al revés: firma, verifica con un validador y después publica el DS.
  • Firmas que caducan porque nadie las vigila. Una zona firmada con 30 días de validez y sin renovación automática se rompe el día 31, a la hora en que se generó la última firma. Pon la alerta en la caducidad de la firma, no en "DNSSEC activado".

4. Qué ve el usuario cuando se rompe

No una página de error útil. Los resolutores validadores devuelven SERVFAIL, el navegador lo traduce a un fallo de conexión genérico y el ticket dice "el sitio está caído" mientras tu origen está sano y tu monitor —que probablemente consulta sin validación o lee caché— informa que todo va bien. Prueba desde un resolutor que valide, como 1.1.1.1 o 8.8.8.8, y vuelve a probar tras cada cambio.

5. Rotación de claves, en breve

Una rotación de KSK significa publicar un DNSKEY nuevo, esperar al menos el TTL más la ventana de propagación y luego cambiar el DS en el padre. Hacer los dos pasos en el mismo minuto es la caída autoinfligida clásica. La rotación de ZSK es más barata y automatizable, por eso la mayoría automatiza ZSK y trata la KSK como una operación planificada. El algoritmo también importa: el 13 (ECDSA P-256) produce firmas mucho más pequeñas que el 8 (RSA/SHA-256) y tiene soporte amplio, así que hoy hay pocas razones para elegir el antiguo.

6. El equilibrio honesto

DNSSEC protege la integridad, no la privacidad: demuestra que la respuesta no fue modificada y no hace nada contra quien observa qué nombres consultas. A cambio añade un modo de fallo global, instantáneo y total, y dificulta la migración de proveedor porque el DS también tiene que moverse. Para un dominio cuya disponibilidad importa, es un coste real: vale la pena pagarlo, pero con monitorización ya montada.

El DNS en claro es una postal: cualquiera en el camino puede leer el destinatario, y la red a la que estás conectado ve cada dominio que consultas. Cifrarlo es una mejora obvia. Tampoco es la garantía de privacidad que se supone, porque la postal no se destruye: se reenvía a otro lector.

7. Qué cambian realmente DoH y DoT

DNS-over-TLS envuelve las consultas en una conexión TLS al puerto 853. DNS-over-HTTPS las envuelve en HTTPS sobre 443, lo que en la práctica las hace parecer tráfico web normal y sobrevivir a redes que bloquean el 853. En ambos casos la consulta y la respuesta van cifradas entre tu dispositivo y el resolutor, así que el operador de la red local —el wifi del hotel, el ISP, un colega con un capturador— ya no puede leer los nombres.

Eso es toda la ganancia, y es real. Lo que no cambia es quién responde. El resolutor sigue viendo cada nombre que pides, sigue viendo tu IP y puede correlacionarlos. No has eliminado al observador: lo has elegido.

8. El problema de la concentración

En la práctica casi todo el DNS cifrado va a un puñado de grandes operadores, porque el navegador los pone por defecto y nadie cambia los valores por defecto. Antes del cifrado, tus consultas se repartían entre el resolutor que asignara cada red. Después, una sola empresa puede ver una parte grande de la navegación de una persona en todas sus redes: cafetería, oficina, casa, móvil. Un registro que estaba fragmentado queda consolidado, y la consolidación es justo lo que preocupa a quien defiende la privacidad.

9. Las roturas de las que nadie avisa

  • El DNS de horizonte dividido deja de funcionar. Un nombre interno que solo resuelve dentro de la empresa no resuelve, o peor, resuelve a algo público cuando el navegador impone su propio resolutor DoH.
  • Los portales cautivos se rompen. El portal necesita secuestrar el DNS para mostrar el login; un navegador anclado a DoH solo dirá que no hay internet.
  • La política DNS de la VPN queda sorteada. Si el sistema o el navegador tienen su propio resolutor cifrado, el tráfico puede salir por el túnel mientras las consultas van por otro lado: una fuga de DNS literal, causada por la función que iba a mejorar la privacidad.
  • El filtrado desaparece. Control parental, bloqueo de malware y políticas corporativas operan sobre DNS. El DNS cifrado las anula o las obliga a inspeccionar certificados, que es peor.

10. El handshake TLS todavía te delata

Aunque la consulta vaya cifrada, el campo SNI del ClientHello anuncia el host al que te conectas en la mayoría de conexiones TLS actuales. Encrypted Client Hello cierra ese agujero, pero el soporte es parcial y requiere que servidor y cliente cooperen; en muchas redes el intermediario simplemente reinicia conexiones con ECH. Si la preocupación es que nadie sepa qué sitio abriste, el DNS cifrado por sí solo no llega.

11. El argumento de rendimiento es real, pero condicional

DoH suele sentirse más rápido que el DNS UDP en claro, lo que sorprende. La razón es la reutilización de conexión: la consulta viaja por la conexión HTTPS que el navegador ya tiene abierta al mismo resolutor, sin viaje extra ni penalización de arranque en frío. DoT gana igual si el cliente mantiene viva la sesión TLS. En frío, sin ninguna conexión, el DNS cifrado añade un handshake antes de poder responder nada.

12. Qué elegir, en la práctica

  • Elige el resolutor por política, no por benchmark. Decide si prefieres que las consultas vayan a tu ISP, a un gran operador o a un resolutor propio: son equilibrios distintos y el más rápido no es automáticamente el correcto.
  • Prefiere un resolutor con política publicada, auditoría y jurisdicción clara. "Cero registros" es una afirmación: busca la auditoría de terceros que la puso a prueba.
  • En una red que controlas, monta tu propio resolutor DoT por encima de los dispositivos. Conservas filtrado y nombres internos, y el salto al upstream sigue cifrado.
  • Deja una vía de respaldo. Una red que solo permite DNS por el resolutor local no está rota por diseño: suele ser un portal cautivo o una política. Falla cerrado en privacidad, falla abierto en conectividad.

La herramienta DNS de ipbox.one resuelve registros sobre DNS-over-HTTPS, y la página de inicio nombra el resolutor que respondió de verdad a tus consultas y si su país coincide con tu salida. Lo primero muestra si las firmas DNSSEC se están sirviendo; lo segundo, a quién entregó tus consultas el DNS cifrado.

Sigue leyendo