Arquivo

Archive for the ‘DNS’ Category

Sobre DNS Policies–Windows Server 2016–volume 05–DNS Filtering

19 de junho de 2017 2 comentários

Saudações! Depois de atuações em alguns auditorias de cybersecurity estamos aí de novo pra continuidade dessa interessante série de posts falando sobre DNS Policies no Windows Server 2016.

A quem está chegando agora, abaixo os links para os outros 4 posts da série:

Sobre DNS Policies – Windows Server 2016 – volume 01 – Teoria

Sobre DNS Policies – Windows Server 2016 – volume 02 – Balanceamento de Carga

Sobre DNS Policies – Windows Server 2016 – volume 03 – Gerenciamento de Tráfego de Rede baseado em Geo-Localização

Sobre DNS Policies – Windows Server 2016 – volume 04 – Split Brain DNS e Selective Recursion Control

Hoje, neste 5o. post desta série, vamos falar sobre DNS Filtering, que são filtros de critérios baseados em requisitos definidos na criação da política propriamente dita, ou seja, a resposta de um DNS Server ocorrerá de acordo com a maneira que um cliente faz a query.

Todos os termos associados aos procedimentos de criação de policies podem ser vistos nos posts anteriores desta série, pois, aqui vamos entrar de forma mais dinãmica no que podemos fazer em termos de Filtering via DNS Policies.

1. Bloqueando queries para um domínio:

Você pode impedir que seu DNS resolva requisições para um determinado domínio. Vamos supor que eu não queira que meus usuários acessem nada que seja do domínio *.malicious.org:

Add-DnsServerQueryResolutionPolicy -Name "BlockedDomains" -Action IGNORE -FQDN "EQ,*.malicious.org" –PassThru

No exemplo acima eu criei uma policy chamada “BlockedDomains” que vai ignorar tudo que for igual (EQ) a “malicious.org”.

2. Bloqueando queries para uma subnet:

Vamos agora supor que eu precise bloquear o acesso a uma subnet, ou seja, uma quantidade de endereços os quais eu teria mais trabalho em bloquear um a um:

Add-DnsServerClientSubnet -Name "BlockedSubnet" -IPv4Subnet 129.214.16.0/24 -PassThru

Add-DnsServerQueryResolutionPolicy -Name "BlockedSubnetPolicy" -Action IGNORE -ClientSubnet  "EQ,BlockedSubnet" -PassThru

No pirmeiro comando eu criei uma subnet chamada “BlockedSubNet” onde eu defino a subnet 129.214.16.0/24. No segundo comando eu crio uma regra chamada “BlockedSubnetPolicy” que ignora tudo o que estiver na range de IP citada.

Este filtro pode ser ainda mais incisivo. Vamos supor que eu queira bloquear acessos a tudo que estiver na subnet acima citada que responda pelo domínio *.malicious.org, ou seja, tudo que responder pelo domínio citado e estiver dentro da subnet criada será ignorado:

Add-DnsServerQueryResolutionPolicy -Name "BlockedSubnetPolicy" -Action IGNORE -ClientSubnet  "EQ,BlockedSubnet" –FQDN “EQ,*.malicious.org” -PassThru

3. Bloqueando e liberando tipo de queries

Vamos fazer um mini lab! Eu vou bloquear toda e qualquer consulta a partir do meu DNS Server e depois vou liberando de acordo com a necessidade.

Add-DnsServerQueryResolutionPolicy -Name "BlockAll" -Action IGNORE -QType "EQ,ANY" –PassThru

Cuidado: O comando acima simplesmente bloqueia todo tipo de queries e requisições a seu DNS. Então planeje bem ao usar o parâmtro ANY.

Agora vou fazer a liberação de determinados tipos de queries. O comando abaixo libera queries do tipo A, AAAA, MX, NS e SOA a partir da interface interface interna do meu DNS Server (10.10.1.20):

Add-DnsServerQueryResolutionPolicy -Name "WhiteListQType" -Action IGNORE -QType "NE,A,AAAA,MX,NS,SOA" –ServerInterface “EQ,10.10.1.20” -PassThru

Vamos agora a outros tipos liberação. Vamos liberar as consultas para meu domínio interno:

Add-DnsServerQueryResolutionPolicy -Name "Whitelist" -Action IGNORE -FQDN "NE,*.uilson.net" –PassThru

O comando acima cria uma white list liberando consultas a tudo que vier do domínio uilson.net, usando o parâmetro NE (Not Equal).

Agora vamos liberar o acesso a uma determinada subnet. Vamos repetir alguns parâmetros do comando exibido no item 2 deste post:

Add-DnsServerClientSubnet -Name "WhiteListSubNet" -IPv4Subnet 129.214.16.0/24 -PassThru

Add-DnsServerQueryResolutionPolicy -Name "WhitelistAllowedSubnetPolicy” -Action IGNORE -ClientSubnet  "NE, WhiteListSubNet" –PassThru

Nos comandos acima criei uma subnet chamada WhileListSubnet contendo a range 129.214.16.0/24 que será liberada para consultas DNS a partir da policy WhiteListAllowedSubNetPolicy.

4. Conclusão

Neste post mostrei exemplos de aplicação de filtros a partir do DNS Policies no Windows Server 2016. Como sempre digo aqui, espero que o conteúdo seja útil e possa ajuda-lo em seu dia a dia.

No próxima post da série irei mostrar DNS Policies para foresincs.

Abraços

Uilson

Anúncios

Sobre DNS Policies–Windows Server 2016–volume 04–Split-Brain DNS e Selective Recursion Control

29 de maio de 2017 Deixe um comentário

Saudações,

Peço desculpas pela demora na publicação do quarto volume desta série. Estive em dias de muito trabalho e alguns percalços pessoais. Mas de qualquer forma vamos ao conteúdo de hoje – Split-Brain DNS.

A quem está chegando agora, abaixo os links para os outros 3 posts da série:

Sobre DNS Policies – Windows Server 2016 – volume 01 – Teoria

Sobre DNS Policies – Windows Server 2016 – volume 02 – Balanceamento de Carga

Sobre DNS Policies – Windows Server 2016 – volume 03 – Gerenciamento de Tráfego de Rede baseado em Geo-Localização

De acordo com a teoria que coloquei no volume 1 desta série, com o recurso de Split-Brain DNS os registros são divididos em diferentes escopos de zona no mesmo servidor DNS. Os clientes DNS recebem uma resposta baseado onde de fato estes clientes estão – internos ou externos. Este recurso pode ser configurado em zonas integradas ao AD ou para DNS Standalone Servers.

Também iremos criar políticas de seletive recursion para mitigação e vulnerabilidades em ambientes como este.

Em tempo – Este laboratório foi criado em meu ambiente tendo como base o laboratório do artigo Split-Brain DNS Deployment Using Windows DNS Server Policies do pessoal do Networking Blog da Microsoft. Como não tinha montado nada semelhante, me espelhei no conteúdo deles para criar o meu. Para aqueles que notarem a semelhança do meu lab com o deles, fica aqui registrado que a idéia inicial é do link citado e deixo a eles o devido crédito.

Vamos então a parte prática!

Imaginemos que tenho um site que deverá ser acessado tanto por usuários internos quanto externos. Esse possui informações de produtos da minha empresa que a equipe compartilha com parceiros externos.

Meu DNS posui duas interfaces, uma interna e outra externa

Interna – IP 10.10.1.100

Externa – IP 200.185.0.55

Meu servidor de aplicação interno responde pelo IP 10.10.1.10 e meu servidor de aplicação externo responde pelo IP 66.56.40.10 (lembrando que estes são IP´s fictícios, os IP´s que usei no laboratório do meu ambiente são outros e aqui fica só para ilustração)

Objetivo – Usuários na minha rede interna, irão acessar o site produtos.uilson.net do back-end Server interno e usuários externos irão acessar o back-end server externo, conforme o desenho abaixo:

 

image

Com o cenário definido, vamos ao procedimento que torna tudo isso real:

Vamos começar criando um zone scope para o acesso interno, ou seja, os acessos que virão pela interface 10.10.1.100:

Add-DnsServerZoneScope –ZoneName “uilson.net” –Name “InternalAccess”

Iremos criar o zone scope somente para o acesso interno, ficando o acesso externo direto no zone uilson.net no escopo padrão.

Agora vamos criar criar os registros para os acessos interno e externo, sendo que, para o acesso interno, iremos cria-lo já dentro do zone scope que acabamos de criar:

Registro de acesso externo – Add-DnsServerResourceRecord –ZoneName “uilson.net” –A –Name “produtos” –IPv4Address “66.56.40.10”

Registro de acesso interno – Add-DnsServerResourceRecord –ZoneName “uilson.net” –A –Name “produtos” –IPv4Address “10.10.1.10” –ZoneScope “InternalAccess”

Agora que temos o zone scope e os registros criados, vamos à política que irá diferenciar acessos internos e externos:

Add-DnsServerQueryResolutionPolicy –Name “SplitBrainPolicy” –Action Allow –ServerInterface “eq,10.10.1.100” –ZoneScope “InternalAccess,1” –ZoneName uilson.net

Feito!!!! Temos agora nosso ambiente direcionando as requisições internas ao site produtos.uilson.net para o back-end server interno e os acessos externos indo diretamente para o servidor externo, conforme definido no escopo inicial.

Poderiamos dizer que temos o trabalho finalizado, certo? Errado! Deixar o ambiente simplesmente como está pode, em alguns casos, criar uma vulnerabilidade que precisa ser mitigada.

Lembre-se que neste exemplo temos um DNS Server resolvendo nomes para recursos internos e externos. O que pode ocorrer aqui é que requisições internas e externas passem fazer queries por endereços de internet, podendo expor o ambiente a um Reflection Attack ou DNS Amplification Attack – um DDoS.

Neste caso, as resoluções recursivas para nomes externos precisa ser bloqueada e para isso criaremos outra política que vem a ajudar na mitigação desta vulneravbilidade:

image

Desenho original do link: https://blogs.technet.microsoft.com/networking/2015/05/12/split-brain-dns-deployment-using-windows-dns-server-policies/

O link que postei sobre DDoS DNS Amplification Attack pede que a funcionalidade da recursiva seja desasbilitada no servidor DNS. Neste caso, vamos desabilitar este recurso que será usado somente para requisições internas.

Desabilitando a recursiva: Set-DnsServerRecursionScope –Name . –EnableRecursion $False

No comando acima, a recursiva está sendo desabilitada para o escope default (tudo que está em uilson.net).

Agora vamos habilitar a recursiva somente para um escopo de clientes internos:

Add-DnsServerRecursionScope –Name “RecursionInternalClients” –EnableRecursion $True

Agora vamos criar a política que irá permitir a recursiva somente para clientes internos;

Add-DnsServerQueryResolutionPolicy –Name “SplitBrainRecursionInternal”-Action ALLOW –ApplyOnRecursion –RecursionScope “RecursionInternalClients” –ServerInterfaceIP “EQ,10.10.1.100”

Agora temos nosso ambiente executando dentro de uma melhor prática para o recurso do Split-Brain DNS.

Espero mais uma vez que o conteúdo possa ser útil e não perca o volume 5 desta série. Iremos falar sobre Filtering com DNS Policies.

Abraços

Uilson

Sobre DNS Policies–Windows Server 2016–volume2–Balanceamento de Carga

11 de abril de 2017 Deixe um comentário

Saudações,

Dando continuidade a nossa série de posts sobre DNS Policies, hoje vou relembrar um post que publiquei a um tempo atrás falando sobre o uso do balanceamento de carga de aplicações.

Para quem ainda não leu o primeiro post desta série, segue abaixo o link:

Sobre DNS Policies – Volume1 – Teoria

1. Planejamento do Balanceamento de carga

Vamos clarificar que, o planejamento para alta disponibilidade e sizing de suas aplicações, você não deve somente se basear no que vamos falar aqui. Você precisa ter em mente os objetivos e tipos de acesso que serão necessários para a sua realidade. O balanceamento de carga pode ser feito via NLB Windows, Failover Clustering ou NLB via hardware (este um recurso mais indicado para aplicações que recebem muitos acessos). No caso de high availability em cloud, verifique as questões de elasticidade em termos desenvolvimento e veja como seu cloud provider trabalha em relação a isso.

Enfim, o balanceamento de carga via DNS Policies deve ser avaliado quanto sua eficácia para o negócio que seu aplicativo visa entregar a um departamento e/ou cliente final. Você precisa estar certo de que esta é a melhor opção para seu cenário.

2. Estudo de caso

Vamos propor aqui, como no artigo original publicado anteriormente, um estudo de caso que nos dará a base para a solução a ser implementada:

2.1. Tenho 4 servidores de aplicação – 1 em São Paulo, 1 no Rio de Janeiro, 1 em Fortaleza e  1 em Belo Horizonte

2.2. Fortaleza e Belo Horizonte possuem links com menos banda que SP e RJ

2.3. Essa aplicação vai atender a todo acesso que vier em qualquer uma das filiais da empresa

3. Cenário

Para atender a esta demanda, temos o seguinte desenho de solução:

 

image

4. Solução técnica

Com o exposto acima, vamos ver agora de forma prática como o DNS Policies nos ajuda a entregar essa solução de forma rápida e tudo via PowerShell!!

Primeiro vamos criar os escopos de zona. É a partir deles que a política vai se orientar para aplicar o que queremos. Para cada localidade onde tenho um servidor de aplicação vou crirar um Scope Zone.

Vou noema-los da seguinte forma:

São Paulo: SP_Scope

Rio de Janeiro: RJ_Scope

Fortaleza: For_Scope

Belo Horizonte: BH_Scope

Como fica as linhas de comando PowerShell para isso:

Add-DnsServerZoneScope –ZoneName “uilson.net” –Name “SP_Scope”

Add-DnsServerZoneScope –ZoneName “uilson.net” –Name “RJ_Scope”

Add-DnsServerZoneScope –ZoneName “uilson.net” –Name “For_Scope”

Add-DnsServerZoneScope –ZoneName “uilson.net” –Name “BH_Scope”

image

Com os Scope Zones criados, vou criar um registro tipo A dentro destes escopos, ou seja, cada escopo estará apontando para o IP do back-end server da localidade correspondente:

Add-DnsServerResourceRecord –ZoneName “uilson.net” –A –Name “AppServer” –IPv4 “10.10.0.10” –ZoneScope “SP_Scope”

Add-DnsServerResourceRecord –ZoneName “uilson.net” –A –Name “AppServer” –IPv4 “10.10.1.10” –ZoneScope “RJ_Scope”

Add-DnsServerResourceRecord –ZoneName “uilson.net” –A –Name “AppServer” –IPv4 “10.10.2.10” –ZoneScope “For_Scope”

Add-DnsServerResourceRecord –ZoneName “uilson.net” –A –Name “AppServer” –IPv4 “10.10.3.10” –ZoneScope “SP_Scope”

image

Agora que já temos os Zone Scopes criados e seus respectivos registros, vamos criar a política que fará o balanceamento de carga via DNS Policies:

Add-DnsServerQueryResolutionPolicy -Name "AppServerPolicy" -Action ALLOW – -ZoneScope "SP_Scope,3;RJ_Scope,3;For_Scope,2;BH_Scope,2" -ZoneName "uilson.net"

image

No comando acima observa-se que ao fim de cada Scope Zone foi colocado uma vírgula e um número (Ex: SP_Scope,3). Isto vai definir que para a cada 10 requisições feitas para o host “appserver.uilson.net”, teremos as 3 primeiras sendo direcionadas para o servidor em São Paulo, as próximas 3 para o servidor do Rio de Janeiro, as 2 seguintes para o servidor em Fortaleza e as 2 últimas para o servidor de Belo Horizonte. Dessa forma conseguimos balancear a carga entre as 3 localidades, respeitando os limites de link de cada uma delas.

5. Conclusão

Este post foi publicado novamente para seguir a série que começamos em 03/abril/2017 sobre DNS Policies. No próximo post falaremos sobre Gerenciamento de tráfego de Rede usando políticas de DNS.

Espero que você tenha gostado e que este conteúdo possa ajuda-lo em suas tarefas diárias.

Abraços

Uilson

Sobre DNS Policies–Windows Server 2016–volume 1–Teoria

3 de abril de 2017 Deixe um comentário

Saudações,

Falando em termos de Windows Server 2016 podemos citar, além de sua total integração e adequação à nuvem também aspectos on-premisses que vão aumentar muito a produtividade de seu datacenter em matéria de Segurança.

Vamos começar hoje uma série de posts voltados a DNS Policies no Windows Server 2016. Nas primeiras versões do ainda recém-divulgado SO Windows Server 2016 TP fiz um laboratório neste espaço acerca do balanceamento de carga de aplicações usando DNS Policies. Vou republicar este post para que a comunidade possa rever o tema e fica como o primeiro de uma série que iremos tratar.

palestra_preview

No que tange à Segurança da Informação levando em mente alguns dos seus principais pilares (Integridade, Disponibilidade e Confidencialidade), o DNS Policies traz possibilidades interessantes de expansão da capacidade de resolução de nomes.

De que forma e como posso configurar DNS Policies? Veja abaixo como:

1. Application Load Balance – Ao implementar vários nodes em uma farm de servidores de aplicação – seja IIS ou outro web server (ou até mesmo um client server) – o DNS Policies pode ser usado para balancear o tráfego entre os nodes desta farm. Diferente do antigo recurso de Round Robin o balanceamento do DNS Policies distribui a carga de forma dinâmica e mais inteligente podendo priorizar um ou mais nodes em relação ao direcionamento das requisições.

2. Gerenciamento de tráfego baseado em Geo-Localização – Para as requisições baseadas em localização geográficas o DNS Policies faz com que servidores DNS primário e secundário fazem o cliente ser redirecionado para o IP do recurso mais próximo, otimizando o tráfego e consumo de banda, dependendo da localização do destino.

3. Split Brain DNS – Com o recurso de Split Brain DNS os registros são divididos em diferentes escopos de zona no mesmo servidor DNS. Os clientes DNS recebem uma resposta baseado onde de fato estes clientes estão – internos ou externos. Este recurso pode ser configurado em zonas integradas ao AD ou para DNS Standalone servers.

4. Filtering – Neste caso você cria filtros de critérios baseados em requisitos definidos na criação da política propriamente dita, ou seja, a resposta de um DNS Server ocorrerá de acordo com a maneira que um cliente faz a query.

5. Foresincs – Um dos recursos que mais gostei nessa parte de políticas. Você pode fazer com que seu DNS redirecione requisições maliciosas para um IP não existente ao invés de direcioná-la para o computador que ela tenta alcançar.

6. Redirecionamento baseado na hora do dia – Vem como uma adicional à política de gerenciamento de tráfego. Você pode direcionar a requisição para um determinado local baseado em uma hora do dia, ou seja, a requisição vai para aquele servidor a partir de um determinado horário do dia.

Novos conceitos

Client Subnet – Um objeto Client Subnet representa uma range IP (IPv4 ou IPv6) a qual as queries são submetidas em um servidor DNS. Você pode criar client subnet’s que vão ser usadas em políticas de DNS que vai resolver/encaminhar uma requisição a um determinado destino baseado na range de IP definida em uma subnet client. Exemplo: Clientes da subnet 10.10.1.0/24 serão encaminhados ao node 2 da farm de servidores de aplicação, enquanto clientes da subnet 10.10.2.0/24 serão encaminhados ao node 1 da minha farm de servidores.

Recursion Scope – Um escopo de recursão contém uma lista de Forwarders e especifica se a recursão está ativada. Um DNS Server pode ter diversos recursion scopes e as políticas atreladas a ele irão ser direcionadas para o escopo que contemple aquela query. Você pode especificar quais forwarders serão utilizados e se utilizarão a recursão.

Zone Scopes – Um DNS Server pode ter diversos escopos de zona (Zone Scopes) contendo neles uma lista de registros. Um mesmo registro pode estar presente em diversos escopos de zona, com diferentes endereços IP. Políticas de Zone Transfer são feitas usando os escopos de zona.

Os conceitos acima se aplicam aos seguintes tipos de política: Query Resolution Policies, Recursion Policies, Zone Transfer Policies, Traffic Management, Block Queries from a Domain, Block Queries from a Subnet, Allow Recursion for Internal Clients, Create a Server Level Zone Transfer Policy, e finalmente, Create a Zone Leve Zone transfer Policy.

No decorrer desta série de posts veremos em exemplos práticos com PowerShell como usar todas as políticas citadas acima em seu ambiente. Não perca! Certamente ela vai ajudar bastante seu dia a dia para assimilar melhor essa nova funcionalidade no Windows Server 2016.

Em breve a parte de balanceamento de carga com DNS Policies será republicada.

A base de estudos para este post foi tirada do link abaixo:

https://technet.microsoft.com/en-us/windows-server-docs/networking/dns/deploy/dns-policies-overview

Abraços

Uilson

DNS Server–Configurando a Global Query Block List via PowerShell

28 de novembro de 2016 Deixe um comentário

Saudações,

Aos que estão acompanhando a nossa série de artigos sobre otimização de tarefas com PowerShell, hoje vou fazer um “adendo” ao 5o. post – Otimização de tarefas com PowerShell – DNS Server.

Um dos pontos de atenção nas empresas nos últimos anos é a configuração do acesso ao proxy usando o registro wpad do DNS Server. O mesmo pode ser configurado via DHCP também, mas, deixarei isso para um próximo post.

Por questões de segurança, desde o Windows Server 2008, o registro WPAD e ISATAP (registro que auxilia na comunicação de dipsositivos IPv4 e IPv6), estão bloqueados para uso. Entretanto, o administrador do ambiente pode escolher entre:

1. Ativar um desses registros – via PowerShell com via linha de comando DNSCMD

2. Desativar a Global Query Global List

Um exemplo de como configurar essa funcionalidade via linha de comando foi dada no meu artigo de 16/07/2013 onde citei a configuração do WPAD via DNS usando o DNSCMD.

No nosso caso em que estamos destrinchando o PowerShell para nosso dia a dia, estou deixando aqui um exemplo prático de como usar o comando Get-DnsServerGlobalQueryBlockList e Set-DnsServerGlobalQueryBlockList

No primeiro exemplo vamos listar os hosts que estão bloqueados pelo Global Query Block List:

Get-DnsServerGlobalQueryBlockList

Em seguinda vamos liberar o uso do registro WPAD:

Set-DnsServerGlobalQueryBlockList –List “isatap” –Passthru

O comando acima vai reconstruir a Global Query Block List deixando bloqueado somente o registro “ISATAP”.

Agora vamos reconstruir a Global Query Block List inclindo, além do ISATAP, o WPAD também;

Set-DnsServerGlobalQueryBlockList –List “wpad, isatap” –Passthru

Se você quiser, também pode desabilitar a Global Query Block List (o que não recomendo):

Set-DnsServerGlobalQueryBlockList –Enable $False

E para habilitar de novo:

Set-DnsServerGlobalQueryBlockList –Enable $True

Abaixo um exemplo prático de como você visualiza todos os comandos citados:

image

No próximo post quero voltar ao Web Application Proxy, mostrando como configurar seu ambiente para aplicações com autenticação Kerberos.

Fique ligado aqui no blog e na fan page – facebook.com/usouzajr.

Abraços

Uilson

Otimizando tarefas com PowerShell–Administração DNS Server

16 de novembro de 2016 Deixe um comentário

Saudações,

Chegamos hoje ao quinto artigo da série “Otimizando tarefas com PowerShell”. Dessa vez vamos falar sobre administração do DNS.

Para quem ainda não viu, abaixo os 4 primeiros posts publicados:

1. Otimizando tarefas com PowerShell – Administrando Active Directory Users and Computers

2. Otimizando tarefas com PowerShell – Implementação e administração Web Application Proxy

3. Otimizando tarefas com PowerShell – Implementando e administrando AD Federation Services

4. Otimizando tarefas com PowerShell – Implementando e administrando Internet Information Services – IIS

Publiquei tb um artigo no TechNet Wiki sobre Administração do AD Directory Services via PowerShell com coneitos mais avançados que o primeiro desta série.

Podemos levar em consideração o ambiente fictício dos últimos 4 posts:

Domínio – uilson.net

Vamos considerar um ambiente básico onde o DNS está junto com o AD e também considerar a instalação de um novo servidor de resolução de nomes com as configurações básicas, criação de zones, hosts, etc.

1. Instalando e configurando a Role via Powershell:

A principio, todo domain controller já vem com o DNS Server instalado. Neste caso vamos simular um segundo DNS Server sendo instalado e que será integrado ao nosso Active Directory.

Como já mostrado em outros artigos desta série vamos usar o cmdlet “Add-WindowsFeature” ou “Install-WindowsFeature”:

Install-WindowsFeature DNS –IncludeManagementTools

No comando acima eu pedi a inclusão da console de gerenciamento, mas, vamos mostrar aqui como administrar seu DNS sem usa-la.

2. Configurando forward, reverse e stub zones (primárias)

Sabemos que podemos ter dois tipos de forward zone no DNS – Com integração no AD (que é o tipo mais comum para redes internas, tanto que um servidor promovido a Domain Controller já instala a role do DNS junto) e sem integração, ou seja, aquele DNS Server que poderá ser usado para resolução de nomes externos

Para criar uma Forward Lookup Zone integrada ao AD – Add-DnsServerPrimaryZone -Name "uilson.net" -ReplicationScope "Forest" –PassThru 

O comando acima vai criar um forward zone primária integrada ao AD, ou seja, todas as informações que forem criadas nesta zona serão armazenadas no base do AD.

Para criar uma Forward Lookup Zone sem integração com o AD – Add-DnsServerPrimaryZone -Name "uilson.net" -ZoneFile "uilson.net"

O Zone File armazena todas as configurações e registros criados neste forward lookup zone, uma vez que não há integração com o AD. Esse arquivo fica na pasta c:\windows\system32\dns do seu servidor DNS. De forma que, para zonas sem integração com o AD é interessante manter um backup destes arquivos para imediato restore em caso de necessidade.

Agora vamos ver como criar as zonas reversas, ou seja, aquelas que fazem a resolução IP-Nome. Abaixo os comandos que você deve usar para esta finalidade:

Para criar uma Reverse Lookup Zone integrada a seu AD – Add-DnsServerPrimaryZone -NetworkID "10.1.1.0/24" -ReplicationScope "Forest"

Para criar uma zona reversa sem integração com o AD – Add-DnsServerPrimaryZone -NetworkID 10.1.1.0/24 -ZoneFile "0.1.10.in-addr.arpa.dns"

Outra tipo de zone que você pode criar no DNS Server é a Stub Zone. Ela facilita a resolução de nomes em ambientes complexos. Os endereços da filial A serão mais rapidamente resolvidos pela filial C que se conectam via WAN em distâncias grandes.

Como os exemplos acima, você poderá criar uma stub zone de forma integrada, não integrada e também uma reverse stub zone.

Para criar uma stub zone não integrada com o AD – Add-DnsServerStubZone -Name "filialrj.uilson.net "192.168.1.1" -PassThru -ZoneFile "filialrj_uilsonnet.dns"

No exemplo acima criei uma stub zone não integrada ao AD para uma filial no Rio de Janeiro dentro da arvore uilson.net.

Com base no cenário do exemplo acima, segue o comando para criar uma stub zone integrada ao AD:

Add-DnsServerStubZone -Name "filialrj.uilson.net" -MasterServers 192.168.1.1 -PassThru -ReplicationScope "Forest"

Você também pode criar uma reverse stub zone – Add-DnsServerStubZone -NetworkId 10.10.1.0/24 -MasterServers 192.168.1.1 -PassThru -ReplicationScope Forest – neste exemplo, integrada ao AD.

3. Criando Zonas Secundárias

Para criação de uma Reserve Lookup Zone integrada ao AD em um DNS Secundário, ou seja, uma zona secundária que irá receber informações de uma zona primária criada conforme mostramos no item 2 deste post, você deve usar o comando abaixo:

Integrada ao AD – Add-DnsServerSecondaryZone –Name “uilson.net” –ReplicationScope “Forest” –MasterServers 10.10.1.1

Associada a um Zone File – Add-DnsServerSecondaryZone -Name "uilson.net" -ZoneFile "uilson.net" -MasterServers 10.10.1.1

4. Configurando propriedades dos zones

DNS Forwarder e DNS Conditional Forwarder

Um dos pontos a serem configurados em uma zona de encaminhamento no DNS Server é o serviço de Forwarder.

O servidor DNS que você configura como Forwarder irá receber as requisições de resolução de nomes externas encaminhadas do seu DNS Interno.

Neste caso, temos duas maneiras de configurar a lista de Forwarders:

1. Set-DnsServerForwarder – Este comando irá começar a lista de IP´s externos do zero, ou seja, usado em situações em que você acabou de instalar e configurar seu DNS Server.

2. Add-DnsServerForwarder – Este comando irá adicionar IP´s a uma lista de forwarders já existente.

OBS: Se você usar o comando Set-DnsServerForwarder em uma lista de forwarders já existente, você vai “zerar” a lista e usar aquele IP que o comando definir no momento em que for executado, portanto, cuidado!

Para criar um nova lista de forwarders – Set-DnsServerForwarder -IPAddress "192.168.0.1" –PassThru

Para adicionar um IP a uma lista de forwarders – Add-DnsServerForwarder -IPAddress 192.168.0.1 –PassThru

Outra configuração interessante a ser feita é a do Conditional Forwarder, funcionalidade que foi introduzida a partir do Windows Server 2003. Um Conditional Forwarder permite a resolver nomes de um rede privada ou externa, ajudando a acelerar a resolução. Quando o DNS recebe a requisição de um cliente para resolver o nome de um host que não está em sua zona autoritativa, o processo começa a partir do root name do servidor e continua até a resolução do nome. Quando você configura um Conditional Forwarder, o DNS local encaminhará a requisição para a zona autoritativa do domínio de destino.

De igual forma aos exemplos mostrados neste post, você pode criar uma zona Conditional Forwarder de forma integrada a seu AD Loal ou não.

O link abaixo fala de Zonas Conditional Forwarder para Windows Server 2003, mas, o conceito explicado pode ser usado em qualquer situação a frente, ou seja, Windows Server 2008, 2012, 2016, etc:

https://support.microsoft.com/en-us/kb/304491 – Conditional Forwarding in Windows Server 2003

Agora vamos a prática:

Para criar uma Conditional Forwarder Zone integrada a seu AD: Add-DnsServerConditionalForwarderZone -Name "contoso.com" -ReplicationScope "Forest" -MasterServers 172.16.10.1

Para criar uma Conditional Forwarder Zone sem integração com seu AD: Add-DnsServerConditionalForwarderZone -Name "contoso.com" -MasterServers 172.16.10.1 –PassThru

Root Hints

Para adicionar um endereço a minha lista de root hints – Add-DnsServerRootHint -NameServer "root.contoso.com" -IPAddress 172.23.90.128

Zone Transfers

Quando você configura uma zona secundária, precisa habilitar a transferência dos dados da primária.

Para habilitar o zone transfer – Start-DnsServerZoneTransfer -Name "uilson.net"

DNS Policy

Ao invés de deixar um ou outro exemplo sobre DNS Policy, vou colocar o link pra um artigo que escrevi em 24/06/2015 – Nele mostrei um cenário completo onde você pode configurar o DNS Policy. Essa feature vem a partir do Windows Server 2016. Clique aqui para ler o post.

Tem muito mais

Os exemplos citados acima são apenas alguns daqueles que podem ser usados para configurar e administrar seu DNS Server via PowerShell. Muitos outros existem e vou deixar um link aqui com todos os cmdlets do DNS Server com exemplos práticos.

5. Criação de Registros

A criação de registros em uma zona é feita de forma automática. Entretanto, imagine a situação em que você precise registrar um host que aponte a um web server, um application server ou back-end server.

Vamos ver abaixo como criar um registro A que venha de encontro a esse propósito.

Cenário: Temos um web server no domínio uilson.net. O mesmo tem uma aplicação que deverá ser publicada e usada internamente ou externamente. No IIS eu configurei esta aplicação com o host header sistemas.uilson.net. O IP deste servidor é 10.10.1.50. Veja abaixo como este registro é criado:

Add-DnsServerResourceRecord -ZoneName "uilson.net" -A -Name "sistemas" -IPv4Address "10.10.1.50"

Nesse link você encontra exemplos práticos de como criar os demais tipos de registro (AAAA, CNAME, etc) – https://technet.microsoft.com/en-us/library/jj649925.aspx

6. Consultas

Neste ponto em que nosso laboratório já está totalmente configurado. Vamos ver os comandos que você pode usar para verificar as configurações de seu DNS Server:

Get-DnsServer

Este comando traz todas as configurações de seu DNS Server. Voce pode usar também o parâmetro –computername para pegar informações remotamente.

image

Get-DnsServerZone

Este comando traz todas as Zones criadas no seu DNS Server. Voce pode usar também o parâmetro –computername para pegar informações remotamente.

image

Get-DnsServerResourceRecord -ZoneName uilson.net

O comando acima lista todos os registros na zone uilson.net:

image

Estas são apenas algumas das muitas consultas que podem ser feitas. No item abaixo você encontra o link que poderá ver exemplos práticos de todas elas.

7. Referências para estudo

Neste link você encontra todos, exatamente todos os comandos DNS para PowerShell com exemplos práticos – https://technet.microsoft.com/en-us/library/jj649850.aspx

8. Conclusão

Neste post mostrei para você exemplos práticos de instalação, configuração e administração do DNS Server via PowerShell.

Espero que o conteúdo possa ser útil e lhe ajudar em suas tarefas diárias.

Abraços

Uilson

Usando o DNS Policies do Windows Server 2016 TP para balanceamento de carga

24 de junho de 2015 4 comentários

Saudações

Um das grandes mudanças que vem com o Windows Server 2016 TP não se resume somente ao que tenho mostrado nesse blog acerca do Web Application Proxy e AD Federation Services.

Hoje vamos abrir mais as possibilidades e compartilhar sobre algumas mudanças que o serviço de DNS também ganhou.

O Windows Server 2016 Technical Preview traz o DNS policies, uma nova feature na role DNS server.

As políticas são criadas para controlar como o DNS Server controla as requisições baseado em diversos parâmetros. O pessoal do Network Blog da Microsoft escreveu uma série de artigos onde detalham as funcionalidades do DNS Policies entre elas a parte de traffic management, deployment do split-brain DNS e criação de DNS query filters usando as políticas.

Neste post vou partilhar com vocês algo que eles também já detalharam, o balanceamento de carga de aplicações via DNS Policies. Para quem usa DNS no Windows Server 2008 ou 2012, trata-se de uma evolução do Round Robin.

Os procedimentos a seguir foram feitos em laboratório montado por mim usando como base de estudo o artigo do pessoal do Network Blog, no endereço abaixo:

http://blogs.technet.com/b/networking/archive/2015/05/20/application-load-balancing-using-dns-server-policies.aspx

Para ilustrar melhor, vamos imaginar um ambiente em que eu tenho meus servidores de aplicação espalhados em 4 datacenters. São Paulo, Rio de Janeiro, Fortaleza e Belo Horizonte. Lembrando que esse é um ambiente fictício. Estou compartilhando aqui o que aprendi estudando o artigo acima citado e o laboratório que fiz.

A diferença deste laboratório para o que foi postado no link acima é que, no meu caso, tenho em São Paulo e Rio de Janeiro, servidores que podem receber mais carga de acessos do que nas outras duas filiais.

No exemplo pelo pessoal do Network Blog, eles possuem 3 ambientes, sendo o primeiro o que tem mais condições de receber a caga de requisições em relação aos dois últimos.

No caso do nosso post aqui, vamos nos ater ao desenho abaixo:

image

Usando por base o exemplo acima, o DNS Policies irá distribuir as requisições entre os servidores fazendo com que as 3 primeiras requisições sejam direcionadas para São Paulo, as próximas 3 para Rio de Janeiro, as 2 seguintes para Fortaleza e as próximas 2 para Belo Horizonte. O processo se repete constantemente.

Agora, tecnicamente falando, como isso pode ser feito? Vamos listar os procedimentos:

Criar os zone scopes

O zone scope é uma instância única em um zone. Um zone pode conter diversos escopos e esses escopos podem conter diversos registros. No nosso laboratório, iremos criar os escopos SP_Scope (para São Paulo), RJ_Scope (para Rio de Janeiro), For_Scope (para Fortaleza) e BH_Scope (para Belo Horizonte). Lembrando que nosso zone tem o nome de uilson.net.

Todos os procedimentos listados aqui são feitos via Power Shell:

Criando o Zone Scope para São Paulo com o comando Add-DnsServerZoneScope -ZoneName "uilson.net" -Name "SP_Scope"

image

Repetir os processos para os sites do Rio, Fortaleza e Belo Horizonte:

Add-DnsServerZoneScope -ZoneName "uilson.net" -Name "RJ_Scope"

Add-DnsServerZoneScope -ZoneName "uilson.net" -Name "For_Scope"

Add-DnsServerZoneScope -ZoneName "uilson.net" -Name "BH_Scope"

Inserir os registros nos Zones Scopes

O próximo passo do nosso laboratório é inserir o registro dos web servers nos zones scopes criados no passo anterior.

Dentro dos zone scopes do domínio uilson.net vou inserir o registro “app” para que a chamada “app.uilson.net” retorne a aplicação a sere balanceada pelo DNS Policies.

O registro app será criado em cada zone scope com o IP referente ao web server da localidade conforme abaixo:

SP_Scope – 10.10.0.10

RJ_Scope – 10.10.1.10

For_Scope – 10.10.2.10

BH_Scope – 10.10.3.10

O primeiro registro a ser criado será no zone scope SP_Scope:

Add-DnsServerResourceRecord -ZoneName "uilson.net" -A -Name "app" -IPv4Address "10.10.0.10" -ZoneScope "SP_Scope"

image

Repetir o comando para os demais sites, alterando IP e Zone Scope name:

Add-DnsServerResourceRecord -ZoneName "uilson.net" -A -Name "app" -IPv4Address "10.10.1.10" -ZoneScope "RJ_Scope"

Add-DnsServerResourceRecord -ZoneName "uilson.net" -A -Name "app" -IPv4Address "10.10.2.10" -ZoneScope "For_Scope"

Add-DnsServerResourceRecord -ZoneName "uilson.net" -A -Name "app" -IPv4Address "10.10.3.10" -ZoneScope "BH_Scope"

Criação da política

Agora que nosso laboratório já tem os zone scopes e os registros criados em cada um deles, nos resta agora criar a política que irá distribuir as requisições entre os DNS Servers de acordo com o que foi planejado no começo deste post.

Relembrando que em nosso laboratório fictício, o hardware dos servidores de São Paulo e Rio de Janeiro têm condições de receberem um número maior de requisições (ambos ficarão com 30% da carga) e os servidores de Fortaleza e Belo Horizonte, com um hardware e menor poder de carga, ficam com 20% das requisições cada um.

A política é configurada através do comando abaixo:

Add-DnsServerQueryResolutionPolicy -Name "AppServerPolicy" -Action ALLOW – -ZoneScope "SP_Scope,3;RJ_Scope,3;For_Scope,2;BH_Scope,2" -ZoneName "uilson.net"

image

Repare na sintaxe do comando PS que após cada zone scope name vem uma vírgula e um número:

SP_Scope,3

RJ_Scope,3

For_Scope,2

BH_Scope,2

Desta forma eu defino que São Paulo receberá as 3 primeiras requisições, o Rio de Janeiro as próximas 3, Fortaleza receberá as 2 seguintes e Belo Horizonte as 2 próximas. O fluxo de repete constantemente.

Vale ressaltar que o processo de balanceamento de carga pelo DNS Policies melhorou muito em relação ao DNS Round Robin. Entretanto, pelo que vi no meu laboratório, algumas limitações permanecem…tais como a impossibilidade de determinar se um host está ou não disponível. Ao menos não encontrei nada que mudasse esse quadro.

Tendo em vista ainda estarmos na versão Technical Preview do Windows Server 2016, imagino que nem tudo o que estamos vendo permanecerá como está. Mudanças podem ocorrer no decorrer do período de testes.

Conclusão

Neste post mostrei pra você como configurar o serviço de balanceamento de carga de aplicações via DNS do Windows Server 2016 Technical Preview, utilizando a nova feature DNS Policies.

Expliquei como se cria os escopos de zona, adição dos registros e criação das políticas em face ao planejamento inicial.

Recomendo o uso deste recurso em aplicações de uso interno de sua corporação. O mesmo não se aplica a acessos externos.

Assim que eu reestruturar meu laboratório vamos retornar aos testes com a nova versão do Web Application Proxy no Windows Server 2016 TP e também o Application Request Router.

Espero que o conteúdo seja útil!

Abraços

Uilson

%d blogueiros gostam disto: