Resumo

  • O bit Authoritative Answer do DNS está ligado ao nome da pergunta ou ao primeiro nome proprietário em Answer; alvos de alias, registros de Authority, glue e dados de Additional na mesma mensagem podem ter procedências diferentes.
  • Um recibo auditável separa cada RRset por proprietário, tipo, seção, corte de zona, origem em cache e estado DNSSEC, preservando as consultas seguintes em vez de transformar um bit de cabeçalho em autoridade ou autenticidade para o pacote todo.

Um resolvedor consulta loja.example. O servidor tem autoridade sobre esse nome e devolve um CNAME. Um endereço do destino, obtido no cache, vem logo depois; Additional inclui outro endereço capaz de poupar uma consulta. AA está marcado.

O banco operacional grava tudo em uma linha: authoritative=true. Mais tarde, a zona do destino responde diretamente com outro endereço. Já não é possível saber se a diferença veio de uma atualização, do relógio do cache ou do dado adicional, porque a trilha foi achatada antes do conflito.

O exemplo é hipotético. Ele testa o desenho do recibo, não acusa um servidor ou operador real.

A autoridade começa em um nome

O RFC 1035, de Paul Mockapetris, define AA como um bit válido em respostas: o servidor declara ser autoridade para o nome de domínio da seção Question. O texto prevê que aliases podem produzir vários nomes proprietários em Answer e, nesse caso, vincula AA ao nome que corresponde à consulta ou ao primeiro proprietário da seção.

Portanto, AA não é um carimbo repetido ao lado de cada RRset. Ele situa o servidor na entrada do caminho de resposta. Aplicar a mesma autoridade aos nomes seguintes, a todas as seções e a qualquer fonte de dados é uma inferência feita fora do protocolo.

O RFC 1034 mostra por que a mistura é normal. Ao encontrar um CNAME em sua zona, o servidor o copia para Answer, muda QNAME para o nome canônico e reinicia o processamento. Numa delegação, coloca NS em Authority e endereços disponíveis em Additional, recorrendo a glue, dados autoritativos ou cache. Antes de sair, pode juntar outros registros locais considerados úteis.

Uma mensagem pode ser íntegra como resposta e heterogênea como prova.

A seção é uma pista de procedência

RFC 1035 distingue Answer, que responde; Authority, que aponta para a autoridade; e Additional, que relaciona informação útil sem constituir estritamente a resposta. Preservar essa posição evita a primeira confusão. Ainda assim, o nome da seção não informa sozinho quem publicou o RRset.

Na fronteira de uma delegação, o pai pode fornecer como glue o endereço do servidor do filho. Sem isso, descobrir o endereço exigiria perguntar justamente ao servidor ainda inalcançável. O glue resolve o impasse, mas não transforma o pai em autoridade abaixo do corte nem equivale a uma resposta emitida pela zona filha.

O RFC 2181 ordena as fontes: arquivos e transferências de zona sem glue; dados autoritativos de Answer; Authority em resposta autoritativa; glue; Answer não autoritativo; Additional. Um RRset recebido depois como resposta autoritativa pode substituir o que antes foi guardado como Additional. O caminho inverso não ganha legitimidade só porque o valor já mora no cache.

Sem essa classificação, o cache lava contexto. Um endereço auxiliar reaparece como Answer e parece ter subido de patente. O tempo em memória reduziu seu TTL; não criou uma nova autoridade.

Um alias atravessa jurisdições

RFC 2181 observa que, numa resposta autoritativa para um alias, apenas o registro que descreve esse alias é necessariamente autoritativo. Os demais podem vir do cache. Quem precisa de autoridade sobre o nome canônico deve consultá-lo novamente.

O RFC 6604 reafirma que uma cadeia de CNAME ou DNAME pode ter estado autoritativo diferente em cada trecho. AA continua baseado no primeiro proprietário de Answer.

Assim, o servidor de loja.example pode afirmar com autoridade que o nome aponta para servico.fornecedor.test. Um endereço cacheado do alvo pode acelerar a resolução, mas não se torna fala autoritativa da zona do fornecedor. A consulta que cruza a fronteira precisa de outro recibo, com servidor e horário próprios.

O histórico deve modelar cada aresta: nome de entrada, RRset CNAME ou DNAME, zona emissora, mensagem de origem, próximo nome e consulta subsequente. Reduzir tudo ao endereço final atende um cache rápido, não uma investigação de atribuição.

Autoritativo não quer dizer autêntico

RFC 6604 é explícito: DNSSEC não protege o bit AA do cabeçalho. TSIG ou SIG(0) podem proteger a transação com um servidor; DNSSEC valida RRsets por meio de outra cadeia.

O RFC 4035 manda classificar cada RRset como Secure, Insecure, Bogus ou Indeterminate. RRSIG, DNSKEY, DS, âncora de confiança, prova de negação e política local sustentam a conclusão. AA não substitui nenhum desses elementos.

AD também não é uma versão mais forte de AA. Um servidor com DNSSEC só deve marcá-lo quando considera autênticos os RRsets relevantes de Answer e Authority. O cliente precisa confiar no resolvedor e no canal ou validar localmente. A promessa do cabeçalho não cobre automaticamente Additional.

Logo, um pacote pode ter AA correto para o primeiro nome, CNAME Secure, destino Insecure, glue em Additional e canal até o intermediário sem autenticação. Todas essas condições precisam coexistir no modelo, sem serem comprimidas num único selo verde.

O lugar de Mockapetris

O perfil do Internet Hall of Fame atribui a Paul Mockapetris a invenção do DNS em 1983 no Information Sciences Institute da USC. Os RFCs 1034 e 1035 registram sua autoria. A fotografia histórica pública da página fundamenta a identidade do retrato editorial.

Esses fatos não o fazem operador de um servidor atual, dono de uma zona ou responsável por uma implantação. Os RFCs posteriores são trabalho coletivo. A contribuição humana relevante aqui foi criar uma arquitetura que distribui autoridade e, por isso, exige que cada mudança de âmbito permaneça visível.

Um recibo por RRset

Comece pela consulta: QNAME, QTYPE, QCLASS, recursão, DO, CD, identificador e horário. Preserve os bytes da resposta, endpoint, transporte, autenticação da transação e instante de recebimento.

Divida então por RRset. Guarde proprietário, tipo, classe, seção, TTL observado, corte de zona, bailiwick, fonte conhecida, entrada e expiração no cache. Se o cliente não sabe se o servidor usou zona ou cache, mantenha a lacuna; não a preencha com AA.

Registre à parte a âncora de AA: QNAME inicial, primeiro proprietário de Answer, servidor e zona de autoridade. Cada CNAME, DNAME ou delegação cria um vínculo com a próxima consulta. NS do pai, glue e resposta do filho se relacionam sem virar o mesmo fato.

Acrescente estado DNSSEC por RRset, assinaturas, percurso DS/DNSKEY, âncora, política, hora e causa de falha. O AD recebido é uma alegação do resolvedor a montante. Quando a aplicação agir, anote qual RRset e qual geração do cache ela usou.

A conclusão precisa torna-se possível: este servidor marcou AA para este primeiro nome; este conjunto veio desta seção e fonte; este validador lhe deu este estado; uma consulta posterior estabeleceu a autoridade do nome seguinte; a aplicação consumiu este resultado. O bit volta a ser útil quando deixa de falar pela resposta inteira.

Fontes