DNS: resolución, delegación, caché y confianza

Un nombre no es una respuesta, y una respuesta no es todavía confianza

Durante una migración, una organización mantiene api.northstar.example en dos vistas. Los clientes internos deben obtener 10.20.8.14; los externos, 203.0.113.14. El lunes, el equipo cambia la delegación pública y observa tres síntomas: un resolver recursivo devuelve la dirección antigua durante varios minutos, otro devuelve SERVFAIL, y una consulta directa al servidor autoritativo devuelve una respuesta con AA. ¿Cuál de esas observaciones describe el estado de la zona? ¿Cuál describe una copia en caché? ¿Cuál permite afirmar que el dato es auténtico?

DNS (Domain Name System) separa varias decisiones que suelen comprimirse en la frase «resolver un dominio»: recorrer un espacio de nombres, seguir delegaciones, consultar un servidor autoritativo, reutilizar una caché y, si procede, validar una cadena DNSSEC. Cada decisión tiene un actor, una fuente y un alcance distintos. Un AA dice que el servidor declara autoridad para la respuesta; no dice que el cliente haya validado su origen. Un TTL limita durante cuánto tiempo un dato puede reutilizarse según las reglas de caché; no es una orden instantánea de borrado. NXDOMAIN y una respuesta sin registros del tipo solicitado tampoco son sinónimos.

Este capítulo construye un modelo operativo para hacer esas distinciones. El caso de Northstar es sintético, pero sus problemas son los de una investigación real: la misma pregunta puede cruzar stub resolver, forwarder, resolver recursivo, raíz, TLD, zona delegada, caché negativa, split-horizon y validación DNSSEC. Las fuentes normativas históricas siguen siendo esenciales, pero RFC 2308 actualiza partes de RFC 1034/1035, RFC 4033–4035 define DNSSEC, RFC 7766 actualiza el uso de TCP y RFC 8020 aclara el NXDOMAIN cut. El texto indica cuándo una afirmación es norma, implementación, práctica operativa o inferencia.

El espacio de nombres y la frontera de una zona

Alcance: glue aporta alcanzabilidad, no autenticidad.

El espacio de nombres DNS es un árbol de etiquetas que termina en la raíz .. Un nombre absoluto se puede escribir con el punto final: api.northstar.example.. El punto no es decoración: expresa que la secuencia llega a la raíz. Las etiquetas forman una jerarquía de nombres, pero una jerarquía de nombres no determina por sí sola quién administra cada dato. RFC 1034 §§3–3.3 describe el árbol y los nodos; RFC 1034 §3.6 y RFC 1035 §§3.2–3.3 describen los resource records (RR) que asocian datos tipados con nombres. RFC 1034, §§3–3.3 y §3.6; RFC 1035, §§3.2–3.3

Una zona es una porción administrativamente servida del árbol. Puede abarcar northstar.example. y contener un nodo delegado, prod.northstar.example., sin contener los datos autoritativos de ese subárbol. En el padre aparece la delegación mediante un RRset NS en prod.northstar.example.; el hijo comienza en su propio apex, con su SOA y su RRset NS. La frontera de zona, no el número de etiquetas, determina qué servidor es autoritativo para qué parte. Un dominio puede contener varias zonas y una zona puede contener muchos nombres.

En el borde de una delegación, el servidor del padre no entrega normalmente los A o AAAA de todos los nombres del hijo. Entrega un RRset NS que indica los servidores del hijo y, cuando el nombre de esos servidores está dentro del propio hijo, puede entregar glue: direcciones necesarias para alcanzar esos servidores sin caer en una dependencia circular. Glue es información de alcance de la delegación; no es una prueba criptográfica de que una dirección sea correcta. Una discrepancia entre glue, datos del hijo, caché y DNSSEC es un problema de consistencia o validación que debe adjudicarse con consultas y versiones concretas.

En Northstar, la delegación pública de northstar.example. puede señalar ns1.dns-provider.example. y ns2.dns-provider.example.. Si el servidor se llamara ns1.prod.northstar.example., el padre necesitaría glue para que un resolver pudiera obtener la dirección inicial del servidor del hijo. Que el resolver llegue a una dirección glue demuestra alcanzabilidad del siguiente paso, no que ese servidor haya sido autenticado como fuente legítima.

Tres funciones que no conviene llamar simplemente «el DNS»

Un stub resolver es el componente local que expone una interfaz al proceso —por ejemplo, una biblioteca o un servicio local— y reenvía la pregunta a uno o varios servidores configurados. Puede mantener una caché pequeña o no tenerla; no se debe suponer que realiza recursión completa. Un resolver recursivo acepta preguntas de clientes y, cuando no tiene una respuesta reutilizable, sigue la cadena de servidores, conserva resultados en caché y puede validar DNSSEC. Un servidor autoritativo sirve datos de una o más zonas para las que está configurado como autoridad; puede además ofrecer recursión, pero esa combinación es una propiedad de implementación y configuración, no una definición de autoridad.

La diferencia entre iterative y recursive resolution describe una relación de consulta, no una especie permanente de máquina. En una consulta iterativa, el servidor responde con el mejor dato que conoce, a menudo una delegación, y el solicitante continúa. En una consulta recursiva, el servidor consultado asume la tarea de continuar y devuelve una respuesta final o un error. RFC 1034 presenta ambos modos y RFC 1035 fija los mensajes; la separación de funciones ayuda a no atribuir a un servidor autoritativo la caché de un resolver o a un stub el trabajo de recorrer la raíz. RFC 1034, §§2.3, 4.3–4.3.2; RFC 1035, §§4–7

Una resolución típica, omitiendo reintentos y políticas locales, sigue esta secuencia:

aplicación → stub → resolver recursivo R
                         │ cache miss
                         ├─ raíz: delegación a .example
                         ├─ .example: delegación a northstar.example
                         └─ autoritativo: RRset de api.northstar.example
                         │ valida, almacena con TTL y responde
aplicación ← stub ← R

La respuesta no tiene que recorrer toda la jerarquía en cada solicitud. El resolver puede tener en caché la delegación, la dirección de un servidor autoritativo, el RRset final, una respuesta negativa o material DNSSEC. Por eso dos clientes pueden obtener resultados distintos sin que el servidor autoritativo haya cambiado entre ambas consultas: usan resolvers, vistas o edades de caché diferentes. Una captura de R tampoco representa todos los clientes; muestra un punto de observación y una población concreta.

RRsets: la unidad que se consulta y se firma

Un RR contiene nombre propietario, clase —normalmente IN—, tipo, TTL y RDATA. El dato profesionalmente útil suele ser el RRset: todos los RR de la misma clase, nombre y tipo que una respuesta presenta como conjunto. A y AAAA expresan direcciones IPv4 e IPv6; NS servidores autoritativos para una zona o delegación; SOA parámetros del apex de zona, incluidos serial y temporizadores; MX intercambio de correo; SRV servicio y puerto; TXT datos de texto sin significado universal. La presencia de un TXT no convierte su contenido en una política de seguridad.

Los RRset y sus TTL deben tratarse como unidades: mezclar miembros con edades o procedencias incompatibles puede crear una imagen que ningún servidor autoritativo publicó. RFC 2181 explica la noción de RRset y el alcance de datos autoritativos; RFC 4034 añade RRSIG, DNSKEY, DS y NSEC como registros usados por DNSSEC, no como tipos que una aplicación deba consumir como direcciones. RFC 2181, §§5.2, 5.4.1; RFC 4034, §§3–6

CNAME hace que un nombre sea un alias para otro nombre. La respuesta exige resolver el objetivo y, en la zona, un propietario con CNAME no debe combinarse con otros datos ordinarios. Eso no crea una dirección ni una autorización, y el objetivo puede estar en otra zona o tener un TTL independiente. DNAME expresa una redirección de un subárbol a otro sufijo; no es un CNAME comodín para el mismo nodo. El uso de cualquiera de ellos añade una transición y otra posible caché, delegación o validación. RFC 1034, §3.6.2; RFC 6672, §§2–3

Delegación y resolución trabajadas

Alcance: una respuesta observada pertenece a su actor, vista y momento.

Supongamos que el resolver R recibe A api.northstar.example. con el bit de recursión deseado. No conoce el RRset, pero sí tiene en caché los servidores de la raíz. Pregunta a uno de ellos y recibe una delegación hacia .example.. Luego pregunta a un servidor del TLD y recibe una delegación hacia northstar.example.. Esa respuesta contiene el RRset NS del hijo y glue si las direcciones de los NS son necesarias para alcanzar la siguiente etapa. Finalmente, R pregunta a un servidor autoritativo de la zona y recibe el RRset A, o un CNAME que obliga a resolver su objetivo.

La palabra autoridad tiene dos sentidos que conviene separar. En el protocolo, el bit AA marca una respuesta que el servidor presenta como autoritativa para el nombre y tipo relevantes, de acuerdo con las reglas de respuesta. En una investigación de confianza, la autenticidad de los datos requiere una cadena de evidencia: configuración de la zona y, si se reclama autenticidad criptográfica, validación DNSSEC. Un resolver puede recibir AA de un servidor mal configurado, comprometido o simplemente no incluido en la cadena que el cliente confía. AA no sustituye a la validación del origen.

El resolver puede responder desde caché sin contactar al servidor autoritativo. Debe decrementar el TTL restante al reutilizar un RRset, respetar la semántica de la respuesta negativa y conservar datos relacionados sólo dentro de las reglas de seguridad y alcance de su implementación. En un servidor recursivo con forwarding, la cadena visible puede empezar en otro resolver corporativo; el cliente final no observa raíz, TLD ni autoridad aunque la respuesta tenga el mismo formato.

TTL, caché y respuestas negativas

Alcance: TTL no es una purga sincronizada de todas las capas.

El TTL es una indicación de cuánto tiempo un RR puede permanecer reutilizable en una caché. Al llegar a cero, el resolver ya no debe usarlo como respuesta fresca según las reglas normales; durante ese intervalo puede servir el valor anterior mientras otros resolvers ya ven el nuevo. El TTL no ordena borrar copias distribuidas en cada implementación ni garantiza que todas las aplicaciones dejen de usar un valor; bibliotecas, caches de sistema, proxies y productos pueden añadir capas con políticas propias. El origen controla un compromiso entre coste de consultas, rapidez de actualización y frescura, no una eliminación sincronizada. RFC 1034, §2.2; RFC 1035, §§3.2.1, 7

La caché negativa guarda también la conclusión de que una consulta no produce el tipo o nombre solicitado. RFC 2308 distingue al menos dos casos que un diagnóstico debe conservar:

• NXDOMAIN: el servidor afirma que el nombre consultado no existe en el espacio de nombres correspondiente. No equivale a «existe pero no tiene un A».
• NODATA: el nombre existe o su existencia está demostrada, pero no hay RRset del tipo solicitado. Se expresa normalmente como NOERROR con una sección de respuesta vacía y evidencia apropiada en autoridad.

El TTL de una respuesta negativa se calcula, conforme a RFC 2308 §5, como el menor entre el TTL del registro SOA y el campo MINIMUM de ese SOA, sujeto a que la respuesta contenga la evidencia de autoridad y a los límites/política del resolver. Si se observa NXDOMAIN, la conclusión debe fijar QNAME, QTYPE, vista y momento. RFC 8020 permite a un resolver que recibe una respuesta NXDOMAIN válida inferir el NXDOMAIN cut: nombres descendientes bajo ese punto también son inexistentes para esa vista, hasta que cambie la evidencia. Es una optimización y una regla de caché para un resolver, no una equivalencia entre NXDOMAIN y NODATA, ni una prueba de que todos los clientes compartan ese conocimiento. RFC 2308, §§3–5; RFC 8020, §§2–3

Un positivo y un negativo deben tener controles simétricos. Para sostener «el nombre no existe», hay que comprobar la autoridad y la vista, comparar A, AAAA y otros tipos relevantes, revisar la caché y verificar DNSSEC cuando esté disponible. Para sostener «no hay A», no basta con una respuesta vacía: hay que distinguir NODATA, SERVFAIL, timeout, REFUSED y una búsqueda que nunca alcanzó la zona correcta.

DNSSEC autentica datos; no cifra consultas

DNSSEC añade autenticación de origen de datos e integridad de los RRset mediante firmas digitales. Una validación correcta permite comprobar que el RRset y, cuando corresponde, la prueba de inexistencia se encadenan desde una clave confiable. La cadena usa DS en el padre, DNSKEY en el hijo y RRSIG sobre el RRset; NSEC o NSEC3 pueden probar la ausencia de un nombre o tipo. DNSSEC no oculta QNAME, QTYPE, respuesta, identidad del resolver ni el momento de la consulta: no proporciona confidencialidad.

El validador necesita un trust anchor configurado fuera de la respuesta que está validando. La raíz suele ser el punto inicial, pero una organización puede instalar anclas para una zona privada. Si la cadena es segura y la firma no valida, el dato es bogus; si el dominio no publica una delegación segura, puede ser insecure según las reglas de la cadena. Un resolver que no valida no puede convertir una respuesta sin firma en autenticada por declarar AA. RFC 4033–4035 separa datos seguros, inseguros y bogus y especifica cómo el resolver valida; el bit AD, cuando aparece, es una señal del resolver validado a su cliente y debe interpretarse dentro de su política, no como una propiedad mágica de todo paquete DNS. RFC 4033, §§2–5; RFC 4034, §§3–6; RFC 4035, §§3–5

El fracaso de validación suele presentarse como SERVFAIL, porque el resolver no debe entregar como respuesta válida un RRset que no puede autenticar. El mismo código también puede aparecer por timeout, fallo de transporte, ciclo o error del servidor; una implementación puede producirlo además por una política propia. Por eso el RCODE no adjudica por sí solo «DNSSEC roto» ni demuestra una causa normativa concreta. Hay que observar el motivo del resolver, repetir con y sin el camino de validación sólo en un entorno controlado, y comparar la respuesta directa de la autoridad con la cadena DS/DNSKEY/RRSIG y su periodo de validez.

UDP, TCP, EDNS(0) y truncation como parte del diagnóstico

DNS usa UDP y TCP según el transporte y el tamaño o estado de la transacción. EDNS(0) permite anunciar capacidades y una carga UDP mayor que el límite histórico; no elimina la posibilidad de fragmentación, pérdida, filtrado o respuesta truncada. El bit TC significa que la respuesta se truncó y que el cliente necesita otro intercambio, normalmente por TCP. RFC 7766 actualiza el requisito operativo: las implementaciones DNS deben soportar TCP y los resolvers deben poder reintentar de manera coherente; la conexión persistente es una optimización de implementación, no un cambio en el significado de la zona. RFC 6891, §§4–6; RFC 7766, §§3–6

Una respuesta UDP pequeña no demuestra que la autoridad no tenga más datos. Un TC=1 sin reintento puede producir un error en el stub, mientras que el mismo nombre funciona para un resolver que abre TCP. Del mismo modo, ver TCP no prueba que la respuesta sea DNSSEC válida; transporte, autoridad y autenticidad son propiedades distintas. Este capítulo usa truncation para explicar el flujo de resolución, no para repetir el modelo general de UDP del capítulo 30.

Bailiwick: límite operativo, no autenticación universal

Un resolver debe evitar aceptar sin restricciones datos adicionales que un servidor no está autorizado a introducir en la delegación o en la respuesta que está procesando. La práctica llamada bailiwick checking limita qué nombres y secciones adicionales se consideran pertinentes al dominio de la consulta. Su objetivo es reducir inyección y contaminación de caché; el alcance exacto depende del algoritmo, la implementación y la política. RFC 5452 documenta la necesidad de restringir autoridad, puerto, identificadores y datos relacionados al mitigar respuestas forjadas, pero no convierte una heurística de bailiwick en una firma.

Bailiwick no prueba que un dato sea correcto fuera de su contexto y no sustituye a DNSSEC. Un resolver puede rechazar un glue fuera de alcance y aun así recibir un RRset autorizado pero no firmado; puede aceptar datos dentro del alcance sintáctico y después fallar validación. El claim correcto es «este resolver aplicó esta política a esta respuesta», no «bailiwick garantiza la seguridad del DNS». RFC 5452 §6 exige limitar la aceptación a registros dentro del dominio pertinente y §9.1 precisa el matching de respuestas. RFC 5452, §§6 y 9.1

El mismo cuidado se aplica a amplification/reflection. Una respuesta DNS puede ser bastante mayor que la pregunta, en especial con RRsets grandes o DNSSEC, y el abuso requiere precondiciones: capacidad de falsificar el origen o inducir tráfico hacia una víctima, un servidor que responda a consultas no autorizadas o una ruta que permita convertir respuestas en reflexión, además de una relación de tamaños y una política de acceso concreta. No todo servidor autoritativo ni todo uso de UDP es automáticamente un amplificador explotable. RFC 5358 recomienda impedir que resolvers abiertos se usen como reflectores; la mitigación debe evaluarse junto con ACL, rate limiting, límites de respuesta y observaciones del operador. RFC 5358, §§1–3

Northstar: adjudicar caché, split-horizon y confianza

Northstar mantiene una vista interna para la red 10.20.0.0/16 y una vista pública. La pregunta es siempre A api.northstar.example.; la respuesta depende del resolver al que llega, de su caché y de la política de vista.

Desliza horizontalmente para consultar todas las columnas.

La investigación comienza por fijar QNAME, QTYPE, clase, bits RD/DO, resolver, vista, hora y respuesta completa. Después compara cuatro planos:

1. Autoridad y delegación: RRset NS del padre, glue vigente, SOA y serial del hijo. Una delegación correcta no demuestra que el RRset final esté actualizado.
2. Caché: TTL restante, respuesta positiva o negativa, edad y si el resolver aplicó NXDOMAIN cut. No se debe inferir que el TTL cero purgó aplicaciones que ya tenían el valor.
3. Vista: origen de la consulta, ACL o política de split-horizon, zona servida y diferencias entre resolvers internos, forwarders y públicos.
4. Validación: DS, DNSKEY, RRSIG, periodo de firma, prueba de inexistencia y trust anchor. AA se registra, pero no reemplaza la validación.

Los controles positivos consultan el mismo QNAME/QTYPE desde dos resolvers y comparan una respuesta autoritativa directa con una respuesta recursiva. Los controles negativos cambian una sola dimensión: pedir AAAA cuando sólo existe A, consultar un nombre deliberadamente inexistente y repetir después de que expire la caché negativa. Un control de transporte fuerza una respuesta suficientemente grande para observar TC y comprueba si el camino TCP completa la misma consulta. Ningún control convierte la observación de un resolver en un censo de clientes.

Errores de resolución y su significado limitado

NOERROR describe el código de respuesta, no la existencia de un RRset del tipo pedido. Puede llevar datos positivos, una respuesta NODATA o una delegación según el contexto. NXDOMAIN afirma inexistencia del nombre para la autoridad y la vista que responde. SERVFAIL indica que el servidor no pudo producir una respuesta válida para la consulta; sus causas son múltiples. REFUSED expresa rechazo por política o autorización, no inexistencia. Un timeout no es un código DNS y no distingue por sí solo pérdida, filtrado, servidor saturado, fallo de ruta o espera de reintento TCP.

Una observación de NXDOMAIN de un resolver caché es una observación sobre su estado y sus fuentes, no una prueba de que la zona autoritativa nunca haya tenido el nombre. Una observación de NODATA no permite concluir que una aplicación no esté disponible: puede usar AAAA, CNAME, SRV u otra vista. La transferencia profesional exige mantener QTYPE, resolver, hora y evidencia de autoridad en el claim.

Lo que este modelo impide afirmar

• «El TTL garantiza que el cambio se propague»: limita reutilización de una copia según la caché; no sincroniza todas las capas ni invalida consumidores que ya usaron el dato.
• «NXDOMAIN y NODATA son lo mismo»: uno niega el nombre; el otro niega el tipo solicitado bajo un nombre que puede existir.
• «AA autentica el origen»: marca autoridad declarada; DNSSEC requiere una cadena validada por un trust anchor.
• «DNSSEC cifra las consultas»: autentica datos e integridad, no confidencialidad del transporte.
• «Bailiwick evita todo poisoning»: reduce aceptación de datos fuera de contexto; su cobertura es una práctica de resolver, no una garantía universal.
• «Cualquier respuesta grande es amplification»: el abuso requiere precondiciones de spoofing, exposición, relación de tamaños y política de respuesta.
• «El resolver observado representa a todos los clientes»: split-horizon, forwarders, caches, rutas y políticas crean poblaciones distintas.
• «SERVFAIL demuestra un fallo de DNSSEC»: es compatible con DNSSEC bogus, pero también con otros fallos y políticas.
• «Un CNAME devuelve la dirección final»: introduce otro nombre y otra resolución; el objetivo puede fallar o cambiar de zona.

Transferencia profesional

Ante «la aplicación no encuentra api.northstar.example», escribiría primero: «El stub S, a las 14:05 UTC, recibió SERVFAIL para A desde el resolver R; R registró validación bogus para la vista pública; la autoridad N respondió AA con A=203.0.113.14 en una consulta directa; aún no se ha establecido si R consultó a N en esa ventana ni si la cadena DS/DNSKEY/RRSIG coincide». Ese claim separa observación, inferencia y límite.

La siguiente prueba no es «probar otro DNS» sin control. Es repetir la misma pregunta desde un resolver no recursivo y uno validado, recoger la delegación y el RRset completo, comparar serial y TTL, y reconstruir la cadena DNSSEC. Si la hipótesis es split-horizon, se cambia sólo el origen de consulta y se verifica qué vista se seleccionó. Si la hipótesis es caché negativa, se espera la expiración calculada o se consulta un resolver limpio, sin llamar a ese resultado «propagación global».

La competencia transferible es tratar DNS como una composición de datos, autoridad, caché y política. Un nombre no es una dirección; una dirección no es una identidad; una respuesta autoritativa no es una autenticación; y un resolver no es una ventana universal. Cuando se fijan QNAME, QTYPE, vista, actor, tiempo y cadena de confianza, los errores dejan de ser etiquetas genéricas y se convierten en hipótesis que una evidencia concreta puede apoyar o refutar.

Síntesis

El árbol DNS distribuye nombres y datos mediante zonas y delegaciones. El padre publica NS y puede necesitar glue; el hijo sirve sus RRsets autoritativos. Stub, resolver recursivo, servidor autoritativo y cliente iterativo cumplen funciones distintas, aunque una implementación pueda combinarlas. El resolver reduce coste mediante caché positiva y negativa: TTL controla frescura reutilizable, NXDOMAIN no es NODATA y RFC 8020 permite una optimización de corte para subárboles inexistentes.

DNSSEC ofrece autenticación de origen e integridad cuando el validador construye una cadena hasta un trust anchor; no cifra. UDP, EDNS(0), truncation y TCP cambian el camino de transporte, no el significado de autoridad. Bailiwick reduce datos fuera de contexto, pero no reemplaza firmas. Split-horizon y capas de caché hacen que una respuesta observada sea siempre una afirmación sobre un actor, una vista y un instante. Esa precisión es la diferencia entre «DNS está mal» y un diagnóstico que puede sostenerse.

Problema de transferencia

Después de delegar payments.northstar.example., clientes internos reciben 10.20.9.17, clientes externos reciben NXDOMAIN, y un resolver público devuelve SERVFAIL sólo cuando activa la validación DNSSEC. Una consulta directa al servidor hijo devuelve CNAME checkout.cdn.example. con AA; una consulta al padre muestra el nuevo RRset NS, pero una vista de monitorización conserva glue antiguo.

Redacta una adjudicación que distinga zona padre, zona hija, glue, caché positiva y negativa, split-horizon y cadena DNSSEC. Explica qué observaciones discriminarían NODATA de NXDOMAIN, qué prueba comprobaría que el CNAME fue seguido, y por qué AA, TTL cero o una única respuesta de resolver no bastan para afirmar disponibilidad o autenticidad globales.