Resumen
- NXDOMAIN niega la existencia del nombre; NODATA niega sólo el tipo solicitado en un nombre que puede existir. Por eso no comparten la misma clave de caché.
- RFC 2308 exige que el SOA de la zona acompañe a las negativas autoritativas. El menor valor entre el TTL del SOA y
MINIMUMdesciende hasta cero, momento en que la respuesta ya no puede reutilizarse. - Una negativa sin SOA no debe almacenarse: en un bucle de reenviadores, cada servidor podría reiniciar una vida corta y mantener el error circulando para siempre.
- NSEC, NSEC3 y la caché agresiva permitieron después validar y reutilizar pruebas sobre intervalos. Esa autenticidad técnica no demuestra propiedad, legitimidad institucional ni una ausencia eterna.
El coste del nombre que nunca responde
Una búsqueda fallida puede repetirse más que una búsqueda correcta. Los sufijos de búsqueda prueban variantes, el software de descubrimiento insiste y miles de usuarios cometen el mismo error tipográfico. Si el resolutor no puede guardar el resultado, cada intento recorre de nuevo la jerarquía.
No basta con guardar «no obtuve datos». Un timeout puede ser pérdida de red. SERVFAIL indica que el servidor no logró completar la respuesta. Una sección vacía puede remitir hacia otra autoridad. La ausencia reutilizable necesita un hablante competente, una materia exacta y una fecha de caducidad.
RFC 1034 ya describía en 1987 la caché de respuestas negativas como opción. Una respuesta autoritativa de error de nombre podía llevar tiempo de vida. Era coherente con la economía de DNS: copiar cerca del cliente reduce el trabajo global, mientras la fuente fija cuánto tiempo soporta la posible obsolescencia.
Pero aquel diseño no permitía entregar bien una negativa almacenada a otro resolutor conservando la evidencia y su edad. La memoria funcionaba localmente; su límite no viajaba con suficiente precisión.
Un nombre ausente no es un tipo ausente
NXDOMAIN es el RCODE Name Error. Afirma que el nombre efectivo no existe en la clase consultada. Si una cadena CNAME conduce a un destino inexistente, la negación se refiere a ese destino final, aunque el alias inicial sí exista. La entrada se recupera por nombre y clase.
NODATA no tiene código propio. Se deduce de NOERROR, la falta del dato pedido y una sección de autoridad que permite distinguir la respuesta de una delegación. Un nombre puede tener MX, TXT o AAAA y carecer de A. La entrada se almacena por nombre, tipo y clase.
La diferencia protege datos positivos. Si una ausencia de A se guardara como NXDOMAIN, el caché silenciaría también el MX real. La optimización sólo es correcta cuando conserva el alcance de la afirmación original.
Una negativa con reloj de zona
RFC 2308, publicado en marzo de 1998, fue escrito por Mark Andrews mientras estaba afiliado a CSIRO, incorporando así a una institución pública australiana de investigación a la genealogía documental de esta regla operativa del DNS. IETF aportó el foro de normalización donde el contrato y las mejoras posteriores de DNSSEC se convirtieron en especificaciones compartidas. Los papeles institucionales son distintos: CSIRO está vinculado aquí porque es la afiliación del autor consignada en la especificación decisiva; el proceso de IETF convirtió el texto en un contrato común de Internet.
Cuando un servidor autoritativo responde NXDOMAIN o NODATA, debe incluir el SOA de la zona contenedora en la sección de autoridad. Ese registro identifica el contexto que puede hablar de la ausencia y porta el tiempo para recordarla. El TTL negativo es el mínimo entre el TTL del propio SOA y el campo MINIMUM.
El resolutor guarda el SOA junto con el resultado. Al contestar desde caché descuenta el tiempo transcurrido. Cuando el contador llega a cero, la negativa no puede volver a usarse. Ya no es una verdad intemporal, sino una licencia temporal para repetir lo que la zona dijo recientemente.
La norma también ordenó la semántica de MINIMUM. RFC 1035 lo había definido como límite inferior de los TTL exportados; la práctica lo usó además como valor por defecto y tiempo negativo. RFC 2308 deprecó el primer sentido, añadió $TTL para los valores omitidos en ficheros de zona y conservó MINIMUM como entrada del TTL negativo.
Por qué una vida corta podía volverse infinita
La jerarquía de nombres forma un árbol, pero el camino de consultas puede cerrar un ciclo. Dos servidores configurados como reenviadores mutuos son el ejemplo más sencillo. Una delegación defectuosa puede producir variantes.
Imaginemos que cada uno almacena una negativa sin SOA durante diez minutos. Al enviarla al otro, el receptor crea una entrada nueva con otros diez minutos. El límite pertenece a cada copia y se reinicia; la indicación puede sobrevivir para siempre.
RFC 2308 dice por eso que una negativa sin SOA no debería almacenarse. El TTL que acompaña al SOA se reduce en la cadena y no vuelve a nacer. En un sistema distribuido, un límite que no se conserva durante la transmisión no limita el poder de la información.
El código llegó antes que la síntesis normativa
La historia incluida en RFC 2308 sitúa en 1987 el uso de caché negativa por CHIVES. Las listas de búsqueda generaban consultas inexistentes, y durante la congestión de ARPANET las pocas máquinas que ejecutaban aquel resolutor observaron una mejora apreciable. Es evidencia de implementación, no una estadística universal.
El apéndice también recuerda BIND 4.9.2 ALPHA en 1993. Una fase usó diez minutos y distinguió NXDOMAIN de NOERROR_NODATA; otra conservó el SOA para devolver contexto con la negativa. El acuerdo común surgió de esas fricciones: claves diferentes, evidencia portable y un contador que nadie pudiera rejuvenecer.
Recordar la ausencia retrasa la aparición
La mejora es inmediata: menos paquetes, menos trabajo autoritativo y respuestas fallidas más rápidas. La deuda aparece cuando el operador crea un nombre o añade el registro que faltaba. Los resolutores que guardan el «no» anterior continúan ocultando la novedad hasta que caduque.
No todos los cachés recibieron la negativa a la vez. Algunos limitan localmente el TTL. La recuperación se extiende como una distribución de edades, no como un instante global. RFC 2308 considera razonables por defecto entre una y tres horas y problemáticos los valores superiores a un día, aunque el campo pueda codificar mucho más.
También importa la decisión de la aplicación. El RFC advierte que un NXDOMAIN inyectado puede hacer rebotar correo inmediatamente, mientras una dirección equivocada puede mantenerlo en cola. Confundir una caída con inexistencia permite que una optimización de red provoque una acción irreversible.
La prueba firmada ocupa más espacio lógico
DNSSEC añadió negación autenticada. NSEC enlaza nombres existentes en orden canónico y enumera tipos presentes; las reglas de RFC 4035 permiten validar si un intervalo demuestra que falta un nombre o si un propietario carece de un tipo.
La enumeración era un coste de NSEC. RFC 5155 introdujo NSEC3 con nombres hash y la opción Opt-Out. Un registro NSEC3 con Opt-Out no afirma la existencia ni la inexistencia de todas las delegaciones inseguras que cubre. El hueco no puede borrarse del razonamiento.
RFC 8020 formalizó después el corte NXDOMAIN: si un nodo no existe, tampoco pueden existir sus descendientes en el árbol DNS. NODATA no produce ese efecto, porque el nombre puede existir con otros tipos y con hijos.
RFC 8198 permitió a un resolutor validador sintetizar una negativa para una consulta nueva cuando ya conserva evidencia NSEC o NSEC3 suficiente. La prueba deja de corresponder a una sola pregunta exacta y cubre una región. Baja la carga, pero aumenta el daño temporal si aparece un nombre nuevo dentro de esa región antes de caducar la evidencia.
La firma demuestra origen e integridad dentro de la cadena DNS. No prueba que la organización deba desaparecer, que el titular no tenga derecho al nombre ni que una zona válidamente firmada sea infalible.
Fuentes y límites de la evidencia
- https://www.rfc-editor.org/rfc/rfc1034.html
- https://www.rfc-editor.org/rfc/rfc1035.html
- https://www.rfc-editor.org/rfc/rfc2181.html
- https://www.rfc-editor.org/rfc/rfc2308.html
- https://www.rfc-editor.org/rfc/rfc4034.html
- https://www.rfc-editor.org/rfc/rfc4035.html
- https://www.rfc-editor.org/rfc/rfc5155.html
- https://www.rfc-editor.org/rfc/rfc8020.html
- https://www.rfc-editor.org/rfc/rfc8198.html
Las normas documentan diseños, requisitos e historia parcial de implementaciones; no miden toda la adopción. NSEC3, el corte de subárbol y la síntesis agresiva pertenecen a etapas posteriores y no deben atribuirse a los resolutores de 1987 o 1998.
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
