Resumen

  • NXDOMAIN niega el nombre efectivo; NODATA deja vivo el nombre y niega únicamente el tipo pedido. Por eso el primero se guarda por nombre y clase, mientras el segundo necesita nombre, tipo y clase.
  • RFC 2308 convirtió el “no” en un dato transportable y finito. El SOA de la zona acompaña la respuesta y su duración negativa toma el menor valor entre el TTL del SOA y MINIMUM; agotado el contador, el resultado ya no puede reutilizarse.
  • DNSSEC y reglas posteriores permiten que una prueba validada cubra intervalos o descendientes. La eficiencia crece, pero también el daño potencial de una negación demasiado amplia o larga. Una firma DNS no es prueba de propiedad ni de inexistencia fuera del protocolo.

El paquete vacío no cuenta toda la historia

Supongamos que un cliente pregunta por el registro A de servicio.example y recibe una sección Answer vacía. Todavía no sabemos si el nombre falta, si sólo carece de A, si la respuesta es una referencia o si el servidor atraviesa una avería. Tampoco un timeout o SERVFAIL describe el contenido de la zona.

La distinción afecta a datos reales. Si una caché convierte la falta de A en inexistencia del nombre, puede ocultar MX, TXT o AAAA válidos. Si reduce una NXDOMAIN auténtica a la ausencia de A, repetirá preguntas por otros tipos aunque la autoridad ya haya negado el nombre completo.

NXDOMAIN es el Name Error del DNS. Se refiere al QNAME efectivo—después de cualquier CNAME—y a su clase. NODATA no posee un RCODE propio: se deduce de NOERROR, de la falta de una respuesta pertinente y de la información de autoridad que permite separarlo de una referencia.

La RFC 2308 traduce ese alcance a dos claves. NXDOMAIN se conserva como <QNAME, QCLASS>; NODATA como <QNAME, QTYPE, QCLASS>. El tipo adicional en la segunda clave protege todos los demás registros que sí pueden existir en el mismo nombre.

El alias no siempre es el nombre negado

Una cadena CNAME complica la identidad de la ausencia. El alias inicial puede existir y apuntar a un destino canónico inexistente. La NXDOMAIN pertenece al destino final, no al primer nombre que el usuario escribió.

Si el resolutor asocia la negación al alias por comodidad, extiende la prueba a un sujeto distinto. De modo semejante, una NODATA en el destino sólo niega el tipo consultado allí; no borra otros tipos del destino, datos del alias ni posibles descendientes.

El cuidado con QNAME muestra que la caché negativa no es simplemente una optimización. Es un sistema de evidencia distribuida: antes de compartir una conclusión, hay que conservar a quién se refiere.

De recordar un error a poder retransmitirlo

La RFC 1034 ya describía en 1987 la caché de respuestas negativas, aunque de manera opcional. Listas de búsqueda, errores repetidos y descubrimiento automatizado podían generar la misma consulta fallida muchas veces. Recordarla reducía latencia y tráfico.

El diseño original, sin embargo, no daba a un servidor una forma robusta de entregar a otro resolutor una negación almacenada con la misma prueba y el tiempo que aún le quedaba. La memoria podía funcionar dentro de una implementación, pero no viajaba limpiamente.

RFC 2308, publicada en marzo de 1998, cerró esa brecha. Si un resolutor guarda respuestas, debe guardar también las negativas. La autoridad que anuncia NXDOMAIN o NODATA incluye el SOA de la zona contenedora. Ese registro identifica el ámbito que habla y proporciona el reloj.

El TTL negativo es el menor entre el TTL propio del SOA y su campo MINIMUM. El SOA queda unido al resultado almacenado. Cada respuesta desde caché muestra un tiempo reducido; cuando llega a cero, la negación deja de ser utilizable.

Mark Andrews figura en RFC 2308 con afiliación a CSIRO. Es un dato de procedencia del autor, no el objeto institucional del artículo. El estándar compartido y sus extensiones posteriores se desarrollaron mediante el proceso documental del IETF.

El “no” que podía circular sin morir

El árbol de nombres no impide que los reenviadores formen bucles. Dos servidores pueden apuntarse mutuamente. Si cada uno recibe una respuesta negativa sin reloj transportable, le asigna un tiempo nuevo y vuelve a enviarla, la indicación puede sobrevivir para siempre.

RFC 2308 recomienda no almacenar negativas sin SOA. Una limitación local no limita nada si el siguiente nodo reinicia el contador. El SOA convierte el plazo en una propiedad de la evidencia compartida y no en una promesa renovable de cada intermediario.

La revisión también ordenó el significado de MINIMUM. La RFC 1035 lo había descrito como un mínimo para TTL. El uso real mezcló esa función con el valor por defecto y la vida de respuestas negativas. RFC 2308 separó el valor por defecto mediante $TTL, abandonó el mínimo universal y conservó MINIMUM como entrada del cálculo negativo.

El código llegó antes que una semántica limpia

La historia incluida en RFC 2308 recuerda el trabajo de CHIVES a finales de los años ochenta. Las rutas de búsqueda producían muchos fallos repetidos, y almacenar errores autoritativos alivió consultas costosas. También registra la evolución de BIND a comienzos de los noventa: distinguir NOERROR_NODATA de un error de nombre y, después, conservar el SOA con el resultado.

No es un censo ni una historia de inventor único. Es evidencia de que varias implementaciones chocaron con el mismo límite: “vacío” no era una categoría bastante precisa. La RFC 2181 ayudó a consolidar el lenguaje de RRsets; RFC 2308 convirtió la experiencia en un contrato interoperable.

El coste oculto de recordar

Una respuesta correcta envejece. Si se crea un nombre después de que un resolutor haya guardado NXDOMAIN, ese usuario continuará viendo inexistencia hasta que expire su entrada. Si se añade AAAA a un nombre que ya produjo NODATA para AAAA, la nueva conectividad puede quedar oculta mientras otros registros siguen visibles.

Un TTL largo ahorra consultas, pero prolonga la invisibilidad de una corrección. No mide la certeza de la negación. RFC 2308 permite topes locales y recoge que valores de una a tres horas funcionaban como predeterminados razonables, mientras más de un día había resultado problemático.

Los resolutores reciben el “no” a distintas horas y aplican políticas diferentes. No existe una medianoche universal en la que toda la Internet olvide. Para lanzar un nombre o tipo nuevo hay que estudiar las negativas anteriores y reducir su vida con anticipación.

Conviene mantener los fallos fuera de este modelo. Timeout, inaccesibilidad y SERVFAIL tienen tratamientos opcionales y mucho más acotados; no prueban inexistencia. Una aplicación que los traduce a NXDOMAIN puede transformar un incidente reversible en rechazo de correo, fallo de identidad o abandono de un servicio.

Una prueba capaz de abarcar más

DNSSEC añadió negaciones autenticadas. La RFC 4034 define NSEC, que enlaza nombres en orden canónico y enumera los tipos presentes en un propietario. La RFC 4035 explica cómo validar una prueba de NXDOMAIN o NODATA.

La criptografía conserva la diferencia. Un intervalo entre nombres demuestra que un nombre no aparece; el bitmap de tipos de un nombre existente demuestra que falta un tipo. La firma garantiza origen e integridad dentro de la cadena DNS, no una conclusión más amplia.

La RFC 5155 introdujo NSEC3 y Opt-Out. Un NSEC3 que cubre un intervalo no demuestra necesariamente que todos los nombres posibles estén ausentes cuando interviene Opt-Out.

La RFC 8020 permitió aprovechar NXDOMAIN para cortar consultas bajo un nombre inexistente, con límites definidos. NODATA no sirve para ello: un nombre sin A puede contener MX, TXT y descendientes.

La RFC 8198 habilitó el uso agresivo de NSEC y NSEC3 en cachés validadoras. El resolutor puede sintetizar una respuesta negativa para una consulta que nunca llegó a la autoridad. Se ahorran paquetes, pero una creación dentro del intervalo cubierto puede tardar en aparecer hasta que caduque la evidencia relevante.

Autoridad limitada, ejecución distribuida

El operador de zona decide el contenido y los temporizadores. El servidor autoritativo construye la respuesta. El resolutor la clasifica, valida, limita y olvida. La aplicación asigna consecuencias. Son poderes relacionados, no una sola soberanía.

Publicar NXDOMAIN puede afectar la accesibilidad. Validarlo impide aceptar pruebas falsificadas. Amplificarlo mediante caché afecta a muchos clientes. Ninguno de esos actos prueba que una persona, empresa o derecho deje de existir fuera del DNS.

El logro histórico fue dar forma limitada a la ausencia: un sujeto exacto, una clase de “nada”, una zona responsable y una fecha de caducidad. Separar NXDOMAIN de NODATA permitió ganar eficiencia sin convertir cada registro faltante en la desaparición del nombre.

Fuentes y límites

El diseño inicial y el SOA proceden de RFC 1034 y RFC 1035, con precisión sobre RRsets en RFC 2181. Las definiciones, claves, reloj y notas históricas están en RFC 2308. La negación autenticada se apoya en RFC 4034, RFC 4035 y RFC 5155; la regla de subárbol y la síntesis posterior en RFC 8020 y RFC 8198. Las capacidades modernas no se atribuyen a 1987 y el apéndice de implementación no se trata como medición total.