Resumo

  • A RFC 9103 impede que um observador passivo copie o conteúdo de uma transferência de zona em texto claro. Ela não oculta necessariamente os servidores, o ritmo e o volume do tráfego, nem bloqueia enumeração por DNSSEC ou consultas autoritativas comuns.
  • Uma alegação XoT auditável precisa separar identidade do primário, autorização para a zona, TLS obrigatório, conclusão da transferência, aceitação da réplica, consistência do transfer group e custódia posterior.

O terceiro leitor nunca pediu a zona

Um servidor primário pode limitar AXFR a endereços conhecidos e exigir TSIG. Um cliente não autorizado será recusado. Mas, se a resposta autorizada cruzar a rede em TCP claro, um observador no caminho não precisa vencer a ACL nem possuir a chave compartilhada. Ele apenas lê a mesma sequência de registros entregue ao secundário legítimo.

A RFC 9103 foi publicada em agosto de 2021 no Standards Track do IETF para remover esse leitor. Ela define XFR over TLS, abrangendo AXFR completo e IXFR incremental. O ganho é relevante porque uma sessão de replicação oferece uma visão concentrada da zona: nomes, endereços e relações que seriam mais trabalhosos de reunir por consultas separadas.

O modelo de ameaça, porém, é preciso. Ele trata conteúdo e tamanho atuais da zona como sensíveis durante a transferência. Não tenta esconder que a zona existe, que há uma transferência ou quais servidores participam. Mesmo cifrado, o tráfego ainda pode revelar relações, horário e volume.

Por isso a frase correta é “este caminho deixou de expor o payload em claro”. Dizer “a zona ficou privada” exigiria uma cadeia muito maior.

Autenticação de mensagem não é sigilo de canal

A RFC 8945 define TSIG para autenticar transações DNS com segredo compartilhado e proteger sua integridade. A RFC 5936 usa TSIG na autorização de clientes de transferência. Mas TSIG não cifra. Uma transferência pode ser íntegra, ter origem autenticada e ainda assim ser legível por quem observa o caminho.

TLS resolve outro problema. Para XoT, o secundário deve autenticar o primário com perfil estrito; o primário deve validar o direito do cliente usando mTLS, ou ACL de IP combinada com TSIG/SIG(0). TLS estrito oferece identidade do servidor e confidencialidade do canal. mTLS acrescenta identidade do cliente. TSIG oferece autenticação da origem dos dados. Essas propriedades se complementam.

Aceitar uma conexão TLS não concede todas as zonas disponíveis no servidor. Várias requisições podem reutilizar o mesmo canal, e implementações comuns aplicam ACL quando chega cada XFR. Porta disponível, handshake concluído e autorização para copiar uma zona específica são recibos diferentes.

A proteção termina onde a exceção começa

A RFC chama de transfer group o conjunto de primários e secundários envolvidos. Para proteger o conjunto, todos os caminhos AXFR e IXFR precisam usar XoT. Um secundário legado, uma rota de contingência em claro ou um proxy que termina TLS antes do backend preserva a fraqueza.

O TLS oportunista não sustenta a mesma promessa. Ele pode continuar sem uma identidade de servidor validada ou voltar ao texto claro se TLS não estiver disponível. Isso talvez melhore outros fluxos, mas não prova uma política que proíbe fallback claro para transferências de zona.

O fallback deve ser descrito com cuidado. Se um IXFR indisponível vira AXFR na mesma conexão TLS autenticada, o volume muda, mas o canal pode continuar confidencial. Se a falha de TLS leva ao TCP claro, muda a própria propriedade de segurança.

Alguns testes negativos são simples: solicitar a zona em claro, sem TSIG ou de endereço não autorizado. Outros são difíceis de observar externamente: saber se todo secundário rejeita dados sem autenticação, usa perfil estrito e aplica XoT a novas réplicas. A coordenação e a imposição dessa política ficam fora do escopo da RFC 9103.

Depois da entrega existe outra administração

Considere uma transferência impecável. O secundário autenticou o primário; o primário autorizou o secundário; TLS 1.3 protegeu o IXFR; a nova série foi aceita. O observador passivo perdeu o conteúdo. Ao mesmo tempo, uma cópia entrou em outro domínio operacional.

Ela pode aparecer em arquivo de zona, journal, banco de dados, snapshot, backup ou log de suporte. Pessoas e ferramentas internas podem alcançá-la. O provedor pode replicá-la a outros secundários. O serviço autoritativo continuará respondendo publicamente aos registros destinados à publicação.

Esses fatos não contradizem TLS; começam depois dele. Por isso, a identidade do receptor não basta. O registro deve incluir local de armazenamento, acesso, retenção de backup e logs, destinos posteriores, processo de inclusão de peers e descarte. Revogar certificado ou chave TSIG bloqueia transferências futuras, não recolhe cópias já entregues.

ZONEMD deixa outra fronteira visível. A RFC 8976 oferece um digest para validar um objeto de zona independente do transporte. É complementar e ortogonal ao XoT. O digest não esconde o trânsito; TLS não comprova que o conteúdo seja correto, atual ou aprovado pela autoridade humana certa.

O serviço público não desaparece

A RFC 9103 separa escuta de transferência e enumeração de zona. NSEC pode permitir percorrer uma zona assinada. NSEC3 tenta dificultar a enumeração por meio de nomes com hash, mas tem limites próprios. Consultas autoritativas comuns continuam oferecendo os dados publicados.

Há, portanto, pelo menos três vias: captura do fluxo de réplica, enumeração por provas de inexistência e coleta gradual de respostas públicas. XoT fecha a primeira. Não seria correto negar essa melhoria só porque parte do DNS é pública; tampouco seria correto transformar a melhoria em segredo total.

Oito campos de uma prova operacional

Escopo: zona, versão da política, transfer group e responsáveis. Identidade do primário: nome de autenticação ou pin SPKI, certificado, versão TLS e endpoint. Admissão do secundário: mTLS ou ACL mais TSIG/SIG(0), decisão por zona e testes de recusa.

Transporte: AXoT ou IXoT, proibição de claro, fallback e limites de proxy. Conclusão: série pedida e aceita, mudança de IXFR para AXFR e erro. Custódia: armazenamento, acessos, backups, logs e replicação posterior.

Exposição residual: consultas comuns, NSEC/NSEC3, relações observáveis e sinais de tempo ou tamanho. Revalidação: troca de certificado, chave, ACL, proxy, secundário, topologia, assinatura ou operador.

Um handshake prova um canal. TSIG prova aspectos de uma mensagem. Uma série aceita prova estado da réplica. Nenhum deles prova sozinho a confidencialidade de todas as cópias.

Fontes