Informazioni generali sui criteri QoS
È possibile usare questo argomento per informazioni sui criteri DNS, una novità di Windows Server 2016. È possibile usare i criteri DNS per la gestione del traffico basata sulla posizione geografica e le risposte DNS intelligenti in base all'ora del giorno per gestire un singolo server DNS configurato per la distribuzione "split brain", applicando filtri alle query DNS e altro ancora. Gli elementi seguenti forniscono maggiori dettagli su queste funzionalità.
Bilanciamento del carico dell'applicazione. Dopo aver distribuito più istanze di un'applicazione in posizioni diverse, è possibile usare i criteri DNS per bilanciare il carico del traffico tra le diverse istanze dell'applicazione, allocando dinamicamente il carico.
Gestione del traffico basata sulla posizione geografica. È possibile utilizzare i criteri di DNS per consentire ai server DNS primario e secondario di rispondere alle query dei client DNS in base alla posizione geografica del client e della risorsa a cui il client sta tentando di connettersi, fornendo al client l'indirizzo IP della risorsa più vicina.
Dividere cervello DNS. Con DNS "split brain". i record DNS vengono suddivisi in diversi ambiti di zona nello stesso server DNS e i client DNS ricevono una risposta basata sul fatto che siano i client interni o esterni. È possibile configurare DNS "split brain" per le zone integrate di Active Directory o per le zone nei server DNS autonomi.
Filtri. È possibile configurare i criteri DNS per creare filtri di query basati su criteri forniti. I filtri di query nei criteri DNS consentono di configurare il server DNS per rispondere in modo personalizzato in base alla query DNS e al client DNS che invia la query DNS.
Analisi forense. È possibile usare i criteri DNS per reindirizzare i client DNS dannosi a un indirizzo IP inesistente anziché indirizzarli al computer che stanno tentando di raggiungere.
Ora del giorno in base reindirizzamento. È possibile utilizzare i criteri DNS per distribuire il traffico dell'applicazione tra diverse istanze distribuite geograficamente di un'applicazione utilizzando i criteri DNS che si basano sull'ora del giorno.
Nuovi concetti
Per creare criteri per supportare gli scenari elencati in precedenza, è necessario essere in grado di identificare gruppi di record in una zona e gruppi di client in una rete, tra gli altri elementi. Questi elementi sono rappresentati dai nuovi oggetti DNS seguenti:
Subnet client: un oggetto subnet client rappresenta una subnet IPv4 o IPv6 da cui vengono inviate query a un server DNS. È possibile creare subnet per definire in un secondo momento i criteri da applicare in base alla subnet da cui provengono le richieste. Ad esempio, in uno scenario DNS split brain, la richiesta di risoluzione per un nome come www.microsoft.com può essere fornita con un indirizzo IP interno ai client da subnet interne e un indirizzo IP diverso ai client in subnet esterne.
Ambito di ricorsione: gli ambiti di ricorsione sono istanze univoche di un gruppo di impostazioni che controllano la ricorsione in un server DNS. Un ambito di ricorsione contiene un elenco di server d'inoltro e specifica se la ricorsione è abilitata. Un server DNS può avere molti ambiti di ricorsione. I criteri di ricorsione del server DNS consentono di scegliere un ambito di ricorsione per un set di query. Se il server DNS non è autorevole per determinate query, i criteri di ricorsione del server DNS consentono di controllare come risolvere tali query. È possibile specificare quali server d'inoltro usare e se usare la ricorsione.
Ambiti zona: una zona DNS può avere più ambiti di zona, con ogni ambito che contiene il proprio set di record DNS. Lo stesso record può essere presente in più ambiti, con indirizzi IP diversi. Inoltre, i trasferimenti di zona vengono eseguiti a livello di ambito della zona. Ciò significa che i record di un ambito di zona primaria verranno trasferiti allo stesso ambito della zona secondaria.
Tipi di criteri
I criteri DNS sono divisi per livello e tipo. È possibile usare i criteri di risoluzione delle query per definire il modo in cui vengono elaborate le query e i criteri di trasferimento di zona per definire il modo in cui si verificano i trasferimenti di zona. È possibile applicare ogni tipo di criterio a livello di server o di zona.
Criteri di risoluzione delle query
È possibile usare i criteri di risoluzione delle query DNS per specificare il modo in cui le query di risoluzione in ingresso vengono gestite da un server DNS. Ogni criterio di risoluzione delle query DNS contiene gli elementi seguenti:
| Campo | Descrizione | Possibili valori |
|---|---|---|
| Nome | Nome del criterio | - Fino a 256 caratteri - Può contenere qualsiasi carattere valido per un nome di file |
| Stato | Stato criteri | - Abilitare (impostazione predefinita) - Disabilitato |
| Livello | Livello dei criteri | Server- - Zona |
| Ordine di elaborazione | Dopo che una query viene classificata per livello e viene applicata, il server trova il primo criterio per il quale la query corrisponde ai criteri e lo applica alla query | - Valore numerico - Valore univoco per criterio contenente lo stesso livello e che si applica al valore |
| Azione | Azione da eseguire dal server DNS | - Consentire (impostazione predefinita per il livello di zona) - Negare (impostazione predefinita per il livello di server) - Ignorare |
| Criteri | Condizione dei criteri (AND/OR) ed elenco di criteri da soddisfare per l'applicazione dei criteri | - Operatore condizione (AND/OR) - Elenco dei criteri (vedere la tabella dei criteri riportata di seguito) |
| Scope | Elenco di ambiti di zona e valori ponderati per ambito. I valori ponderati vengono usati per la distribuzione del bilanciamento del carico. Ad esempio, se questo elenco include datacenter1 con un peso pari a 3 e datacenter2 con un peso pari a 5, il server risponderà con un record dal datacentre1 tre volte su otto richieste | - Elenco di ambiti di zona (per nome) e pesi |
Nota
I criteri a livello di server possono avere solo i valori Deny o Ignore come azione.
Il campo Criteri DNS è composto da due elementi:
| Nome | Descrizione | Valori di esempio |
|---|---|---|
| Subnet client | Nome di una subnet del client predefinito. Utilizzato per verificare la subnet da cui la query è stata inviata. | - EQ,Spain,France: restituisce true se la subnet viene identificata come Spagna o Francia - NE,Canada,Messico: viene risolto in true se la subnet client è una subnet diversa da Canada e Messico |
| Protocollo di trasporto | Il trasporto di protocollo utilizzato nella query. Sono possibili voci UDP e TCP | - EQ,TCP - EQ,UDP |
| Protocollo Internet | Protocollo di rete utilizzato nella query. Sono possibili voci IPv4 e IPv6 | - EQ,IPv4 - EQ,IPv6 |
| Indirizzo IP di interfaccia server | Indirizzo IP per l'interfaccia di rete del server DNS in ingresso | - EQ,10.0.0.1 - EQ,192.168.1.1 |
| FQDN | L'FQDN del record nella query, con la possibilità di utilizzare un carattere jolly | - EQ,www.contoso.com: restituisce true solo se la query sta tentando di risolvere l'FQDN www.contoso.com - EQ,*.contoso.com,*.woodgrove.com: restituisce true se la query è relativa a un record che termina in contoso.comOPPUREwoodgrove.com |
| Tipo di query | Tipo di record sottoposto a query (A, SRV, TXT) | - EQ,TXT,SRV: restituisce true se la query richiede un record TXT OPPURE SRV - EQ,MX: restituisce true se la query richiede un record MX |
| Ora del giorno | Ora del giorno in cui viene ricevuta la query | - EQ,10:00-12:00,22:00-23:00 : viene risolto in true se la query viene ricevuta tra le 10:00 e mezzogiorno OPPURE tra le 22:00 e le 23:00 |
Usando la tabella precedente come punto di partenza, la tabella seguente può essere usata per definire un criterio usato per associare le query per qualsiasi tipo di record, ad eccezione dei record SRV, nel dominio contoso.com proveniente da un client nella subnet 10.0.0.0/24 tramite TCP tra le 20:00 e le 22:00 attraverso l'interfaccia 10.0.0.3:
| Nome | Valore |
|---|---|
| Subnet client | EQ,10.0.0.0/24 |
| Protocollo di trasporto | EQ,TCP |
| Indirizzo IP di interfaccia server | EQ,10.0.0.3 |
| FQDN | EQ,*.contoso.com |
| Tipo di query | NE,SRV |
| Ora del giorno | EQ,20:00-22:00 |
È possibile creare più criteri di risoluzione query dello stesso livello, purché abbiano un valore diverso per l'ordine di elaborazione. Quando sono disponibili più criteri, il server DNS elabora le query in ingresso nel modo seguente:
Criteri di ricorsione
I criteri di ricorsione sono un tipo speciale di criteri a livello di server. I criteri di ricorsione controllano il modo in cui il server DNS esegue la ricorsione per una query. I criteri di ricorsione si applicano solo quando l'elaborazione delle query raggiunge il percorso di ricorsione. È possibile scegliere un valore DENY o IGNORE per la ricorsione per un set di query. In alternativa, è possibile scegliere un set di server d'inoltro per un set di query.
È possibile usare i criteri di ricorsione per implementare una configurazione DNS "split brain". In questa configurazione, il server DNS esegue la ricorsione per un set di client per una query, mentre il server DNS non esegue la ricorsione per altri client per tale query.
I criteri di ricorsione contengono gli stessi elementi di un normale criterio di risoluzione delle query DNS, insieme agli elementi nella tabella seguente:
| Nome | Descrizione |
|---|---|
| Applicare alla ricorsione | Specifica che questo criterio deve essere usato solo per la ricorsione. |
| Ambito di ricorsione | Nome dell'ambito di ricorsione. |
Nota
I criteri di ricorsione possono essere creati solo a livello di server.
Criteri di trasferimento di zona
I criteri di trasferimento della zona controllano se un trasferimento di zona è consentito o meno dal server DNS. È possibile creare criteri per il trasferimento di zona a livello di server o a livello di zona. I criteri a livello di server si applicano a ogni query di trasferimento di zona che si verifica nel server DNS. I criteri a livello di zona si applicano solo alle query in una zona ospitata nel server DNS. L'uso più comune per i criteri a livello di zona consiste nell'implementare elenchi bloccati o sicuri.
Nota
I criteri di trasferimento di zona possono usare solo DENY o IGNORE come azioni.
È possibile usare i criteri di trasferimento della zona a livello di server seguenti per negare un trasferimento di zona per il dominio contoso.com da una determinata subnet:
Add-DnsServerZoneTransferPolicy -Name DenyTransferOfContosoToFabrikam -Zone contoso.com -Action DENY -ClientSubnet "EQ,192.168.1.0/24"
È possibile creare più criteri di trasferimento di zona dello stesso livello, purché abbiano un valore diverso per l'ordine di elaborazione. Quando sono disponibili più criteri, il server DNS elabora le query in ingresso nel modo seguente:
Gestione dei criteri DNS
È possibile creare e gestire criteri DNS usando PowerShell. Gli esempi seguenti illustrano diversi scenari di esempio che è possibile configurare tramite i criteri DNS:
Gestione del traffico
È possibile indirizzare il traffico in base di un FQDN a server diversi a seconda del percorso del client DNS. L'esempio seguente illustra come creare criteri di gestione del traffico per indirizzare i clienti da una determinata subnet a un data center nordamericano e da un'altra subnet a un data center europeo.
Add-DnsServerClientSubnet -Name "NorthAmericaSubnet" -IPv4Subnet "172.21.33.0/24"
Add-DnsServerClientSubnet -Name "EuropeSubnet" -IPv4Subnet "172.17.44.0/24"
Add-DnsServerZoneScope -ZoneName "Contoso.com" -Name "NorthAmericaZoneScope"
Add-DnsServerZoneScope -ZoneName "Contoso.com" -Name "EuropeZoneScope"
Add-DnsServerResourceRecord -ZoneName "Contoso.com" -A -Name "www" -IPv4Address "172.17.97.97" -ZoneScope "EuropeZoneScope"
Add-DnsServerResourceRecord -ZoneName "Contoso.com" -A -Name "www" -IPv4Address "172.21.21.21" -ZoneScope "NorthAmericaZoneScope"
Add-DnsServerQueryResolutionPolicy -Name "NorthAmericaPolicy" -Action ALLOW -ClientSubnet "eq,NorthAmericaSubnet" -ZoneScope "NorthAmericaZoneScope,1" -ZoneName "Contoso.com"
Add-DnsServerQueryResolutionPolicy -Name "EuropePolicy" -Action ALLOW -ClientSubnet "eq,EuropeSubnet" -ZoneScope "EuropeZoneScope,1" -ZoneName contoso.com
Le prime due righe dello script creano oggetti subnet client per America del Nord ed Europa. Le due righe successive creano un ambito di zona all'interno del dominio contoso.com, uno per ogni area. Le due righe successive creano un record in ogni zona che associa www.contoso.com a un indirizzo IP diverso, uno per l'Europa, un altro per l'America del Nord. Infine, le ultime righe dello script creano due criteri di risoluzione delle query DNS, uno da applicare alla subnet America del Nord, un altro alla subnet Europa.
Bloccare le query per un dominio
È possibile usare criteri di risoluzione delle query DNS per bloccare le query in un dominio. L'esempio seguente blocca tutte le query per treyresearch.net:
Add-DnsServerQueryResolutionPolicy -Name "BlackholePolicy" -Action IGNORE -FQDN "EQ,*.treyresearch.com"
Bloccare le query da una subnet
È anche possibile bloccare le query provenienti da una subnet specifica. Lo script seguente crea una subnet per 172.0.33.0/24 e quindi crea un criterio per ignorare tutte le query provenienti da tale subnet:
Add-DnsServerClientSubnet -Name "MaliciousSubnet06" -IPv4Subnet 172.0.33.0/24
Add-DnsServerQueryResolutionPolicy -Name "BlackholePolicyMalicious06" -Action IGNORE -ClientSubnet "EQ,MaliciousSubnet06"
Consentire la ricorsione per i client interni
È possibile controllare la ricorsione usando un criterio di risoluzione delle query DNS. L'esempio seguente può essere usato per abilitare la ricorsione per i client interni, disabilitandolo per i client esterni in uno scenario split brain.
Set-DnsServerRecursionScope -Name . -EnableRecursion $False
Add-DnsServerRecursionScope -Name "InternalClients" -EnableRecursion $True
Add-DnsServerQueryResolutionPolicy -Name "SplitBrainPolicy" -Action ALLOW -ApplyOnRecursion -RecursionScope "InternalClients" -ServerInterfaceIP "EQ,10.0.0.34"
La prima riga nello script modifica l'ambito di ricorsione predefinito, semplicemente denominato "." (punto), per disabilitare la ricorsione. La seconda riga crea un ambito di ricorsione denominato InternalClients con ricorsione abilitata. La terza riga crea un criterio per applicare l'ambito di ricorsione appena creato a qualsiasi query in arrivo tramite un'interfaccia server con 10.0.0.34 come indirizzo IP.
Creare un criterio di trasferimento della zona a livello di server
È possibile controllare il trasferimento della zona in un formato più granulare usando i criteri di trasferimento di zona DNS. Lo script di esempio seguente può essere usato per consentire trasferimenti di zona per qualsiasi server in una determinata subnet:
Add-DnsServerClientSubnet -Name "AllowedSubnet" -IPv4Subnet 172.21.33.0/24
Add-DnsServerZoneTransferPolicy -Name "NorthAmericaPolicy" -Action IGNORE -ClientSubnet "ne,AllowedSubnet"
La prima riga nello script crea un oggetto subnet denominato AllowedSubnet con il blocco IP 172.21.33.0/24. La seconda riga crea un criterio di trasferimento della zona per consentire i trasferimenti di zona a qualsiasi server DNS nella subnet creata in precedenza.
Creare un criterio di trasferimento della zona a livello di zona
È anche possibile creare criteri di trasferimento della zona a livello di zona. L'esempio seguente ignora qualsiasi richiesta di trasferimento di zona per contoso.com proveniente da un'interfaccia server con un indirizzo IP 10.0.0.33:
Add-DnsServerZoneTransferPolicy -Name "InternalTransfers" -Action IGNORE -ServerInterfaceIP "eq,10.0.0.33" -PassThru -ZoneName "contoso.com"
Scenari del criterio DNS
Per informazioni su come usare i criteri DNS per scenari specifici, vedere gli argomenti seguenti in questa guida.
- Usare i criteri DNS per la gestione del traffico basata sulla posizione geografica con server primari
- Usare i criteri DNS per la gestione del traffico basata sulla posizione geografica con distribuzioni primarie e secondarie
- Usare i criteri DNS per risposte DNS intelligenti basate sull'ora del giorno
- Risposte DNS basate sull'ora del giorno con un server app Azure Cloud
- Usare i criteri DNS per la distribuzione DNS "split brain"
- Usare i criteri DNS per DNS "split brain" in Active Directory
- Usare i criteri DNS per l'applicazione di filtri alle query DNS
- Usare i criteri DNS per il bilanciamento del carico dell'applicazione
- Usare i criteri DNS per l'applicazione del bilanciamento del carico con la consapevolezza della posizione geografica
Uso dei criteri DNS nei controller di dominio di sola lettura
I criteri DNS sono compatibili con i controller di dominio di sola lettura. Si noti che per caricare i nuovi criteri DNS nei controller di dominio di sola lettura è necessario riavviare il servizio server DNS. Ciò non è necessario nei controller di dominio scrivibili.