Resumen

  • NSID permite pedir el identificador de la instancia que contesta una consulta DNS. Preguntarlo después, aunque se use la misma dirección, podría identificar otra instancia.
  • Un resolutor recursivo se identifica a sí mismo ante su cliente. Sus consultas a servidores autoritativos constituyen intercambios separados y no forman una cadena NSID transferible.
  • El contenido es una secuencia opaca de bytes definida por el operador. Debe conservarse con exactitud, sin confundirla con un nombre global, una ubicación certificada o una prueba de autenticidad.

Datos de ayer, interlocutor de ahora

Un resolutor recursivo puede contestar con registros que ya tenía en caché. La instancia que envía esa respuesta está presente en el intercambio; el servidor autoritativo del que se obtuvieron los datos quizá no participe en él. Si el cliente pide un identificador NSID, ¿a cuál de los dos está preguntando quién es?

La respuesta del protocolo es inequívoca: al interlocutor actual. El resolutor puede identificarse, pero no debe presentar la identidad de un servidor consultado en otro intercambio como si fuese la suya. NSID no es un expediente que acompañe a un registro desde su origen hasta cada lector.

Esta distinción combina dos reglas documentadas. RFC 5001, de agosto de 2007, define NSID como un mecanismo no transitivo. RFC 6891, que revisó EDNS en abril de 2013, especifica que OPT contiene control de una transacción concreta, no datos DNS que puedan almacenarse en caché o en ficheros de zona. De ambas reglas se desprende la separación entre la procedencia de los registros y la identidad de quien responde ahora.

No se trata de una carencia accidental. Si un identificador viajara sin conservar esos límites, sería difícil saber a qué consulta, instante o estado de la caché se refiere. El estándar prefirió resolver una ambigüedad sin fabricar una historia completa que no podía garantizar.

Cuando la dirección deja de ser un nombre de máquina

La necesidad de identificar la instancia surgía de una separación útil: una dirección podía representar un servicio distribuido. En anycast, varios nodos independientes anuncian una misma dirección de servicio y el encaminamiento determina cuál recibe el tráfico. La dirección común facilita el acceso sin obligar a los clientes a conocer cada dirección de mantenimiento.

Pero una consulta posterior no tiene asegurado el mismo destino interno. Tampoco debe simplificarse anycast diciendo que siempre elige la máquina geográficamente más cercana o que cambia de nodo con cada paquete. El problema es la falta de garantía, no la obligación de que todo cambie continuamente.

El documento operativo RFC 4786, publicado en diciembre de 2006 como BCP 126, recomendaba identificar los nodos dentro del propio protocolo de servicio. Un traceroute podía aportar información, aunque las condiciones hubieran cambiado cuando se ejecutara. También aconsejaba observar desde ubicaciones representativas y registrar la identidad junto a disponibilidad y rendimiento.

Ese texto mencionaba los trabajos NSID todavía en desarrollo. Su recomendación no debe confundirse con una norma final que ya existiera en 2006. La secuencia histórica importa: primero se describió una dificultad operativa; después se concretó el mecanismo común para reducirla.

La segunda pregunta podía ser correcta y aun así engañar

Antes de NSID había convenciones para preguntar a un servidor cómo se llamaba. Una consulta TXT de clase CHAOS para HOSTNAME.BIND. podía devolver un identificador configurado por el administrador. ID.SERVER. evitaba el nombre ligado a una implementación. VERSION.BIND. informaba de la versión, una función diferente.

Estas consultas eran sencillas y dejaban la divulgación bajo control local. No desaparecieron porque se diseñara NSID. Su limitación era que requerían una pregunta adicional. En un escenario posible de diagnóstico, la primera consulta recibe una respuesta anómala; la segunda llega a una instancia sana y devuelve su nombre. El nombre puede ser verdadero, pero no identificar a quien produjo la anomalía.

RFC 4892, de junio de 2007, convirtió esa falta de correlación en requisitos. Varias consultas al mismo destino podían acabar en servidores distintos por anycast o balanceo de carga. Emplear ICMP u otro tráfico de diagnóstico no aseguraba encontrar al mismo sistema. La identidad debía poder solicitarse dentro de una consulta ordinaria.

Los requisitos incluían neutralidad respecto a la implementación y la posibilidad de activar, desactivar o limitar la respuesta. También buscaban evitar que un diagnóstico útil exigiera revelar nombres privados o direcciones unicast de mantenimiento. Identificar una instancia no tenía por qué significar publicar la organización interna del servicio.

Un hueco común, no una nomenclatura mundial

El mecanismo definido por R. Austein en RFC 5001 utiliza una opción EDNS dentro del pseudorregistro OPT. El cliente añade una opción NSID vacía. No debe incluir contenido y el servidor debe ignorarlo si llega a recibirlo. Por tanto, no es un desafío que haya que devolver, una orden de escoger una máquina ni un identificador elegido por el cliente para el servidor.

Si el servidor admite NSID y decide atender la petición, devuelve sus bytes identificadores en el OPT de esa misma respuesta. Puede negarse. Y no debe enviar NSID si no se le ha solicitado. La ausencia del campo no demuestra que DNS haya fallado o que detrás de la dirección exista una sola instancia.

El registro de parámetros DNS de IANA asigna a NSID el código de opción EDNS 3. Esa asignación crea un punto de entendimiento entre implementaciones. No asigna los códigos particulares de los servidores ni establece que deban contener un país, una ciudad o un nombre de equipo.

La respuesta puede ser opaca para quien la recibe. El operador conserva el significado y el cliente conserva el indicio. Esta división permite que un usuario remita una referencia útil al soporte sin aprender cómo ese operador organiza sus nodos.

El salto es DNS, no cada router del camino

Un cliente que habla con un resolutor recursivo puede solicitar el NSID de ese resolutor. A su vez, el resolutor puede incluir peticiones NSID en sus propias consultas a servidores autoritativos. Pero la segunda decisión no deriva automáticamente de la primera y su resultado no sustituye a la identidad del resolutor en la respuesta al cliente.

Hablar de funcionamiento salto a salto puede resultar engañoso si se imagina que los routers IP van añadiendo marcas. Los extremos relevantes son los participantes en cada transacción DNS. El mecanismo no descubre todos los dispositivos atravesados, ni entrega una lista de servidores consultados durante la recursión.

La restricción evita atribuir a un dato más alcance del que posee. Un identificador recibido en una consulta autoritativa puede ser útil para los registros internos del resolutor; no por ello es la respuesta apropiada a la pregunta del cliente sobre quién le está contestando.

Un byte nulo no es el final del indicio

RFC 5001 exige representar la secuencia con dos dígitos hexadecimales por octeto y comparar los datos binarios. La copia no puede suponer que el primer byte nulo termina una cadena. Los ceros iniciales o internos forman parte del identificador.

Tampoco debe tratarse automáticamente como texto, un nombre DNS o una etiqueta geográfica. Una vista legible puede ayudar, pero no sustituye a los bytes exactos. Las letras mayúsculas o minúsculas de una representación hexadecimal pueden describir los mismos bytes; cambiar el caso o normalizar el texto supuesto del contenido es otra operación, potencialmente destructiva.

El detalle tiene una consecuencia práctica: una interfaz de soporte que embellece la referencia puede inutilizarla. El usuario no necesita entenderla, pero sí debe poder copiarla sin que el programa decida qué partes merecen conservarse.

Privacidad y confianza no vienen incluidas

El operador puede emplear un nombre, una dirección, valores aleatorios u otras codificaciones. Exponer una dirección de mantenimiento puede revelar un nodo individual que el servicio anycast mantenía menos visible. Aplicar una función hash a una dirección IPv4 no elimina el espacio de entrada de solo 32 bits. Los nombres predecibles también pueden someterse a pruebas.

Un identificador aleatorio persistente evita algunas divulgaciones, pero exige guardar su correspondencia. Una configuración que asigne el mismo valor a todos los nodos destruye la distinción que se buscaba. Las rotaciones introducen otra cautela: un cambio no prueba por sí solo una migración de hardware o una modificación de ruta.

El RFC considera contenidos firmados o cifrados sin ofrecer un diseño completo de seguridad. Un bloque estático puede reproducirse. Además, NSID es señalización del canal, no queda protegido automáticamente por DNSSEC. Autenticar los registros de una respuesta no autentica necesariamente el identificador adjunto. El texto menciona mecanismos de canal como TSIG cuando se requiere integridad; no afirma que toda respuesta NSID disponga de ella.

La implementación conserva las decisiones separadas

La referencia de BIND capturada para este análisis, identificada como 9.20.27, documenta server-id y request-nsid por separado. El primero determina el identificador que se devuelve mediante NSID o ID.SERVER y su valor predeterminado es none; puede elegirse el nombre del sistema. El segundo incorpora solicitudes vacías en las consultas iterativas y registra los valores recibidos en la categoría nsid; por defecto está desactivado.

No hay un interruptor universal de transparencia. Revelar la propia identidad y recopilar la de otro participante son decisiones locales diferentes. Las páginas de manual de BIND describen dig +nsid, que añade una petición sin forzar al servidor a satisfacerla ni verificar la autenticidad del contenido.

La documentación demuestra que existe una vía de uso, no cuántas instalaciones la tienen habilitada. La especificación también recuerda que los bytes adicionales pueden acercar una respuesta a los límites de truncamiento: NSID no cambia esas reglas ni obliga a truncar solo para incluir un identificador opcional.

La aportación histórica fue conectar una referencia con el intercambio correcto. El estándar no necesitó resolver la identidad de toda Internet para hacer menos confuso un diagnóstico concreto.