2. Introduzione (Introduction)
Questo RFC introduce i nomi in stile dominio (Domain Style Names), il loro utilizzo per la posta Internet e il supporto degli indirizzi host, nonché i protocolli e i server utilizzati per implementare le funzionalità dei nomi di dominio.
2.1. La storia dei nomi di dominio (The history of domain names)
L'impulso per lo sviluppo del sistema di dominio è stata la crescita di Internet:
-
Le mappature da nome host a indirizzo (Host name to address mappings) erano mantenute dal Network Information Center (NIC) in un singolo file (HOSTS.TXT) che veniva scaricato tramite FTP da tutti gli host [RFC-952, RFC-953]. La larghezza di banda di rete totale consumata nella distribuzione di una nuova versione con questo schema è proporzionale al quadrato del numero di host nella rete, e anche quando vengono utilizzati più livelli di FTP, il carico FTP in uscita sull'host NIC è considerevole. La crescita esplosiva del numero di host non prometteva nulla di buono per il futuro.
-
La popolazione della rete (The network population) stava cambiando anche carattere. Gli host a tempo condiviso che componevano l'ARPANET originale venivano sostituiti con reti locali di workstation. Le organizzazioni locali amministravano i propri nomi e indirizzi, ma dovevano attendere che il NIC modificasse HOSTS.TXT per rendere visibili le modifiche a Internet nel suo insieme. Le organizzazioni volevano anche una certa struttura locale sullo spazio dei nomi.
-
Le applicazioni su Internet (The applications) stavano diventando più sofisticate e creavano la necessità di un servizio di nomi generico.
Il risultato furono diverse idee sugli spazi dei nomi e sulla loro gestione [IEN-116, RFC-799, RFC-819, RFC-830]. Le proposte variavano, ma un filo comune era l'idea di uno spazio dei nomi gerarchico, con la gerarchia che corrisponde approssimativamente alla struttura organizzativa, e i nomi che utilizzano "." come carattere per segnare il confine tra i livelli gerarchici. Un design che utilizzava un database distribuito e risorse generalizzate è stato descritto in [RFC-882, RFC-883]. Sulla base dell'esperienza con diverse implementazioni, il sistema si è evoluto nello schema descritto in questo memo.
I termini "dominio (Domain)" o "nome di dominio (Domain Name)" sono utilizzati in molti contesti oltre al DNS qui descritto. Molto spesso, il termine nome di dominio viene utilizzato per riferirsi a un nome con una struttura indicata da punti, ma senza relazione con il DNS. Ciò è particolarmente vero nell'indirizzamento della posta [Quarterman 86].
2.2. Obiettivi di progettazione del DNS (DNS design goals)
Gli obiettivi di progettazione del DNS influenzano la sua struttura. Sono:
-
Spazio dei nomi coerente (Consistent name space): L'obiettivo principale è uno spazio dei nomi coerente che verrà utilizzato per fare riferimento alle risorse. Per evitare i problemi causati da codifiche ad hoc, i nomi non dovrebbero essere obbligati a contenere identificatori di rete, indirizzi, percorsi o informazioni simili come parte del nome.
-
Manutenzione distribuita (Distributed maintenance): Le dimensioni considerevoli del database e la frequenza degli aggiornamenti suggeriscono che deve essere mantenuto in modo distribuito, con caching locale per migliorare le prestazioni. Gli approcci che tentano di raccogliere una copia coerente dell'intero database diventeranno sempre più costosi e difficili, e quindi dovrebbero essere evitati. Lo stesso principio vale per la struttura dello spazio dei nomi, e in particolare per i meccanismi di creazione e cancellazione dei nomi; anche questi dovrebbero essere distribuiti.
-
Controllo dei compromessi dalla fonte (Source control of tradeoffs): Dove ci sono compromessi tra il costo di acquisizione dei dati, la velocità degli aggiornamenti e l'accuratezza delle cache, la fonte dei dati dovrebbe controllare il compromesso.
-
Utilità generale (General utility): I costi di implementazione di tale struttura dettano che sia generalmente utile e non limitata a una singola applicazione. Dovremmo essere in grado di utilizzare i nomi per recuperare indirizzi host, dati di caselle postali e altre informazioni ancora non determinate. Tutti i dati associati a un nome sono etichettati con un tipo, e le query possono essere limitate a un singolo tipo.
-
Indipendenza dal protocollo (Protocol independence): Poiché vogliamo che lo spazio dei nomi sia utile in reti e applicazioni dissimili, forniamo la capacità di utilizzare lo stesso spazio dei nomi con diverse famiglie di protocolli o gestione. Ad esempio, i formati di indirizzo host differiscono tra i protocolli, sebbene tutti i protocolli abbiano la nozione di indirizzo. Il DNS etichetta tutti i dati con una classe oltre al tipo, in modo da poter consentire l'uso parallelo di diversi formati per i dati di tipo indirizzo.
-
Indipendenza dal trasporto (Transport independence): Vogliamo che le transazioni del name server siano indipendenti dal sistema di comunicazione che le trasporta. Alcuni sistemi potrebbero voler utilizzare datagrammi per query e risposte, e stabilire circuiti virtuali solo per transazioni che necessitano di affidabilità (ad esempio, aggiornamenti del database, transazioni lunghe); altri sistemi utilizzeranno esclusivamente circuiti virtuali.
-
Ampia gamma di capacità host (Wide host capability range): Il sistema dovrebbe essere utile attraverso un ampio spettro di capacità host. Sia i personal computer che i grandi host a tempo condiviso dovrebbero essere in grado di utilizzare il sistema, anche se forse in modi diversi.
2.3. Presupposti sull'utilizzo (Assumptions about usage)
L'organizzazione del sistema di dominio deriva da alcuni presupposti sui bisogni e i modelli di utilizzo della sua comunità di utenti ed è progettata per evitare molti dei problemi complicati trovati nei sistemi di database generici.
I presupposti sono:
-
Dimensione del database (Database size): La dimensione del database totale sarà inizialmente proporzionale al numero di host che utilizzano il sistema, ma alla fine crescerà proporzionalmente al numero di utenti su quegli host man mano che le caselle postali e altre informazioni verranno aggiunte al sistema di dominio.
-
Frequenza di aggiornamento (Update frequency): La maggior parte dei dati nel sistema cambierà molto lentamente (ad esempio, binding delle caselle postali, indirizzi host), ma il sistema dovrebbe essere in grado di gestire sottoinsiemi che cambiano più rapidamente (dell'ordine di secondi o minuti).
-
Confini amministrativi (Administrative boundaries): I confini amministrativi utilizzati per distribuire la responsabilità del database corrisponderanno solitamente a organizzazioni che hanno uno o più host. Ogni organizzazione che ha la responsabilità di un particolare insieme di domini fornirà name server ridondanti, sia sugli host dell'organizzazione stessa sia su altri host che l'organizzazione si organizza per utilizzare.
-
Server affidabili (Trusted servers): I client del sistema di dominio dovrebbero essere in grado di identificare i name server affidabili che preferiscono utilizzare prima di accettare riferimenti a name server al di fuori di questo insieme "affidabile".
-
Disponibilità vs coerenza (Availability vs consistency): L'accesso alle informazioni è più critico degli aggiornamenti istantanei o delle garanzie di coerenza. Pertanto, il processo di aggiornamento consente agli aggiornamenti di permeare attraverso gli utenti del sistema di dominio piuttosto che garantire che tutte le copie siano aggiornate simultaneamente. Quando gli aggiornamenti non sono disponibili a causa di guasti di rete o host, il corso abituale è credere alle vecchie informazioni continuando gli sforzi per aggiornarle. Il modello generale è che le copie siano distribuite con timeout per l'aggiornamento. Il distributore imposta il valore del timeout e il destinatario della distribuzione è responsabile dell'esecuzione dell'aggiornamento. In situazioni speciali, possono essere specificati intervalli molto brevi, o il proprietario può proibire le copie.
-
Approcci di risoluzione delle query (Query resolution approaches): In qualsiasi sistema che ha un database distribuito, un particolare name server può ricevere una query a cui può rispondere solo un altro server. I due approcci generali per affrontare questo problema sono "ricorsivo (Recursive)", in cui il primo server persegue la query per il client presso un altro server, e "iterativo (Iterative)", in cui il server riferisce il client a un altro server e lascia che il client persegua la query. Entrambi gli approcci hanno vantaggi e svantaggi, ma l'approccio iterativo è preferito per lo stile di accesso a datagramma. Il sistema di dominio richiede l'implementazione dell'approccio iterativo, ma consente l'approccio ricorsivo come opzione.
Origine e gestione dei dati (Data origin and management)
Il sistema di dominio presuppone che tutti i dati abbiano origine in file master (Master Files) sparsi tra gli host che utilizzano il sistema di dominio. Questi file master sono aggiornati dagli amministratori di sistema locali. I file master sono file di testo che vengono letti da un name server locale, e quindi diventano disponibili attraverso i name server agli utenti del sistema di dominio. I programmi utente accedono ai name server attraverso programmi standard chiamati resolver (Resolvers).
Il formato standard dei file master consente loro di essere scambiati tra host (tramite FTP, posta o qualche altro meccanismo); questa funzionalità è utile quando un'organizzazione vuole un dominio, ma non vuole supportare un name server. L'organizzazione può mantenere i file master localmente usando un editor di testo, trasferirli a un host esterno che esegue un name server, e quindi organizzarsi con l'amministratore di sistema del name server per far caricare i file.
I name server e i resolver di ciascun host sono configurati da un amministratore di sistema locale [RFC-1033]. Per un name server, questi dati di configurazione includono l'identità dei file master locali e le istruzioni su quali file master non locali devono essere caricati dai server esterni. Il name server utilizza i file master o le copie per caricare le sue zone. Per i resolver, i dati di configurazione identificano i name server che dovrebbero essere le fonti primarie di informazioni.
Il sistema di dominio definisce procedure per accedere ai dati e per i riferimenti ad altri name server. Il sistema di dominio definisce anche procedure per memorizzare nella cache i dati recuperati e per l'aggiornamento periodico dei dati definiti dall'amministratore di sistema.
Divisione delle responsabilità (Division of responsibilities)
Gli amministratori di sistema forniscono:
- La definizione dei confini di zona
- File master di dati
- Aggiornamenti ai file master
- Dichiarazioni delle politiche di aggiornamento desiderate
Il sistema di dominio fornisce:
- Formati standard per i dati delle risorse
- Metodi standard per interrogare il database
- Metodi standard per i name server per aggiornare i dati locali dai name server esterni
2.4. Elementi del DNS (Elements of the DNS)
Il DNS ha tre componenti principali:
SPAZIO DEI NOMI DI DOMINIO e RECORD DI RISORSE (DOMAIN NAME SPACE and RESOURCE RECORDS)
Lo SPAZIO DEI NOMI DI DOMINIO e i RECORD DI RISORSE (DOMAIN NAME SPACE and RESOURCE RECORDS) sono specifiche per uno spazio dei nomi strutturato ad albero e dati associati ai nomi. Concettualmente, ogni nodo e foglia dell'albero dello spazio dei nomi di dominio nomina un insieme di informazioni, e le operazioni di query sono tentativi di estrarre tipi specifici di informazioni da un particolare insieme. Una query nomina il nome di dominio di interesse e descrive il tipo di informazione di risorsa desiderata. Ad esempio, Internet utilizza alcuni dei suoi nomi di dominio per identificare gli host; le query per le risorse di indirizzo restituiscono indirizzi host Internet.
NAME SERVER (NAME SERVERS)
I NAME SERVER sono programmi server che contengono informazioni sulla struttura dell'albero di dominio e informazioni sull'insieme. Un name server può memorizzare nella cache la struttura o le informazioni sull'insieme su qualsiasi parte dell'albero di dominio, ma in generale un particolare name server ha informazioni complete su un sottoinsieme dello spazio di dominio, e puntatori ad altri name server che possono essere utilizzati per condurre alle informazioni da qualsiasi parte dell'albero di dominio. I name server conoscono le parti dell'albero di dominio per le quali hanno informazioni complete; si dice che un name server sia un'AUTORITÀ (AUTHORITY) per queste parti dello spazio dei nomi. Le informazioni autorevoli sono organizzate in unità chiamate ZONE, e queste zone possono essere distribuite automaticamente ai name server che forniscono un servizio ridondante per i dati in una zona.
RESOLVER (RESOLVERS)
I RESOLVER sono programmi che estraggono informazioni dai name server in risposta alle richieste dei client. I resolver devono essere in grado di accedere ad almeno un name server e utilizzare le informazioni di quel name server per rispondere direttamente a una query, o perseguire la query utilizzando riferimenti ad altri name server. Un resolver sarà tipicamente una routine di sistema direttamente accessibile ai programmi utente; quindi nessun protocollo è necessario tra il resolver e il programma utente.
Tre viste del sistema di dominio (Three views of the domain system)
Questi tre componenti corrispondono approssimativamente ai tre livelli o viste del sistema di dominio:
-
Dal punto di vista dell'utente (From the user's point of view), il sistema di dominio è accessibile attraverso una semplice procedura o chiamata OS a un resolver locale. Lo spazio di dominio consiste di un singolo albero e l'utente può richiedere informazioni da qualsiasi sezione dell'albero.
-
Dal punto di vista del resolver (From the resolver's point of view), il sistema di dominio è composto da un numero sconosciuto di name server. Ogni name server ha uno o più pezzi dei dati dell'intero albero di dominio, ma il resolver vede ciascuno di questi database come essenzialmente statico.
-
Dal punto di vista di un name server (From a name server's point of view), il sistema di dominio consiste di insiemi separati di informazioni locali chiamate zone. Il name server ha copie locali di alcune delle zone. Il name server deve aggiornare periodicamente le sue zone da copie master in file locali o name server esterni. Il name server deve elaborare contemporaneamente le query che arrivano dai resolver.
Nell'interesse delle prestazioni, le implementazioni possono accoppiare queste funzioni. Ad esempio, un resolver sulla stessa macchina di un name server potrebbe condividere un database composto dalle zone gestite dal name server e dalla cache gestita dal resolver.