4. NAME SERVER (NAME SERVERS)

4.1. Introduzione (Introduction)

I name server sono i repository di informazioni che costituiscono il database di dominio. Il database è diviso in sezioni chiamate zone, che sono distribuite tra i name server. Sebbene i name server possano avere diverse funzioni opzionali e fonti di dati, il compito essenziale di un name server è rispondere alle query utilizzando i dati nelle sue zone. Per progettazione, i name server possono rispondere alle query in modo semplice; la risposta può sempre essere generata utilizzando solo dati locali, e contiene la risposta alla domanda o un riferimento ad altri name server "più vicini" alle informazioni desiderate.

Una determinata zona sarà disponibile da diversi name server per assicurarne la disponibilità nonostante guasti dell'host o del collegamento di comunicazione. Per decreto amministrativo, richiediamo che ogni zona sia disponibile su almeno due server, e molte zone hanno più ridondanza di questa.

Un determinato name server supporterà tipicamente una o più zone, ma ciò gli fornisce informazioni autorevoli solo su una piccola sezione dell'albero di dominio. Può anche avere alcuni dati non autorevoli memorizzati nella cache su altre parti dell'albero. Il name server contrassegna le sue risposte alle query in modo che il richiedente possa dire se la risposta proviene da dati autorevoli o meno.

4.2. Come il database è diviso in zone (How the database is divided into zones)

Il database di dominio è partizionato in due modi: per classe, e tramite "tagli" effettuati nello spazio dei nomi tra i nodi.

Partizionamento per classe (Class partitioning)

La partizione per classe è semplice. Il database per qualsiasi classe è organizzato, delegato e mantenuto separatamente da tutte le altre classi. Poiché, per convenzione, gli spazi dei nomi sono gli stessi per tutte le classi, le classi separate possono essere pensate come un array di alberi di namespace paralleli. Si noti che i dati collegati ai nodi saranno diversi per queste diverse classi parallele. I motivi più comuni per creare una nuova classe sono la necessità di un nuovo formato di dati per i tipi esistenti o il desiderio di una versione gestita separatamente dello spazio dei nomi esistente.

Tagli di zona (Zone cuts)

All'interno di una classe, "tagli" nello spazio dei nomi possono essere effettuati tra due nodi adiacenti qualsiasi. Dopo che tutti i tagli sono stati effettuati, ogni gruppo di spazio dei nomi connesso è una zona separata. Si dice che la zona sia autorevole per tutti i nomi nella regione connessa. Si noti che i "tagli" nello spazio dei nomi possono essere in luoghi diversi per classi diverse, i name server possono essere diversi, ecc.

Queste regole significano che ogni zona ha almeno un nodo, e quindi un nome di dominio, per il quale è autorevole, e tutti i nodi in una particolare zona sono connessi. Data la struttura ad albero, ogni zona ha un nodo più alto che è più vicino alla radice di qualsiasi altro nodo nella zona. Il nome di questo nodo è spesso utilizzato per identificare la zona.

Sarebbe possibile, anche se non particolarmente utile, partizionare lo spazio dei nomi in modo che ogni nome di dominio fosse in una zona separata o che tutti i nodi fossero in una singola zona. Invece, il database è partizionato nei punti in cui una particolare organizzazione vuole prendere il controllo di un sottoalbero. Una volta che un'organizzazione controlla la propria zona, può modificare unilateralmente i dati nella zona, far crescere nuove sezioni di albero connesse alla zona, eliminare nodi esistenti o delegare nuove sottozone sotto la sua zona.

Se l'organizzazione ha una sottostruttura, potrebbe voler effettuare ulteriori partizioni interne per ottenere delegazioni nidificate del controllo dello spazio dei nomi. In alcuni casi, tali divisioni sono effettuate puramente per rendere più comoda la manutenzione del database.

4.2.1. Considerazioni tecniche (Technical considerations)

I dati che descrivono una zona hanno quattro parti principali:

• Dati autorevoli (Authoritative data) per tutti i nodi all'interno della zona.
• Dati che definiscono il nodo superiore (Data that defines the top node) della zona (possono essere considerati parte dei dati autorevoli).
• Dati che descrivono le sottozone delegate (Data that describes delegated subzones), cioè tagli attorno al fondo della zona.
• Dati che consentono l'accesso ai name server per le sottozone (Data that allows access to name servers for subzones) (a volte chiamati dati "glue").

Tutti questi dati sono espressi sotto forma di RR, quindi una zona può essere completamente descritta in termini di insieme di RR. Intere zone possono essere trasferite tra name server trasferendo gli RR, trasportati in una serie di messaggi o tramite FTP di un file master che è una rappresentazione testuale.

Dati autorevoli (Authoritative data)

I dati autorevoli per una zona sono semplicemente tutti gli RR collegati a tutti i nodi dal nodo superiore della zona fino ai nodi foglia o ai nodi sopra i tagli attorno al bordo inferiore della zona.

Sebbene logicamente parte dei dati autorevoli, gli RR che descrivono il nodo superiore della zona sono particolarmente importanti per la gestione della zona. Questi RR sono di due tipi: RR di name server che elencano, uno per RR, tutti i server per la zona, e un singolo RR SOA che descrive i parametri di gestione della zona.

Dati di delega (Delegation data)

Gli RR che descrivono i tagli attorno al fondo della zona sono RR NS che nominano i server per le sottozone. Poiché i tagli sono tra i nodi, questi RR NON fanno parte dei dati autorevoli della zona, e dovrebbero essere esattamente gli stessi degli RR corrispondenti nel nodo superiore della sottozona. Poiché i name server sono sempre associati ai confini di zona, gli RR NS si trovano solo nei nodi che sono il nodo superiore di qualche zona. Nei dati che compongono una zona, gli RR NS si trovano nel nodo superiore della zona (e sono autorevoli) e nei tagli attorno al fondo della zona (dove non sono autorevoli), ma mai in mezzo.

Dati glue (Glue data)

Uno degli obiettivi della struttura di zona è che qualsiasi zona abbia tutti i dati necessari per stabilire comunicazioni con i name server per qualsiasi sottozona. Cioè, le zone parent hanno tutte le informazioni necessarie per accedere ai server per le loro zone child. Gli RR NS che nominano i server per le sottozone spesso non sono sufficienti per questo compito poiché nominano i server, ma non forniscono i loro indirizzi. In particolare, se il nome del name server è esso stesso nella sottozona, potremmo trovarci di fronte alla situazione in cui gli RR NS ci dicono che per conoscere l'indirizzo di un name server, dovremmo contattare il server utilizzando l'indirizzo che desideriamo conoscere. Per risolvere questo problema, una zona contiene RR "glue" che non fanno parte dei dati autorevoli, e sono RR di indirizzo per i server. Questi RR sono necessari solo se il nome del name server è "sotto" il taglio, e sono utilizzati solo come parte di una risposta di riferimento.

4.2.2. Considerazioni amministrative (Administrative considerations)

Quando un'organizzazione vuole controllare il proprio dominio, il primo passo è identificare la zona parent appropriata e ottenere l'accordo dei proprietari della zona parent per la delega del controllo. Sebbene non ci siano particolari vincoli tecnici riguardo a dove nell'albero questo possa essere fatto, ci sono alcuni raggruppamenti amministrativi discussi in [RFC-1032] che trattano dell'organizzazione di livello superiore, e le zone di livello intermedio sono libere di creare le proprie regole. Ad esempio, un'università potrebbe scegliere di utilizzare una singola zona, mentre un'altra potrebbe scegliere di organizzarsi tramite sottozone dedicate a singoli dipartimenti o scuole. [RFC-1033] cataloga il software DNS disponibile e discute le procedure amministrative.

Una volta selezionato il nome appropriato per la nuova sottozona, i nuovi proprietari dovrebbero essere tenuti a dimostrare il supporto ridondante del name server. Si noti che non c'è requisito che i server per una zona risiedano in un host che ha un nome in quel dominio. In molti casi, una zona sarà più accessibile a Internet in generale se i suoi server sono ampiamente distribuiti piuttosto che essere nelle strutture fisiche controllate dalla stessa organizzazione che gestisce la zona. Ad esempio, nel DNS attuale, uno dei name server per il Regno Unito, o dominio UK, si trova negli Stati Uniti. Ciò consente agli host statunitensi di ottenere dati britannici senza utilizzare la limitata larghezza di banda transatlantica.

Come ultimo passo di installazione, gli RR NS di delega e gli RR glue necessari per rendere efficace la delega dovrebbero essere aggiunti alla zona parent. Gli amministratori di entrambe le zone dovrebbero assicurarsi che gli RR NS e glue che segnano entrambi i lati del taglio siano coerenti e rimangano tali.

4.3. Strutture interne del name server (Name server internals)

4.3.1. Query e risposte (Queries and responses)

L'attività principale dei name server è rispondere alle query standard. Sia la query che la sua risposta sono trasportate in un formato di messaggio standard descritto in [RFC-1035]. La query contiene un QTYPE, QCLASS e QNAME, che descrivono i tipi e le classi di informazioni desiderate e il nome di interesse.

Il modo in cui il name server risponde alla query dipende dal fatto che stia operando in modalità ricorsiva o meno:

• Modalità non ricorsiva (Non-recursive mode): La modalità più semplice per il server è non ricorsiva, poiché può rispondere alle query utilizzando solo informazioni locali: la risposta contiene un errore, la risposta, o un riferimento a qualche altro server "più vicino" alla risposta. Tutti i name server devono implementare query non ricorsive.

• Modalità ricorsiva (Recursive mode): La modalità più semplice per il client è ricorsiva, poiché in questa modalità il name server agisce nel ruolo di un resolver e restituisce un errore o la risposta, ma mai riferimenti. Questo servizio è opzionale in un name server, e il name server può anche scegliere di limitare i client che possono utilizzare la modalità ricorsiva.

Quando utilizzare il servizio ricorsivo (When to use recursive service)

Il servizio ricorsivo è utile in diverse situazioni:

• Un richiedente relativamente semplice che manca della capacità di utilizzare qualcosa di diverso da una risposta diretta alla domanda.
• Una richiesta che deve attraversare protocolli o altri confini e può essere inviata a un server che può agire da intermediario.
• Una rete in cui vogliamo concentrare la cache piuttosto che avere una cache separata per ogni client.

Il servizio non ricorsivo è appropriato se il richiedente è in grado di seguire i riferimenti ed è interessato a informazioni che aiuteranno le richieste future.

Negoziazione della ricorsione (Recursion negotiation)

L'uso della modalità ricorsiva è limitato ai casi in cui sia il client che il name server accettano il suo utilizzo. L'accordo è negoziato attraverso l'uso di due bit nei messaggi di query e risposta:

• Il bit ricorsione disponibile (RA) (The recursion available bit) è impostato o cancellato da un name server in tutte le risposte. Il bit è vero se il name server è disposto a fornire servizio ricorsivo per il client, indipendentemente dal fatto che il client abbia richiesto servizio ricorsivo. Cioè, RA segnala la disponibilità piuttosto che l'uso.

• Le query contengono un bit ricorsione desiderata (RD) (Queries contain a recursion desired bit). Questo bit specifica se il richiedente desidera servizio ricorsivo per questa query. I client possono richiedere servizio ricorsivo da qualsiasi name server, anche se dovrebbero fare affidamento sulla sua ricezione solo da server che hanno precedentemente inviato un RA, o da server che hanno accettato di fornire il servizio tramite accordo privato o altri mezzi al di fuori del protocollo DNS.

La modalità ricorsiva si verifica quando una query con RD impostato arriva a un server che è disposto a fornire servizio ricorsivo; il client può verificare che la modalità ricorsiva sia stata utilizzata controllando che sia RA che RD siano impostati nella risposta. Si noti che il name server non dovrebbe mai eseguire servizio ricorsivo a meno che non sia richiesto tramite RD, poiché ciò interferisce con la risoluzione dei problemi dei name server e dei loro database.

Tipi di risposta (Response types)

Se il servizio ricorsivo è richiesto e disponibile, la risposta ricorsiva a una query sarà una delle seguenti:

• La risposta alla query, possibilmente preceduta da uno o più RR CNAME che specificano alias incontrati sulla strada verso una risposta.
• Un errore di nome che indica che il nome non esiste. Questo può includere RR CNAME che indicano che il nome della query originale era un alias per un nome che non esiste.
• Un'indicazione di errore temporaneo.

Se il servizio ricorsivo non è richiesto o non è disponibile, la risposta non ricorsiva sarà una delle seguenti:

• Un errore di nome autorevole che indica che il nome non esiste.
• Un'indicazione di errore temporaneo.
• Una combinazione di:
  • RR che rispondono alla domanda, insieme a un'indicazione se i dati provengono da una zona o sono memorizzati nella cache.
  • Un riferimento ai name server che hanno zone che sono antenati più vicini al nome rispetto al server che invia la risposta.
  • RR che il name server pensa saranno utili al richiedente.

4.3.2. Algoritmo (Algorithm)

L'algoritmo effettivo utilizzato dal name server dipenderà dal sistema operativo locale e dalle strutture dati utilizzate per memorizzare gli RR. Il seguente algoritmo presume che gli RR siano organizzati in diverse strutture ad albero, una per ogni zona, e un'altra per la cache:

1. Impostare o cancellare il valore di ricorsione disponibile (Set or clear the value of recursion available) nella risposta a seconda che il name server sia disposto a fornire servizio ricorsivo. Se il servizio ricorsivo è disponibile e richiesto tramite il bit RD nella query, andare al passo 5, altrimenti passo 2.

2. Cercare le zone disponibili (Search the available zones) per la zona che è l'antenato più vicino a QNAME. Se tale zona viene trovata, andare al passo 3, altrimenti passo 4.

3. Iniziare la corrispondenza verso il basso, etichetta per etichetta, nella zona (Start matching down, label by label, in the zone). Il processo di corrispondenza può terminare in diversi modi:

   a. Se l'intero QNAME corrisponde (If the whole of QNAME is matched), abbiamo trovato il nodo.

   Se i dati al nodo sono un CNAME, e QTYPE non corrisponde a CNAME, copiare l'RR CNAME nella sezione risposta della risposta, cambiare QNAME nel nome canonico nell'RR CNAME, e tornare al passo 1.

   Altrimenti, copiare tutti gli RR che corrispondono a QTYPE nella sezione risposta e andare al passo 6.

   b. Se una corrispondenza ci porterebbe fuori dai dati autorevoli (If a match would take us out of the authoritative data), abbiamo un riferimento. Questo accade quando incontriamo un nodo con RR NS che segnano tagli lungo il fondo di una zona.

   Copiare gli RR NS per la sottozona nella sezione autorità della risposta. Mettere qualsiasi indirizzo disponibile nella sezione aggiuntiva, utilizzando RR glue se gli indirizzi non sono disponibili dai dati autorevoli o dalla cache. Andare al passo 4.

   c. Se a un'etichetta, una corrispondenza è impossibile (If at some label, a match is impossible) (cioè, l'etichetta corrispondente non esiste), verificare se l'etichetta "*" esiste.

   Se l'etichetta "*" non esiste, verificare se il nome che stiamo cercando è il QNAME originale nella query o un nome che abbiamo seguito a causa di un CNAME. Se il nome è originale, impostare un errore di nome autorevole nella risposta e uscire. Altrimenti uscire semplicemente.

   Se l'etichetta "" esiste, confrontare gli RR a quel nodo con QTYPE. Se qualcuno corrisponde, copiarli nella sezione risposta, ma impostare il proprietario dell'RR come QNAME, e non il nodo con l'etichetta "". Andare al passo 6.

4. Iniziare la corrispondenza nella cache (Start matching down in the cache). Se QNAME viene trovato nella cache, copiare tutti gli RR ad esso collegati che corrispondono a QTYPE nella sezione risposta. Se non c'era delega dai dati autorevoli, cercare la migliore dalla cache, e metterla nella sezione autorità. Andare al passo 6.

5. Utilizzare il resolver locale (Using the local resolver) o una copia del suo algoritmo (vedere la sezione resolver di questo memo) per rispondere alla query. Memorizzare i risultati, inclusi eventuali CNAME intermedi, nella sezione risposta della risposta.

6. Utilizzando solo dati locali (Using local data only), tentare di aggiungere altri RR che potrebbero essere utili alla sezione aggiuntiva della query. Uscire.

4.3.3. Caratteri jolly (Wildcards)

Nell'algoritmo precedente, è stato dato un trattamento speciale agli RR con nomi di proprietario che iniziano con l'etichetta "*". Tali RR sono chiamati caratteri jolly. Gli RR carattere jolly possono essere pensati come istruzioni per sintetizzare RR. Quando vengono soddisfatte le condizioni appropriate, il name server crea RR con un nome di proprietario uguale al nome della query e contenuti presi dagli RR carattere jolly.

Questa funzionalità è più spesso utilizzata per creare una zona che verrà utilizzata per inoltrare la posta da Internet ad un altro sistema di posta. L'idea generale è che qualsiasi nome in quella zona che viene presentato al server in una query sarà assunto esistere, con certe proprietà, a meno che non esistano prove esplicite del contrario. Si noti che l'uso del termine zona qui, invece di dominio, è intenzionale; tali default non si propagano attraverso i confini di zona, anche se una sottozona può scegliere di ottenere quell'aspetto impostando default simili.

Sintassi e semantica dei caratteri jolly (Wildcard syntax and semantics)

Il contenuto degli RR carattere jolly segue le regole e i formati usuali per gli RR. I caratteri jolly nella zona hanno un nome di proprietario che controlla i nomi di query con cui corrisponderanno. Il nome di proprietario degli RR carattere jolly è della forma *.<anydomain>, dove <anydomain> è qualsiasi nome di dominio. <anydomain> non dovrebbe contenere altre etichette , e dovrebbe essere nei dati autorevoli della zona. I caratteri jolly si applicano potenzialmente ai discendenti di <anydomain>, ma non a <anydomain> stesso. Un altro modo di vedere ciò è che l'etichetta "" corrisponde sempre ad almeno un'etichetta intera e talvolta di più, ma sempre etichette intere.

Quando i caratteri jolly non si applicano (When wildcards do not apply)

Gli RR carattere jolly non si applicano:

• Quando la query è in un'altra zona (When the query is in another zone). Cioè, la delega annulla i default dei caratteri jolly.

• Quando il nome della query o un nome tra il dominio carattere jolly e il nome della query è noto per esistere (When the query name or a name between the wildcard domain and the query name is known to exist). Ad esempio, se un RR carattere jolly ha un nome di proprietario di "*.X", e la zona contiene anche RR collegati a B.X, i caratteri jolly si applicherebbero alle query per il nome Z.X (presumendo che non ci siano informazioni esplicite per Z.X), ma non a B.X, A.B.X o X.

Un'etichetta * che appare in un nome di query non ha effetto speciale, ma può essere utilizzata per testare i caratteri jolly in una zona autorevole; tale query è l'unico modo per ottenere una risposta contenente RR con un nome di proprietario con * al suo interno. Il risultato di tale query non dovrebbe essere memorizzato nella cache.

Si noti che il contenuto degli RR carattere jolly non viene modificato quando viene utilizzato per sintetizzare RR.

Esempio di carattere jolly (Wildcard example)

Per illustrare l'uso degli RR carattere jolly, supponiamo che una grande azienda con una grande rete non IP/TCP volesse creare un gateway di posta. Se l'azienda si chiamava X.COM, e la macchina gateway capace di IP/TCP si chiamava A.X.COM, i seguenti RR potrebbero essere inseriti nella zona COM:

X.COM           MX      10      A.X.COM

*.X.COM         MX      10      A.X.COM

A.X.COM         A       1.2.3.4
A.X.COM         MX      10      A.X.COM

*.A.X.COM       MX      10      A.X.COM

Ciò farebbe sì che qualsiasi query MX per qualsiasi nome di dominio che termina con X.COM restituisca un RR MX che punta a A.X.COM. Sono necessari due RR carattere jolly poiché l'effetto del carattere jolly a *.X.COM è inibito nel sottoalbero A.X.COM dai dati espliciti per A.X.COM. Si noti anche che i dati MX espliciti a X.COM e A.X.COM sono richiesti, e che nessuno degli RR sopra corrisponderebbe a un nome di query di XX.COM.

4.3.4. Memorizzazione nella cache delle risposte negative (Negative response caching) (Opzionale)

Il DNS fornisce un servizio opzionale che consente ai name server di distribuire, e ai resolver di memorizzare nella cache, risultati negativi con TTL. Ad esempio, un name server può distribuire un TTL insieme a un'indicazione di errore di nome, e un resolver che riceve tali informazioni è autorizzato a presumere che il nome non esista durante il periodo TTL senza consultare dati autorevoli. Allo stesso modo, un resolver può effettuare una query con un QTYPE che corrisponde a più tipi, e memorizzare nella cache il fatto che alcuni dei tipi non sono presenti.

Questa funzionalità può essere particolarmente importante in un sistema che implementa abbreviazioni di denominazione che utilizzano elenchi di ricerca perché un'abbreviazione popolare, che richiede un suffisso verso la fine dell'elenco di ricerca, genererà più errori di nome ogni volta che viene utilizzata.

Metodo di implementazione (Implementation method)

Il metodo è che un name server può aggiungere un RR SOA alla sezione aggiuntiva di una risposta quando quella risposta è autorevole. Il SOA deve essere quello della zona che era la fonte dei dati autorevoli nella sezione risposta, o errore di nome se applicabile. Il campo MINIMUM del SOA controlla la durata durante la quale il risultato negativo può essere memorizzato nella cache.

Si noti che in alcune circostanze, la sezione risposta può contenere più nomi di proprietario. In questo caso, il meccanismo SOA dovrebbe essere utilizzato solo per i dati che corrispondono a QNAME, che sono gli unici dati autorevoli in questa sezione.

I name server e i resolver non dovrebbero mai tentare di aggiungere SOA alla sezione aggiuntiva di una risposta non autorevole, o tentare di dedurre risultati che non sono direttamente dichiarati in una risposta autorevole. Ci sono diverse ragioni per questo, tra cui: le informazioni memorizzate nella cache di solito non sono sufficienti per abbinare gli RR e i loro nomi di zona, gli RR SOA possono essere memorizzati nella cache a causa di query SOA dirette, e i name server non sono tenuti a emettere i SOA nella sezione autorità.

Questa funzionalità è opzionale, sebbene si preveda che una versione perfezionata diventi parte del protocollo standard in futuro. I name server non sono tenuti ad aggiungere gli RR SOA in tutte le risposte autorevoli, né i resolver sono tenuti a memorizzare nella cache i risultati negativi. Entrambi sono raccomandati. Tutti i resolver e i name server ricorsivi sono tenuti almeno ad essere in grado di ignorare l'RR SOA quando è presente in una risposta.

Sono stati proposti anche alcuni esperimenti che utilizzeranno questa funzionalità. L'idea è che se i dati memorizzati nella cache sono noti provenire da una particolare zona, e se viene ottenuta una copia autorevole del SOA della zona, e se il SERIAL della zona non è cambiato da quando i dati sono stati memorizzati nella cache, allora il TTL dei dati memorizzati nella cache può essere reimpostato al valore MINIMUM della zona se è più piccolo. Questo utilizzo è menzionato solo a scopo di pianificazione, e non è ancora raccomandato.

4.3.5. Manutenzione e trasferimenti di zona (Zone maintenance and transfers)

Parte del lavoro di un amministratore di zona è mantenere le zone su tutti i name server che sono autorevoli per la zona. Quando vengono apportate le inevitabili modifiche, devono essere distribuite a tutti i name server. Sebbene questa distribuzione possa essere realizzata utilizzando FTP o qualche altra procedura ad hoc, il metodo preferito è la parte di trasferimento di zona del protocollo DNS.

Modello di trasferimento di zona (Zone transfer model)

Il modello generale del trasferimento o aggiornamento automatico di zona è che uno dei name server sia il master o primario per la zona. Le modifiche sono coordinate al primario, tipicamente modificando un file master per la zona. Dopo la modifica, l'amministratore segnala al server master di caricare la nuova zona. Gli altri server non master o secondari per la zona controllano periodicamente le modifiche (a un intervallo selezionabile) e ottengono nuove copie di zona quando sono state apportate modifiche.

Rilevamento delle modifiche tramite SERIAL (Change detection via SERIAL)

Per rilevare le modifiche, i secondari controllano semplicemente il campo SERIAL del SOA per la zona. Oltre a qualsiasi altra modifica apportata, il campo SERIAL nel SOA della zona viene sempre avanzato ogni volta che viene apportata una modifica alla zona. L'avanzamento può essere un semplice incremento, o potrebbe essere basato sulla data e ora di scrittura del file master, ecc. Lo scopo è rendere possibile determinare quale di due copie di una zona è più recente confrontando i numeri di serie. Gli avanzamenti e i confronti dei numeri di serie utilizzano l'aritmetica dello spazio di sequenza, quindi c'è un limite teorico sulla velocità con cui una zona può essere aggiornata, fondamentalmente che le vecchie copie devono estinguersi prima che il numero di serie copra metà del suo intervallo a 32 bit. In pratica, l'unica preoccupazione è che l'operazione di confronto gestisca correttamente i confronti intorno al confine tra i numeri a 32 bit più positivi e più negativi.

Parametri SOA per il trasferimento di zona (SOA parameters for zone transfer)

Il polling periodico dei server secondari è controllato da parametri nell'RR SOA per la zona, che impostano gli intervalli di polling minimi accettabili. I parametri sono chiamati REFRESH, RETRY ed EXPIRE. Ogni volta che una nuova zona viene caricata in un secondario, il secondario attende REFRESH secondi prima di controllare con il primario per un nuovo serial. Se questo controllo non può essere completato, nuovi controlli vengono avviati ogni RETRY secondi. Il controllo è una semplice query al primario per l'RR SOA della zona. Se il campo serial nella copia di zona del secondario è uguale al serial restituito dal primario, allora non sono avvenute modifiche, e l'attesa dell'intervallo REFRESH viene riavviata. Se il secondario trova impossibile eseguire un controllo serial per l'intervallo EXPIRE, deve presumere che la sua copia della zona sia obsoleta e scartarla.

Trasferimento di zona AXFR (AXFR zone transfer)

Quando il polling mostra che la zona è cambiata, allora il server secondario deve richiedere un trasferimento di zona tramite una richiesta AXFR per la zona. L'AXFR può causare un errore, come rifiutato, ma normalmente viene risposto da una sequenza di messaggi di risposta. I primi e ultimi messaggi devono contenere i dati per il nodo autorevole superiore della zona. I messaggi intermedi trasportano tutti gli altri RR dalla zona, inclusi sia RR autorevoli che non autorevoli. Il flusso di messaggi consente al secondario di costruire una copia della zona. Poiché l'accuratezza è essenziale, TCP o qualche altro protocollo affidabile deve essere utilizzato per le richieste AXFR.

Ogni server secondario è tenuto a eseguire le seguenti operazioni contro il master, ma può anche opzionalmente eseguire queste operazioni contro altri server secondari. Questa strategia può migliorare il processo di trasferimento quando il primario non è disponibile a causa di tempi di inattività dell'host o problemi di rete, o quando un server secondario ha un migliore accesso di rete a un secondario "intermedio" rispetto al primario.

---