Cerrar
InicioDNSDirectivas DNS en Windows Server 2016

Directivas DNS en Windows Server 2016

Con la llegada de Windows Server 2016 se han introducido diferentes novedades, hoy me gustaría comentar una de las que más me han gustado: Directivas para la resolución de nombres vía DNS. Esto nos permite definir como se comportará nuestro servidor DNS en base a las consultas que se la realicen a nuestro servidor:

  • Application high availability. DNS clients are redirected to the healthiest endpoint for a given application.
  • Traffic Management. DNS clients are redirected to the closest datacenter.
  • Split Brain DNS. DNS records are split into different Zone Scopes, and DNS clients receive a response based on whether they are internal or external clients.
  • Filtering. DNS queries from a list of malicious IP addresses or FQDNs are blocked.
  • Forensics. Malicious DNS clients are redirected to a sink hole instead of the computer they are trying to reach.
  • Time of day based redirection. DNS clients can be redirected to datacenters based on the time of the day.

Para poder crear nuestras directivas, primero debemos crear un conjunto de registros que nos permiten definir a quien vamos a aplicar nuestra directiva:

  • Client subnet: a client subnet object represents an IPv4 or IPv6 subnet from which queries are submitted to a DNS server. You can create subnets to later define policies to be applied based on what subnet the requests come from. For instance, in a split brain DNS scenario, the request for resolution for a name such as www.microsoft.com can be answered with an internal IP address to clients from internal subnets, and a different IP address to clients in external subnets.
  • Recursion scope: recursion scopes are unique instances of a group of settings that control recursion on a DNS server. A recursion scope contains a list of forwarders and specifies whether recursion is enabled. A DNS server can have many recursion scopes. DNS server recursion policies allow you to choose a recursion scope for a set of queries. If the DNS server is not authoritative for certain queries, DNS server recursion policies allow you to control how to resolve those queries. You can specify which forwarders to use and whether to use recursion.
  • Zone scopes: a DNS zone can have multiple zone scopes, with each zone scope containing their own set of DNS records. The same record can be present in multiple scopes, with different IP addresses. Also, zone transfers are done at the zone scope level. That means that records from a zone scope in a primary zone will be transferred to the same zone scope in a secondary zone.

Yo me voy a centrar en configurar un entorno con Split-DNS, vamos, que tengamos el mismo nombre de dominio tanto en interno como en internet. Esto suele ser muy común, de tal forma que los FQDN que utilizamos para conectarnos a los distintos servicios (SharePoint, Webs, Exchange, SkypefB) sean siempre los mismos, estemos fuera o dentro de la red. Es muy probable que tengamos los servidores de Exchange, SharePoint, SkypefB o algún servidor Web dentro de la red, en una DMZ o en el CPD del proveedor al cual nos conectamos vía VPN, MPLS, etc… . Además, a esos servidores también tenemos acceso desde Internet, publicando dichos servicios a través de nuestros Firewalls, Reverse-Proxy, etc… y para conectarnos a ellos utilizamos un FQDN, el cual si tenemos el mismo nombre de dominio en interno y externo, debemos crear los registros DNS de forma correcta. Desde dentro de la red el servidor web www.asirlab.com tiene la IP 10.10.10.10, y desde Internet también nos conectamos a www.asirlab.com pero con la IP 109.123.117.188. Esto así sin más sería muy sencillo de configurar, puesto que si tenemos dos servidores DNS, únicamente en el interno creamos el registros FQDN www.asirlab.com con la IP 10.10.10.10 y en el servidor DNS externo el registro FQDN www.asirlab.com con la IP Pública correspondiente. Bien, pero que ocurre cuando queremos utilizar el mismo servidor DNS para que resuelva ambos registros DNS y con direcciones IP diferentes en base a que cliente haga la consulta, pues para eso tenemos las Directivas DNS con Windows Server 2016!! (https://technet.microsoft.com/es-es/windows-server-docs/networking/dns/deploy/dns-policies-overview).

Este será mi LAB para este articulo:

  • Servidor DNS (tiene dos interfaces para simular conexiones por una u otra interface)
    • IP LAN: 10.10.10.10
    • IP WAN: (el servidor tiene RAS configurado y esta seria la interface “pública”): 192.168.100.69
  • Clientes
    • Cliente 1: Equipo unido al dominio y con una IP del rango 10.10.10.0/24
    • Cliente 2: Equipo fuera del dominio, con una IP del rango 192.168.100.0/24 y como servidor DNS tiene la IP 192.168.100.69 del servidor DNS
    • Cliente 3: Equipo fuera del dominio, con una IP del rango 192.168.250.0/24 y como servidor DNS tiene la IP 192.168.100.69 del servidor DNS
  • FQDN a consultar: www.asirlalb.com
    • IP a resolver por el cliente 1: 10.10.10.10 (es la misma IP que el servidor DNS, pero lo suyo sería es que fuese otra IP de otro equipo)
    • IP a resolver por el cliente 2: 109.123.117.188
    • IP a resolver por el cliente 3: 10.10.10.10 (es la misma IP que el servidor DNS, pero lo suyo sería es que fuese otra IP de otro equipo)
  • Policitas:
    • En base a su Zona: En base a la zona en la que se encuentre el cliente, resolverá la IP del FQDN www.asirlab.com
    • En base a la Subred: En base a la subred IP donde se encuentre el cliente resolverá la IP del FQDN www.asirlab.com

Lo primero que haré será crear la zona Interna, la cual utilizaré para que los clientes unidos al dominio resuelvan la IP 10.10.10.10 del registro www.asirlab.com, para ello utilizaremos el siguiente cmdlet: Add-DnsServerZoneScope

split-brain_dns_deployment_using_windows_dns_policies_14

Ahora que tengo la zona creada, añadiré dos registros a la misma zona, pero con distinto ámbito. El primer registro está en la zona por defecto, el cual deberá resolver el Cliente 1 de esta LAB. El segundo registro, lo asociará a la zona Interna que previamente hemos creado.

split-brain_dns_deployment_using_windows_dns_policies_04

Como de momento no hemos configurado más que los objetos necesarios para posteriormente crear nuestra directiva, si ahora nos vamos al Cliente 1 y Cliente 2, veremos que ambos resuelven la IP 109.123.117.188, puesto que se ha creado dicho registro en la zona por defecto:

IP del Cliente 1:

split-brain_dns_deployment_using_windows_dns_policies_02

Resolución del registro www.asirlab.com:

split-brain_dns_deployment_using_windows_dns_policies_06

IP del Cliente 2:

split-brain_dns_deployment_using_windows_dns_policies_00

Resolución del registro www.asirlab.com:

split-brain_dns_deployment_using_windows_dns_policies_05

Como se puede apreciar, ambos clientes resuelven la misma IP del registro www.asirlab.com, puesto que de momento no hemos creado nuestra política. Pues bien, ahora crearemos nuestra directiva DNS con el siguiente cmdlet: Add-DnsServerQueryResolutionPolicy (https://technet.microsoft.com/es-es/library/mt126273.aspx). Si os fijáis, simplemente definimos la zona en función de la IP que tiene configurada el servidor DNS como interface habilitada para tal servicio. En este caso, la IP 10.10.10.10 también es la IP del registro www.asirlab.com, pero lo normal es que sea una IP diferente a la del servidor, puesto que el servidor DNS no debería tener más servicios que ese.

split-brain_dns_deployment_using_windows_dns_policies_07

Si ahora volvemos al Cliente 1 y ya dentro del nslookup lanzamos nuevamente la misma consulta, veréis que ahora ya nos muestra la IP 10.10.10.10 del registro www.asirlab.comsplit-brain_dns_deployment_using_windows_dns_policies_08

Si lo mismo que en el Cliente 1 lo hacemos en el Cliente 2, vemos que sigue resolviendo la IP 109.123.117.188 sobre el registro www.asirlab.comsplit-brain_dns_deployment_using_windows_dns_policies_09

Con esto ya tenemos a los clientes internos resolviendo la IP interna (10.10.10.10) del servidor en donde tenemos la web (www.asirlab.com) y los clientes externos resolviendo la IP externa (109.123.117.188) en donde tenemos nuestro Firewall, Reverse-Proxy, etc.. publicando el servidor para los clientes externos. En nuestro caso, como hemos configurado nuestr zona en base la  IP por la que el servidor DNS recibe las peticiones, si alguien le consulta a la IP 192.168.250.69 serán clientes externos y si se le consulta por la IP 10.10.10.10 serán clientes internos.

Ahora bien, quiero añadir una nueva directiva, la cual me permita definir que en base a la subred IP desde al cual se conecte el cliente, se la resolverá un IP u otra del FQDN www.asirlab.com.  En este LAB tenemos otro cliente, el Cliente 3, el cual está conectado mediante otra subred (192.168.250.0/24), el cual queremos que sus consultas a nuestro servidor DNS siempre se le resuelva la IP 10.10.10.10, aún cuando la consulta se la hará por la interface 192.168.100.69 (la cual la tenemos como interface pública en el servidor).

Para ello, debemos configurarlo con dos cmdlets:

  • Add-DnsServerClientSubnet: Definiremos la subred desde donde nos llegará la petición al servidor DNS
  • Add-DnsServerQueryResolutionPolicy: Definiremos que permitiremos la conexión a la zona Interna (creada anteriormente) siempre que vengan de la subred DataCenter (192.168.250.0/24)

split-brain_dns_deployment_using_windows_dns_policies_12

Aquí tenéis la consulta al servidor DNS  (192.168.100.69 IP Pública en el servidor DNS) vía NSLOOKUP, como vemos, nos mostrará una IP diferente sobre el FQDN www.asirlab.com antes y después de tener la directiva creada:

split-brain_dns_deployment_using_windows_dns_policies_13

Esta última configuración también es muy útil para servicio geográficamente dispersos, lo que nos permitiría tener varios servidores por todo el mundo distribuidos, y que los clientes en base a las subredes (podríamos hacerlo por IP Públicas o Privadas, depende de como se conectasen a dichos servidores) en las que se encuentren a uno u otro servidor. Esto nos permitiría llevar al usuario, al servidor más cercano a su ubicación, optimizando con ellos su acceso.

Yo he utilizado dos criterios para crear mis directivas, pero tenemos las siguientes opciones disponibles (https://technet.microsoft.com/es-es/windows-server-docs/networking/dns/deploy/dns-policies-overview):

Nombre Descripción Valores de ejemplo
Subred del cliente Utilizado en la consulta de protocolo de transporte. Las entradas posibles son UDP y TCP EQ, España, Francia -resuelve en verdadero si la subred se identifica como España o Francia
NE, Canadá, México -resuelve en verdadero si la subred del cliente es una subred que no sea Canadá y México
Protocolo de transporte

Transport Protocol
Utilizado en la consulta de protocolo de transporte. Las entradas posibles son UDP y TCP EQ, TCP
EQ, UDP
Protocolo de Internet Protocolo de red utilizado en la consulta. Las entradas posibles son IPv4 y IPv6 EQ, IPv4
EQ, IPv6
Dirección IP de la interfaz del servidor Dirección IP de la interfaz de red entrante del servidor DNS EQ, 10.0.0.1
EQ, 192.168.1.1
FQDN FQDN del registro de la consulta, con la posibilidad de utilizar un carácter comodín EQ, www.contoso.com -resuelve tot rue sólo el cuando la consulta está intentando resolver la www.contoso.com FQDN
EQ,*. contoso.com,*. woodgrove.com -resuelve en verdadero si la consulta es para cualquier registro termina en contoso.comowoodgrove.com
Tipo de consulta Tipo de registro que se está consultando (A, SVR, TXT) SRV EQ, TXT, -resuelve tot rue si la consulta solicita un TXT o registro SRV
EQ, MX -resuelve tot rue si la consulta solicita un registro MX
Hora del día Hora del día en que se recibe la consulta EQ, 10:00-12:00:22: 00-23:00 -resuelve tot rue si se recibe la consulta entre las 10 A.M. y a mediodía, o entre 10 P.M. y las 11 P.M.

Esto ya os lo dejo para vosotros, sólo comentaros que a mi me ha encantado esta nueva funcionalidad en nuestros servidores DNS!!!

Espero que mi ejemplo no haya resultado confuso por la topología, ese que se LAB lo utiliza para llevar mis MV a cualquier subred y que tengan internet los clientes y servidores. Tengo un DC con RAS con NAT habilitado, y los clientes en una interface privada en una VLAN en al subred 10.10.10.0/24. En esa subred está el Controlador de Dominio (IP 10.10.10.10) que a su vez es servidor DNS, y los clientes tienen como servidor DNS y Gateway la IP del servidor. La configuración de los clientes es así  porque así los clientes tendrán internet a través del propio servidor, puesto que tiene el servicio de RAS con NAT configurado y como interface WAN la única interface física disponible que tiene mi Surface 4 Pro. Suelo utilizar la red inalámbrica, porque si utilizar el adaptador USB para la red cableado me ocupa el único USB disponible. De esta forma la interface WAN de la MV del Controlador de Dominio está siempre por DHCP y vaya a donde vaya siempre tengo internet por ella, y luego el resto de MV salen a Internet por la configuración del servicio de RAS.

Lo dicho, espero que no os haya liado más todavía la segunda explicación jeje, pero bueno, era para que entendierais el porqué de mi LAB y las direcciones IP utilizadas.

 Espero que os sea de utilidad!!

Cómo instalar certi
Skype For Business R
6 COMENTARIOS

DEJA UN COMENTARIO

Este sitio web utiliza cookies. Si continúas navegando, consideramos que aceptas su uso. Puedes obtener más información en nuestra política de cookies. ACEPTAR

Aviso de cookies