Windows Server 2016 Highlights: DNS Server

Tra le molte novità introdotte in Windows Server 2016 ce ne sono alcune particolarmente interessanti legate al Domain Name System (DNS).

Il DNS è un servizio di risoluzione dei nomi che associa i nomi dei computer agli indirizzi IP. In Windows Server 2016 il DNS è un ruolo che permette di trovare risorse all’interno di un dominio, di una rete aziendale o in Internet. Inoltre è un servizio che permette di facilitare l’autenticazione degli utenti e dei computer in dominio.

Windows Server 2016 introduce funzionalità nuove nel DNS:

  • Criteri DNS: È possibile configurare dei criteri DNS per specificare come un server DNS risponde alle query DNS. Le risposte date dal server DNS possono essere basate sull’indirizzo IP del client (in base alla sua posizione geografica), momenti precisi della giornata e molti altri parametri. I criteri DNS permettono di implementare scenari basati sul riconoscimento della posizione, la gestione del traffico, il bilanciamento del carico o DNS “split brain”.
  • Response Rate Limiting (RRL): È possibile abilitare il limite della velocità di risposta dei server DNS in modo da evitare la possibilità di ricevere degli attacchi denial of service (DOS).
  • DNS-based Authentication of Named Entities (DANE): È possibile utilizzare i record TLSA (autenticazione di sicurezza del Layer di trasporto) per indicare ai client DNS da quale Certification Authority si devono aspettare un certificato per il nome di dominio. Questo impedisce gli attacchi man-in-the-middle.
  • Unknown record support: È possibile aggiungere tipi di record che non sono supportati dal server DNS di Windows.
  • IPv6 Root Hints: è possiible usare i Root Hints IPv6 per la risoluzione dei nomi Internet.

Tra queste funzionalità quella che mi ha colpito maggiormente è stata quella relativa ai Criteri DNS. Gli scenari per cui si presta questo tipo di funzionalità sono molteplici:

  • Disponibilità elevata di un’applicazione. I client DNS vengono reindirizzati verso l’endpoint dell’applicazione che è funzionante
  • Gestione del traffico. I client DNS vengono reindirizzati al Datacenter più vicino. Supponiamo di avere due Datacenter, uno in America ed uno in Europa, e di voler dirottare il traffico proveniente dalla subnet 10.10.11.0/24 verso l’America e quello proveniente dalla subnet 192.168.11.0/24 verso l’Europa. I comandi da eseguire sono:

#Definisco le due Subnet utilizzate dai client

Add-DnsServerClientSubnet -Name “AmericaSubnet” -IPv4Subnet “10.10.11.0/24”

Add-DnsServerClientSubnet -Name “EuropeSubnet” -IPv4Subnet “192.168.11.0/24”

#Creo due scope per la zona ICTPower.it

Add-DnsServerZoneScope -ZoneName “ictpower.it” -Name “AmericaZoneScope

Add-DnsServerZoneScope -ZoneName “ictpower.it” -Name “EuropeZoneScope”

#Creo due record www, uno per ogni scope

Add-DnsServerResourceRecord -ZoneName “ictpower.it” -A -Name “www” -IPv4Address “192.168.11.24” -ZoneScope “EuropeZoneScope”

Add-DnsServerResourceRecord -ZoneName “ictpower.it” -A -Name “www” -IPv4Address “10.10.11.24” -ZoneScope “AmericaZoneScope”

#Creo le policy per il Traffic Management

Add-DnsServerQueryResolutionPolicy -Name “AmericaPolicy” -Action ALLOW -ClientSubnet “eq,AmericaSubnet” -ZoneScope “AmericaZoneScope,1” -ZoneName “ictpower.it”

Add-DnsServerQueryResolutionPolicy -Name “EuropePolicy” -Action ALLOW -ClientSubnet “eq,EuropeSubnet” -ZoneScope “EuropeZoneScope,1” -ZoneName ictpower.it

Figura 1: Creazione della Policy per il Traffic Management

  • Split-brain DNS. I record DNS vengono suddivisi in diversi scope di zona (interna ed esterna) e i client DNS ricevono una risposta basata sul fatto che siano client interni o esterni.
  • Filtro. Le query DNS provenienti da un elenco di indirizzi IP o di nomi FQDN dannosi vengono bloccate. Per poter creare un filtro è sufficiente eseguire il comando:

#Indico qual è la subnet da filtrare

Add-DnsServerClientSubnet -Name “MaliciousSubnet” -IPv4Subnet 192.168.33.0/24 -PassThru

#Creo la policy per il filtering

Add-DnsServerQueryResolutionPolicy -Name “BlackholePolicyMalicious” -Action IGNORE -ClientSubnet “EQ,MaliciousSubnet” -PassThru

Figura 2: Creazione di un filtro

  • Reindirizzamento basato su ora del giorno. I client DNS possono essere reindirizzati verso un datacenter in base all’ora del giorno.
  • Load balancing. I client DNS ricevono risposte in base al bilanciamento voluto. Se un Datacenter ha il doppio della capacità di un altro allora è possibile fare in modo che la risposta alle query verso il DNS server restituisca i risultati in base al peso stabilito. Per effettuare la configurazione basta eseguire questi comandi:

#Configuro i due scope

Add-DnsServerZoneScope -ZoneName “ictpower.it” -Name “Datacenter1ZoneScope”

Add-DnsServerZoneScope -ZoneName “ictpower.it” -Name “Datacenter2ZoneScope”

#Aggiungo i resource record agli scope

Add-DnsServerResourceRecord -ZoneName “ictpower.it” -A -Name “intranet” -IPv4Address “192.168.1.20” -ZoneScope “Datacenter1ZoneScope”

Add-DnsServerResourceRecord -ZoneName “ictpower.it” -A -Name “intranet” -IPv4Address “10.10.1.20” -ZoneScope
“Datacenter2ZoneScope”

#Specifico la subnet da cui vengono originate le richieste

Add-DnsServerClientSubnet -Name “Location1Subnet” -IPv4Subnet “192.168.1.0/24” -PassThru

Add-DnsServerClientSubnet -Name “Location2Subnet” -IPv4Subnet “10.10.1.0/24” -PassThru

#Creo una policy che stabilisca che la webfarm che si trova nel Datacenter 1 riceva il doppio delle connessioni della webfarm che si trova nel Datacenter 2

Add-DnsServerQueryResolutionPolicy -Name “IntranetPolicy” -Action ALLOW -ZoneScope “Datacenter1ZoneScope,2;Datacenter2ZoneScope,1” -ZoneName “ictpower.it”

Figura 3: Creazione della policy di Load Balancing

Per maggiori informazioni vi invito a leggere questi articoli:

DNS Policy Overview

Geo-Location Based Traffic Management Using DNS Policies

Split-Brain DNS Deployment Using Windows DNS Server Policies

Applying Filters on DNS Queries using Windows DNS Server Policies

Application Load Balancing using DNS Server Policies

Intelligent DNS Responses Based on the Time of Day

Traffic Management with DNS Policies in Primary-Secondary Deployment