Passa al contenuto principale

6. Name Server Implementation (Implementazione del server dei nomi)

Questo capitolo tratta le considerazioni di implementazione per i name server DNS.

6.1. Architecture (Architettura)​

La struttura ottimale per il name server dipenderà dal sistema operativo host e dal fatto che il name server sia integrato con le operazioni del resolver, sia supportando il servizio ricorsivo, sia condividendo il suo database con un resolver.

Questa sezione tratta le considerazioni di implementazione per un name server che condivide un database con un resolver, ma la maggior parte di queste preoccupazioni sono presenti in qualsiasi name server.

6.1.1. Control (Controllo)​

Un name server deve (MUST) impiegare più attività simultanee, che siano implementate come task separati nel sistema operativo dell'host o multiplexate all'interno di un singolo programma name server.

Requisiti:

  • UDP non-bloccante: È semplicemente inaccettabile che un name server blocchi il servizio delle richieste UDP mentre attende dati TCP per attività di aggiornamento o query

  • Elaborazione parallela: Un name server non dovrebbe (SHOULD NOT) tentare di fornire servizio ricorsivo senza elaborare tali richieste in parallelo, sebbene possa scegliere di:

    • Serializzare le richieste da un singolo client
    • Considerare le richieste identiche dallo stesso client come duplicati

  • Operazioni di zona non-bloccanti: Un name server non dovrebbe (SHOULD NOT) ritardare sostanzialmente le richieste mentre:

    • Ricarica una zona da file master
    • Incorpora una zona appena aggiornata nel suo database

6.1.2. Database​

Sebbene le implementazioni dei name server siano libere di utilizzare qualsiasi struttura dati interna che scelgono, la struttura suggerita consiste di tre parti principali:

Struttura del database suggerita​

1. Struttura dati del catalogo (Catalog Data Structure):

  • Elenca le zone disponibili per questo server
  • Contiene un "puntatore" alla struttura dati della zona
  • Scopo principale: trovare la zona antenata più vicina, se presente, per le query standard in arrivo

2. Strutture dati di zona (Zone Data Structures):

  • Strutture dati separate per ciascuna delle zone detenute dal name server
  • Contiene dati autoritativi per la zona

3. Struttura dati cache (Cache Data Structure):

  • Una struttura dati per i dati memorizzati nella cache
  • Può avere cache separati per diverse classi

Considerazioni sull'implementazione​

Struttura ad albero: Tutte queste strutture dati possono essere implementate in un formato di struttura ad albero identico, con diversi dati concatenati ai nodi in parti diverse:

  • Nel catalogo: i dati sono puntatori alle zone
  • Nelle strutture dati di zona e cache: i dati saranno RR

Requisiti di elaborazione delle query: Durante la progettazione del framework ad albero, il progettista dovrebbe riconoscere che:

  • L'elaborazione delle query dovrà attraversare l'albero utilizzando confronti di etichette insensibili alle maiuscole
  • Nei dati reali, pochi nodi hanno un fattore di ramificazione molto alto (100-1000 o più)
  • La stragrande maggioranza ha un fattore di ramificazione molto basso (0-1)

Soluzione di archiviazione insensibile alle maiuscole​

Un modo per risolvere il problema delle maiuscole è memorizzare le etichette per ogni nodo in due parti:

  1. Una rappresentazione standardizzata delle maiuscole dell'etichetta dove tutti i caratteri ASCII sono in un unico caso
  2. Una maschera di bit che indica quali caratteri sono effettivamente di un caso diverso

Ottimizzazione del fattore di ramificazione​

La diversità del fattore di ramificazione può essere gestita:

  • Utilizzando una semplice lista concatenata per un nodo fino a quando il fattore di ramificazione supera una certa soglia
  • Passando a una struttura hash dopo che la soglia è stata superata

Importante: Le strutture hash utilizzate per memorizzare le sezioni ad albero devono garantire che le funzioni e le procedure hash preservino le convenzioni di maiuscole del DNS.

Vantaggi delle strutture separate​

L'uso di strutture separate per le diverse parti del database è motivato da diversi fattori:

1. Stabilità del catalogo:

  • La struttura del catalogo può essere una struttura quasi statica
  • Deve cambiare solo quando l'amministratore di sistema modifica le zone supportate dal server
  • Può anche memorizzare parametri utilizzati per controllare le attività di aggiornamento

2. Sostituzione atomica della zona:

  • Le strutture dati individuali per le zone permettono di sostituire una zona semplicemente cambiando un puntatore nel catalogo
  • Le operazioni di aggiornamento della zona possono costruire una nuova struttura e, una volta completata, innestarla nel database tramite una semplice sostituzione del puntatore
  • Critico: Quando una zona viene aggiornata, le query non dovrebbero (SHOULD NOT) utilizzare contemporaneamente vecchi e nuovi dati

3. Priorità dei dati:

  • Con le procedure di ricerca appropriate, i dati autoritativi nelle zone "nasconderanno" sempre, e quindi avranno la priorità su, i dati memorizzati nella cache

4. Isolamento degli errori:

  • Gli errori nelle definizioni di zona che causano zone sovrapposte possono causare risposte errate alle query
  • La determinazione del problema è semplificata
  • Il contenuto di una zona "cattiva" non può corrompere un'altra

5. Gestione della cache:

  • Poiché la cache è aggiornata più frequentemente, è più vulnerabile alla corruzione durante i riavvii del sistema
  • Può anche riempirsi di dati RR scaduti
  • In entrambi i casi, può essere facilmente scartata senza disturbare i dati della zona

Recupero da crash​

Un aspetto importante della progettazione del database è la selezione di una struttura che permetta al name server di gestire i crash dell'host del name server.

Informazioni di stato che un name server dovrebbe (SHOULD) salvare attraverso i crash del sistema:

  • La struttura del catalogo (incluso lo stato di aggiornamento per ogni zona)
  • I dati della zona stessi

6.1.3. Time (Tempo)​

Sia i dati TTL per gli RR che i dati temporali per le attività di aggiornamento dipendono da timer a 32 bit in unità di secondi.

Rappresentazione del tempo​

Modello concettuale:

  • All'interno del database, i timer di aggiornamento e i TTL per i dati memorizzati nella cache concettualmente "contano alla rovescia"
  • I dati nella zona rimangono con TTL costanti

Strategia di implementazione consigliata:

Memorizzare il tempo in due modi: come incremento relativo e come tempo assoluto.

Un modo per farlo è utilizzare:

  • Numeri positivi a 32 bit per un tipo
  • Numeri negativi per l'altro

Utilizzo:

  • Gli RR nelle zone utilizzano tempi relativi
  • I timer di aggiornamento e i dati cache utilizzano tempi assoluti
  • I numeri assoluti vengono presi rispetto a un'origine nota e convertiti in valori relativi quando inseriti nella risposta a una query
  • Quando un TTL assoluto è negativo dopo la conversione in relativo, allora i dati sono scaduti e dovrebbero essere ignorati

6.2. Standard Query Processing (Elaborazione delle query standard)​

L'algoritmo principale per l'elaborazione delle query standard è presentato in RFC-1034.

Casi speciali e regole​

Elaborazione QCLASS=*:

  • Durante l'elaborazione di query con QCLASS=*, o qualche altra QCLASS che corrisponde a più classi
  • La risposta non dovrebbe (SHOULD NOT) mai essere autoritativa a meno che il server non possa garantire che la risposta copra tutte le classi

Gestione degli RR duplicati:

  • Durante la composizione di una risposta, gli RR che devono essere inseriti nella sezione aggiuntiva, ma duplicano RR nelle sezioni risposta o autorità, possono essere omessi dalla sezione aggiuntiva

Politica di troncamento:

  • Quando una risposta è così lunga da richiedere il troncamento
  • Il troncamento dovrebbe (SHOULD) iniziare alla fine della risposta e procedere in avanti nel datagramma
  • Quindi, se ci sono dati per la sezione autorità, la sezione risposta è garantita essere unica

Campo SOA MINIMUM:

  • Il valore MINIMUM nel SOA dovrebbe (SHOULD) essere utilizzato per impostare un limite inferiore sul TTL dei dati distribuiti da una zona
  • Questa funzione di limite inferiore dovrebbe (SHOULD) essere eseguita quando i dati vengono copiati in una risposta
  • Ciò permetterà ai protocolli di aggiornamento dinamico futuri di modificare il campo SOA MINIMUM senza semantica ambigua

6.3. Zone Refresh and Reload Processing (Elaborazione dell'aggiornamento e ricaricamento della zona)​

Gestione degli errori​

Nonostante i migliori sforzi di un server, potrebbe non essere in grado di:

  • Caricare i dati di zona da un file master a causa di errori di sintassi, ecc.
  • Aggiornare una zona entro il suo parametro di scadenza

In questo caso: Il name server dovrebbe (SHOULD) rispondere alle query come se non dovesse possedere la zona.

Coerenza del trasferimento di zona​

Se un master sta inviando una zona tramite AXFR, e viene creata una nuova versione durante il trasferimento:

  • Il master dovrebbe (SHOULD) continuare a inviare la vecchia versione se possibile
  • In ogni caso, non deve mai (MUST NOT) inviare parte di una versione e parte di un'altra
  • Se il completamento non è possibile, il master dovrebbe (SHOULD) reimpostare la connessione su cui sta avvenendo il trasferimento di zona

6.4. Inverse Queries (Query inverse) (Opzionale)​

Le query inverse sono una parte opzionale del DNS.

Requisiti di supporto​

  • I name server non sono tenuti (NOT REQUIRED) a supportare alcuna forma di query inverse
  • Se un name server riceve una query inversa che non supporta, restituisce una risposta di errore con l'errore "Non implementato" impostato nell'intestazione
  • Sebbene il supporto delle query inverse sia opzionale, tutti i name server devono (MUST) almeno essere in grado di restituire la risposta di errore

6.4.1. The Contents of Inverse Queries and Responses (Contenuto delle query e risposte inverse)​

Le query inverse invertono le mappature eseguite dalle operazioni di query standard:

  • Mentre una query standard mappa un nome di dominio a una risorsa
  • Una query inversa mappa una risorsa a un nome di dominio

Esempio:

  • Una query standard può associare un nome di dominio a un indirizzo host
  • La query inversa corrispondente associa l'indirizzo host a un nome di dominio

Formato​

Le query inverse assumono la forma di:

  • Un singolo RR nella sezione risposta del messaggio
  • Una sezione domanda vuota
  • Il nome del proprietario dell'RR della query e il suo TTL non sono significativi

Risposta​

La risposta porta domande nella sezione domanda che identificano tutti i nomi che possiedono l'RR della query CHE IL NAME SERVER CONOSCE.

Limitazioni importanti:

  • Poiché nessun name server conosce tutto lo spazio dei nomi di dominio, la risposta non può mai essere considerata completa
  • Pertanto, le query inverse sono principalmente utili per le attività di gestione del database e debugging
  • Le query inverse NON sono un metodo accettabile per mappare gli indirizzi host ai nomi host; utilizzare invece il dominio IN-ADDR.ARPA

Confronti insensibili alle maiuscole​

Ove possibile, i name server dovrebbero (SHOULD) fornire confronti insensibili alle maiuscole per le query inverse:

  • Una query inversa che chiede un RR MX di Venera.isi.edu dovrebbe (SHOULD) ottenere la stessa risposta di una query per VENERA.ISI.EDU
  • Una query inversa per l'RR HINFO IBM-PC UNIX dovrebbe (SHOULD) produrre lo stesso risultato di una query inversa per IBM-pc unix

Nota: Questo non può essere garantito perché i name server possono possedere RR che contengono stringhe di caratteri ma il name server non sa che i dati sono caratteri.

Elaborazione dei risultati​

Quando un name server elabora una query inversa, restituisce:

  1. Zero, uno o più nomi di dominio per la risorsa specificata come QNAME nella sezione domanda
  2. Un codice di errore che indica che il name server non supporta la mappatura inversa del tipo di risorsa specificato

Modifica della risposta​

Quando la risposta a una query inversa contiene uno o più QNAME:

  • Il nome del proprietario e il TTL dell'RR nella sezione risposta che definisce la query inversa vengono modificati per corrispondere esattamente a un RR trovato al primo QNAME

Restrizioni di caching​

Gli RR restituiti nelle query inverse non possono essere memorizzati nella cache (CANNOT) utilizzando lo stesso meccanismo utilizzato per le risposte alle query standard.

Motivo: Un nome potrebbe avere più RR dello stesso tipo, e ne apparirebbe solo uno. Ad esempio, una query inversa per un singolo indirizzo di un host multi-homed potrebbe creare l'impressione che esistesse un solo indirizzo.

6.4.2. Inverse Query and Response Example (Esempio di query e risposta inversa)​

La struttura complessiva di una query inversa per recuperare il nome di dominio che corrisponde all'indirizzo Internet 10.1.0.52:

Query:

+-----------------------------------------+
|  Header   | OPCODE=IQUERY, ID=997       |
+-----------------------------------------+
| Question  | <empty>                     |
+-----------------------------------------+
|  Answer   | <anyname> A IN 10.1.0.52    |
+-----------------------------------------+
| Authority | <empty>                     |
+-----------------------------------------+
|Additional | <empty>                     |
+-----------------------------------------+

Spiegazione:

  • Questa query richiede una domanda la cui risposta è l'indirizzo in stile Internet 10.1.0.52
  • Poiché il nome del proprietario non è noto, qualsiasi nome di dominio può essere utilizzato come segnaposto (e viene ignorato)
  • Un singolo ottetto di zero, che significa la radice, è solitamente utilizzato perché minimizza la lunghezza del messaggio
  • Il TTL dell'RR non è significativo

Risposta:

+-----------------------------------------+
|  Header   | OPCODE=RESPONSE, ID=997     |
+-----------------------------------------+
| Question  | QTYPE=A, QCLASS=IN,         |
|           | QNAME=VENERA.ISI.EDU        |
+-----------------------------------------+
|  Answer   | VENERA.ISI.EDU A IN         |
|           | 10.1.0.52                   |
+-----------------------------------------+
| Authority | <empty>                     |
+-----------------------------------------+
|Additional | <empty>                     |
+-----------------------------------------+

Nota: Il QTYPE in una risposta a una query inversa è lo stesso del campo TYPE nella sezione risposta della query inversa. Le risposte alle query inverse possono contenere più domande quando l'inverso non è unico. Se la sezione domanda nella risposta non è vuota, allora l'RR nella sezione risposta viene modificato per corrispondere a una copia esatta di un RR al primo QNAME.

6.4.3. Inverse Query Processing (Elaborazione delle query inverse)​

I name server che supportano le query inverse possono supportare queste operazioni attraverso ricerche esaustive dei loro database, ma ciò diventa impraticabile man mano che aumenta la dimensione del database.

Approccio alternativo: Invertire il database secondo la chiave di ricerca.

Raccomandazione per i grandi server​

Per i name server che supportano più zone e una grande quantità di dati, l'approccio consigliato è:

  • Inversioni separate per ogni zona
  • Quando una zona particolare viene modificata durante un aggiornamento, solo le sue inversioni devono essere rifatte

Nota: Il supporto per il trasferimento di questo tipo di inversione potrebbe essere incluso nelle versioni future del sistema di dominio, ma non è supportato in questa versione.

6.5. Completion Queries and Responses (Query e risposte di completamento)​

I servizi di completamento opzionali descritti in RFC-882 e RFC-883 sono stati eliminati.

Servizi riprogettati potrebbero diventare disponibili in futuro.

Successivo: 7. Resolver Implementation (Implementazione del resolver)

Ultimo aggiornamento il