Resumo

  • A RFC 9824 pode responder por um nome inexistente com RCODE NOERROR, seção Answer vazia e prova NSEC ou NSEC3 assinada contendo NXNAME. A afirmação autenticada está no corpo; o cabeçalho DNS não recebe proteção criptográfica.
  • O sinal EDNS Compact Answers OK pode restaurar NXDOMAIN, mas funciona salto a salto. O resolvedor precisa guardar essa capacidade com a prova em cache e ajustar a apresentação ao próximo consulente.
  • Respostas compactas reduzem material e trabalho de assinatura em comparação com outras formas de assinatura on-line, mas não permitem síntese negativa agressiva. Validação, apresentação, cache, carga e efeito na aplicação precisam de recibos separados.

O campo de status não era grande o bastante para a verdade

O caso de abertura é construído, não um incidente observado. Seu mecanismo é administrativo: quando o esquema de telemetria aceita apenas um resultado, a decisão sobre qual resultado sobreviverá se transforma em decisão de autoridade.

A RFC 9824, Compact Denial of Existence in DNSSEC, define uma forma alternativa de provar que um nome não existe. A negação DNSSEC convencional demonstra a ausência do nome exato e a impossibilidade de síntese por wildcard. Em assinatura on-line, isso pode exigir até dois NSEC assinados ou três NSEC3 assinados.

A resposta compacta muda a forma da proposição. Para um nome inexistente sem correspondência wildcard, o servidor autoritativo cria algo semelhante a NODATA: NOERROR no cabeçalho, Answer vazia e um único NSEC ou NSEC3 assinado que coincide com o QNAME. Para fins da prova, afirma que o nome existe, mas não possui dados do tipo consultado. Um registro de cobertura mínima basta.

O registro do RFC Editor e o Datatracker classificam o texto como Proposed Standard de setembro de 2025 que atualiza as RFCs 4034 e 4035. O histórico, as referências e os documentos que o citam registram o contexto público. Não provam implementação, ativação ou resultado operacional.

NXNAME dá significado assinado ao vazio

Answer vazia não basta. Um nome existente pode não ter o tipo solicitado. Um empty non-terminal existe porque há nomes descendentes, embora não tenha RRsets próprios. Esses casos podem produzir bitmaps tão escassos quanto o de um nome ausente.

A RFC 9824 define NXNAME, Meta-TYPE sintético de valor 128. Na modalidade NSEC, o bitmap de um nome inexistente contém RRSIG, NSEC e NXNAME. Na modalidade NSEC3, NXNAME é a única entrada. O empty non-terminal não traz esse marcador. Assim, a inexistência deixa de ser inferida do silêncio e passa a ser declarada em material assinado.

O IANA DNS Parameters registra NXNAME, a flag CO e o EDE 30. A coordenação do código torna o mecanismo nomeável; não demonstra que um servidor o emite nem que um resolvedor o valida.

NXNAME não é dado comum da zona. Deve aparecer apenas no bitmap NSEC/NSEC3 de uma Compact Answer para nome inexistente. Consulta explícita por esse QTYPE recebe FORMERR; o servidor pode acrescentar EDE 30, Invalid Query Type. O resolvedor não deve encaminhá-la nem iniciar resolução iterativa. A RFC 8914 fornece o quadro geral de EDE; a RFC 9824 define esse uso.

O RCODE apresenta; a assinatura prova

A RFC 9824 afirma que o cabeçalho DNS não é protegido criptograficamente e, portanto, o RCODE não pode ser autenticado. O corpo assinado é a base mais forte para concluir o estado.

Isso não torna o cabeçalho irrelevante. Bibliotecas e ferramentas de segurança dependem dele. Uma ferramenta pode ler NOERROR e classificar NODATA; o validador pode conferir RRSIG e NXNAME e concluir inexistência. Os dois registros precisam manter o ponto de observação. A coluna mais fácil não pode apagar a testemunha mais forte.

A RFC 4034 define NSEC, RRSIG e os demais registros DNSSEC. A RFC 4035 define processamento e negação autenticada. A RFC 9824 cria as exceções para o formato compacto dinâmico. A RFC 9364 resume DNSSEC, e a RFC 9499 consolida a terminologia. Nenhuma transforma um cabeçalho não validado em fato assinado.

O recibo mínimo reúne nome e tipo consultados, DO/CO, RCODE recebido, formato NSEC/NSEC3, presença de NXNAME, identificadores públicos de algoritmo e chave, resultado de validação, versão, tempo e impressão digital da prova. A chave privada fica fora.

Restaurar NXDOMAIN é uma decisão entre vizinhos

A RFC 9824 recomenda preservar NXDOMAIN quando possível. Para respostas DNSSEC, define a flag EDNS Compact Answers OK. Um resolvedor que envia CO declara aceitar NXNAME assinado com RCODE restaurado para NXDOMAIN. Um autoritativo que implementa ambos pode responder com CO e esse código.

Pela RFC 6891, EDNS é salto a salto. O resolvedor deve ligar o CO recebido aos dados em cache. Se o próximo consulente DNSSEC não enviar CO, o RCODE da resposta NXNAME volta a NOERROR.

A prova não mudou; mudou a apresentação local. Perder CO durante persistência ou replicação do cache impede reproduzir o contrato. Guardar somente o último RCODE impede dizer se houve validação, adaptação ao par ou simples repetição do upstream.

Compactação também redistribui custo

A RFC 4470 antecede o mecanismo com NSEC de cobertura mínima e assinatura on-line. A RFC 5155 define NSEC3. A RFC 9824 reduz tamanho e operações de assinatura diante de provas dinâmicas maiores e limita enumeração útil da zona.

Ao mesmo tempo, Compact Answers não permitem a síntese de NXDOMAIN e wildcard descrita nas RFC 8020 e RFC 8198. Consultas por subdomínios pseudoaleatórios podem alcançar o autoritativo em vez de serem absorvidas pelo cache.

O signatário on-line mantém capacidade privada em infraestrutura acessível pela Internet e calcula provas sob demanda. O formato compacto reduz trabalho relativo, não o transforma em assinatura pré-computada. A especificação reconhece exposição a negação de serviço computacional e mantém outras técnicas como escolha local quando os benefícios não compensam.

A aplicação é a última testemunha

Uma biblioteca de endereço pode receber NODATA para AAAA e perguntar depois por A no mesmo nome; NXDOMAIN poderia evitar a segunda consulta. O stub talvez não peça DNSSEC, a ferramenta talvez ignore o bitmap e o recursor talvez adapte o RCODE a um par sem CO.

A primazia do código em execução segue o que ocorreu: geração, assinatura, validação, interpretação de NXNAME, escrita do cache, decisão CO, RCODE entregue, consultas seguintes e efeito da aplicação. As camadas de realidade impedem tanto que NOERROR vença a prova assinada quanto que uma assinatura válida seja confundida com sucesso de aplicação.

Fontes

  1. IETF Datatracker: RFC 9824
  2. Histórico da RFC 9824
  3. Documentos que citam a RFC 9824
  4. Referências da RFC 9824
  5. Heng Lu: Minimum Initial Specification
  6. Heng Lu: Reality Layers
  7. Heng Lu: Running-Code Primacy
  8. IANA DNS Parameters
  9. Errata da RFC 9824
  10. Informações do RFC Editor
  11. RFC 4034
  12. RFC 4035
  13. RFC 4470
  14. RFC 5155
  15. RFC 6891
  16. RFC 8020
  17. RFC 8198
  18. RFC 8914
  19. RFC 9364
  20. RFC 9499
  21. RFC 9824