Resumo

  • NXDOMAIN nega a existência do nome efetivo; NODATA mantém o nome e nega apenas o tipo consultado. Por isso, uma resposta usa nome e classe como chave, enquanto a outra também precisa do tipo.
  • A RFC 2308 tornou a negativa transmissível e finita. O SOA da zona acompanha a resposta; o TTL negativo é o menor entre o TTL do próprio SOA e MINIMUM, e a cache deve abandonar a afirmação quando o contador chega a zero.
  • DNSSEC, o corte NXDOMAIN e a síntese agressiva ampliaram o alcance de uma prova validada. Ganham-se consultas, mas um escopo errado ou um prazo excessivo passa a ocultar mais dados. Assinatura DNS não comprova propriedade nem inexistência fora do protocolo.

A seção vazia não identifica a ausência

Um resolvedor pergunta pelo registro A de servico.example e não encontra A na seção Answer. Isso ainda permite várias explicações. O nome pode não existir. Pode ter MX, TXT ou AAAA, mas não A. A mensagem pode ser uma delegação. O servidor pode estar temporariamente indisponível ou retornar SERVFAIL.

Guardar a interpretação errada altera o namespace visto pelos clientes. Se a falta de A virar inexistência do nome, uma consulta posterior por MX pode ser bloqueada apesar de o correio existir. Se uma NXDOMAIN verdadeira for lembrada apenas como falta de A, o resolvedor desperdiçará consultas por AAAA, TXT e outros tipos.

NXDOMAIN é o Name Error do DNS e se aplica ao QNAME efetivo após qualquer cadeia CNAME. NODATA não tem RCODE próprio: é inferida de NOERROR, da ausência da resposta relevante e de dados de autoridade que permitam descartar uma simples referência.

A RFC 2308 transforma essa semântica em chaves. NXDOMAIN fica sob <QNAME, QCLASS>; NODATA sob <QNAME, QTYPE, QCLASS>. O QTYPE extra impede que a falta de um RRset apague todos os outros.

O CNAME muda o sujeito da negativa

O rótulo digitado pode existir e apontar para um alvo canônico ausente. Nesse caso, a NXDOMAIN diz respeito ao último alvo, não ao alias que entregou um CNAME válido.

Vincular a negativa ao primeiro nome por conveniência amplia a prova para outro sujeito. NODATA exige o mesmo cuidado: a ausência de um tipo no alvo não elimina os demais tipos, os dados do alias ou possíveis descendentes.

Cache negativa é evidência distribuída. Antes de compartilhar “não há”, o resolvedor precisa conservar com exatidão “em qual nome não há o quê”.

Uma lembrança que outros resolvedores podem usar

A RFC 1034 já descrevia cache negativa em 1987, mas como opção. Caminhos de busca, erros de digitação e descoberta automática repetiam consultas perdedoras. Memorizar a negativa reduzia tráfego e tempo de resposta.

Faltava, porém, uma forma robusta de repassar a outro resolvedor uma negativa já armazenada com a mesma evidência e o mesmo tempo restante. O “não” funcionava como memória local, não como afirmação portátil.

Publicada em março de 1998, a RFC 2308 corrigiu essa lacuna e tornou o tratamento obrigatório para quem mantém cache. Ao responder NXDOMAIN ou NODATA, o servidor autoritativo inclui o SOA da zona que contém o nome. O registro situa quem fala e fornece o relógio.

O prazo negativo é o menor entre o TTL do SOA e seu campo MINIMUM. O SOA fica associado ao resultado e seu TTL diminui durante a permanência na cache. Chegando a zero, a negativa não pode mais ser usada; é preciso observar a autoridade novamente.

Mark Andrews aparece na RFC 2308 com vínculo ao CSIRO. É proveniência do autor, não o tema institucional deste texto. O padrão compartilhado e as extensões posteriores foram desenvolvidos por meio do processo documental do IETF.

Um relógio reiniciado em cada salto nunca vence

O namespace é uma árvore, mas forwarders podem formar um grafo com laços. Dois servidores mal configurados podem encaminhar consultas um ao outro. Se cada um atribuir um novo prazo a uma negativa sem relógio portátil, a indicação pode circular indefinidamente.

É por isso que a RFC 2308 diz que respostas negativas sem SOA não deveriam ser armazenadas. Um limite local não limita nada se o próximo servidor começa a contagem de novo. O SOA faz os intermediários carregarem o declínio da mesma afirmação.

A correção também organizou MINIMUM. A RFC 1035 o descrevera como limite inferior de TTL; implementações misturaram mínimo, valor padrão e prazo negativo. A RFC 2308 separou o padrão do arquivo de zona em $TTL, abandonou o mínimo universal e manteve MINIMUM no cálculo negativo. O código em operação revelou a ambiguidade antes que a especificação a estreitasse.

O código encontrou duas ausências

O apêndice histórico da RFC 2308 registra o uso de cache negativa pelo CHIVES no fim dos anos 1980, quando caminhos de busca produziam muitas falhas repetidas. Registra também a evolução do BIND no início dos anos 1990: distinguir erro de nome de NOERROR_NODATA e, depois, preservar o SOA com a resposta.

Não é um censo da Internet nem uma narrativa de inventor único. É evidência de que “vazio” era uma categoria insuficiente. A precisão de RRsets da RFC 2181 e as tuplas da RFC 2308 transformaram descobertas de implementação em linguagem comum.

A eficiência pode atrasar uma criação

Uma negativa correta envelhece quando a zona muda. Se um nome for criado enquanto resolvedores guardam NXDOMAIN, parte dos usuários continuará vendo inexistência. Se AAAA for acrescentado após NODATA para AAAA, o nome e seus outros registros aparecem, mas a nova conectividade IPv6 demora.

TTL não mede certeza; troca consultas por velocidade de correção. A RFC 2308 permite que o resolvedor imponha teto menor e relata uma a três horas como padrões razoáveis, enquanto valores acima de um dia haviam causado problemas.

As caches recebem respostas em momentos diferentes e usam políticas próprias. Não existe um instante global de esquecimento. Planejar uma ativação requer conhecer as negativas publicadas antes da mudança, não apenas a zona servida depois dela.

Falha precisa permanecer separada de ausência. Timeout, servidor inalcançável e SERVFAIL não provam que um nome não existe. Convertê-los em NXDOMAIN pode transformar uma interrupção recuperável em rejeição de e-mail, falha de descoberta ou perda de identidade.

Quando uma prova passou a responder por um intervalo

DNSSEC adicionou negação autenticada. A RFC 4034 define NSEC, que liga nomes em ordem canônica e lista os tipos existentes em um owner. A RFC 4035 define a validação de NXDOMAIN e NODATA.

A assinatura não mistura os sentidos. Um intervalo entre owners pode provar ausência de nome; o bitmap de um owner existente prova ausência de tipo. A criptografia autentica a evidência correta, não uma conclusão maior.

A RFC 5155 introduziu NSEC3 e Opt-Out. Com Opt-Out, um registro que cobre um intervalo não prova necessariamente que todo nome possível esteja ausente.

A RFC 8020 permitiu usar NXDOMAIN para interromper buscas abaixo de um nó inexistente, dentro de seus limites. NODATA não permite isso: um nome sem A ainda pode ter outros tipos e filhos.

A RFC 8198 autorizou resolvedores validadores a sintetizar negativas a partir de NSEC/NSEC3 em cache. Uma prova passa a responder por consultas que nunca chegaram à autoridade. A economia aumenta, assim como o intervalo durante o qual um nome recém-criado pode continuar invisível.

Evidência limitada de protocolo

O operador da zona escolhe conteúdo e prazos. O servidor autoritativo monta a resposta. O resolvedor classifica, valida, limita e esquece. A aplicação decide o efeito sobre correio, login ou descoberta. Esses poderes não se somam em uma autoridade sobre a realidade externa.

DNSSEC comprova origem e integridade dentro da cadeia DNS. Não comprova direito jurídico, desaparecimento de uma organização ou correção moral de uma remoção. A cache pode amplificar uma negativa válida, mas não torná-la permanente.

O avanço histórico foi estreito e poderoso: identificar o sujeito, distinguir a espécie de ausência, carregar a zona responsável e impor o vencimento. Separar NXDOMAIN de NODATA permitiu economizar trabalho sem apagar dados que continuavam ali.

Fontes e limites

O desenho inicial e o SOA vêm das RFC 1034 e RFC 1035, com esclarecimento de RRsets na RFC 2181. Definições, chaves, relógio, laços e história de implementação vêm da RFC 2308. A negação autenticada é delimitada pelas RFC 4034, RFC 4035 e RFC 5155; o corte e a síntese posteriores pelas RFC 8020 e RFC 8198. O texto não projeta capacidades modernas em 1987 nem trata o apêndice como medição completa.