Resumo

  • A opção 23 do RFC 3646 fornece uma preferência de servidores recursivos e a opção 24 fornece uma lista de busca exclusiva do DNS; a entrega não comprova adoção nem uso.
  • O aceite de uma mudança deve reunir proveniência, política de precedência, estado efetivo, transformação do nome, consulta real, validação e efeito na aplicação.

O roteiro de homologação costuma perguntar se o cliente recebeu endereços DNS. A pergunta é pequena demais. Um Reply pode chegar corretamente e ser rejeitado por uma configuração manual. Pode ser aceito e depois combinado com Router Advertisement. Pode instalar dois servidores e usar o segundo. Pode responder do cache. E a aplicação pode pedir um nome curto que se transforma antes de qualquer pacote DNS sair.

RFC 3646 define OPTION_DNS_SERVERS, código 23, com uma ou mais endereços IPv6 de servidores recursivos na ordem de preferência do resolvedor cliente. Define também OPTION_DOMAIN_LIST, código 24, para a lista de domínios de busca usada na resolução DNS de nomes de host, sem alcançar outros mecanismos. A versão em texto restringe as duas opções a Solicit, Advertise, Request, Renew, Rebind, Information-Request e Reply.

Preferência não é uma medição de serviço. A primeira posição não declara alcance, latência, saúde, seleção efetiva ou resposta correta. Para demonstrar qual servidor participou de um incidente, a equipe precisa do estado do host e do traço da consulta, não apenas do pacote de configuração.

A lista de busca muda a identidade consultada. RFC 1535 e RFC 1536 explicam riscos de listas implícitas e recomendações para nomes com pontos. A operação precisa ir além: registrar a entrada original da aplicação, cada sufixo acrescentado, a ordem das tentativas e a resposta escolhida. Sem isso, “DNS funcionou” pode significar que o nome errado respondeu corretamente.

Autenticação DHCP é uma defesa de origem. O RFC recomenda exigi-la antes de instalar a lista de servidores ou aceitar a lista de busca, porque um servidor intruso pode desviar consultas. Ainda assim, a autenticação não testa a saúde do serviço nem transforma configuração em resultado. RFC 4033 delimita outra prova: DNSSEC pode validar dados legitimamente assinados dentro de um domínio inválido introduzido pela busca. A assinatura confirma dados sob aquele nome; não confirma a intenção que gerou o nome.

O texto preserva autoridade local ao dizer que parâmetros DNS configurados manualmente não devem ser sobrescritos por DHCP. Assim, uma captura do Reply não decide qual estado deveria prevalecer. O aceite da mudança deve conferir a regra de precedência, a decisão de instalação e o estado lido de volta após a convergência.

Também há mais de um plano automático. RFC 8106 define opções de Router Advertisement para servidores recursivos e domínios de busca. Uma mesma direção pode existir por DHCPv6 e RA, com fontes e tempos de vida diferentes. Deduplicar apenas pelo valor destrói a proveniência necessária para entender persistência e retirada.

RFC 3315 forneceu a base original do DHCPv6; RFC 8415 é a base atual. RFC 8504 registra requisitos para nós IPv6. Essas obrigações ajudam a planejar testes, mas não comprovam o comportamento de uma máquina durante a janela.

A arquitetura em RFC 1034 e as mensagens em RFC 1035 permitem interpretar consultas e respostas. RFC 3397 traz o paralelo da lista de busca no DHCPv4. São contexto técnico; o recibo operacional continua sendo a observação daquele host.

O registro DHCPv6 da IANA coordena os códigos 23 e 24. Ele não atesta anúncio, aceitação, instalação ou resultado. A página no Datatracker, a ficha do RFC Editor, os errata e o histórico comprovam a origem documental, não uma implantação.

As lentes de Heng Lu sobre a primazia do código em execução, a especificação inicial mínima e as camadas da realidade orientam o controle de mudança. A especificação comum torna a troca possível. A política local decide o que instalar. O sistema em operação e a aplicação limitam o que a equipe pode afirmar como concluído.

O pacote de aceite deve conter interface e rede, identidade e autenticação DHCP, bytes das opções, configuração manual, regra de precedência, decisão de aceite, vida por fonte, estado instalado, nome original, candidatos, servidor e transporte escolhidos, cache, resposta, estado DNSSEC e resultado da aplicação. Cada lacuna deve aparecer como incerteza explícita.