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

Tipos de consultas DNS

Como sabemos, a função principal de um servidor DNS é prover tradução de endereços IP em nomes de fácil memorização. Desta forma ao invés de decorar o endereço IP de cada servidor da rede pode-se apenas memorizar um mnemônico que remeta ao serviço que oferecido pelo servidor. Para executar esta função o DNS tem uma arquitetura cliente-servidor. Os clientes DNS enviam aos servidores requisições de vários tipos, entre eles: 

- Host (A)
DNS Client envia um FQDN* na requisição e o servidor DNS retorna um endereço IP formato IPv4.

* FQDN: Fully-Qualified Domain Name, nome que descreve completamente um host na estrutura DNS. Por exemplo, se o nome do host é “desktop” e o domínio “robertobraga.net”, o FQDN será “desktop.robertobraga.net” 

- Host (AAAA)
DNS Client envia um FQDN na requisição e o servidor DNS retorna um endereço IP formato IPv6. Os registros do tipo AAAA tem suporte tanto no Windows 2000 Server, Windows Server 2003 e Windows Server 2008. O transporte DNS é possível, entretanto, apenas a partir do Windows Server 2003 e a funcionalidade não vem habilitada por padrão. A partir do Windows Server 2008 o suporte a IPv6 é nativo.

- Alias (CNAME)
Em uma requisição do tipo CNAME (Canonical Name), traduz-se um FQDN em outro FQDN. É utlizado para a criação de alias em servidores DNS.

- Pointer (PTR)
Registros do tipo Pointer (PTR) fazem consultas reversas no DNS. O DNS Client envia na requisição um endereço IPv4 ou IPv6 e recebe um FQDN como resposta.

- Service Location (SRV)
Em uma requisição deste tipo, o requisitante envia um serviço e respectivo protocolo e recebe como resposta uma Porta e um FQDN. É utlizado em protocolos recentes, como SIP e XMPP. É também utilizado no processo de descoberta de Domain Controllers em um domínio Active Directory. 

- Mail Exchanger (MX)
A requisição passa um FQDN de nome de domínio e recebe como resposta um FQDN de servidor de correio para aquele domínio.

Zonas em um servidor DNS
O DNS utiliza-se da estrutura em forma de zonas para executar suas funções. Uma zona armazena nomes para determinado domínio. Desta forma, um mesmo servidor DNS pode ter várias zonas, cada uma correspondendo a um domínio: contoso.com, microsoft.com, robertobraga.net, por exemplo. As entradas DNS – cada uma associada a um dos tipos – estão dentro de cada zona. Importante notar que as informações são armazenadas por zona (e não por servidor).

Replicação em servidores DNS
Quanto ao tipo, as zonas podem ser Zonas de Pesquisa Direta (Forward Lookup Zones), que traduzem nomes e serviços DNS ou Zonas de Pesquisa Inversas (Reverse Lookup Zones),  que traduzem IPs em nomes DNS. As zonas DNS são ainda definidas pelo tipo de replicação que estão submetidas. Quanto a este critério, uma zona pode ser Integrada ao AD, Primária (Master), Secundária (Slave) ou Stub.

O serviço DNS é tipicamente distribuído.  Desta forma, obtêm-se redundância através de bases de dados para resolução de nomes disponível em vários servidores. Esta disponibilidade é permitida pela funcionalidade de replicação do serviço.

A maneira tradicional (especificada originalmente na RFC 1035) em que a replicação acontece é na direção Master -> Slave. O banco de dados em formato texto (arquivo .dns) é armazenado em um servidor DNS primário, como cópia read/write. Os outros servidores – secundários – armazenam cópias deste arquivo (read-only).

Com o Active Directory implantado no Windows 2000 e seu intenso uso do serviço DNS, um novo tipo de zona foi implementado. As Zonas Integradas do Active Directory (ou apenas Zonas Integradas) tem algumas diferenças em comparação com zonas DNS tradicionais. Em especial, as zonas se tornam objetos do Active Directory e são replicadas junto com o restante do banco de dados do AD. Outra diferença essencial é que não existem cópias secundárias da zona. Todas as cópias passam a ser read/write. E essas cópias, por sua vez, podem estar apenas em servidores DNS que sejam também Domain Controllers (DCs).

Uma Zona Stub é uma cópia de uma zona que tem a função de apenas informar quais são os servidores DNS autoritativos para a zona. Geralmente é usada para interligar infraestruturas de DNS distintas.

Funcionamento das consultas DNS
Zonas Integradas, Primárias e Secundárias são autoritativas. Isto significa que caso um servidor DNS da zona receba uma query de um DNS Client ele saberá a responder sem ter que consultar outros servidores DNS – se a consulta for para uma zona que ele é autoritativo. Desta forma se o servidor srv-dc1 é autoritativo para a zona robertobraga.net ele saberá responder uma consulta tipo A para desktop.robertobraga.net com o IP correspondente.

Se a consulta for para uma zona em que o servidor DNS não seja autoritativo (www.brasildotnet.net, host www para o domínio brasildotnet.net, por exemplo) há algumas possibilidades para a resolução correta do nome acontecer. São elas:

• Repassar a query a um forwarder, servidor DNS um nível acima;
• Repassar a query a um root hint, que são os servidores DNS raiz;
• Repassar a query a um servidor delegado para aquele namespace (caso possível apenas caso esteja sendo utilizado uma estrutura com sub-zonas)

O funcionamento de uma consulta DNS e repasse em um cenário de rede local com forwarders e com root hints desabilitados é mostrado no vídeo abaixo.

a) Registros Netbios comuns a WINS e DNS.
b) Falha na integração com Active Directory.
c) Servidor autoritativo para um domínio.
d) Aguardando resposta do servidor raiz.
e) Transferência de zona incremental.

Em um serviço de resolução de nomes (Domain Name System – Sistema de Nomes de Domínios, ou apenas DNS) é possível dividir em zonas as informações a serem fornecidas pelos servidores. Uma zona armazena informações sobre um ou mais domínios (esses últimos denominados subdomínios). Os subdomínios criados em uma zona podem ser tanto administrados pelo próprio servidor DNS que criou a zona originalmente quanto delegados a um outro servidor. Além da delegação, a zona pode ser completamente replicada a um servidor secundário para fins de redundância e alta disponibilidade.

A partir do momento em que uma zona é criada em um servidor secundário para redundância (zona secundária) ela é automaticamente replicada com o servidor principal. Para coordenar esta sincronização os servidores mantém um número de versão para a zona. Caso a versão do servidor solicitante seja inferior à versão do servidor principal é iniciada uma transferência de zona. Nas primeiras implementações DNS esta replicação enviava informações completas da zona (transferência do tipo AXFR) . A partir da RFC 1995 foi proposto o IXFR (opção correta para a questão do concurso), transferência que envia apenas as mudanças para o servidor secundário, de maneira incremental. Os acrônimos AXFR e IXFR representam os opcodes das transferências.

O serviço DNS passou por revisões recentes e teve adicionado características interessantes visando aprimorar segurança e flexibilidade, dentre elas:

• Serviço de notificação sobre mudanças em zonas, disponível a partir do Windows 2000;
• DNSSEC,  extensões que mitigam ataques do tipo spoofing e man-in-the-middle que está disponível nativamente no Windows Server 2008 R2 e Windows 7 (mais informações no DNSSEC Deployment Guide). O DNSSEC ganhou popularidade por evitar a vulnerabilidade exposta na descoberta do famoso bug na especificação original do DNS em 2008 (em breve artigo sobre DNSSEC aqui!);
• Suporte a IPv6, a partir do Windows Server 2008.

(PETROBRÁS – 2008)
Para servidores com Windows Server é CORRETO afirmar que:
 

Managing DNS Records – http://technet.microsoft.com/en-us/library/bb727018.aspx

 2) o recurso round robin de um servidor DNS pode ser utilizado para realizar o balanceamento de carga entre servidores Web.
Correto. Servidores DNS devolvem uma lista de registros ordenados por round robin quando há mais de um registro para um mesmo nome. Se forem cadastrados vários registros tipo A para o nome do servidor web (webserver.dominio.com, por exemplo), ao se fazer uma consulta por este nome será devolvida a lista de IPs dos servidores ordenada por round robin. Este arranjo também confere alta disponibilidade, já que se o primeiro IP fornecido não estiver acessível o cliente DNS resolverá os seguintes da lista, um a um.

O artigo Configuring round robin (http://technet.microsoft.com/en-us/library/cc787484(WS.10).aspx) explica o funcionamento do Round Robin. O DNS do Windows Server tem também a possibilidade de priorizar um endereço IP que esteja “mais próximo” (na mesma subrede) do host solicitante. O artigo Prioritizing local subnets (http://technet.microsoft.com/en-us/library/cc787373(WS.10).aspx) explica este procedimento.

 3) os servidores DHCP devem ser configurados com endereço IP dinâmico. 
Errado. Servidores DHCP tem por função fornecer endereço IP e outras configurações de rede a adaptadores de rede. Sendo assim, servidores DHCP devem possuir IP fixo. A instalação do serviço DHCP faz esta recomendação quando da instalação. No documento DHCP server role: Configuring a DHCP server (http://technet.microsoft.com/en-us/library/cc756865(WS.10).aspx) a recomendação também está expressa como um dos requisitos para a instalação do DHCP. 

 4) um servidor DHCP pode fornecer a uma estação cliente um endereço de IP padrão para um servidor DNS.
Correto. Além de endereço IP o servidor DHCP pode fornecer configurações adicionais para a placa de rede. Uma listagem de servidores DNS a serem usados está na listagem de possíveis configurações a serem passadas para um host que envia uma solicitação. Uma listagem completa das configurações possíveis pode ser obtida em http://technet.microsoft.com/en-us/library/cc958929.aspx.

RFC 2131 Dynamic Host Configuration Protocol - http://www.ietf.org/rfc/rfc2131.txt 

 5) um servidor DNS pode atuar, simultaneamente, como servidor primário para algumas zonas, enquanto atua também como servidor secundário para outras.
Correto. Uma zona DNS é primária se foi criada e pode ser gerenciada diretamente a partir de determinado servidor DNS. Uma zona secundária é uma cópia read only de uma zona primária contida em outro servidor. Não confudir zona primária e zona secundária em um servidor DNS com servidor DNS primário e servidor DNS secundário em um cliente. Não necessariamente um servidor DNS primário configurado em um cliente deve conter uma zona primária. Não necessariamente um servidor DNS secundário deve conter uma zona secundária. 

A Technet Libraryexplica no artigo Understanding zones and zone transfer (http://technet.microsoft.com/en-us/library/cc781340(WS.10).aspx) como funciona a transferência de zonas entre servidores DNS. Uma configuração interessante é utilizar a replicação de zonas para permitir interoperabilidade entre servidores DNS Linux e Windows.