Resumo

  • O RFC 9886 mapeia DRIP Entity Tags no DNS reverso e define registros HHIT e BRID para material público de registro e identificação remota estática.
  • O DET é um identificador, não um localizador; uma resposta válida não prova posição atual, operação, posse da chave privada ou entrega de mensagem.
  • Automação segura precisa preservar separadamente DNS autoritativo, DNSSEC, cadeia de certificados, prova de posse no ar e correlação de sensores.

O centro de operações conhecia o nome, mas não conhecia o lugar. Um receptor forneceu o DET, a consulta retornou HHIT, o certificado canônico validou e o BRID revelou dados estáticos. No painel, tudo isso cabia em um selo: “aeronave verificada”. Na realidade, nenhum sensor havia estabelecido a posição de uma aeronave.

O RFC 9886 é cuidadoso justamente nesse ponto. Ele cria infraestrutura pública para resolver informações associadas a um DRIP Entity Tag. Embora o valor de 128 bits pareça um endereço IPv6, sua finalidade principal é identificação, não localização. A forma do número não produz roteabilidade ou geografia. O DET nomeia uma identidade criptográfica registrada; não diz onde está o equipamento que a apresenta, se está voando ou se quem transmite controla a chave correspondente.

Uma árvore de identidade, não um mapa

Os DETs do prefixo 2001:30::/28 entram na árvore reversa sob 3.0.0.1.0.0.2.ip6.arpa.. Assim, o sistema reaproveita delegação, cache e autenticação do DNS. A consulta, porém, não busca um PTR capaz de apontar para um local. Ela solicita os tipos HHIT ou BRID.

Há registrante, registrador e registro. Servidores autoritativos publicam dados permitidos em cada domínio delegado. Em níveis superiores, o desenho prevê alocações ligadas a autoridades nacionais ou da aviação civil, enquanto a IANA administra o espaço reverso. O padrão organiza a mecânica interoperável; não define toda a política, gestão e legitimidade de cada nível.

Uma resposta autoritativa comprova que uma autoridade serviu determinados bytes em determinado instante. Essa é uma afirmação útil e auditável. Ela não incorpora fatos físicos que a autoridade não observou. Poder registrar um identificador não é poder localizar o objeto identificado.

Os tipos 67 e 68 têm alcance preciso

A IANA registra HHIT como tipo 67 e BRID como tipo 68. Todo DET deve resolver para HHIT, cujo certificado canônico e material de chave pública permitem verificar a relação com a hierarquia de registro. Para Remote ID de UAS, BRID também é obrigatório. Ele contém informações estáticas de Broadcast Remote ID e endossos, deixando o significado de campos específicos à aplicação.

Isso elimina dependências frágeis. Ao receber uma Host Identity desconhecida, o observador pode buscar a chave e o registro. Sem conectividade, o RFC 9575 permite armazenar a mensagem para verificar depois. O BRID pode suprir dados que não chegaram pelo rádio ou ser usado como referência de comparação.

Mas um registro estático não é uma emissão ao vivo. A chave pública não demonstra que o transmissor atual possui a chave privada. O certificado de registro não é autorização de voo nem certificado de aeronavegabilidade. Os bytes de BRID não são retorno de radar, posição GNSS, trilha óptica ou confirmação de que um comando chegou.

O RFC 9575 encerra a cadeia de confiança antes dessa conclusão. Mesmo com todos os vínculos válidos, o observador sabe que DET e chave pública estão registrados de maneira adequada. Para associar a identidade à aeronave observada, ainda precisa de prova de posse durante a troca no ar. Sem ela, uma reprodução de mensagem antiga pode imitar identidade legítima.

DNSSEC autentica a resposta, não o espaço aéreo

DNSSEC trata origem e integridade na cadeia configurada. O RFC 9886 o exige para ápices autoassinados e o recomenda na hierarquia. Sem proteção, conteúdo falso pode apoiar clonagem, personificação, sequestro de registro ou metadados corrompidos. Quando DNSSEC não fecha essa dúvida, o cliente deve validar a cadeia de certificados.

Mesmo assim, assinatura válida não confirma que a afirmação registral permanece fisicamente verdadeira. Ela não prova que a aeronave esteja na coordenada alegada, que o operador tenha licença, que a transmissão ocorreu naquele ponto ou que uma ação foi executada. Autenticação fortalece uma afirmação dentro de seu escopo; não amplia o escopo.

O princípio institucional é simples: um registro descreve a realidade que lhe compete, não cria toda a realidade. Coordenação fina deve preservar unicidade, exatidão, prova de controle, segurança e auditabilidade. Quando um sistema transforma a facilidade de consulta em veredito universal, entrega ao registrador uma autoridade que a evidência não sustenta.

Publicar pode parecer operar

O RFC recomenda publicação just-in-time quando possível. A chave poderia aparecer pouco antes do voo e desaparecer ao final. Isso reduz exposição prolongada, porém convida outra inferência automática: registro presente significaria aeronave em operação.

Não há tal garantia. Um registro pode ter sido preparado cedo, sobreviver a uma missão cancelada ou permanecer em cache. Um voo real pode começar sem atualização por falha de conexão. TTL, cache negativo, caminho do resolvedor e diferença de relógio mudam a fotografia disponível. Publicação e presença física precisam de tempos e provas próprios.

A arquitetura também cria custo institucional. Credenciais, contratos, taxas e transações antes de cada voo podem gerar atrito. O RFC reconhece que registro dinâmico pode não escalar e admite alternativas de alocação. Se constar do diretório virar condição para operar, quem controla a entrada ganha poder econômico. Limites e recurso contra esse poder devem ser explícitos, não presumidos a partir de um resultado DNS.

Fontes