Resumo

  • Um DET é um identificador de 128 bits em forma IPv6, não um localizador. A RFC 9886 o mapeia para a árvore de DNS reverso sob 2001:30::/28.
  • O identificador hierárquico de 28 bits é dividido entre Registered Assigning Authority (RAA) e HHIT Domain Authority (HDA). A delegação DNS expressa essas camadas de registro.
  • Um nome DET deve resolver para um registro HHIT; no caso de UAS Remote ID, um registro BRID também deve estar presente. DNSSEC é obrigatório para entidades de ápice e recomendado para as demais.

O ponto de entrada operacional é 3.0.0.1.0.0.2.ip6.arpa, o espaço reverso associado a 2001:30::/28. As delegações abaixo dele representam as camadas RAA e HDA. Isso faz do DNS uma superfície de controle: uma resposta positiva demonstra que há dados no caminho consultado, mas não prova, sozinha, que a entidade tem inclusão registral verificável.

O RRType 67, HHIT, contém metadados de registro e um certificado de registro canônico. O RRType 68, BRID, contém informações estáticas do UAS Broadcast RID, incluindo endossos. Para quem valida, esses papéis não se substituem: HHIT liga o DET aos dados de registro e ao certificado; BRID fornece a informação estática necessária ao uso de UAS Remote ID. No cenário UAS, a presença de um não elimina a exigência do outro.

Fixture de verificação DNS

Os comandos abaixo são pontos de partida concretos para uma verificação reproduzível. Eles não representam um serviço implantado, um provedor, uma medição de disponibilidade ou uma entidade de produção:

dig +dnssec 3.0.0.1.0.0.2.ip6.arpa NS
dig +dnssec 3.0.0.1.0.0.2.ip6.arpa DS
dig +dnssec <owner name reverso calculado exatamente a partir do DET recebido> HHIT
dig +dnssec <o mesmo owner name> BRID

O operador deve validar primeiro delegação, DS, RRSIG e a cadeia de validação; depois deve examinar o certificado de registro no HHIT. Para UAS Remote ID, deve confirmar também a existência e a interpretação do BRID segundo a RFC. Os sinais de menor e maior descrevem a etapa de inserir o nome exato calculado do pacote recebido; não são um nome de exemplo que este texto declare válido. Este briefing não reproduz as strings de bytes dos exemplos de apêndice corrigidas pelas erratas verificadas 8822 e 8823.

A RFC 9886 separa dados e ponteiros públicos de DNS dos registros privados. O DNS público oferece material de verificação pública; um registro privado pode manter dados que não devem ser expostos. A RFC, porém, não especifica os mecanismos AAA usados para proteger informações pessoalmente identificáveis. Também permanecem desconhecidos, neste pacote factual, adoção e produção atuais, disponibilidade ou latência de DIME ou de qualquer registro implantado, política ou preço por jurisdição, cobertura de fornecedores e resolvedores, abuso, incidentes, privacidade e resultados de rastreabilidade.

Quando há DNSSEC para uma entidade de ápice, o cliente pode usar dados DNS autenticados. Sem DNSSEC, a RFC 9886 exige que o cliente percorra a hierarquia de certificados por consultas HHIT sucessivas para provar o registro. Uma resposta DNS não autenticada não basta. O caminho do certificado e a presença, tipo e conteúdo dos registros continuam sendo verificações distintas.

Como o DET expõe uma chave pública para verificação de assinaturas, a RFC recomenda, quando for prático, adiar a publicação dos tipos de registro sob o DET até que sejam necessários. O mecanismo just-in-time não faz parte do escopo da RFC. A recomendação não é uma proibição de publicar nem uma medição de efeito de privacidade.

Fontes