Resumo

  • A RFC 9083 define delegationSigned como verdadeiro quando há registros DS no pai; zoneSigned e os dados DS ou de chave são partes distintas do objeto RDAP secureDNS.
  • O campo é evidência cadastral, não um resultado de validação ao vivo. Uma conclusão DNSSEC defensável também requer o DS atual do pai, DNSKEY e RRSIG da zona filha, alcance dos servidores autoritativos, validade temporal e o resultado de um validador identificado.

Um booleano exato com alcance limitado

A resposta do LACNIC examinada para 84.7.200.in-addr.arpa é clara sobre o que apresenta. O objeto é da classe domain. Ele lista três servidores de nomes e um objeto secureDNS em que zoneSigned e delegationSigned são falsos, com o array dsData vazio.

Isso é evidência útil sobre o registro devolvido pelo LACNIC no instante da coleta. Não permite generalizar para todas as zonas reversas da região nem descreve o estado operacional atual dos servidores listados. A resposta não contém um rastreamento de resolução nem os pacotes necessários para reconstruí-lo.

A presença do DS no pai é apenas um elo

A RFC 9083 separa os significados de propósito. zoneSigned informa se a zona foi assinada. delegationSigned informa se existem registros DS no pai. dsData pode descrever a etiqueta da chave, o algoritmo, o resumo e seu tipo; keyData pode carregar material DNSKEY.

Esses campos descrevem dados de registro. A validação DNSSEC é uma operação feita sobre uma cadeia de respostas DNS atuais e em um momento específico. O validador obtém o DS do pai, consulta DNSKEY e registros assinados da zona filha, compara resumos e algoritmos, verifica assinaturas e janelas de tempo e trata falhas de alcance ou resposta. Um booleano RDAP não realiza essas etapas silenciosamente.

Verdadeiro e falso exigem linguagem disciplinada

Quando delegationSigned é verdadeiro, a afirmação sustentada é que a representação RDAP informa DS no pai. Isso não prova que a zona filha publique a DNSKEY correspondente, que as assinaturas estejam válidas, que a cadeia alcance uma âncora de confiança ou que um resolvedor específico valide com sucesso.

Quando o valor é falso, a representação informa ausência de DS no pai segundo a definição do campo. Ela não explica a ausência, não exclui uma alteração pendente nem garante que uma observação posterior concorde. É preciso guardar a URL, os bytes e a hora da resposta.

Preserve duas superfícies de evidência

A superfície cadastral deve guardar a URL exata do domínio RDAP, ldhName, a lista de servidores, os valores secureDNS, arrays de DS ou chaves, o hash da resposta e a hora da consulta. A superfície operacional deve guardar separadamente consultas DNS ao pai e à zona filha, endereços dos servidores, códigos, sinalizadores de autoridade, DNSKEY, DS, RRSIG, saída do validador e contexto do relógio.

Somente após comparar as duas superfícies é possível descrever a validação atual. Mesmo assim, o resultado pertence ao ponto e ao instante de observação identificados. Uma cadeia criptográfica válida não estabelece propriedade, autoridade contratual ou controle das máquinas.

Fontes