Resumo

  • O RFC 9704 permite comparar uma declaração recebida na rede local com um valor publicado pela zona pai. A aprovação pode ser verificada sem transformar a lista de subdomínios privados em um inventário público.
  • O nome de autenticação do resolvedor permanece exposto no nome do registro de verificação. Uma informação sensível colocada ali não fica protegida apenas porque a lista foi ocultada.
  • Autorizar uma zona filha estável reduz alterações públicas, mas também dá espaço para novos nomes surgirem sob uma aprovação anterior.

Um nome de infraestrutura pode acabar contando uma história que ninguém pretendia anunciar. Se ele incorpora o nome de um projeto, de uma reorganização ou de um serviço ainda reservado, sua publicação já é uma decisão de divulgação. Não é preciso que exista uma lista completa de sistemas para que apareça uma pista.

Esse problema merece atenção quando uma empresa quer manter nomes internos fora da vista pública e, ao mesmo tempo, demonstrar que um resolvedor local tem autorização para responder por eles. O desenho do RFC 9704 permite separar as duas necessidades. Ele não promete, contudo, que tudo relacionado à autorização se torne invisível.

O ponto de partida é uma situação conhecida: alguns nomes precisam de respostas diferentes dentro da rede. O cliente pode já usar um serviço externo de DNS criptografado para suas consultas comuns. Encaminhar tudo ao resolvedor local resolve a necessidade interna ampliando bastante a mudança. Ignorar qualquer informação local preserva a escolha anterior, mas pode impedir que os serviços internos sejam encontrados da maneira esperada.

Existe espaço para uma exceção específica, verificável e limitada. A pergunta deixa de ser apenas “qual servidor a rede anunciou?” e passa a incluir o que deve ser publicado para justificar o uso daquela exceção.

A lista local e a confirmação pública

Publicado em janeiro de 2025, o RFC 9704 descreve um mecanismo de DNS com visões distintas validadas. Ele se aplica a clientes capazes de combinar métodos de resolução, a nomes enraizados no DNS global e a resolvedores com comunicação criptografada e autenticada.

A rede fornece uma declaração que identifica o resolvedor, a zona pai e os subdomínios reivindicados, além do algoritmo de hash e de um valor aleatório de sal. O operador da zona pai aprova o conteúdo e publica um token calculado a partir da representação canônica do conjunto de nomes e do sal.

O cliente recebeu a declaração local e pode calcular o resultado esperado. Ao verificar o registro TXT correspondente na zona pública, consegue comparar esse resultado com a aprovação. A lista de nomes não precisa ser reproduzida no registro público para que a comparação seja possível.

Um hash não é uma agenda interna criptografada que será depois aberta com uma senha. O sal também não é um segredo escondido dos clientes que recebem a declaração. O mecanismo distribui informações diferentes para públicos diferentes; não elimina a necessidade de que os participantes locais conheçam aquilo que vão usar.

Isso oferece uma forma mais cuidadosa de exigir transparência. Uma autorização pode precisar de comprovação externa sem que todos os detalhes operacionais precisem de divulgação irrestrita. Tornar o responsável identificável não exige necessariamente publicar seu inventário interno.

A organização continua precisando desse inventário para si. Guardar somente o token deixaria o próximo operador sem saber qual conjunto foi aprovado e por quê. O registro interno deve preservar o significado da decisão, com escopo, finalidade e responsável. Menos exposição pública não pode virar menos capacidade de explicar a operação.

A tabela de domínios de provisionamento da IANA registra splitDnsClaims e os cinco campos da declaração. Essa padronização ajuda a expressar o mesmo tipo de informação em sistemas diferentes. Não comprova suporte em um modelo de equipamento, adoção por uma empresa ou resultado de uma implantação.

A identidade que fica do lado de fora

O nome do registro de verificação inclui o nome de autenticação do resolvedor. O RFC chama atenção para o possível vazamento quando essa identidade contém informação sensível. A lista privada pode estar protegida contra divulgação pública e, ainda assim, seu representante público revelar demais.

Considere apenas como hipótese um resolvedor batizado com o codinome de uma aquisição ainda não anunciada. Não seria necessário descobrir os subdomínios individuais para obter uma informação relevante. O problema estaria na nomenclatura escolhida, não na quebra do algoritmo.

A identidade pública merece, portanto, revisão própria. Ela precisa servir à autenticação e à verificação da autorização, mas não precisa reproduzir a estrutura comercial ou os nomes dos projetos atendidos. Mesmo uma sigla aparentemente neutra pode ter significado para alguém que conheça os padrões da organização.

Esse cuidado é diferente de uma promessa de anonimato. O desenho admite que parte da informação seja pública. O objetivo é decidir qual parte é necessária e evitar que detalhes adicionais sejam publicados por hábito.

Há ainda uma fronteira que o transporte criptografado não muda: o resolvedor conhece as consultas que recebe. O RFC 9463 destaca que criptografar o DNS não reduz os dados disponíveis no próprio resolvedor. A proteção contra observadores do caminho não apaga a relação de informação com o serviço escolhido.

Por isso, terceirizar uma visão interna continua exigindo uma decisão sobre o fornecedor. A orientação técnica de gateways do ACSC, da ASD recomenda considerar os modelos de confiança e ameaça antes de expor visões internas a prestadores externos. Também alerta para não tratar a seleção de respostas por endereço IP como um mecanismo de segurança. A referência da orientação ao RFC 9704 não é certificação de uma implantação nem levantamento de compatibilidade.

Resolver o nome de um sistema tampouco autoriza o usuário a entrar nele. Login, identidade e permissões da aplicação precisam continuar funcionando mesmo se o nome se tornar conhecido. A ausência de uma lista pública não substitui esses controles.

Confirmar a autorização sem depender apenas de quem a pede

O registro público só é útil se a rede local não puder fabricar a resposta empregada para validar sua própria declaração. O RFC 9704 admite uma consulta por um resolvedor externo criptografado previamente configurado ou uma validação DNSSEC completa feita pelo cliente.

Na primeira alternativa, o cliente mantém as regras de aceitação que já utiliza com aquele serviço. Se não obtiver resposta em um tempo razoável, a verificação falha. A necessidade de abrir uma aplicação interna não transforma a falta de resposta em aprovação.

Na segunda, o estado Secure permite usar o resultado. Bogus e Indeterminate provocam rejeição. Para Insecure, recomenda-se tentar outro método; se o cliente não tentar novamente, a validação deve ser considerada malsucedida. Os estados não são apenas mensagens diferentes para uma mesma decisão permissiva.

O mecanismo não serve para validar dessa maneira nomes de uso especial, como local., nem dá à rede permissão para filtrar domínios de terceiros. A zona pai apropriada participa da autorização de seu próprio espaço.

Descobrir o resolvedor e conferir seu certificado continuam sendo tarefas necessárias, mas limitadas. O RFC 9463 fornece nome de autenticação, endereços e parâmetros de serviço. Sua verificação de certificado compara o servidor ao nome informado; ela não atesta, sozinha, a segurança do mecanismo de provisionamento ou a confiança do usuário na rede. O RFC 9704 acrescenta a autorização para um conjunto específico de nomes.

O tamanho da exceção muda o trabalho de amanhã

Uma zona filha estável pode reunir os serviços internos. O RFC 9704 recomenda essa organização para reduzir a frequência de alterações no registro público de verificação. Ela não é obrigatória apenas para evitar a divulgação dos nomes individuais.

A conveniência é fácil de entender: quando o âmbito já está aprovado, a equipe pode acrescentar serviços dentro dele sem pedir uma nova mudança pública a cada vez. Isso reduz a necessidade de coordenação entre quem administra a zona interna e quem controla a zona pai.

Mas o que se delega não é apenas a lista existente no dia da aprovação. Há também uma margem para criar nomes futuros. Uma análise que examine somente a fotografia atual pode aprovar mais autonomia do que percebe.

Não existe um tamanho correto para todos os casos. Um serviço sensível e estável pode justificar um conjunto restrito. Uma plataforma interna com muitas mudanças pode justificar uma zona filha coerente. Reivindicar todo o domínio pai é uma decisão mais ampla, que não deveria resultar apenas da busca por menos chamados.

As atualizações também precisam de coordenação. O novo registro público deve existir antes da mudança na declaração correspondente; o antigo precisa permanecer pelo período exigido para as configurações ainda válidas. O RFC 8801 define separadamente a expiração e a atualização das informações do domínio de provisionamento. Não há uma única gravação que garanta a troca simultânea de todos os clientes.

Este artigo analisa documentos, não apresenta teste de equipamentos, medição de adoção, incidente observado ou cálculo de economia. A conclusão operacional é que manter uma exceção estreita exige capacidade de manutenção. Quando essa capacidade falta, ampliar o âmbito pode parecer uma correção de eficiência, embora seja também uma redistribuição de autoridade.

Uma boa solução permite comprovar a necessidade local sem entregar todas as consultas à mesma rede e sem transformar o catálogo interno em informação pública. Para isso, a identidade exposta, o escopo delegado e o processo de renovação precisam ser escolhas conscientes.