2. Introduction (Introduzione)
2. Introduction (Introduzione)
2.1. Overview (Panoramica)
L'obiettivo dei nomi di dominio (domain names) è fornire un meccanismo per la denominazione delle risorse in modo tale che i nomi siano utilizzabili su host (hosts), reti (networks), famiglie di protocolli (protocol families), internet e organizzazioni amministrative (administrative organizations) diversi.
Dal punto di vista dell'utente, i nomi di dominio sono utili come argomenti per un agente locale (local agent), chiamato resolver, che recupera le informazioni associate al nome di dominio. Pertanto, un utente potrebbe richiedere l'indirizzo host o le informazioni di posta associate a un particolare nome di dominio. Per consentire all'utente di richiedere un particolare tipo di informazioni, un tipo di query (query type) appropriato viene passato al resolver insieme al nome di dominio. Per l'utente, l'albero di dominio (domain tree) è un singolo spazio informativo (information space); il resolver è responsabile di nascondere all'utente la distribuzione dei dati tra i name server (name servers).
Dal punto di vista del resolver, il database che costituisce lo spazio di dominio (domain space) è distribuito tra vari name server. Diverse parti dello spazio di dominio sono memorizzate in diversi name server, sebbene un particolare elemento di dati verrà memorizzato in modo ridondante (redundantly) in due o più name server. Il resolver inizia con la conoscenza di almeno un name server. Quando il resolver elabora una query dell'utente, chiede a un name server noto le informazioni; in cambio, il resolver riceve le informazioni desiderate o un riferimento (referral) a un altro name server. Utilizzando questi riferimenti, i resolver apprendono le identità e i contenuti di altri name server. I resolver sono responsabili di gestire la distribuzione dello spazio di dominio e di gestire gli effetti del guasto del name server consultando database ridondanti in altri server.
I name server gestiscono due tipi di dati. Il primo tipo di dati è contenuto in insiemi chiamati zone (zones); ogni zona è il database completo per un particolare sottoalbero "potato" (pruned) dello spazio di dominio. Questi dati sono chiamati autoritativi (authoritative). Un name server controlla periodicamente per assicurarsi che le sue zone siano aggiornate e, in caso contrario, ottiene una nuova copia delle zone aggiornate da file master (master files) memorizzati localmente o in un altro name server. Il secondo tipo di dati è costituito da dati memorizzati nella cache (cached data) che sono stati acquisiti da un resolver locale. Questi dati possono essere incompleti, ma migliorano le prestazioni del processo di recupero quando si accede ripetutamente a dati non locali. I dati memorizzati nella cache vengono infine eliminati da un meccanismo di timeout (timeout mechanism).
Questa struttura funzionale isola i problemi di interfaccia utente (user interface), recupero da errore (failure recovery) e distribuzione nei resolver e isola i problemi di aggiornamento e refresh del database nei name server.
2.2. Common configurations (Configurazioni comuni)
Un host può partecipare al sistema dei nomi di dominio in diversi modi, a seconda che l'host esegua programmi che recuperano informazioni dal sistema di dominio, name server che rispondono alle query da altri host, o varie combinazioni di entrambe le funzioni. La configurazione più semplice, e forse più tipica, è mostrata di seguito:
Local Host | Foreign
|
+---------+ +----------+ | +--------+
| | user queries | |queries | | |
| User |-------------->| |---------|->|Foreign |
| Program | | Resolver | | | Name |
| |<--------------| |<--------|--| Server |
| | user responses| |responses| | |
+---------+ +----------+ | +--------+
| A |
cache additions | | references |
V | |
+----------+ |
| cache | |
+----------+ |
I programmi utente interagiscono con lo spazio dei nomi di dominio tramite resolver; il formato delle query utente e delle risposte utente è specifico per l'host e il suo sistema operativo. Le query utente saranno tipicamente chiamate di sistema (operating system calls), e il resolver e la sua cache faranno parte del sistema operativo dell'host. Gli host meno capaci possono scegliere di implementare il resolver come una subroutine (subroutine) da collegare con ogni programma che necessita dei suoi servizi. I resolver rispondono alle query utente con informazioni che acquisiscono tramite query a name server esterni e alla cache locale.
Si noti che il resolver potrebbe dover effettuare diverse query a diversi name server esterni per rispondere a una particolare query utente, e quindi la risoluzione di una query utente può comportare diversi accessi alla rete e una quantità arbitraria di tempo. Le query ai name server esterni e le corrispondenti risposte hanno un formato standard descritto in questo memo, e possono essere datagrammi (datagrams).
A seconda delle sue capacità, un name server potrebbe essere un programma autonomo su una macchina dedicata o un processo o processi su un host condiviso di grandi dimensioni. Una configurazione semplice potrebbe essere:
Local Host | Foreign
|
+---------+ |
/ /| |
+---------+ | +----------+ | +--------+
| | | | |responses| | |
| | | | Name |---------|->|Foreign |
| Master |-------------->| Server | | |Resolver|
| files | | | |<--------|--| |
| |/ | | queries | +--------+
+---------+ +----------+ |
Qui un name server primario (primary name server) acquisisce informazioni su una o più zone leggendo file master dal suo file system locale, e risponde alle query su quelle zone che arrivano da resolver esterni.
Il DNS richiede che tutte le zone siano supportate in modo ridondante da più di un name server. I server secondari designati (secondary servers) possono acquisire zone e verificare gli aggiornamenti dal server primario utilizzando il protocollo di trasferimento di zona (zone transfer protocol) del DNS. Questa configurazione è mostrata di seguito:
Local Host | Foreign
|
+---------+ |
/ /| |
+---------+ | +----------+ | +--------+
| | | | |responses| | |
| | | | Name |---------|->|Foreign |
| Master |-------------->| Server | | |Resolver|
| files | | | |<--------|--| |
| |/ | | queries | +--------+
+---------+ +----------+ |
A |maintenance | +--------+
| +------------|->| |
| queries | |Foreign |
| | | Name |
+------------------|--| Server |
maintenance responses | +--------+
In questa configurazione, il name server stabilisce periodicamente un circuito virtuale (virtual circuit) con un name server esterno per acquisire una copia di una zona o per verificare che una copia esistente non sia cambiata. I messaggi inviati per queste attività di manutenzione seguono la stessa forma delle query e delle risposte, ma le sequenze di messaggi sono leggermente diverse.
Il flusso di informazioni in un host che supporta tutti gli aspetti del sistema dei nomi di dominio è mostrato di seguito:
Local Host | Foreign
|
+---------+ +----------+ | +--------+
| | user queries | |queries | | |
| User |-------------->| |---------|->|Foreign |
| Program | | Resolver | | | Name |
| |<--------------| |<--------|--| Server |
| | user responses| |responses| | |
+---------+ +----------+ | +--------+
| A |
cache additions | | references |
V | |
+----------+ |
| Shared | |
| database | |
+----------+ |
A | |
+---------+ refreshes | | references |
/ /| | V |
+---------+ | +----------+ | +--------+
| | | | |responses| | |
| | | | Name |---------|->|Foreign |
| Master |-------------->| Server | | |Resolver|
| files | | | |<--------|--| |
| |/ | | queries | +--------+
+---------+ +----------+ |
A |maintenance | +--------+
| +------------|->| |
| queries | |Foreign |
| | | Name |
+------------------|--| Server |
maintenance responses | +--------+
Il database condiviso (shared database) contiene i dati dello spazio di dominio per il name server e il resolver locale. Il contenuto del database condiviso sarà tipicamente una miscela di dati autoritativi mantenuti dalle operazioni di refresh periodiche del name server e dati memorizzati nella cache da precedenti richieste del resolver. La struttura dei dati di dominio e la necessità di sincronizzazione tra name server e resolver implicano le caratteristiche generali di questo database, ma il formato effettivo dipende dall'implementatore locale.
Il flusso di informazioni può anche essere personalizzato in modo che un gruppo di host agisca insieme per ottimizzare le attività. A volte questo viene fatto per scaricare host meno capaci in modo che non debbano implementare un resolver completo. Questo può essere appropriato per PC o host che desiderano minimizzare la quantità di nuovo codice di rete richiesta. Questo schema può anche consentire a un gruppo di host di condividere un piccolo numero di cache piuttosto che mantenere un gran numero di cache separate, sulla premessa che le cache centralizzate avranno un rapporto di successo (hit ratio) più elevato. In entrambi i casi, i resolver vengono sostituiti con resolver stub (stub resolvers) che agiscono come front-end per i resolver situati in un server ricorsivo (recursive server) in uno o più name server noti per eseguire quel servizio:
Local Hosts | Foreign
|
+---------+ |
| | responses |
| Stub |<--------------------+ |
| Resolver| | |
| |----------------+ | |
+---------+ recursive | | |
queries | | |
V | |
+---------+ recursive +----------+ | +--------+
| | queries | |queries | | |
| Stub |-------------->| Recursive|---------|->|Foreign |
| Resolver| | Server | | | Name |
| |<--------------| |<--------|--| Server |
+---------+ responses | |responses| | |
+----------+ | +--------+
| Central | |
| cache | |
+----------+ |
In ogni caso, si noti che i componenti di dominio vengono sempre replicati per affidabilità quando possibile.
2.3. Conventions (Convenzioni)
Il sistema di dominio ha diverse convenzioni che trattano problemi di basso livello, ma fondamentali. Mentre l'implementatore è libero di violare queste convenzioni ALL'INTERNO DEL SUO SISTEMA, deve osservare queste convenzioni in TUTTO il comportamento osservato da altri host.
2.3.1. Preferred name syntax (Sintassi del nome preferita)
Le specifiche DNS tentano di essere il più generali possibile nelle regole per la costruzione di nomi di dominio. L'idea è che il nome di qualsiasi oggetto esistente possa essere espresso come nome di dominio con modifiche minime.
Tuttavia, quando si assegna un nome di dominio a un oggetto, l'utente prudente selezionerà un nome che soddisfi sia le regole del sistema di dominio sia eventuali regole esistenti per l'oggetto, indipendentemente dal fatto che queste regole siano pubblicate o implicite dai programmi esistenti.
Ad esempio, quando si denomina un dominio di posta, l'utente dovrebbe soddisfare sia le regole di questo memo sia quelle in RFC-822. Quando si crea un nuovo nome host, devono essere seguite le vecchie regole per HOSTS.TXT. Questo evita problemi quando i vecchi software vengono convertiti per utilizzare i nomi di dominio.
La seguente sintassi risulterà in meno problemi con molte applicazioni che utilizzano nomi di dominio (ad esempio, mail, TELNET).
<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case
<digit> ::= any one of the ten digits 0 through 9
Si noti che mentre le lettere maiuscole e minuscole sono consentite nei nomi di dominio, non viene data importanza al caso. Cioè, due nomi con la stessa ortografia ma caso diverso devono essere trattati come identici.
Le etichette devono seguire le regole per i nomi host ARPANET. Devono iniziare con una lettera, terminare con una lettera o una cifra e avere come caratteri interni solo lettere, cifre e trattino (hyphen). Ci sono anche alcune restrizioni sulla lunghezza. Le etichette devono essere di 63 caratteri o meno.
Ad esempio, le seguenti stringhe identificano host in Internet:
A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
2.3.2. Data Transmission Order (Ordine di trasmissione dei dati)
L'ordine di trasmissione dell'intestazione e dei dati descritti in questo documento è risolto al livello di ottetto (octet). Ogni volta che un diagramma mostra un gruppo di ottetti, l'ordine di trasmissione di quegli ottetti è l'ordine normale in cui vengono letti in inglese. Ad esempio, nel seguente diagramma, gli ottetti vengono trasmessi nell'ordine in cui sono numerati.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ogni volta che un ottetto rappresenta una quantità numerica, il bit più a sinistra nel diagramma è il bit di ordine elevato o più significativo (most significant bit). Cioè, il bit etichettato 0 è il bit più significativo. Ad esempio, il seguente diagramma rappresenta il valore 170 (decimale).
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
Allo stesso modo, ogni volta che un campo multi-ottetto rappresenta una quantità numerica, il bit più a sinistra dell'intero campo è il bit più significativo. Quando viene trasmessa una quantità multi-ottetto, l'ottetto più significativo viene trasmesso per primo.
2.3.3. Character Case (Maiuscole/minuscole dei caratteri)
Per tutte le parti del DNS che fanno parte del protocollo ufficiale, tutti i confronti tra stringhe di caratteri (ad esempio, etichette, nomi di dominio, ecc.) vengono eseguiti in modo insensibile alle maiuscole/minuscole (case-insensitive). Attualmente, questa regola è in vigore in tutto il sistema di dominio senza eccezioni. Tuttavia, aggiunte future oltre l'uso corrente potrebbero dover utilizzare le capacità complete degli ottetti binari nei nomi, quindi dovrebbero essere evitati i tentativi di memorizzare nomi di dominio in ASCII a 7 bit o l'uso di byte speciali per terminare le etichette, ecc.
Quando i dati entrano nel sistema di dominio, la loro maiuscola/minuscola originale dovrebbe essere preservata quando possibile. In determinate circostanze ciò non può essere fatto. Ad esempio, se due RR sono memorizzati in un database, uno in x.y e uno in X.Y, sono effettivamente memorizzati nello stesso posto nel database, e quindi solo una maiuscola/minuscola verrebbe preservata. La regola di base è che la maiuscola/minuscola può essere scartata solo quando i dati vengono utilizzati per definire la struttura in un database, e due nomi sono identici quando confrontati in modo insensibile alle maiuscole/minuscole.
La perdita di dati sensibili alle maiuscole/minuscole deve essere minimizzata. Quindi, mentre i dati per x.y e X.Y possono essere entrambi memorizzati in un'unica posizione x.y o X.Y, i dati per a.x e B.X non verrebbero mai memorizzati in A.x, A.X, b.x o b.X. In generale, questo preserva la maiuscola/minuscola della prima etichetta di un nome di dominio, ma forza la standardizzazione delle etichette dei nodi interni.
Gli amministratori di sistema che inseriscono dati nel database di dominio dovrebbero prestare attenzione a rappresentare i dati che forniscono al sistema di dominio in modo coerente con la maiuscola/minuscola se il loro sistema è sensibile alle maiuscole/minuscole. Il sistema di distribuzione dei dati nel sistema di dominio garantirà che le rappresentazioni coerenti vengano preservate.
2.3.4. Size limits (Limiti di dimensione)
Vari oggetti e parametri nel DNS hanno limiti di dimensione. Sono elencati di seguito. Alcuni potrebbero essere facilmente modificati, altri sono più fondamentali.
| Oggetto | Limite |
|---|---|
| labels (etichette) | 63 ottetti o meno |
| names (nomi) | 255 ottetti o meno |
| TTL | valori positivi di un numero con segno a 32 bit |
| UDP messages (messaggi UDP) | 512 ottetti o meno |