Passa al contenuto principale

2. Nomi

Hostname: Questo termine ha diverse definizioni contrastanti in diversi documenti DNS e ha causato molta confusione. Un "hostname" era originariamente (prima dell'introduzione del DNS) definito come l'intero nome di un computer, solitamente un singolo nome senza struttura interna (vedere Sezione 2 di [RFC952]). Con l'introduzione della delega DNS, gli hostname sono stati tipicamente trattati con la struttura interna dettata dall'albero DNS, come una parte locale di un nome all'interno di una zona, la radice della gerarchia dei nomi e/o un nome di dominio completamente qualificato (fully qualified domain name). Nell'uso contemporaneo, "hostname" si riferisce solo alla parte locale di un nome DNS (a volte indicato anche come "node name" - nome del nodo).

Alcuni documenti, come [RFC1912], usano "hostname" per significare "un singolo label, senza punti". Lo stesso documento usa quindi "host" e "domain name" come sinonimi, ma non lo sono.

Per ulteriori informazioni vedere [RFC1983], Appendice B. Ai fini di questo documento, un hostname si riferisce a un label DNS che rappresenta un nodo speciale in una zona. Questo dovrebbe essere un caso d'uso preferito rispetto agli hostname che specificano nodi a qualsiasi livello della gerarchia DNS.

Nome di dominio (Domain name): "Un nome di dominio è identificato da un label (una singola parola o un insieme di label costituito da una sequenza di label)." (Citato da [RFC1034], Sezione 2.3)

Label: Un elemento ordinato in un nome di dominio. "Ogni nodo [nella gerarchia dei nomi] ha un label, che ha una lunghezza da zero a 63 ottetti. I nodi fratelli non possono avere lo stesso label, anche se lo stesso label può essere usato per nodi che non sono fratelli." (Citato da [RFC1034], Sezione 2.3) Questo significa che i nodi che non sono fratelli possono avere gli stessi label.

FQDN (Fully Qualified Domain Name - Nome di Dominio Completamente Qualificato): Questo è spesso usato ma non definito nel contesto DNS. [RFC1594], Sezione 5.2, lo discute, ma solo nel contesto della registrazione di organizzazioni con domini geografici. [RFC1983] lo definisce come "l'indirizzo completo di una casella di posta elettronica Internet o di un host" e si riferisce a [RFC1123], che non lo definisce. [RFC2181] non definisce FQDN, ma è oggetto di discussione nella Sezione 11 di quel documento: "Un nome di dominio è spesso indicato come assoluto quando appare nel formato wire (terminando con un label di lunghezza zero come ultimo label), e relativo quando quel label nullo non è presente. Un nome di dominio assoluto è spesso chiamato 'Fully Qualified', spesso abbreviato in FQDN, che è un chiaro riferimento alla completezza fornita dal label nullo."

Per ragioni storiche, parte della confusione attorno al concetto di "Fully Qualified Domain Names" era che alcuni software DNS avrebbero diviso le query nello spazio dei nomi di dominio in diversi documenti o record. I nomi di dominio all'interno di ciascuno di questi documenti potrebbero essere "locali" rispetto al documento o record, e un processo di qualificazione verrebbe eseguito prima di tentare di risolvere i nomi. Il software moderno per server DNS non richiede più che i nomi di dominio siano qualificati in questo modo, anche se il software resolver stub include ancora spesso un elenco di ricerca per la qualificazione locale. "FQDN" è ancora comunemente usato per riferirsi al nome di dominio riferito dopo che tale qualificazione è stata completata.

TLD (Top-Level Domain - Dominio di Primo Livello): "Il nome nella gerarchia DNS direttamente sotto la radice è un TLD". (Citato da [RFC4033], Sezione 9)

Nome di dominio internazionalizzato (Internationalized Domain Name): La maggior parte dei label nel DNS non può essere descritta con caratteri non ASCII. I nomi di dominio internazionalizzati (IDN) sono nomi di dominio che hanno una rappresentazione Unicode e sono rappresentati internamente nel DNS come formato di codifica compatibile ASCII. Questa codifica è anche chiamata "Punycode". Per gli IDN esistono [RFC5890], [RFC5891], [RFC5892], [RFC5893] e [RFC5894]. Ci sono anche [RFC6055], [RFC6365] e [RFC4690].

Sottodominio (Subdomain): "Un dominio è un sottodominio di un altro dominio se è contenuto all'interno di quel dominio. Questa relazione può essere testata indirettamente vedendo se il dominio di origine giace sotto il dominio finale su tutti i percorsi che salgono verso la radice." (Citato da [RFC1034], Sezione 2.3.1)

Alias: "Un alias è un nome di dominio che è mappato su un RR CN [canonical name resource record], il cui valore è un nome canonico." (Citato da [RFC2181], Sezione 10.1.1) I CNAME RR consentono agli operatori di archivi di nomi di dominio (spesso server DNS) di mantenere voci che mappano nomi DNS su altri nomi DNS. Anche se i CNAME RR non sono specificamente necessari per rispondere alle query, forniscono una funzionalità di "indirezione". Cioè, un operatore può posizionare un particolare nome di dominio (un label che nomina un dispositivo di rete) in luoghi diversi, o modificare frequentemente il suo significato o associazioni, mentre altri nomi di dominio che puntano a quel nome (attraverso CNAME RR) possono rimanere relativamente statici. Ci sono spesso ragioni tecniche o commerciali per cui l'indirezione è desiderabile; il DNS fornisce un modo per ottenere l'indirezione attraverso i CNAME RR. [RFC1912] è un documento utile per gli operatori di servizi di nomi per comprendere quando e come utilizzare il CNAME RR. [RFC2181] aiuta a chiarire la comprensione di come funziona il CNAME RR e perché il suo uso è limitato in determinati modi.

Suffisso pubblico (Public Suffix): "Un suffisso pubblico è un label o una sequenza di label sotto i quali un nome di dominio registrabile può essere registrato da un particolare registro secondo determinate condizioni e politiche che sono al di fuori dell'ambito di questo documento. Esempi di suffissi pubblici sono .com, .co.uk e pvt.k12.wy.us. Il termine è stato originariamente definito nel contesto dei Cookie di gestione dello stato HTTP, ma è utilizzato anche altrove, ad esempio nel problema dei confini di dominio [DBOUND]." (Questa definizione è una riformulazione di quanto detto in [RFC6265].) In pratica, ciò che è considerato un suffisso pubblico dipende in gran parte da un elenco piuttosto arbitrario che viene reso disponibile pubblicamente e non fa parte di uno standard.

Storicamente, si pensava che i "suffissi pubblici" fossero tutti i TLD. Sarebbe stata ancora una buona regola se non fosse che i TLD storici avevano una gerarchia più piatta che era "appena sotto la radice". Ad esempio, nei primi giorni del DNS, .uk, .us e alcuni altri TLD avevano domini assegnati "direttamente sotto" il TLD, come foo.uk, e venivano create anche sottodomini sotto altri label, come foo.co.uk, creando lì due "suffissi pubblici". Più o meno struttura può esistere a seconda del TLD, e molti TLD utilizzano strutture di nomi di dominio più complicate, ad esempio i gTLD. (Alcuni descrivono questa pratica in modo dispregiativo perché manca di coerenza.) Queste strutture portano a suffissi pubblici più complessi, a seconda del TLD.

IDNA: "Internationalized Domain Names in Applications" (Nomi di Dominio Internazionalizzati nelle Applicazioni), l'attuale protocollo IETF per la gestione dei nomi di dominio internazionalizzati. Il termine "IDNA" dovrebbe riferirsi solo ai protocolli definiti in [RFC5890], [RFC5891], [RFC5892], [RFC5893], [RFC5894] e [RFC5895]. La pratica comune di utilizzare "IDNA" per riferirsi all'ormai storico RFC 3490 e ai documenti correlati dovrebbe cessare, poiché nessuna specifica di protocollo li ha più sul percorso degli standard. Alcune applicazioni non hanno effettuato gli aggiornamenti al protocollo IDNA; queste non sono conformi con l'attuale DNS. (Un termine precedente per IDNA era "IDNA2008", ma non è mai stato parte di alcun RFC e sicuramente non dovrebbe più essere utilizzato.)