Resumo

  • A Homenet Naming Authority monta e assina a zona pública, guarda as chaves privadas DNSSEC e funciona como primário oculto; o Distribution Manager e os servidores autoritativos entregam a visibilidade externa.
  • TLS mútuo autentica os participantes do controle e da sincronização, mas não comprova posse do domínio, atualização do DS pai, distribuição de uma geração nem validação fora da residência.
  • A operação precisa ligar direito, seleção, assinatura, transferência, distribuição, delegação, observação e retirada por meio da mesma identidade de geração.

O reset que não apagou a autoridade antiga

O roteador deixa de funcionar e o morador executa uma restauração de fábrica. A nova instalação cria chaves DNSSEC, encontra o provedor e volta a anunciar nomes. Só então a equipe descobre que a credencial usada para comandar o antigo Distribution Manager existia apenas no equipamento apagado. A zona anterior continua pública e suas assinaturas ainda são válidas.

Esse cenário é ilustrativo, não um incidente relatado pelo RFC. Ele mostra por que a posse de uma chave de assinatura e a capacidade de retirar uma publicação não são o mesmo poder. O RFC 9526 mantém o material DNSSEC no HNA, mas usa outra identidade para autenticar o canal de controle. Perder uma credencial não necessariamente invalida a outra.

Uma arquitetura simples para o usuário pode conter várias autoridades administrativas. O lar escolhe e assina. O DOI recebe e distribui. O registrador ou operador da zona pai conecta o DS. O público observa por meio de resolvers. Se a evidência desses passos desaparece junto com o roteador, o sistema automatizou a criação sem garantir a saída.

Publicar não é exportar home.arpa

O objeto do RFC é a Public Homenet Zone sob um domínio registrado. A zona local home.arpa continua interna e fora do fluxo público. Essa distinção impede que a descoberta doméstica vire uma lista pública por inércia.

O HNA pode recolher nomes e endereços por DHCP, mDNS, UPnP, PCP ou configuração manual. Depois precisa selecionar. Endereços link-local não pertencem à zona pública. Endereços privados ou ULA podem ser úteis para acesso por VPN, mas um nome resolvido não significa um serviço acessível a qualquer origem.

O primeiro recibo deve registrar a política de seleção: itens incluídos, itens recusados, versão da regra, aprovador e finalidade. Sem isso, a zona final não explica se o nome de uma câmera foi deliberadamente publicado, entrou por descoberta automática ou permaneceu depois que o dispositivo saiu da casa.

Nomes também carregam privacidade. Em geral, são mais memoráveis e estáveis que endereços e podem revelar função, hábito ou presença. NSEC3 e transferência criptografada reduzem alguns caminhos de enumeração, mas não transformam uma etiqueta pública em segredo.

A autoria criptográfica não sai da residência

Todo o conteúdo da zona pública é criado pelo HNA. Ele assina com DNSSEC e administra as chaves privadas. A arquitetura não prevê transferência dessas chaves para o DM.

O HNA opera como primário oculto. Seu endereço não deve aparecer em NS público sem proteção adicional, nem o equipamento deve responder consultas ordinárias da Internet. Os servidores públicos pertencem à DNS Outsourcing Infrastructure.

O arranjo limita o terceirizado: ele recebe uma afirmação assinada, não o poder de inventar outra. Mas o terceirizado ainda controla quando busca a nova série, para quais nós a envia e por quanto tempo uma versão anterior permanece visível. A casa segura a caneta; o DOI controla boa parte da tiragem e da entrega.

Por isso, “assinado” e “publicado” são estados diferentes. O primeiro deve citar série, hash, DNSKEY e validade das assinaturas. O segundo deve citar instâncias autoritativas, série observada e janela de medição. A existência de uma assinatura não autoriza inferir distribuição.

Controle e sincronização mudam os papéis

No Control Channel, o HNA inicia uma conexão com o DM. Eles trocam parâmetros de delegação, dados para o DS e o endereço do serviço de sincronização, usando autenticação TLS mútua.

No Synchronization Channel, o DM passa a ser cliente TLS e o HNA atua como servidor e primário oculto. AXFR ou IXFR leva a zona. NOTIFY acelera a verificação; os temporizadores SOA permitem que o secundário procure mudanças mesmo sem receber um aviso.

Os mesmos endereços podem participar dos dois canais, mas as afirmações são distintas. O canal autenticado prova quem estabeleceu a sessão conforme uma regra de confiança. Para provar a série transferida, o operador precisa de leitura e hash. Para provar distribuição pública, precisa de outra observação.

O certificado do HNA também não é prova automática de que seu portador possui o Registered Homenet Domain. Identidade de dispositivo, direito registral e chave DNSSEC podem ter proprietários e calendários diferentes. Autenticação não deve ser promovida silenciosamente a autorização, execução e resultado.

O trecho até o público depende da implementação do DOI

O DM recebe a zona como secundário oculto e a distribui aos servidores autoritativos. O RFC chama isso de Distribution Channel, mas deixa o mecanismo aberto: AXFR, cópia de banco, REST ou outra solução.

A escolha acomoda plataformas reais. Ela também impede que o comprovante HNA–DM represente automaticamente todos os nós. Anycast, regiões múltiplas e versões de software diferentes podem esconder uma implantação parcial atrás de um único endereço.

O DOI deve produzir evidência por geração: o que o DM aceitou, quais destinos aplicaram, que série e DNSKEY cada classe de instância retorna e qual quórum foi considerado suficiente. Sondas externas em várias redes observam o serviço, mas não substituem o inventário interno.

Uma conclusão útil preserva limites: “a série 108 chegou ao DM; quatro perspectivas responderam 108; uma ainda respondeu 107”. Dizer apenas “publicado” elimina a informação necessária para corrigir a divergência.

A resposta NOERROR ainda não é a zona pai

O HNA fornece o hash da KSK como DS. Quando o DOI tem relação com registrador ou registro, pode encaminhar a atualização ao pai. A aceitação pelo DM produz NOERROR como compromisso de atualizar o DS.

O compromisso termina no DM. Ele não é leitura do pai, conclusão do processo registral ou expiração de caches. Uma conta sem autoridade pode falhar depois da aceitação; um DS antigo pode permanecer; duas referências podem coexistir de modo indesejado.

Delegação segura exige zona filha assinada, DS correto no pai e um validador capaz de montar a cadeia. O RFC manda assinar mesmo quando o HNA não consegue providenciar delegação segura. Assim, uma assinatura pode ser correta e ainda estar desconectada da confiança pública.

O registro operacional precisa do DS enviado, resposta do DM, leitura do pai e validação independente. Reduzir tudo a “DNSSEC ligado” impede localizar a quebra durante rotação ou migração.

A posse do domínio vem antes das mensagens do RFC

O DOI não deve servir a zona se não estiver confiante de que o HNA possui o domínio registrado. O RFC, porém, deixa a prova fora de escopo. Existe uma autoridade anterior ao protocolo.

Se DOI e registrador são a mesma organização, conta e contrato podem formar a base. Se o DNS está com um provedor independente, outro método é necessário. Em ambos, direito sobre o domínio, certificado de controle e chaves DNSSEC podem seguir ciclos separados.

Uma migração deve mapear quem altera o pai, qual identidade comanda o DM, que chave assinou a geração atual e quando o provedor antigo deixa de responder. Um backup do arquivo de zona não restaura a credencial de controle. Uma nova chave não concede o domínio.

Revogar é mais difícil que ativar

O HNA deve conseguir solicitar ao DM a exclusão da delegação. O DM precisa parar de servir a zona e pode responder NOERROR para indicar a remoção.

Essa resposta cobre um limite. Cópias públicas precisam sumir, NS e DS do pai podem exigir mudanças e caches sobrevivem até o TTL. Numa troca de fornecedor, a nova autoridade pode começar antes de a antiga desaparecer.

O comprovante de retirada observa ausência: antigo DM, todos os destinos públicos conhecidos, registros no pai, validade de assinaturas, horizonte de cache e início do substituto. Enquanto a infraestrutura velha responder, resta poder operacional, mesmo que a nova esteja saudável.

A exclusão de um HNA inativo depende do acordo comercial. O direito técnico do cliente de retirar e o direito contratual do provedor de limpar são poderes diferentes. Seus prazos e meios de contestação devem aparecer na governança.

Renumeração cria várias linhas do tempo

Quando o prefixo muda, o HNA atualiza os endereços, informa ao DM sua nova localização e provoca outra transferência. Em make-before-break, prefixos coexistem. Em troca brusca, o antigo pode morrer antes que o novo esteja pronto.

O HNA deve atualizar a localização ao inicializar porque não sabe quanto tempo ficou desligado nem se a zona assinada expirou. Endereço desejado, série do HNA, cópia do DM, cópias públicas, pai e caches não avançam atomicamente.

O monitoramento precisa comparar essas linhas. Um endereço velho pode estar corretamente em cache e já ser inalcançável. Um novo pode surgir antes da regra de firewall. A resolução local pode continuar durante queda de WAN, escondendo o envelhecimento público. A pergunta útil é: qual geração cada fronteira aceita, em que horário e até quando?

Fontes

Fontes