Boas práticas para redirecionamentos DNS
Forwarders
Recomenda-se configurar pelo menos dois Forwarders em servidores DNS que “saiam” para a Internet, por motivos de redundância. Recomenda-se também elaborar um procedimento para checar regularmente se os Forwarders definidos estão respondendo e ativos.

Root Hints
Para servidores DNS que não saem diretamente para a Internet, é recomendável desligar Root Hints. O timeout padrão para uma query repassada aos Forwarders é de 5 segundos. Se não houver retorno nesse tempo, um Root Hint é consultado e a query é resolvida recursivamente. Desligar os Root Hints força o fluxo a passar pelos Forwarders. Se os Forwarders pararem de responder logo será percebido.

Round Robin vs. Netmask Ordering
Na especificação original do DNS, previu-se que para o caso em que existam vários IPs cadastrados para um mesmo hostname o servidor retornaria um dos IP’s aleatoriamente seguindo o algoritmo Round Robin. O uso do Round Robin fornece aleatoriamente uma das várias entradas de IP para determinado nome, a cada requisição.

Na verdade, todas as entradas são retornadas a cada requisição e o DNS Client trata a lista recebida. O que o algoritmo faz é ordenar os resultados aleatoriamente. Este cenário é muito interessante para balanceamento de carga, por exemplo. O Round Robin pode ser indesejável, entretando, num cenário em que os servidores estejam dispersos geograficamente e sejam interligados por links de longa distância.

Visando em especial atender a estes cenários foi incluído a partir do Windows 2000 a funcionalidade Netmask Ordering no DNS. O Netmask Ordering faz um cálculo (cálculo explicado aqui) para determinar a distância dos servidores DNS disponíveis ao DNS Client requisitante. Desta forma a lista de IPs devolvida é encabeçada pelo servidor provavelmente “mais próximo” (na mesma subrede ou em subrede próxima) ao solicitante. Este comportamento é extremamente desejado em cenários de branch office, por exemplo.

Netmask Ordering e Round Robin podem coexistir. Este cenário é, inclusive, a configuração padrão. Desta forma os registros estarão organizados tanto por subrede quanto balanceados por aleatoriedade. Caso algum dos dois comportamentos não seja desejado é possível desabilitá-los.

Limpeza de registros DNS
Registros em um servidor DNS podem ser estáticos ou dinâmicos. Registros estáticos são os criados manualmente, via console MMC/Server Manager, utilitário dnscmd ou provider Powershell. Registros dinâmicos são geralmente criados ao se receber um endereço via servidor DHCP, por exemplo.

Em cenários complexos, os registros dinâmicos geram uma grande carga administrativa. Em geral, há problemas tanto de vários hostnames apontando para um mesmo IP quanto o inverso, vários IPs apontando para o mesmo hostname. O primeiro sinal de que problemas desta ordem estão acontecendo é que serviços que se utilizam de resolução de nomes começam a falhar sem causa aparente.

Felizmente, há procedimentos que automatizam a limpeza de registros dinâmicos que não sejam mais válidos (e apenas destes!). Em especial, a limpeza destes registros é feita combinando-se duas funcionalidades. O Aging define para os registros uma data de criação e é também responsável por fazer o controle desses “timestamps”. O Scavenging promove um ciclo de limpeza de registros. Apenas registros datados (que sofreram Aging) serão contemplados por uma thread de Scavenging.

Para habilitar os procedimentos de limpeza, são necessárias ações em três níveis: no servidor DNS, na zona em que se deseja habilitar o procedimento e nos registros em si. No servidor, deve-se permitir que o Scavenging seja executado. Na configuração padrão, o Scavenging é executado a cada 7 dias. Para definir esta configuração devemos acessar o console MMC do DNS, Server Manager ou RSAT. Botão direito no servidor DNS > Properties > Aba “Advanced” > Habilitar a opção “Enable automatic scavenging of stale records”.

O processo de Aging/Scavenging só atua sobre registros dinâmicos. Pode-se facilmente observar quais registros DNS são dinâmicos através do console de gerenciamento do DNS a partir do Windows Server 2008.

Quanto à zona, deve-se certificar que a zona em que se deseja habilitar os procedimentos de manutenção automática seja primária. Deve-se ainda definir o Aging para a zona para garantir que seu registros criados sejam datados automaticamente. Para habilitar a opção de Aging, botão direito na zona > “Properties” > “Aging” > marcar “Scavenge stale resource records” e definir “No-refresh interval” e “Refresh interval”.

A definição dos intervalos “Refresh” e “No-refresh” é muito importante para o sucesso do procedimento de limpeza. O intervalo de “No-refresh” está relacionado com a manutenção constante do registro e define o período em que o registro permanece na base de dados do DNS sem renovar o timestamp. Outras alterações no registro são permitidas. O objetivo deste intervalo é diminuir tráfego de replicação por renovação de timestamp.

O valor “Refresh” refere-se ao período de tempo em que os timestamp dos registros pode ser renovado. Quando da atualização do timestamp registro, o período de “No-refresh” é novamente iniciado. Automaticamente é feita a replicação do registro para outros servidores para a zona. Se o registro não for atualizado pelo DNS Client durante o “Refresh Interval” o registro é considerado como marcado para deleção pelo Scavenging.

Definindo intervalos e verificando funcionamento
O processo de Scavenging é configurado, como dito anteriormente, no nível de servidor DNS. A cada ciclo, a thread de Scavenging verifica quais zonas são primárias para o servidor. Dentre as zonas primárias, o processo será executado apenas nas zonas com Aging habilitado. Nessas zonas, o procedimento vai verificar quais registros dinâmicos expiraram. Para um registro ser considerado expirado ele deve ter seu timestamp maior que a soma dos intervalos de “No-refresh” e “Refresh. Isto significa que o registro foi criado e não foi renovado pelo DNS Client que o criou e, provavelmente, refere-se a um computador que obteve um novo endereço IP via DHCP, por exemplo.

Como registros dinâmicos são em geral criados por concessões de endereço IP obtidas via DHCP, uma boa prática é definir os intervalos de Aging associados à duração do lease DHCP. Desta forma, a soma dos intervalos de “No-refresh” e “Refresh” deve ser menor que a duração do lease DHCP. Assim, a limpeza provavelmente ocorrerá logo antes da expiração do lease. Se o lease do servidor DHCP tiver duração de 8 dias, por exemplo, é razoável definir o “No-refresh” para 4 dias e “Refresh” para 3 dias (4+3 = 7, menor que 8).

Dois eventos descrevem o correto funcionamento dos processos de limpeza. O evento 2501 descreve que o processo de Scavenging ocorreu corretamente. O evento 2502 reporta que, apesar do Scavenging ter sido executado, provavelmente nenhuma zona estava configurada para remoção automática de registros.

Outra recomendação relevante é tomar alguns cuidados na implementação. O Scavenging deve ser definido em servidores de sites centrais. Isto evita deleções acidentais. Deve ainda se tomar cuidado com a duração dos intervalos, definindo-os com uma margem de segurança.

*Contribuiu Luis Roberto Tognini – Premium Field Engineer, Microsoft