Ago27201927 Agosto 201927 Agosto 20190Commentidi Ermanno Goletto

DHCP e aggiornamento dinamico record DNS IV

Pubblicato in IT

Come illustrato nel post How DNS Scavenging and the DHCP Lease Duration Relate ci possono essere situazioni in cui per un certo periodo nel DNS lo stesso indirizzo IP risulta assegnato allo stesso client nel caso gli IP vengano rilasciata da un DHCP a causa dei valori dell’intervallo DNS Scaveging e della durata del DHCP Lease, a riguardo si veda lo scenario descritto nel precedente post:

The Scenario
Consider the following simplified scenario.

 

DHCP

  • A DHCP scope has its lease duration set to the default 8 days.
  • The DHCP scope is low on available IP addresses.
  • Client-A has NOT renewed its IP address lease in 8 days, so it has expired.
  • Client-B is requesting a new IP address.
  • The DHCP server assigns Client-B the address that was leased to Client-A.

So far so good. This is a very typical scenario and everything works as we would expect. Now let’s add DNS into this story.

 

DNS

  • An Active Directory integrated DNS zone is set to scavenge stale resource records.
  • The defaults are used; “No Refresh = 7 days” and “Refresh = 7 days”.
  • The server defaults are used as well; “Scavenging Period = 7 days”.
  • Client-A renewed its DNS record 8 days ago (the last time its DHCP lease was updated as well).
  • Client-A is the owner of its DNS record so it cannot be deleted by the DHCP server (by default).
  • Client-B registers its DNS record with the new IP address it received from the DHCP server.
  • This IP address is the same one that is registered to Client-A!
  • The DNS server will not be able to scavenge Client-A’s DNS record for another 6 days!

(NOTE: if you’re unsure what all of this “scavenging”, “refresh/no refresh” stuff is check out Josh Jones’ blog, it’s great!)

 

Uh-oh, not so good. This happens more than you’d think. Now Client-A and Client-B have the same IP address registered in DNS!

Per risolvere questo tipo di problemi è possibile agire in tre modi diversi come illustrato sempre nel post How DNS Scavenging and the DHCP Lease Duration Relate.

Metodo 1 – Aumento della durata del DHCP lease:

Increase the DHCP lease duration to match the “no-refresh + refresh” interval. In our example we would increase the DHCP lease to 14 days.

 

Pros:

  1. DHCP leases will remain until the DNS record is scavenged which means no other client will receive the address and register it in DNS
  2. It’s easy.

Cons:

  1. If the DHCP scope is already low on addresses, you’ll likely run out
  2. A small percentage of records may not be scavenged before the lease expires because of small time differences. Setting the scavenging interval to 1 day will ensure the defunct records are removed the next day.

Metodo 2 – Riduzione dell’intervallo di scavenging del DNS:

Decrease the “no-refresh + refresh” interval to match the DHCP lease. In our example we would decrease both “no-refresh” and “refresh” to 4 days.

 

Pros:

  1. The existing DNS record will be scavenged sooner affectively achieving the same results as in the first solution
  2. It’s easy.

Cons:

  1. Active Directory replication will increase (if these are AD integrated DNS zones). This is because the DNS records will be refreshed by the clients more often (every 4 days instead of every 7)
  2. A small percentage of records may not be scavenged before the lease expires because of small time differences. Setting the scavenging interval to 1 day will ensure the defunct records are removed the next day

Lo scavenging del DNS è stato anche oggetto del seguente post DNS Scavenging da cui riporto alcune informazioni che possono essere utili per meglio comprendere tale processo:

La presenza di records DNS obsoleti (stale) può causare vari problemi, quali l’occupazione inutile di spazio sul DB e la possibilità che un server utilizzi questi records per rispondere alle query DNS. Il risultato è che le performance del DNS possano risentirne ed inoltre lo startup del database DNS potrebbe essere lento.

 

Per risolvere questo tipo di problematica, il DNS Microsoft può effettuare scavenging (pulizia) dei records obsoleti (records registrati dinamicamente che non vengono aggiornati da un certo intervallo di tempo) cercandoli nel database ed eliminandoli automaticamente.

 

Il processo di aging (invecchiamento dei records) e scavenging (pulizia dei records) può essere controllato specificando:

  • Quali records devono essere eliminati se diventano obsoleti
  • Quali zone devono essere soggette al processo di scavenging
  • Quali servers possono effettuare scavenging della zona DNS

N.B.: Lo scavenging deve essere attivato su tutti questi elementi per poter funzionare!

 

E’ possibile inoltre configurare due intervalli: NO-REFRESH e REFRESH, che determinano l‘aging (invecchiamento) dei records DNS.

 

L’intervallo di NO-REFRESH (default 7gg) è il periodo di tempo durante il quale il timestamp di un record non può essere aggiornato. La funzione principale di questo intervallo è quella di ridurre il traffico di replica (ogni modifica di un record deve essere replicata). Durante l’intervallo di NO-REFRESH un’eventuale modifica all’indirizzo IP di un record verrà considerata come un ‘aggiornamento’ e sarà comunque applicata.

 

L’intervallo di REFRESH (default 7gg) è invece il periodo di tempo durante il quale il timestamp del records può essere aggiornato (ai clients verrà permesso di aggiornare il timestamp dei loro records). Se durante questo intervallo il record non verrà aggiornato dal client, esso sarà “eleggibile” per il processo di Scavenging.

 

In sostanza il processo di scavenging non inizia se prima non sono trascorsi gli intervalli di NO-REFRESH e REFRESH (default 7gg+7gg=14gg).

 

IMPORTANTE: Attivare lo scavenging prima sulla zona DNS ed attendere che siano trascorsi gli intervalli di NO-REFRESH e REFRESH prima di abilitarlo anche sul server. Questo per dar modo ai timestamps di aggiornarsi ed evitare la loro prematura e non voluta cancellazione!

 

Gli intervalli di NO-REFRESH, REFRESH e Scavenging vanno impostati in relazione alla durata del lease DHCP, che di default è impostato ad 8gg.

 

Esempio

  • Sulla zona l’intervallo di No-Refresh è impostato a 3gg e l’intervallo di Refresh è impostato a 3gg
  • Sul Server il periodo di Scavenging è impostato a 3gg
  • L’ultimo evento DNS 2501 o 2502 si è verificato alle 6:00 il 1/1/2008
  • Il record DNS ha un timestamp del 1/1/2008 alle 12:00

 

 

 

 

 

 

 

 

 

Dall’esempio si può notare che il record che è stato creato il 1 gennaio diventerà candidato allo scavenging a partire dalle 12:00 del 7 gennaio ma non verrà cancellato fino al prossimo ciclo di scavenging che inizierà alle 6:00 del 10 gennaio.

Per ulteriori approfondimenti sulle impostazioni di aging e scavenging del DNS si vedano anche i seguenti articoli della Knowledge Base DELL:

Metodo 3 – Configurare il servizio DHCP per gestire la registrazione degli indirizzi IP:

Allow the server DHCP to register the addresses on behalf of the clients.

Pros:

  1. The DHCP server will be able to remove the DNS record as soon as the lease expires
  2. If setup correctly no duplicate records should exist.

Cons:

  1. The setup is more involved.
  2. A service account will need to be setup to run the DHCP service, or all the DHCP servers will need to be joined to the DNSUpdateProxy group (less secure) adding complexity.

Se si opta per il metodo 3 è anche possibile valutare l’utilizzo della funzionalità Name Protection del DHCP al posto dell’utilizzo dell’opzione 81 come descritto nel post Windows 2008 R2 DHCP Name Protection e Option 81:

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.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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.

 

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)

 

Per ulteriori approfondimenti circa l’aggiornamento dinamico record DNS tramite DHCP si vedano anche i miei precedenti post: