Resumo

  • O RFC 9527 define opções DHCPv6 para o domínio residencial registrado e para os gestores de distribuição direta e reversa.
  • Um Reply correto comprova a entrega da configuração, não a delegação do pai, a aceitação da zona, a validade do DNSSEC nem a resposta observada por redes externas.
  • A garantia operacional precisa unir sete recibos: configuração, autoridade, canal autenticado, publicação, validação, alcance e ciclo de vida.

O novo equipamento recebeu tudo o que a operadora pretendia: o domínio registrado, o gestor da zona direta, o gestor da zona reversa e a indicação de transporte. Mesmo assim, durante a troca de prefixo, consultas externas continuaram encontrando a versão anterior.

Esse é um cenário analítico, não um incidente atribuído a fornecedor. Ele marca o limite do RFC 9527. O padrão entrega coordenadas para que a Homenet Naming Authority prossiga. Não declara que a autoridade pública já mudou.

O que as três opções realmente dizem

OPTION_REGISTERED_DOMAIN, código 145, transporta o FQDN do domínio residencial. OPTION_FORWARD_DIST_MANAGER, código 146, informa o FQDN do gestor direto e os transportes suportados. OPTION_REVERSE_DIST_MANAGER, código 147, faz o mesmo para o lado reverso.

O cliente pede os códigos no ORO. O servidor responde se tiver os valores configurados. É possível preservar bytes, servidor, interface, lease e horário, criando um recibo preciso da configuração recebida.

Depois disso, o FQDN do gestor ainda precisa resolver. HNA e gestor precisam se autenticar. A zona precisa ser montada e aceita. A delegação superior precisa apontar para os servidores certos. DNSSEC precisa validar. Só então uma consulta independente pode confirmar o estado público.

A terceirização começa depois do Reply

O RFC 9527 depende do RFC 9526 para o processo de terceirização. A divisão é deliberada: DHCPv6 fornece parâmetros; o fluxo de nomeação altera a autoridade DNS.

O bit obrigatório de DomTLS no campo Supported Transport ilustra a diferença. Ele anuncia suporte a DNS sobre TLS mutuamente autenticado e transferência de zona sobre TLS. Não registra um handshake concluído, o certificado aceito, a política aplicada ou o serial publicado.

Assim, uma captura perfeita pode coexistir com cadastro antigo de assinante, FQDN apontando para endpoint desativado, autenticação seguida de rejeição, zona aceita antes da delegação, ou DS e DNSKEY fora de sincronia.

Registro padroniza significado

A IANA atribui os códigos e mantém o registro de transportes. Isso impede interpretações incompatíveis do mesmo valor. Não certifica implementação em roteadores, qualidade do cadastro do ISP nem existência de zona pública.

Texto normativo, pacote DHCPv6, log do gestor e resposta externa pertencem a camadas diferentes. Ligá-los aumenta a confiança. Usar o primeiro resultado verde para representar todos os outros cria apenas uma aparência de conclusão.

Direto e reverso têm guardiões diferentes

O provedor de acesso conhece o prefixo e pode operar a autoridade reversa. O domínio direto pode pertencer ao ISP, ao assinante ou a uma infraestrutura terceira. Por isso, os gestores são separados.

Após mudar o prefixo, o nome direto pode apontar para o endereço novo enquanto a zona reversa mantém o antigo. Após trocar o HNA, a nova zona pode ser recebida sem retirar a anterior. Cada lado precisa registrar objeto, gestor, par autenticado, versão, servidores autoritativos, assinatura e respostas observadas.

Conveniência concentra poder

No cenário básico, o ISP pode controlar DHCPv6, os dois gestores e os servidores autoritativos. A experiência fica simples e a substituição do equipamento pode ser automática. Ao mesmo tempo, domínio, autenticação e publicação ficam reunidos.

Isso não prova abuso nem falha. Exige apenas observação independente. Uma consulta de redes fora do ISP responde a uma pergunta que o log interno não consegue responder sozinho: a Internet vê a zona que o operador considera publicada?

Domínios de terceiros acrescentam registrar, titularidade, redirecionamento e credenciais. Múltiplos ISPs podem entregar múltiplos domínios; o RFC deixa essa gestão à implementação. Failover de acesso, portanto, não é sinônimo de continuidade de nome.

Sete recibos

O recibo de configuração guarda a troca DHCPv6 e o lease. O de autoridade guarda titularidade, prefixo e delegações. O de canal guarda resolução, certificado, regra de confiança e transação aceita.

O de publicação guarda versão, serial e servidores. O de validação guarda DNSSEC e respostas negativas. O de alcance consulta de redes independentes por IPv4 e IPv6. O de ciclo de vida cobre renew, rebind, prefixo, troca do HNA, mudança de ISP, rollback e retirada do estado antigo.

A separação de Heng Lu entre especificação, código em execução e realidade observada vira disciplina operacional. O RFC define o mínimo comum; decisões locais conectam identidades e fornecedores; o DNS público revela o resultado.

Limites

As fontes não oferecem censo de adoção, lista de produtos, falha nomeada ou taxa de incidentes. O exemplo inicial é uma hipótese de controle. Registro IANA também não equivale a suporte de produto.

“O HNA recebeu a configuração RFC 9527” é uma conclusão sustentada. “A casa tem DNS público autoritativo, validado e recuperável” requer os demais recibos.

Fontes