Alterações do número de sérieEditar
A parte preambular da transferência de zona depende do número de série, e apenas do número de série, para determinar se os dados de uma zona foram alterados e, portanto, se a transferência de dados real é necessária. Para alguns pacotes de servidores DNS, os números de série dos registros de recursos SOA são mantidos pelos administradores à mão. Cada edição no banco de dados envolve fazer duas alterações, uma no registro sendo alterado e a outra no número de série da zona. O processo requer precisão: o administrador pode esquecer de alterar o número de série ou alterá-lo incorretamente (reduzi-lo). A RFC 1912 (seção 2.2 registros SOA) recomenda usar o valor YYYYMMDDnn como número (YYYY=ano, MM=mês, DD=dia, nn=número de revisão). Isto não irá transbordar até ao ano 4294.
Alguns pacotes de servidores DNS ultrapassaram este problema ao construírem automaticamente o número de série a partir do último carimbo de tempo de modificação do ficheiro da base de dados no disco. Este é o caso dos djbdns, por exemplo. O sistema operacional garante que o carimbo de data/hora da última modificação é atualizado sempre que um administrador edita o arquivo de banco de dados, efetivamente atualizando automaticamente o número de série, e assim aliviando os administradores da necessidade de fazer duas edições (em dois lugares diferentes) para cada alteração.
Outras vezes, o paradigma de replicação de banco de dados para o qual a verificação do número de série (e de fato a própria transferência de zona) é projetada, o que envolve um único servidor DNS central contendo a versão primária do banco de dados com todos os outros servidores DNS contendo apenas cópias, simplesmente não corresponde ao de muitos pacotes de servidores DNS modernos. Os modernos pacotes de servidores DNS com back ends sofisticados como os servidores SQL e Active Directory permitem aos administradores fazer actualizações à base de dados em múltiplos locais (tais sistemas empregam replicação multi-master), com o próprio mecanismo de replicação do back end da base de dados a tratar da replicação para todos os outros servidores. Este paradigma simplesmente não corresponde ao de um número único, central e monotonicamente crescente para registar alterações, sendo assim incompatível com a transferência de zonas em grande medida. Pacotes de servidores DNS modernos com back ends de base de dados sofisticados muitas vezes criam um número de série “shim”, simulando a existência de um único lugar central onde as atualizações são feitas, mas isto é, na melhor das hipóteses, imperfeito.
Felizmente, por esta e várias razões descritas mais tarde, servidores DNS que usam back ends de banco de dados tão sofisticados em geral raramente usam a transferência de zona como seu mecanismo de replicação de banco de dados em primeiro lugar, e geralmente empregam os mecanismos de replicação de banco de dados distribuídos amplamente superiores que os próprios back ends fornecem.
Comparações de números de sérieEditar
Comparações de números de série são destinadas a usar a Aritmética de Números de Série como definida na RFC 1982. Entretanto, isto não foi claramente especificado na RFC 1034, resultando em que nem todos os clientes realizam a verificação do número de série, no preâmbulo, da mesma forma. Alguns clientes verificam apenas que o número de série fornecido pelo servidor é diferente do número conhecido pelo cliente, ou não zero. Outros clientes verificam que o número de série fornecido pelo servidor está dentro de um determinado intervalo do número de série já conhecido pelo cliente. No entanto, outros clientes ainda realizam esta última verificação e, adicionalmente, verificam se o número de série fornecido pelo servidor não é zero.
Vários registros de recursosEditar
Originalmente, na transferência de dados real, cada conjunto de registros de recursos para um único nome e tipo de domínio foi transferido em uma mensagem de resposta separada do servidor para o cliente. Entretanto, isso é ineficiente, e alguns softwares de servidor DNS implementaram otimizações, destinadas a permitir o mecanismo de compressão de resposta no protocolo DNS para reduzir os requisitos de largura de banda total das transferências de dados, como por exemplo:
- processamento de “seções adicionais” para incluir qualquer conjunto de registros de recursos “colados” na mesma resposta de um conjunto de registros de recursos NS, SRV ou MX
- colhendo todos os conjuntos de registros de recursos relacionados a um único nome de domínio juntos e enviando-os, se caberem, em uma única resposta
Alguns clientes foram escritos para esperar apenas o formato de resposta original, e não executariam a transferência de dados se tais otimizações fossem empregadas. Vários pacotes de servidores DNS, portanto, têm uma configuração que permite aos administradores especificar o uso de respostas em “formato de resposta única” para aqueles clientes que o requerem.
Exposição dos dadosEditar
Os dados contidos em uma zona DNS podem ser sensíveis de um aspecto de segurança operacional. Isso ocorre porque informações como nomes de hosts de servidores podem se tornar conhecimento público, que pode ser usado para descobrir informações sobre uma organização e até mesmo fornecer uma superfície de ataque maior. Em junho de 2017, o registrador responsável pelas transferências de zona DNS de nível superior russo ativou acidentalmente as transferências de zona DNS via AXFR, o que levou à exposição acidental de 5,6 milhões de registros.
Em 2008, um tribunal no Dakota do Norte, EUA, decidiu que a realização de uma transferência de zona como um estranho não autorizado para obter informações que não eram acessíveis ao público constitui uma violação da lei do Dakota do Norte.