Resumen

  • RFC 9660 devuelve la versión de zona dentro de la misma respuesta que esa versión generó, evitando atribuirle a posteriori el SOA observado en otra consulta.
  • El token no verifica todo el contenido, no representa por sí solo a la flota y no está cubierto por RRSIG; una decisión exige conservar paquete, alcance, repetición e integridad.

La diferencia cabe en una sola dirección IP. Dos sondas llegan al mismo destino anycast y preguntan por el mismo nombre. Ambas reciben NOERROR. Una obtiene la dirección nueva; otra, la anterior. En la primera respuesta, ZONEVERSION informa el SOA-SERIAL 4120. En la segunda, 4119.

Consultar el SOA después parece una comprobación razonable, pero llega tarde. La ruta puede cambiar o el nodo retrasado puede actualizarse entre una petición y otra. Las dos consultas auxiliares devolverían 4120 y el sistema perdería la prueba de que la respuesta antigua nació de 4119.

El caso es ilustrativo, no un incidente atribuido a una red. Expone la contribución exacta de RFC 9660: la respuesta y su identificador de versión llegan juntos. No explica por qué hay divergencia ni garantiza que 4120 sea correcto. Tampoco convierte una muestra en inventario de toda la autoridad.

El cliente pregunta; no ordena una versión

La petición incluye el código EDNS 19 en el pseudo-RR OPT. Su OPTION-LENGTH es cero y no lleva datos. No pide “responde desde 4120” ni solicita promover una zona. Solo pregunta qué versión utilizó el servidor para construir la respuesta que está enviando.

Un largo distinto de cero o dos opciones ZONEVERSION en la misma consulta invalidan el formato. El servidor autoritativo que implementa la RFC devuelve FORMERR. Ese código obliga a revisar la herramienta de medición antes que el contenido DNS. Sin los bytes originales, el investigador no puede demostrar que su propia pregunta era válida.

El servidor puede no contestar la opción. Debe comprenderla, ser autoritativo para una zona envolvente pertinente y decidir atenderla. La ausencia solo deja la correlación sin probar. No autoriza a etiquetar la instancia como atrasada.

Además, el mecanismo es salto a salto. Un reenviador no puede copiar ciegamente la solicitud y reutilizar el valor del upstream como si describiera una respuesta creada en otro punto. La cadena probatoria depende de mantener juntos al productor, el mensaje y el token.

LABELCOUNT evita asignar el serial a la zona equivocada

La respuesta empieza con un octeto LABELCOUNT, otro octeto TYPE y después VERSION. LABELCOUNT toma etiquetas por la derecha del QNAME original para identificar la zona envolvente; cero designa la raíz.

En host.rama.example, dos etiquetas corresponden a rama.example; una, a example. El valor no puede superar las etiquetas del nombre preguntado. Por eso una telemetría que guarda únicamente “serial 4120” elimina el espacio de nombres al que pertenecía.

La opción también puede describir una referencia descendente, porque la zona padre generó la delegación; una negativa NXDOMAIN o NODATA; y ciertos SERVFAIL cuando aún se identifica la zona autoritativa relevante. Puede haber varias zonas o tipos en una respuesta, pero no dos valores del mismo TYPE y LABELCOUNT.

La clave de observación necesita QNAME, zona derivada, TYPE y VERSION, además del servidor, la posición de red, el tiempo y la respuesta completa.

SOA-SERIAL tiene aritmética propia y no resume el contenido

El TYPE 0, SOA-SERIAL, es el único tipo público definido actualmente por RFC 9660. Copia cuatro octetos del SERIAL del SOA de la zona. Sumados LABELCOUNT y TYPE, la longitud de respuesta es seis.

El serial no es global. Solo se compara dentro de la misma zona, y RFC 1982 establece un espacio circular de 32 bits. Tras el desbordamiento, un número menor puede ser más reciente; para algunos pares el orden no está definido. Usar una comparación entera convencional puede inventar una regresión.

Tampoco es un hash. Dos contenidos distintos pueden compartir serial por error operativo. Bajo un mismo serial, el contexto o la política pueden producir respuestas distintas. Hay que conservar y contrastar RRsets, secciones, flags, TTL y validación DNSSEC.

Cuando la pregunta es si toda la zona coincide con un contenido esperado, la herramienta pertinente es ZONEMD de RFC 8976. ZONEVERSION ofrece procedencia temporal para una respuesta; ZONEMD ofrece digest de zona. Pedirle a uno la garantía del otro destruye la precisión de ambos.

Anycast obliga a definir el conjunto observado

Una dirección anycast puede llevar a instancias diferentes según origen y momento. La frase “el servidor respondió” oculta precisamente lo que debe medirse. Antes de comparar, el operador necesita inventariar NS, direcciones, prefijos anycast, cohortes esperadas y puntos de observación.

Cada consulta directa debe ir sin recursión y conservar origen, destino, transporte, hora, QNAME, RCODE, AA, paquete, TTL, opción y resultado criptográfico. Repetirla permite separar una ruta efímera de una diferencia persistente.

NSID aporta una pista adicional sobre la instancia, pero su contenido y unicidad dependen del operador. No queda autenticado por aparecer en el paquete y no reemplaza a la dirección ni a la posición de medición.

Tres puntos que repiten 4120 y los mismos bytes frente a un cuarto que mantiene 4119 y la dirección vieja demuestran una divergencia acotada. Para encontrar la causa hacen falta journal, transferencia, salida del firmante, versión cargada y mapeo del tráfico. El token señala dónde mirar; no dicta el culpable.

DNSSEC protege los RRset, no estos bytes EDNS

La validación DNSSEC puede autenticar los RRset firmados de la respuesta. Los bytes de ZONEVERSION no están cubiertos por RRSIG. En un camino inseguro, alguien podría quitar o modificar la opción sin romper la firma del dato DNS.

Conviene registrar dos resultados separados: validación del RRset y custodia de la pareja respuesta–versión. Para el segundo se puede usar transporte autenticado y cifrado, TSIG o SIG(0), guardando identidad de extremo o clave y el veredicto real. Ninguno demuestra que la zona sea correcta ni que el despliegue haya terminado.

OPT no es dato de zona. El token no debe almacenarse, transferirse ni cachearse como RR. Una caché puede retener la respuesta durante su TTL; no puede separar la etiqueta y atribuírsela a otra respuesta.

Fuentes