Resumen

  • RFC 8005 define un RR HIP que conserva una identidad pública HI, su HIT y nombres opcionales de servidores de encuentro. Es un objeto de publicación y descubrimiento, no un comprobante de vida.
  • La validación DNSSEC autentica datos DNS dentro de su cadena y el TTL regula su reutilización. Ninguno demuestra que el RVS mantenga hoy la asociación HIT-dirección o que el nodo pueda usar la clave privada.
  • El estado defendible enlaza el registro exacto con la selección de RVS, su registro vigente, el relé de I1, la autenticación HI, el intercambio base y el resultado de la aplicación.

Una respuesta correcta para la pregunta equivocada

A las 09:00, un resolvedor recibe el RR HIP de un nodo móvil. El conjunto trae la HI esperada, el HIT y rvs.example. La cadena DNSSEC es segura y queda una hora de TTL. El sistema de cumplimiento resume todo como «identidad verificada y servicio alcanzable».

A las 09:12, el nodo cambia de acceso. El mensaje que debía actualizar su dirección en el RVS no llega. No hay razón automática para que cambie el RR: el mismo nombre de encuentro sigue siendo la puerta publicada. A las 09:20, el iniciador envía I1; el RVS consulta una asociación antigua y reenvía hacia una red donde el nodo ya no reside.

El caso es hipotético, no una acusación a un despliegue. Cada dato DNS puede seguir siendo válido. La contradicción fue creada por el modelo de control, que trató la vigencia del directorio como si fuera una medición del camino.

El RR distribuye material público

RFC 5205 apareció en 2008 como Experimental. RFC 8005 lo sustituyó en 2016 con categoría Standards Track. El tipo 55 permite publicar una Host Identity, el Host Identity Tag que se deriva de ella y, de forma opcional, nombres de RVS.

La HI es la parte pública del par criptográfico. El HIT es una forma hash abreviada para referirse a ella. Son datos necesarios para elegir y preparar un intercambio, pero una consulta DNS no contiene la clave privada ni obliga al dispositivo a demostrarla.

Por eso RFC 8005 dice que un extremo no debería autenticar al par basándose solo en un HIT recuperado de DNS. La autenticación debe apoyarse en la HI. La diferencia es práctica: encontrar un identificador publicado no equivale a ver una firma válida en el intercambio actual.

Una plataforma que marca peer_authenticated al resolver el HIT elimina un escalón de evidencia. Si la clave privada fue retirada, dañada o quedó fuera de línea, el RR puede conservar el mismo contenido hasta que el operador publique otra cosa.

DNSSEC no certifica todo lo que está detrás del nombre

Modificar un RR HIP sin protección permite sustituir la clave pública o redirigir el primer paquete. El documento recomienda un canal con integridad y autenticidad, y señala DNSSEC como la solución.

También prohíbe una lectura expansiva. La garantía se refiere al canal entre el servidor que publica la zona y el nodo HIP. No establece que el publicador sea confiable. La RRSIG del conjunto HIP no debe interpretarse como un certificado que vincula la HI o el HIT con el nombre propietario.

El resultado secure tiene entonces un significado fuerte y limitado. Acredita bytes, cadena, ancla, instante y política de validación. No observa la tabla del RVS, el almacén de claves del nodo, la ruta IP ni el proceso de aplicación.

Confundir estos planos perjudica incluso a DNSSEC: cuando el servicio falla, los operadores investigan una firma que hizo exactamente su trabajo.

Un TTL no es una reserva de capacidad

RFC 8005 exige borrar el RR cuando el tiempo transcurrido desde su obtención supera el TTL. Si hace falta para iniciar comunicación, debe realizarse una consulta nueva. Esa regla es concreta: define cuándo puede reutilizarse la publicación.

No define durante cuánto tiempo debe funcionar el destino. El TTL no reserva una entrada en el RVS, no inmoviliza una dirección, no preserva una ruta y no garantiza que la clave privada esté cargada. Que falten diez minutos para vencer solo dice algo sobre el caché.

Después de vencer, una consulta fresca tampoco prueba el estado dinámico. Puede devolver exactamente el mismo RR, correctamente firmado, mientras el RVS sigue conservando una dirección vieja. Renovar la evidencia de una capa no refresca automáticamente las demás.

El riesgo crece cuando un controlador usa el TTL para evitar pruebas «innecesarias». Se ahorra una consulta al servicio y, a cambio, se inventa una disponibilidad que nadie midió.

Directorio estable, asociación móvil

La arquitectura de encuentro desacopla dos ritmos. El nodo publica nombres de RVS relativamente estables en DNS. En otro protocolo, mantiene al RVS informado de su conjunto actual de direcciones. RFC 8004 explica que el servidor consulta sus registros vigentes para decidir si reenvía I1.

Por eso la resolución del RVS y el registro dentro del RVS son objetos diferentes. Puede existir el primero y faltar el segundo. También puede haber una asociación sin renovar o una asociación que apunta a la localización anterior. Incluso un relé correcto no prueba que el destinatario respondió; ese límite pertenece a otra etapa.

Un panel útil conserva la secuencia:

RR HIP → validación DNSSEC → TTL → RVS elegido → asociación HIT-dirección → relé I1 → autenticación HI → asociación HIP → tráfico útil.

El color de cada casilla debe proceder de su propia fuente. Desconocido es la respuesta correcta cuando no hay observación.

La selección entre varios registros también deja rastro

RFC 8005 acepta varios RR HIP para el mismo nombre y deja fuera de alcance la política de selección. Si la información RVS difiere, el cliente debe comprobar que el servidor elegido está asociado con la HI utilizada.

Esto impide separar todas las HIs y todos los RVS en dos inventarios sin relación. Tal normalización puede fabricar una combinación inexistente, sobre todo durante una rotación de claves. El problema ya no estaría en DNS ni en HIP, sino en la base que perdió la procedencia.

El recibo debe conservar cada RR como unidad, el algoritmo, la HI, el HIT, los nombres RVS, el TTL y el motivo de selección. Cuando cambie el conjunto, debe quedar claro qué versión consumió cada intento.

Qué se necesita para afirmar alcance

La trazabilidad empieza con propietario, consulta, servidor autoritativo, marcas de tiempo y huella de respuesta. Añade el RRset íntegro, el resultado DNSSEC con ancla y política, la edad del caché y la evidencia de reconsulta. Continúa con A/AAAA del RVS, identificador de registro, HIT, localizadores, refrescos, vencimiento y cancelación. Después registra envío y recepción de I1, decisión de relé, autenticación HI y estado de ambos extremos. El camino de carga y la aplicación producen sus comprobantes propios.

Ningún equipo tiene que afirmar más de lo que observa. DNS controla la publicación. El RVS controla su asociación. El extremo controla el uso de la clave. La red y la aplicación controlan entrega y efecto. La unión se hace por identificadores y tiempos, no por optimismo.

RFC 8005 añadió ECDSA, aclaró la reconsulta tras TTL, trató múltiples registros y refinó formatos. Citarlo no demuestra que un binario desplegado haya migrado. Hay que conservar versión, build, configuración y trazas.

El valor del RR HIP es permitir que el contacto empiece con información identificable. Mantener ese límite no lo rebaja. En el escenario, el texto correcto sería: «RR seguro y vigente; registro RVS sin confirmar; alcance desconocido». Esa precisión dirige la reparación al estado móvil, no a una zona que seguía publicando lo acordado.

Fuentes