Resumen

  • Un DET usa 2001:30::/28 y es una dirección IPv6 válida, aunque no enrutable; su forma codifica una jerarquía de identificación, no un destino ni coordenadas.
  • El registro HHIT tipo 67 contiene metadatos y un certificado canónico de registro; el BRID tipo 68 conserva información estática de Broadcast RID y avales.
  • DNSSEC autentica el origen y la integridad de la respuesta DNS, pero la posición, la posesión actual de la clave, el acceso privado, el estado operativo y la autoridad legal son pruebas separadas.

La consulta termina sin errores. El nombre invertido de un valor con aspecto IPv6 devuelve HHIT y BRID. DNSSEC valida la cadena. El certificado confirma el registro y los avales se verifican. Una regla automática está a punto de clasificar el objeto como «aeronave localizada».

No falta un último campo en la respuesta. Falta un tipo de observación completamente distinto.

RFC 9886 normaliza cómo registrar y buscar en DNS los DRIP Entity Tags, o DET. Permite descubrir la jerarquía del identificador, su clave pública y los documentos que respaldan el registro. Ninguno de esos datos convierte al DNS en un sistema de vigilancia del espacio aéreo. Resolver responde qué registro habla sobre el identificador; localizar exige medir el mundo físico.

La apariencia técnica invita a confundirlos. RFC 9374 reserva 2001:30::/28 para DET y describe los HHIT como direcciones IPv6 válidas pero no enrutables. Así pueden aprovechar estructuras de 128 bits y mecanismos de nombres inversos. No son destinos para enviar paquetes a la aeronave y no llevan latitud ni longitud.

La zona inversa del prefijo es 3.0.0.1.0.0.2.ip6.arpa. Cada DET se expresa mediante inversión de nibbles, como cualquier dirección IPv6, pero la consulta busca tipos HHIT o BRID, no el PTR convencional. El resultado es información del identificador.

Dos registros, dos afirmaciones limitadas

Todo DET debe resolver a un registro HHIT. Para Remote ID de UAS también debe existir un BRID. La obligación de publicar ambos no borra la diferencia entre sus contenidos.

HHIT RR tipo 67 reúne el tipo de entidad, una abreviatura de la jerarquía y el certificado canónico de registro. El certificado incluye la clave pública de la entidad, firmada por el registrador u otro ancla de confianza. Validarlo respalda que el identificador derivado de esa clave fue incluido en la jerarquía declarada. También puede señalar mediante URI el servicio de información privada.

BRID RR tipo 68 guarda datos de Broadcast RID que son estáticos. Su función principal en DRIP es publicar uno o varios Broadcast Endorsements generados por el registrador tras un registro satisfactorio. Puede reponer material estático que no llegó por radio o servir de contraste.

Sin embargo, encontrar BRID en DNS no prueba que un receptor oyó esa emisión en el vuelo presente. DNS es el canal del registro público. Broadcast RID es un evento radioeléctrico local con receptor, alcance y marca temporal propios. La palabra compartida no fusiona los hechos.

RFC 9434 advierte además que un DET autoafirmado no demuestra por sí solo la identidad del emisor. Repetir información firmada permite ataques de replay. Para acreditar posesión actual de la clave hacen falta datos nuevos y cambiantes cuya realidad pueda comprobar el observador: por ejemplo, una ubicación y hora firmadas que coincidan con la aeronave observada. Autenticar el mensaje y medir la posición siguen siendo operaciones diferentes.

DNSSEC valida una respuesta, no el cielo

RFC 9886 obliga a usar DNSSEC en entidades apex con certificado canónico autofirmado y lo recomienda para las demás. Sin DNSSEC, una respuesta falsa puede facilitar denegación de servicio, replay, suplantación o clonación de aeronaves, secuestro de registros DET, metadatos corruptos y daños a relaciones de confianza. Si no utiliza DNSSEC, el cliente debe recorrer la cadena de certificados HHIT; los avales BRID mantienen su propia validación.

El resultado seguro importa, pero no puede extenderse a otras preguntas. DNSSEC ofrece evidencia criptográfica sobre procedencia e integridad de datos DNS dentro de su cadena. No observa una aeronave, no sabe si el operador previsto conserva la clave privada, no confirma una operación activa, no contrasta las coordenadas y no concede permiso regulatorio.

Una zona puede firmar correctamente una afirmación equivocada. Un registro auténtico puede haber perdido actualidad para la decisión. secure describe el estado de validación del DNS; no certifica toda la realidad mencionada en el dato.

El enlace privado inicia otra decisión de acceso

El registro público puede indicar dónde existe información privada. RFC 9886 deja fuera de alcance los mecanismos de autenticación, autorización y contabilidad con los que el registro privado protege datos personales. RFC 9434 sitúa allí números de serie, identificadores de intención operacional y otra información regulada.

Por eso una autoridad de seguridad, un servicio de espacio aéreo y un ciudadano pueden comenzar con el mismo DET y recibir respuestas legítimamente distintas. DNS señala el servicio; el registro privado decide quién puede consultar, con qué propósito y bajo qué norma local. Resolver públicamente no entrega credenciales privadas.

Tampoco la identidad obtenida autoriza por sí sola el vuelo o una intervención. El registrador avala el registro sin pilotar. Un UAS Service Supplier informa de una operación sin convertirse en regulador. Un receptor de radio autentica un mensaje sin garantizar que su posición declarada sea cierta.

La publicación tiene un tiempo distinto al vuelo

Publicar el HHIT de cada DET expone la clave pública necesaria para verificar firmas. RFC 9886 recomienda, cuando sea viable, no publicar esos registros hasta que otra parte los necesite. Plantea que un UAS o un componente UTM podría avisar cuando una operación con Specific Session ID vaya a comenzar o termine.

Es una idea útil para reducir exposición, no un protocolo completo de estado. La combinación de publicación justo a tiempo con DNSSEC queda fuera del documento. La ausencia puede indicar que no hay vuelo, que falló la publicación, que se rompió la delegación o que una política la impide. La presencia puede sobrevivir al aterrizaje. La automatización debe conservar la causa, no inventar un significado único.

Los estándares permiten comprobar varias afirmaciones estrechas. No ofrecen un bit universal de «dron localizado». La primacía del código en ejecución exige usar solo lo que cada componente observó realmente, a la hora registrada y dentro de su competencia.

Fuentes