Resumen

  • RFC 3646 transporta servidores recursivos en orden de preferencia y una lista de búsqueda exclusiva para DNS, pero no atestigua qué configuración quedó activa.
  • La cronología de un incidente debe unir la fuente autenticada con el nombre original, sus expansiones, el servidor consultado, la respuesta, la validación y el consumo por la aplicación.

A las 09:00 un Reply entrega dos direcciones. A las 09:01 el agente del sistema informa “configuración aplicada”. A las 09:04 una aplicación no encuentra portal. Esa secuencia no identifica la causa. El nombre pudo expandirse con un sufijo inesperado; el primer servidor pudo no responder; otra fuente pudo conservar una dirección idéntica; el caché pudo intervenir; o la aplicación pudo usar un mecanismo distinto de DNS. El paquete inicial no decide entre esas posibilidades.

RFC 3646 define OPTION_DNS_SERVERS con código 23. La opción enumera direcciones IPv6 de servidores recursivos según la preferencia para el resolvedor cliente, y su longitud es múltiplo de 16. OPTION_DOMAIN_LIST, código 24, entrega dominios de búsqueda para resolver nombres de host con DNS. No se aplica a otros mecanismos. La edición en texto restringe ambas opciones a Solicit, Advertise, Request, Renew, Rebind, Information-Request y Reply.

“Preferido” no significa “usado”. La lista no contiene una medición de disponibilidad, una promesa de latencia ni una constancia de que una consulta salió. Para afirmar el camino real se necesitan datos del host: qué fuente fue aceptada, qué configuración se instaló, qué servidor eligió el resolvedor, si hubo reintento o caché y qué respuesta regresó.

El nombre corto exige todavía más cuidado. Una lista de búsqueda convierte una entrada en candidatos distintos. RFC 3646 remite a RFC 1535 y RFC 1536 para los peligros de listas implícitas y el tratamiento de nombres con puntos. El registro forense no debería guardar solo el nombre ganador: debe conservar la cadena original, el orden de sufijos y cada consulta intentada.

La autenticación de DHCP cubre una frontera, no toda la historia. El RFC recomienda exigirla antes de instalar servidores o aceptar dominios de búsqueda, porque un servidor intruso puede desviar consultas. Pero una fuente autenticada aún puede entregar una configuración equivocada, y un servicio legítimo puede estar indisponible. Tampoco RFC 4033 resuelve la intención: DNSSEC puede validar perfectamente un registro firmado dentro del dominio erróneo que añadió la lista. La firma protege los datos bajo ese nombre; no certifica que fuera el nombre que el usuario quiso consultar.

Hay una regla local que cambia el diagnóstico: los parámetros DNS configurados manualmente no deberían ser sustituidos por DHCP. Por eso una captura que muestra el Reply no demuestra cuál era el estado efectivo. Hacen falta la configuración manual previa, la regla de precedencia, la decisión de aceptación y una lectura posterior del resolvedor.

Además, RFC 8106 permite anunciar servidores y dominios mediante Router Advertisement. DHCPv6 y RA son autoridades distintas y pueden tener vidas distintas. Si la herramienta de inventario junta valores idénticos y elimina su origen, una dirección que sigue presente ya no revela por qué sigue presente.

El contexto normativo delimita, pero no observa. RFC 3315 fue la base original; RFC 8415 la sustituyó y organiza el DHCPv6 actual. RFC 8504 recoge requisitos de nodos IPv6. Nada de ello certifica la conducta de un equipo concreto.

La arquitectura de RFC 1034 y los mensajes de RFC 1035 ayudan a interpretar la resolución. RFC 3397 ofrece el paralelo DHCPv4 para listas de dominios. Son fuentes para entender los mecanismos, no sustitutos de la telemetría de la consulta investigada.

El registro de parámetros DHCPv6 de IANA asigna los códigos 23 y 24. Esa asignación prueba que el vocabulario está coordinado, no que una opción fuera aceptada o produjera una respuesta. La ficha de Datatracker, la información del RFC Editor, los errata y el historial cumplen la misma función de procedencia documental.

Las ideas de Heng Lu sobre la primacía del código en ejecución, la especificación mínima y las capas de realidad permiten ordenar la investigación. El estándar crea un idioma común. La política local decide si lo acepta. El sistema en ejecución revela qué hizo. La aplicación muestra el efecto. Ninguna capa puede hablar por las demás.

Una cronología completa registra interfaz, red, identidad y autenticación DHCP, bytes de las opciones, precedencia manual, aceptación, vida por fuente, estado instalado, nombre original, candidatos generados, dirección y transporte elegidos, caché, respuesta, estado DNSSEC y resultado de la aplicación. Si una marca temporal falta, la conclusión debe conservar esa incertidumbre.