Continuamos com o quarto post da série sobre DNS para preparação para o exame 70-410 da certificação Microsoft MCSA.

Para ver os posts anteriores acesse o menu aqui do lado direito da tela.

Zonas GlobalNames

Anteriormente nesta parte, falamos sobre organizações usando o WINS para resolver nomes NetBIOS (também chamados de nomes de computador) em endereços TCP/IP. Mesmo hoje, muitas organizações ainda usam o WINS junto com o DNS para a resolução de nomes. Infelizmente, o WINS está lentamente se tornando obsoleto.

Para ajudar as organizações a avançarem para uma rede totalmente apoiada no DNS, o DNS do Microsoft Windows Server 2012 R2 suporta zonas GlobalNames. Estas usam nomes únicos (nomes que não contém sufixo como .com, .net e assim por diante). Zonas GlobalNames não são feitas para suportar redes ponto a ponto e resolução de nomes de estações de trabalho, e não suportam atualizações dinâmicas DNS.

Zonas GlobalNames são feitas para serem usadas com servidores. Pois zonas GlobalNames não são dinâmicas, um administrador tem que inserir os registros dentro da zona manualmente. Na maioria das organizações, os servidores tem endereços TCP/IP estáticos, e isso funciona bem com o modelo das Zonas GlobalNames. As Zonas GlobalNames são normalmente usadas para mapear nomes únicos de registros de recursos CNAME (apelido) para um FQDN (nome de domínio totalmente qualificado).

Transferências de Zonas e Replicação

O DNS é parte tão importante da rede que você não deveria usar um único servidor DNS. Com um único servidor DNS, você também pode ter um único ponto de falhas, e de fato, muitas empresas de registro de domínio encorajam o uso de mais de dois servidores de nome para um domínio. Servidores secundários ou vários servidores primários Integrados ao Active Directory fazem papel integral em prover informações de DNS para um domínio inteiro.

Como dito anteriormente, servidores DNS recebem seus banco de dados de zonas através de transferências de zonas. Quando você configura um servidor secundário pela primeira vez, você deve especificar o servidor primário que é autoritativo para a zona e que irá enviar a transferência de zona. O servidor primário também deve permitir que o servidor secundário solicite a transferência de zona.

Transferências de zonas podem ocorrer de duas maneiras: transferências de zonas completas (AXFR) e transferências de zonas incrementais (IXFR).

Quando um novo servidor secundário é configurado pela primeira vez, recebe uma transferência de zona completa do servidor DNS primário. A transferência de zona completa contém toda a informação do banco de dados DNS. Algumas implementações do DNS sempre recebem transferências de zonas completas.

Depois que o servidor secundário recebe a sua primeira transferência de zona completa, transferências de zonas subsequentes são incrementais. O servidor de nomes primário compara o número de versão da sua zona com a do servidor secundário, e envia apenas as mudanças que foram realizadas nesse interim. Isso reduz significantemente o tráfego de rede gerado pelas transferências de zonas.

O servidor secundário geralmente inicia transferências de zonas quando o tempo de intervalo de atualização para a zona expira ou quando o servidor secundário ou stub faz o boot. Alternativamente, você pode configurar listas de notificação no servidor primário que envia uma mensagem aos servidores secundário ou stub sempre que ocorrer uma mudança no banco de dados da zona.

Quando você considera sua estratégia de DNS, você deve ponderar com cuidado o layout da sua rede. Se você tem um domínio único com escritórios em cidades diferentes, você quer reduzir o número de transferências de zonas através de links WAN potencialmente lentos ou caros, embora isso esteja se tornando uma preocupação cada vez menor devido a oferta sempre crescente de largura de banda.

Zonas Integradas ao Active Directory evitam transferências de zonas tradicionais totalmente. No lugar, elas replicam através do Active Directory junto com todas as outras informações do AD. Esta replicação é segura e criptografada pois usa a segurança do Active Directory.

Como funciona a notificação do DNS

O Windows Server 2012 R2 suporta notificação DNS (DNS Notify). A notificação DNS é um mecanismo que permite o processo de iniciar notificações para servidores secundários quando as mudanças de zona ocorrem (RFC1996). A notificação DNS usa um mecanismo de empurar (push) para comunicação com um conjunto seleto de servidores de zona secundários quando a informação de suas zonas é atualizada (A notificação DNS não permite que você configure uma lista de notificação para uma zona stub).

Depois de ser notificado das mudanças, servidores secundários podem então “puxar” (pull) uma transferência de zona e atualizar suas cópias de banco de dados locais.

Para configurar o processo de Notificação DNS, você cria uma lista de servidores secundários à serem notificados. Liste o endereço IP do servidor na caixa de diálogo Notificar do mestre primário (ver figura abaixo). A caixa de diálogo Notificar está localizada  dentro da aba de Transferências de Zonas, a qual está na janela de propriedades da zona.

Configurar Transferência de Zonas Stub com Replicação de Zona

Na seção anterior, falamos sobre como configurar transferência de zonas para servidores secundários. E se você quisesse configurar configurar transferência de zonas para servidores stub? Aqui é onde o escopo de replicação de zona entra em ação.

Apenas zonas primárias integradas ao Active Directory e zonas Stub podem configurar seus escopos de replicação. Servidores secundários não possuem esta habilidade.

Você pode configurar o escopo de replicação de zona de duas maneiras. Um administrador pode definir opções de configuração através do snap-in do DNS ou de uma ferramenta de linha de comando chamada DNSCmd.

Para configurar o escopo de replicação de zona pelo snap-in do DNS, siga esses passos:

• Abra o Gerenciador do Servidor, no menu Ferramentas clique em DNS.
• Clique com o botão direito do mouse na zona que você quer configurar.
• Selecione Propriedades.
• Na janela de Propriedades, clique no botão Alterar que se refere à Replicação (ver figura abaixo).
• Escolha o escopo de replicação que seja melhora para sua organização.

Vantagens do DNS no Windows Server 2012 R2

O DNS no Windows Server 2012 R2 possui algumas vantagens ótimas sobre outras versões de DNS Microsoft. Aqui estão alguns dos melhoramentos do DNS no Windows Server 2012 R2 ( Alguns destes se tornaram disponíveis no Windows Server 2008, mas eles foram melhorados).

• Carregamento de zona em segundo plano
• Suporte ao TCP/IP versão 6 (IPv6)
• Controladores de domínio somente leitura
• Zona GlobalNames
• Pool de Socket DNS
• Travamento de Cache DNS
• Extensões de Segurança DNS (DNSSEC)
• Devolução DNS
• Estatísticas de Nível de Zona
• Pesagem de Registros
• Ordenação de Máscara de Rede
• Grupo DnsUpdateProxy
• Suporte ao Windows PowerShell

Carregamento de zona em segundo plano

Se no passado, uma organização tivesse que reiniciar um servidor DNS com um banco de dados de zonas integradas ao Active Directory extremamente grande, DNS tinha um problema comum com uma zona DNS integrada ao Active Directory. Durante este tempo, o servidor DNS ficava impossibilitado de servir quaisquer requisições de clientes.

O DNS do Windows Server 2008 enfrentava este problema implementando o carregamento de zona em segundo plano, e o Windows Server 2012 R2 foi um passo adiante. Quando o DNS reinicia,  os dados da zona no Active Directoy popula o banco de dados em segundo plano. Isto permite ao servidor DNS atender clientes pedindo por dados de outras zonas quase imediatamente após o reinício.

O carregamento de zona em segundo plano executa esta tarefa carregando a zona DNS por meio de threads separadas. Isto permite que um servidor DNS atenda solicitações de clientes enquanto carrega o resto da zona. Se um cliente envia uma solicitação ao servidor DNS por um computador que ainda não foi carregado na memória, o servidor DNS recupera os dados do Active Directory e atualiza o registro.

Suporte a endereços IPv6

Nos últimos anos, a Internet começou a se deparar com um problema que não foi previsto quando ela foi criada – começou a ficar sem endereços TCP/IP. Como você provavelmente sabe, quando a Internet foi criada, era usada somente para fins acadêmicos e de governo. Então aparentemente em uma noite cresceu  para ser a super-rodovia da informação.

Hoje em dia, perguntar o e-mail de alguém é tão comum quanto perguntar seu número de telefone.

A versão 4 (IPv4) era a versão comum do TCP/IP. O lançamento da versão 6 do TCP/IP (IPv6) resolveu o problema da falta de endereços IP. Endereços IPv4 tem 32 bits de comprimento, mas endereços IPv6 tem 128 bits. O comprimento maior permite um número muito maior de endereços IP globais únicos.

O Microsoft Windows Server 2012 R2 tem suporte incluso para acomodar registros de endereços IPv4 e IPv6. O DHCP também pode atribuir endereços IPv6, o que deixa administradores permitirem que o DHCP registre o cliente no DNS, ou o cliente IPv6 pode registrar seu endereço com o servidor DNS.

Suporte a Controladores de Domínio Somente Leitura

O Windows Server 2008 introduziu um novo tipo de controlador de domínio chamado Controlador de Domínio Somente Leitura (Read-Only Domain Controller – RODC). É uma cópia completa do banco de dados do Active Directory sem a habilidade de escrever no Active Directory. O RODC permite que a organização instale um controlador de domínio em uma localização onde segurança é uma preocupação.

Uma zona primária, somente leitura é exatamente isso – uma zona somente de leitura; então para fazer qualquer mudança, você tem que mudar as zonas primárias localizadas no servidor DNS integrado ao Active Directory, ou seja, através de um controlador de domínio padrão.

Pools de Socket DNS

Se o seu servidor roda o Windows Server 2012 R2, você poderá aproveitar o recurso de Pools de Socket DNS. Eles permitem randomizar a porta de origem para proteger contra ataques de envenenamento de cache.

Se você escolher usar a randomização de porta de origem, quando o serviço DNS inicia, o servidor DNS escolherá aleatoriamente uma porta de origem a partir de um pool de sockets disponíveis. Isto é uma vantagem pois, ao invés do DNS usar uma porta conhecida quando envia consultas, o servidor DNS usa uma porta aleatória selecionada do pool de socket. Isto ajuda a proteger contra ataques pois um hacker precisa saber a porta de origem correta da consulta DNS. O pool de socket é automaticamente ativado no DNS com as configurações padrão.

Quando usa o Pool de Socket DNS, o tamanho padrão do Pool de Socket DNS é 2.500. Quando configura o Pool de socket, você tem a possibilidade de escolher um valor entre 0 até 10.000. Quanto maior o valor, maior proteção você terá contra ataques de falsificação de DNS. Se decidir configurar o seu Pool de Socket com valor zero, apenas um único socket para consultas DNS remotas será usado.

Travamento de Cache DNS

O Travamento de Cache do DNS no Windows Server 2012 R2 permite que registros DNS em cache permaneçam à salvo pela duração do valor do tempo de vida (TTL) do registro. Isto significa que os registros DNS em cache não podem ser sobrescritos ou modificados. Devido à esse novo recurso do DNS, fica mais difícil para hackers realizarem ataques de envenenamento de cache contra o seu servidor DNS.

Administradores de DNS podem definir quanto tempo um registro permanecerá seguro no cache. A configuração é baseada em um valor percentual. Por exemplo, se você configurar o valor de travamento de cache DNS em 50%, então os registros em cache não podem ser sobrescritos até que se passe metade do tempo do TTL. O travamento de cache DNS é configurado em 100% por padrão. Isto significa que os registros em cache nunca são sobrescritos.

Extensões de Segurança DNS

Uma grande questão que você deve sempre olhar é manter seu DNS seguro. Pense um pouco – o DNS é um banco de dados fito de nomes de computadores e endereços IP. Sendo um hacker, se eu controlo o DNS, eu posso controlar sua empresa. Em organizações que não suportam segurança extra como o IPSec, a segurança do DNS é ainda mais importante. Aqui é onde o DNSSEC pode ajudar.

O Windows Server 2012 R2 pode usar um pacote de extensões que irão adicionar segurança ao DNS, e esse pacote é chamado de Extensões de Segurança DNS (Domain Name System Security Extensions – DNSSEC), que foi introduzido no Windows Server 2008 R2. O protocolo DNSSEC permite que seus servidores DNS fiquem seguros através da validação de respostas DNS. O DNSSEC protege os seus registros de recurso do DNS anexando uma assinatura digital nos registros.

Para permitir que os registros de recursos do DNS recebam uma assinatura digital, o DNSSEC é aplicado ao seu servidor DNS por meio de um processo chamado Assinatura de Zona. Este processo inicia quando um resolvedor inicia uma consulta DNS por um registro de recurso em uma zona DNS assinada. Quando uma resposta chega, uma assinatura digital (RRSIG) acompanha a resposta, e isto permite que a resposta seja verificada. Se a verificação for bem sucedida, então o resolvedor DNS sabe que os dados não foram modificados ou manipulados de qualquer forma.

Uma vez que você implemente uma zona com o DNSSEC, todos os registros que estão contidos dentro desta zona são individualmente assinados. Já que todos os registros na zona são assinados individualmente, isto dá aos administradores a habilidade de adicionar, modificar ou deletar registros sem precisar reassinar a zona inteira. O único requisito é reassinar qualquer registro atualizado.

Âncoras de confiança

Âncoras de confiança são uma parte importante do processo DNSSEC pois as âncoras de confiança permitem que servidores DNS validem os registros de recursos DNSKEY. Âncoras de confiança são chaves públicas pré-configuradas que são ligadas com uma zona DNS. Para um servidor DNS realizar a validação, um ou mais âncoras de confiança devem ser configuradas. Se você estiver rodando uma zona integrada ao Active Directory, as âncoras de confiança podem ser armazenadas na partição de diretório do Active Directory na floresta. Se você decidir armazenar as âncoras de confiança na partição de diretório, então todos os servidores DNS que residem em um controlador de domínio recebem uma cópia desta âncora de confiança. Em servidores DNS que residem em servidores membros, as âncoras de confiança são armazenadas em um arquivo chamado TrustAnchors.dns.

Se os seus servidores estão rodando o Windows Server 2012 R2, então você pode ver as âncoras de confiança na árvore do console do Gerenciador de DNS no container Pontos de Confiança. O Windows PowerShell é o método de linha de comando recomendado para visualizar âncoras de confiança. O comando a seguir é um comando do PowerShell para ver as âncoras de confiança para o domínio w1.com.br

Get-DnsServerTrustAnchor sec.w1.com.br

Devolução DNS

Com o uso  da Devolução DNS, se um computador cliente é um membro de um espaço de nomes filho, o computador cliente poderá acessar recursos no espaço de nomes pai sem a necessidade de informar explicitamente o FQDN do recurso. A Devolução DNS permite que o resolvedor DNS crie os novos FQDNs. A Devolução DNS funciona anexando o sufixo pai do nome de sufixo DNS primário ao nome de etiqueta única (single-label) não qualificado.

Estatísticas de Nível de Zona

Estatísticas de servidor no nível de zona estão disponíveis no Windows Server 2012 R2 por meio do uso do cmdlet do Windows PowerShell Get-DnsServerStatistics. Abaixo segue um exemplo de uso do mesmo:

Get-DnsServerStatistics -ZoneName <String[]> [-AsJob][-CimSession <CimSession[]> ][-Clear][-ComputerName <String> ][-ThrottleLimit <Int32> ] [ <CommonParameters>]

O parâmetro ZoneName permite que o administrador receba as estatísticas para a zona DNS que especificar. Se o parâmetro ZoneName não for especificado, as estatísticas de nível de servidor são recuperadas e exibidas. Se um administrador usar o parâmetro Clear no cmdlet do PowerShell junto com o parâmetro ZoneName, as estatísticas para a zona especificada serão limpas. Então use este cmdlet com cuidado.

Pesagem de Registros

A pesagem de registros irá permitir que o administrador coloque um valor em registros DNS SRV. Clientes irão então escolher aleatoriamente registros SRV proporcionalmente ao valor de peso atribuído.

Ordenação de Máscara de Rede

Se o Robin Round estiver habilitado, quando um cliente solicita por resolução de nomes, o primeiro endereço inserido no banco de dados é retornado ao resolvedor, e então é enviado para o fim da lista. Na próxima vez que um cliente tentar resolver o nome, o servidor DNS retorna o segundo nome no banco de dados (que agora é o primeiro) e depois envia-o para o final da lista, e assim por diante.

A Ordenação de Máscara de Rede é parte do processo Robin Round. Quando um administrador configura ordenação de máscara de rede, o servidor DNS irá detectar a subrede do cliente solicitante. O servidor DNS irá então retornar um endereço de host disponível na mesma subrede. A ordenação de máscara de rede a habilitada através do console do Gerenciador DNS na aba Avançado da janela de propriedades do servidor.

Grupo DnsUpdateProxy

Como mencionado previamente, o servidor DHCP pode ser configurado para registrar registros de recursos do tipo host (A) e ponteiro (PTR) automaticamente em nome de clientes DHCP. Devido a isso, o servidor DNS pode ficar com registros estagnados. Para ajudar a resolver este problema, um administrador pode usar o grupo de segurança built-in (que já existe por padrão) chamado DnsUpdateProxy.

Para usar o grupo DnsUpdateProxy, um administrador primeiro cria uma conta de usuário dedicada e configura os servidores DHCP com suas credenciais. Isso irá proteger contra a criação de registros inseguros. Além disso, quando você cria  a conta de usuário dedicada, membros do grupo DnsUpdateProxy poderão gravar registros em zonas que permitam apenas atualizações dinâmicas seguras. Vários servidores DHCP podem usar as mesmas credenciais de uma conta de usuário dedicada.

Suporte ao Windows PowerShell

A Microsoft tem mais de 100 cmdlets específicos para o DNS. Dentro do Windows PowerShell, você pode listar todos os cmdlets disponíveis. Para ver a lista completa, use o seguinte cmdlet:

Get-Command –Module DnsServer cmdlet.

Por hoje é isso

No próximo post começaremos com os tipos de registros DNS.

Caso ainda não saiba aqui no blog tem um ebook com dicas para quem está se preparando para certificações Microsoft.

E tem um simulado completo para o exame 70-410.

Qualquer coisa se comunique aqui pelos comentários ou lá pelo Face ou me mande email no thiago@wise1.com.br

Sucesso!

Thiago

Para ver todos os materiais disponíveis para serem adquiridos aqui na WiseOne acesse essa página.

Links ->  Fanpage, Grupo