Share via

Windows 2008 R2 DHCP Name Protection e Option 81

  • Article

Ciao a tutti!

A partire da Windows Server 2008 R2 è stata introdotta una nuova feature sul nostro DHCP server, chiamata DHCP name protection.

La feature è stata implementata in base alle RFC 4701 e 4703 della IETF. Lo scopo è molto semplice: mantenere accurata la corrispondenza tra indirizzi IP assegnati dinamicamente e FQDN registrati sul DNS – che vanno sempre mantenuti aggiornati.

Lo scenario tipico in cui questa corrispondenza viene minata è il seguente:

Client1 con hostname “workstation” ottiene indirizzo IP dal DHCP server (ad esempio 10.0.0.11)
Client2 ha lo stesso hostname “workstation” ma un diverso indirizzo IP (ad esempio 192.168.0.24)

Se Client2 registra il suo record A sul DNS, avremo un record per “workstation” con indirizzo IP 192.168.0.24, e nessuno nell’infrastruttura potrà quindi contattare Client1 perchè nessuno può ottenere il suo indirizzo IP 10.0.0.11. Tra l’altro, essendo Client2 l’owner del record A, non c’è possibilità per Client1 di sovrascrivere l’informazione sul DNS.

Questo problema è anche chiamato Name Squatting.

Diciamo subito, per rassicurare i più, che il problema non si pone in un ambiente dove abbiamo puramente client e server Windows: la natura stessa di Active Directory impedisce che ci siano più macchine con lo stesso nome nello stesso dominio, e gli update su una zona DNS integrata in Active Directory dovrebbero essere di default “secure only”.

Ma in un ambiente enterprise con device Unix, Linux, Mac OS e quant’altro allora il problema torna di attualità.
La soluzione è quindi semplicissima, basta abilitare DHCP name protection sul DHCP server.

Per farlo, semplicemente dalle proprietà DNS a livello di scope o a livello di server stesso, basta abilitare l’apposito flag come in figura:

image

 

 

Una considerazione molto importante:
Abilitando il name protection sul DHCP server, i settings che abbiamo impostato per i dynamic updates verranno sovrascritti (come vedete anche sull’interfaccia sono grey out) quindi non abbiamo più la possibilità di scegliere se sarà il client o il server ad effettuare l’update dei record A o PTR, ma il comportamento sarà definito univocamente.

Infatti, con name protection abilitato:
- se il client è un client Windows, il client stesso provvederà alla registrazione del suo record A, mentre il record PTR sarà registrato dal server. Se un qualsiasi altro client tenterà di registrarsi con lo stesso FQDN, gli verrà di conseguenza impedito.

 

- se il client NON è un client Windows, il DHCP server provvederà a registrare record A e PTR per conto del client. Inoltre il DHCP server registrerà sul DNS un record di tipo DHCID. Il Dynamic Host Configuration Identifier (DHCID) è un resource record che si registra come tutti gli altri sul DNS ed è utilizzato dal DHCP per identificare univocamente il matching tra record A e indirizzo IP assegnatogli.
Nel momento in cui un client tenterà di andarsi a registrare con lo stesso nome, il DHCP server controllerà se è autorizzato andandone a cercare il rispettivo record DHCID. In questo modo, solo il client originale avrà la possibilità di effettuare updates.

 

image

In figura: esempio di record DHCID registrato fra gli altri record sul DNS

 

Vale la pena ricordare che la tecnologia di name protection funziona con la logica del “first come, first serve” cioè il record verrà registrato e protetto per il primo client che arriverà a registrarsi il nome – e tutti i client successivi falliranno, indipendentemente da quale di questi sia il client che noi vorremmo veramente (non c’è possibilità di reservation). In questi casi particolari, è suggerito intervenire manualmente .

Apro due piccole parentesi per domande che potrebbero sorgere spontanee:

1) Come fa il Client, che ha semplicemente chiesto e ottenuto un indirizzo IP, a sapere se dovrà essere lui a registrarsi il record A o se lascerà fare al DHCP?

2) Come fa il DHCP server a capire se il client è un client Microsoft, e quindi decidere se lasciar registrare il record A oppure farlo lui stesso aggiungendo il DHCID?

La risposta è, come sempre, facilmente ritracciabile dall’analisi di una traccia di rete. Ogni client Windows, di default, include la Option 81 nella lista delle opzioni DHCP nel pacchetto di REQUEST.

 

- Dhcp: Request, MsgType = REQUEST, TransactionID = 0x76A3BF50
…
- DHCPEOptionsFullyQualifiedDomainName:
- FullyQualifiedDomainName: - Type 81
Code: Fully Qualified Domain Name, 81(0x51)
Length: 16 UINT8(s)
- Flag: 0 (0x0)
MBZ: (0000....) 0
N: (....0...) SHOULD NOT perform the A RR (FQDN to address) DNS updates
E: (.....0..) ASCII encoding of the Domain Name field (deprecated)
O: (......0.) the server has not overridden the client's preference for the 'S' bit
S: (.......0) SHOULD NOT perform the A RR (FQDN to address) DNS updates
RCODE1: 0 (0x0)
RCODE2: 0 (0x0)

 

Il punto chiave è il bit S: compilato con uno zero, il client sta chiaramente dicendo al DHCP server: “non devi fare la registrazione del record A”

Quando il server risponderà con il messaggio DHCP ACK finale, includerà la opzione 81 con la sua risposta. Il DHCP server può sovrascrivere, se necessario, quanto deciso dal client nella request. Il client quindi deciderà di effettuare o non effettuare l’update del record A in base a quanto riceve scritto nel bit S nel pacchetto ACK di ritorno.

Se il DHCP server è quindi impostato per essere responsabile dell’update dei record A, risponderà in questo modo:

- Dhcp: Reply, MsgType = ACK, TransactionID = 0x76A3BF50
…
- DHCPEOptionsFullyQualifiedDomainName:
- FullyQualifiedDomainName: - Type 81
Code: Fully Qualified Domain Name, 81(0x51)
Length: 3 UINT8(s)
- Flag: 3 (0x0)
MBZ: (0000....) 0
N: (....0...) SHOULD NOT perform the A RR (FQDN to address) DNS updates
E: (.....0..) ASCII encoding of the Domain Name field (deprecated)
O: (......1.) the server has overridden the client's preference for the 'S' bit
S: (.......1) SHOULD perform the A RR (FQDN to address) DNS updates
RCODE1: 255 (0xFF)
RCODE2: 0 (0x0)

Con il bit S posto a 1 infatti il server risponde al client: “non preoccuparti, ci penso io a fare l’update del record A”
Ripeto ancora, alla fine l’ultima parola che conta è quella del server.

Infine, come fa il server a capire che il client è Windows? Niente di più semplice: un client Windows aggiunge una opzione aggiuntiva nei pacchetti di DISCOVER e REQUEST, la Vendor Class Identifier Option 60, dicendo di essere un device Microsoft. (MSFT 5.0 indica sistemi operativi successivi a Windows 2000). Anche questa possiamo vederla da una trace di rete:

- Dhcp: Request, MsgType = REQUEST, TransactionID = 0x76A3BF50
…
- DHCPEOptionsVendorClassIdentifier:
- VendorClassIdentifier: MSFT 5.0 - Type 60
Code: Class-identifier, 60(0x3C)
Length: 8 UINT8(s)
VendorClassIdentifier: MSFT 5.0

Link di riferimento:

 

Grazie a tutti e alla prossima!

Stefano Gagliardi
Support Engineer
Microsoft Enterprise Platform Support