Resumen

  • Un DET es un identificador con forma IPv6 de 128 bits, no un localizador; RFC 9886 sitúa su jerarquía DNS inversa bajo 2001:30::/28.
  • La jerarquía distingue la Registered Assigning Authority (RAA) y la HHIT Domain Authority (HDA), con delegaciones bajo 3.0.0.1.0.0.2.ip6.arpa.
  • El nombre de un DET debe resolver a HHIT; en el caso de UAS Remote ID también debe existir BRID.
  • DNSSEC es obligatorio para las entidades de ápice y recomendable para las demás. Si no hay DNSSEC, el cliente recorre la jerarquía de certificados mediante consultas HHIT sucesivas.

La fixture operativa comienza en 3.0.0.1.0.0.2.ip6.arpa. El operador obtiene el tramo RAA y HDA correspondiente al DET, comprueba las delegaciones en servidores autoritativos y consulta el nombre del DET. Allí debe encontrar HHIT, RRType 67, junto con el certificado de registro canónico. Para un UAS debe comprobar además BRID, RRType 68, que contiene información estática del Broadcast RID y posibles endosos. Estos nombres, tipos y relaciones son verificaciones DNS concretas; no requieren copiar cadenas de bytes de los ejemplos de los apéndices.

La validación tiene dos rutas. Con DNSSEC, se revisan las firmas y la cadena de delegación conforme a la posición de la entidad. Sin DNSSEC, el cliente debe recorrer la jerarquía de certificados mediante búsquedas HHIT sucesivas para probar el registro. Una resolución positiva, por sí sola, no demuestra que una autoridad registral haya incluido el identificador. La diferencia entre presencia sintáctica y pertenencia validada es el centro de la operación.

RFC 9886 separa los datos y punteros públicos del DNS de los registros privados. No define los mecanismos AAA para proteger la información personal identificable. Por tanto, una cadena pública correcta no permite concluir que un proceso privado sea adecuado, que una identidad real esté autorizada, que exista una política concreta de una jurisdicción o que haya un precio o servicio disponible.

El DET deja expuesta una clave pública para verificar firmas. Cuando sea práctico, RFC 9886 recomienda retrasar la publicación de tipos de registro bajo un DET hasta que sean necesarios. El mecanismo de publicación justo a tiempo queda fuera del alcance. Esto es orientación sobre exposición pública, no una promesa de anonimato ni una medición de resultados de privacidad.

Ruta de decisión para operadores: 1) tratar el DET como identificador con forma IPv6, no como localizador; 2) ubicarlo en el árbol inverso de 2001:30::/28; 3) confirmar la delegación autoritativa RAA/HDA; 4) exigir HHIT; 5) exigir BRID para UAS Remote ID; 6) validar DNSSEC o ejecutar el recorrido de certificados si falta; 7) guardar la respuesta autoritativa, el resultado de validación, la cadena y el momento de observación; 8) publicar otros registros solo cuando su necesidad y exposición estén justificadas.

La vigilancia de ciclo de vida, la evaluación de registros obsoletos y el momento de divulgar claves son análisis de Theo March, no requisitos de RFC 9886. La delegación funciona como superficie de control: cambiarla, cambiar un registro o alterar una cadena certificada puede modificar lo que acepta un tercero. Conviene observar delegaciones ausentes, HHIT o BRID retirados, cadenas rotas y pruebas envejecidas. El paquete no permite afirmar adopción o despliegue productivo, disponibilidad o latencia de DIME o de un registro, cobertura de proveedores, resolutores o implementaciones, historial de incidentes, abuso, efectos de privacidad o trazabilidad, ni política jurisdiccional alguna.

Fuentes

Las erratas verificadas 8822 y 8823 corrigen codificaciones de ejemplos en los apéndices. Este briefing no reproduce esas cadenas de bytes ni las trata como mediciones operativas.