Resumen

  • El bit Authoritative Answer de DNS se refiere al nombre consultado o al primer nombre propietario de Answer; el destino de un alias, los registros de Authority, el glue y otros datos de Additional pueden proceder de ámbitos distintos.
  • Un recibo verificable separa cada RRset por propietario, tipo, sección, corte de zona, origen de caché y estado DNSSEC, y conserva las consultas posteriores en vez de transformar un bit de cabecera en autoridad o autenticidad para todo el mensaje.

Un resolvedor pregunta por tienda.example. El servidor es autoridad para ese nombre y responde con un CNAME. Tras él aparece una dirección del destino recuperada de caché. Additional incluye otra dirección útil para evitar una consulta inmediata. La cabecera lleva AA=1.

El registro operativo guarda el paquete en una sola fila y asigna autoritativo=true a todos sus RRsets. Cuando una respuesta directa de la zona de destino ofrece otra dirección, nadie puede reconstruir el desacuerdo. Se borró la diferencia entre la afirmación sobre el alias, el dato cacheado y la ayuda adicional.

El caso es hipotético. No atribuye un fallo a ningún servidor real; prueba los límites del modelo de datos.

La cabecera no contiene un mapa de autoridad

El RFC 1035, de Paul Mockapetris, define AA para las respuestas DNS. El servidor declara que es autoridad para el nombre de dominio de Question. Como una respuesta puede incluir varios propietarios debido a alias, el documento acota el bit al nombre que coincide con la consulta o al primer propietario de Answer.

Esa precisión impide una lectura cómoda pero falsa. AA no se repite junto a cada RRset. Describe el punto inicial de autoridad del servidor, no todas las jurisdicciones que un resolvedor puede atravesar dentro del mismo mensaje.

El RFC 1034 explica cómo se compone la mezcla. Al encontrar un CNAME en datos autoritativos, el servidor lo copia a Answer, sustituye QNAME por el nombre canónico y vuelve a empezar. Al hallar una delegación, copia los NS a Authority y agrega en Additional las direcciones disponibles, sean glue, datos autoritativos o caché. Al final puede adjuntar otros registros locales que considere útiles.

El resultado puede ser protocolariamente correcto y contener varias procedencias. La unidad de transporte no es una unidad automática de prueba.

La sección conserva contexto, no dicta confianza

Según RFC 1035, Answer contiene registros que responden; Authority orienta hacia servidores con autoridad; Additional aporta información relacionada que no constituye estrictamente la respuesta. Guardar la sección evita una primera pérdida. Aun así, dos RRsets de una misma sección pueden haber llegado por caminos diferentes.

La delegación lo muestra bien. El padre puede incluir como glue la dirección del servidor del hijo para romper una dependencia circular. Esa dirección es operativamente valiosa. No convierte al padre en autoridad para el espacio situado bajo el corte ni equivale a una afirmación emitida por la zona hija.

El RFC 2181 establece una jerarquía: datos de zona y transferencia sin glue; datos autoritativos de Answer; Authority de una respuesta autoritativa; glue; respuestas no autoritativas; y Additional. Un RRset autoritativo nuevo puede sustituir a uno antes aprendido en Additional. El segundo no debería desplazar al primero solo por estar en la caché.

Si la base elimina ese rango, la caché puede blanquear contexto. Una dirección auxiliar regresa después como Answer y parece haber ganado autoridad. Ningún paso del protocolo le concedió ese ascenso.

El alias cambia de jurisdicción

RFC 2181 advierte que, ante un alias, solo el registro que lo describe es necesariamente autoritativo. Los demás registros de Answer pueden proceder de caché. Si el cliente necesita autoridad para el nombre canónico, debe formular otra consulta.

El RFC 6604 confirma que una cadena CNAME o DNAME puede tener un estado autoritativo diferente en cada tramo. AA sigue basándose en el primer nombre propietario de Answer.

Un servidor de tienda.example puede declarar correctamente que ese nombre apunta a servicio.proveedor.test. También puede ofrecer una dirección cacheada para acelerar el camino. Esa ayuda no convierte la dirección en una respuesta autoritativa de la zona del proveedor. La consulta siguiente es otro acontecimiento con otro servidor y otro reloj.

Por eso el recibo debe modelar aristas: nombre de entrada, RRset de alias, zona, mensaje de origen, nombre siguiente y consulta que continuó la cadena. Almacenar solo la dirección final sirve para responder rápido, pero no para atribuir afirmaciones.

Ser autoridad no significa ser auténtico

RFC 6604 afirma que AA no está protegido por DNSSEC. TSIG o SIG(0) pueden autenticar la transacción con un servidor; las firmas DNSSEC y su cadena de confianza validan RRsets. Son controles separados.

El RFC 4035 define estados por RRset: Secure, Insecure, Bogus e Indeterminate. El resolvedor los determina mediante DNSKEY, DS, RRSIG, anclas de confianza y pruebas de negación. AA no produce ninguno de esos resultados.

AD tampoco es otro nombre para AA. Conforme a las reglas de DNSSEC, el servidor activa AD únicamente después de atribuir autenticidad a los RRsets relevantes de Answer y Authority. El cliente aún necesita confiar en el resolvedor y en el canal, o validar por sí mismo. Additional no queda mágicamente autenticado por la promesa resumida en la cabecera.

Así, un paquete puede tener AA correcto para el primer nombre, un CNAME Secure, un destino Insecure y glue no autenticado. El sistema debería poder expresar las cuatro cosas sin forzarlas a compartir color.

La contribución de Mockapetris y su límite

La semblanza del Internet Hall of Fame atribuye a Paul Mockapetris la invención de DNS en 1983 en el Information Sciences Institute de USC. Los RFC 1034 y 1035 documentan su autoría. La fotografía histórica pública de esa página sustenta la identidad del retrato editorial.

Nada de ello lo convierte en operador de un resolvedor actual, dueño de una zona o autoridad sobre una implementación moderna. Los RFC posteriores son productos colectivos. Sirven aquí porque preservan una idea arquitectónica: una red con autoridad distribuida necesita recibos que mantengan visible cada frontera.

Registrar RRsets, no colorear paquetes

El expediente comienza con QNAME, QTYPE, QCLASS, intención de recursión, opciones DO y CD, identificador y hora. Conserva después los bytes de la respuesta, endpoint, transporte, autenticación de transacción y momento de recepción.

Cada RRset obtiene su propia fila: propietario, tipo, clase, sección, TTL observado, corte de zona, bailiwick y origen conocido. Si el cliente no puede saber si el servidor usó zona o caché, debe marcar incertidumbre; no inferirlo a partir de AA.

La ancla de AA se guarda aparte: nombre inicial, primer propietario de Answer, servidor y zona. Cada CNAME, DNAME o referencia abre una relación hacia la consulta posterior. El NS del padre, su glue y la respuesta del hijo permanecen conectados, no fusionados.

La capa DNSSEC añade estado, firmas, ruta DS/DNSKEY, ancla, política y hora a cada RRset. El AD recibido se conserva como declaración del intermediario. Por último, la aplicación registra qué versión de caché consumió y qué decisión tomó.

La frase final ya no exagera: este servidor marcó AA para este nombre; este conjunto llegó en esta sección; este validador le asignó este estado; una consulta posterior estableció la autoridad del siguiente nombre; la aplicación usó este resultado. Un bit puede ser preciso si la organización deja de pedirle que certifique toda la respuesta.

Fuentes