Resumen

  • La RFC 5001, publicada en agosto de 2007, definió NSID como opción de EDNS. El cliente solicita la identidad con un campo vacío y el servidor puede incluir bytes identificadores en esa misma respuesta.
  • La opción actúa entre dos extremos de una consulta, sin atravesar automáticamente un resolvedor recursivo. Su valor es opaco: el operador decide si entrega un nombre legible, un seudónimo u otra marca.
  • L-Root documentó en 2014 el uso de nombres completos de sus nodos como NSID. El registro oficial de IANA reserva para NSID el código de opción 3.

La repetición no interrogó necesariamente al culpable

La frase «el servidor DNS cambió de respuesta» parece razonable cuando en dos capturas aparece la misma IP. En anycast, esa IP funciona como una ventanilla común. Distintos nodos reciben el tráfico según las rutas activas. También un distribuidor de carga puede colocar varios procesos detrás de una sola dirección. Un cliente que vuelve a preguntar puede encontrarse con otra copia de los datos, otro estado de servicio y otra máquina. La segunda respuesta limpia no absuelve a la primera ni identifica a quien la produjo.

La guía operativa de anycast de 2006 ya señalaba la identificación del nodo como herramienta de diagnóstico. Un técnico podía hacer después una consulta especial para conocer el nombre de un servidor. Ese procedimiento tenía un defecto temporal: entre la respuesta defectuosa y la consulta de identificación, el encaminamiento podía cambiar. El nombre obtenido correspondía al siguiente testigo, quizá no al que había cometido el error.

La RFC 5001 resolvió la unión entre prueba y respondedor en el propio paquete. Su introducción menciona anycast y balanceo de carga como causas del problema: más de un servidor de nombres comparte la dirección. Las consultas DNS no mantienen una sesión que ate la investigación posterior al nodo original. Por eso el servidor que contesta puede insertar su identificador en la misma respuesta que se examinará. El dato queda junto a la respuesta problemática antes de que la ruta tenga ocasión de cambiar.

El cliente pregunta con un campo vacío

El resolvedor envía una opción NSID vacía dentro del pseudorregistro OPT de EDNS. La consulta no debe llevar datos de identidad. El código 3 está registrado por IANA. Un servidor que entiende la opción y acepta la petición devuelve una cadena de bytes identificadores en su respuesta. Debe ignorar cualquier dato que el cliente hubiera introducido indebidamente en la consulta y no puede devolver NSID a quien no lo pidió. Estos detalles separan una solicitud explícita de un anuncio indiscriminado de la topología interna.

Los bytes no tienen una presentación obligatoria. La RFC permite el nombre real del servidor, una dirección de mantenimiento, un valor seudoaleatorio estable, una marca que cambia, datos firmados o datos cifrados. Un cliente puede conservar la cadena exacta y el operador puede decidir qué revela. Un nombre público agiliza los avisos de incidentes. Un seudónimo diferencia réplicas sin mostrar dónde se administran. Un token cambiante limita la correlación externa, pero obliga al operador a mantener una buena correspondencia interna si quiere usar los informes de sus clientes.

Esa libertad crea una responsabilidad concreta. Publicar la IP privada de mantenimiento de cada nodo contradice el deseo de ocultar la estructura detrás de la dirección compartida. Ocultar toda marca deja al cliente sin una forma sencilla de señalar la réplica que falló. La discusión de seguridad de RFC 5001 sitúa NSID como señal del canal, fuera de la protección que DNSSEC da a los datos DNS. Si dos partes discuten si la marca era auténtica, necesitan protección del canal o registros operativos que permitan comprobarla.

L-Root puso nombres propios en el campo

Los operadores de L-Root publicaron en enero de 2014 una descripción de sus mecanismos de identificación de nodos anycast. Allí NSID devolvía el nombre completo del nodo que había contestado a la consulta. El documento muestra una salida de dig con los octetos en hexadecimal y su lectura como nombre, por ejemplo ytz01.l.root-servers.org. Es una decisión de divulgación del operador: el estándar no obligaba a usar nombres de host.

L-Root también respondía a consultas HOSTNAME.BIND e ID.SERVER. Estas pueden identificar al nodo que responde a la consulta de seguimiento. La ruta puede cambiar entre la respuesta que dio problemas y el intento posterior de averiguar la identidad. NSID se pide en la consulta que importa y aparece con la respuesta que importa. Así, un informe técnico puede llevar la pregunta, el dato recibido y la marca del servidor en un solo registro.

El artículo de L-Root documenta una instalación en esa fecha, no un censo de las prácticas actuales de todos los servidores raíz. Para atribuir un incidente concreto se conservan el mensaje original, la opción NSID, el origen, el transporte y la hora. La traducción de la marca a una máquina física o virtual depende del inventario de quien opera el servicio.

El salto de un resolvedor recursivo tiene su propio nombre

La solicitud NSID termina en el servidor que la recibe. Si una aplicación pregunta a su resolvedor recursivo, el identificador solicitado pertenece a ese resolvedor. El resolvedor puede preguntar por separado a un servidor autoritativo, pero esa segunda comunicación tiene su propia solicitud y su propia respuesta. El identificador de un salto no se propaga como una etiqueta del recorrido completo. Tampoco debe aparecer en la respuesta de un servidor a un cliente que nunca lo solicitó.

Un cliente que quiere saber qué autoridad contestó detrás de una resolución recursiva necesita el registro de la consulta aguas arriba. El NSID recibido del resolvedor local no sustituye ese registro. Esta frontera evita atribuir el error a un servidor autoritativo que quizá ni siquiera produjo el dato en ese momento. Dentro de un salto, la marca informa de lo que el servidor declara; las configuraciones, los registros y la protección del canal completan la prueba sobre qué ocurrió.

La dirección compartida perdió su coartada

La propuesta de 2007 mantuvo intacta la dirección del servicio. Añadió al paquete un espacio facultativo para que el nodo respondedor se identificara. IANA fija la palabra común y su número. El operador elige los bytes que entrega. El resolvedor decide pedirlos y conservarlos junto al resultado. Esa división de funciones explica por qué una marca pequeña puede mejorar una investigación sin rediseñar el DNS.

Un servidor también puede guardar silencio. Los bytes adicionales pueden agrandar una respuesta hasta provocar truncamiento; la RFC deja opcional su inclusión. Si una captura no contiene NSID, solo sabemos que en ese intercambio no se devolvió una marca. El nodo tendrá que localizarse mediante otros registros. El silencio no convierte la dirección compartida en identidad de máquina.

Un servicio anycast necesita una dirección común para recibir preguntas. Para entender un fallo, necesita una forma de decir cuál de sus máquinas respondió a la pregunta concreta. L-Root eligió un nombre legible. Otros operadores pueden elegir una clave privada. La utilidad permanece en la unión temporal: la marca viaja con la respuesta, antes de que la siguiente consulta acabe en otro escritorio.