Panoramica su terminologie, componenti e concetti del DNS

DNS (Domain Name System) è uno dei componenti cruciali che muovono l’internet. Avere una corretta comprensione di come funziona il DNS può aiutare a diagnosticare problemi con la configurazione del sito web e ampliare la comprensione di ciò che accade dietro le quinte.

In questa guida, parleremo di alcuni concetti fondamentali del DNS per fornirti una base solida mentre lavori con la tua configurazione DNS. Questa guida ti aiuterà anche a configurare il tuo nome di dominio o server DNS.

Iniziamo!

Terminologie dei domini

In primo luogo, dobbiamo stabilire una comprensione dei termini che useremo. Potresti già avere familiarità con alcuni di essi in altri contesti. Tuttavia, ci sono molti termini specifici quando si parla di nomi di dominio e DNS che non vengono discussi molto in altre aree dell’informatica.

• Domain Name System

Il domain name system (DNS, in breve) è un sistema di rete in uso che traduce nomi di dominio facilmente comprensibili dall’uomo in indirizzi IP unici.

• Nome di dominio

Un nome di dominio si riferisce al nome facilmente comprensibile dall’uomo utilizzato per associarsi a una risorsa internet. Ad esempio, “cloudsigma.com” è un nome di dominio. Alcuni potrebbero sostenere che solo la parte “cloudsigma” sia il nome di dominio, ma generalmente ci si riferisce all’intero.

L’URL “cloudsigma.com” è associato ai server di proprietà di CloudSigma. Quando si inserisce l’URL nel browser web, questo comunica con il DNS per connettersi all’indirizzo IP del server di destinazione.

• Indirizzo IP

Un indirizzo IP funge da indirizzo di rete per un dispositivo connesso alla rete. Ciascun indirizzo IP deve essere unico all’interno della rete. Nel contesto dei siti web, la rete è, nella maggior parte dei casi, l’intera internet.

Esistono due tipi di indirizzi IP:

• • IPv4: Questa è la forma più comune di indirizzo IP. È scritto come un insieme di quattro numeri, ciascuno dei quali composto da un massimo di 3 cifre. Ogni insieme è separato da un punto. L’intervallo di IPv4 va da 0.0.0.0 a 255.255.255.255.

  • IPv6: È uno standard più moderno sviluppato per risolvere il problema dell’esaurimento degli indirizzi IPv4. IPv4 supporta fino a 232 indirizzi unici, mentre IPv6 supporta fino a 2128 indirizzi. Qualsiasi indirizzo IPv6 è scritto in cifre esadecimali. Può contenere fino a 32 cifre, suddivise in 8 sezioni (4 cifre per ogni sezione). Ciascuna sezione è separata da due punti (:).

Dominio di primo livello

Un dominio di primo livello (TLD in breve) è la parte più generale del dominio. Si riferisce alla parte situata più a destra (separata da un punto). Alcuni dei domini di primo livello più comuni includono:

• “com”

• “net”

• “org”

• “edu”

• “io”

• “gov”

In termini di nomi di dominio, questi domini si trovano al vertice della gerarchia. L’ICANN (Internet Corporation for Assigned Names and Numbers) può rilasciare un permesso per il controllo di determinate parti sui domini di primo livello. Con il permesso, queste parti possono distribuire nomi di dominio sotto il TLD (di solito tramite un registrar di domini).

• Host

Nel dominio, il proprietario può specificare singoli host, riferendosi a macchine/servizi separati accessibili tramite un dominio. Ad esempio, è pratica comune rendere i server web accessibili tramite il dominio nudo ( example.com) e la definizione di “host” “www  ( www.example.com).

È possibile avere host aggiuntivi sotto il dominio generale, ad esempio, l’accesso alle API tramite l’host “api” ( api.example.com), l’accesso FTP tramite l’host “ftp” o “files” ( ftp.example.com o files.example.com).

Si noti che i nomi di dominio possono essere arbitrari purché siano unici all’interno del dominio.

• Sottodominio

Un sottodominio è un argomento correlato agli host. Il DNS funziona in modo gerarchico. Un TLD può avere molti domini al di sotto di esso. Ad esempio, “ example.com”, “ cloudsigma.com”, ecc. sono tutti sotto il TLD “com”. In tal senso, un sottodominio è un riferimento a qualsiasi dominio che fa parte del dominio di destinazione. Pertanto, possiamo dire che “example.com” è un sottodominio di “com”. In genere, la parte “example” viene definita SLD (second-level domain).

Allo stesso modo, un dominio può controllare tutti i “sottodomini” situati sotto di esso. Questo è solitamente ciò a cui ci si riferisce con “sottodominio”. Ad esempio, “ history.example.com” è un sottodominio di “ example.com”.

La differenza fondamentale tra un hostname e un sottodominio è che un host definisce un computer/risorsa, mentre un sottodominio estende il dominio principale. Ogni volta che parliamo di sottodomini o host, puoi verificarlo guardando la parte più a sinistra di un dominio, in quanto è la più specifica. È così che funziona il DNS: dal più specifico (il lato più a sinistra) al meno specifico (il lato più a destra).

• Nome di dominio completamente qualificato

Un nome di dominio completamente qualificato (in breve FQDN) si riferisce a un nome di dominio assoluto. Nel sistema DNS, i domini possono essere forniti in relazione tra loro. Ciò può portare a una certa ambiguità. Un FQDN, tuttavia, è un nome assoluto che si riferisce alla radice assoluta del sistema dei nomi di dominio.

Ciò significa che l'FQDN specifica ogni dominio principale, incluso il TLD. Un esempio calzante sarebbe “ mail.google.com”. In casi specifici, l'FQDN potrebbe non terminare con un punto, ma deve avere un punto finale (richiesto dagli standard ICANN).

• Nameserver

Un nameserver è un computer dedicato alla traduzione dei nomi di dominio in indirizzi IP. I nameserver sostengono la maggior parte del carico nel sistema DNS. Poiché il numero totale di richieste di traduzione dei domini è troppo elevato per essere gestito da un singolo server, le richieste vengono spesso reindirizzate ad altri nameserver per alleggerire la pressione.

Un name server può essere “autorevole”, il che significa che fornisce risposte solo alle query sui domini sotto il suo controllo. Tali server possono inoltrare la richiesta ad altri nameserver o fornire una copia memorizzata nella cache dei dati di altri nameserver.

• File di zona

Un file di zona è un file di testo contenente le associazioni tra nomi di dominio e indirizzi IP. Funge da database del sistema DNS. Questo è il catalogo che il DNS utilizza per trovare quale indirizzo IP contattare quando si completa la richiesta di un utente per un determinato nome di dominio.

In genere, i nameserver ospitano i file di zona e definiscono le risorse disponibili sotto un singolo dominio. Possono anche contenere informazioni su dove andare per ottenere tali informazioni.

• Record

Un file di zona comprende numerosi record. In questo contesto, un record è definito come una singola associazione tra una risorsa e un nome. I record possono essere l'associazione di un nome di dominio a un indirizzo IP, risorse disponibili sotto un dominio specifico o riferimenti a posizioni in cui ottenere le informazioni.

Il DNS in azione

Finora abbiamo familiarizzato con alcune terminologie comuni relative al DNS. Tuttavia, come funziona effettivamente il sistema? Il sistema può apparire molto semplice a una vista di alto livello. Ciononostante, approfondire i dettagli ne svelerà la reale complessità. Nel complesso, il sistema DNS è fondamentale per l'adozione diffusa di Internet.

• Root server

Il DNS, fondamentalmente, funziona in modo gerarchico. Al vertice del sistema risiedono i “root server”. Questi server sono sotto il controllo di varie organizzazioni. L'autorità di questi server è delegata dall'ICANN (Internet Corporation for Assigned Names and Numbers).

Attualmente sono in funzione circa 13 root server. A causa del carico, tuttavia, ognuno di questi server è replicato. È importante notare che tutti i server mirror condividono lo stesso indirizzo IP del root server. Ogni volta che viene effettuata una richiesta al root server, la richiesta viene reindirizzata al mirror più vicino di quel server.

Quali sono i compiti dei root server? Forniscono informazioni sui domini di primo livello. Ogni volta che un name server di livello inferiore non riesce a risolvere una richiesta, questa viene reindirizzata al root server del dominio.

Tuttavia, il root server non conosce effettivamente la posizione del dominio. Reindirizza solo la richiesta che gestirà il dominio di primo livello specificamente richiesto. Ad esempio, se viene effettuata una richiesta per “ blog.cloudsigma.com”, il root server non lo avrà nei suoi record. Cercherà nei suoi file di zona ma non ci sarà alcun record per esso. Invece, riconoscerà il TLD “com” e reindirizzerà l'entità richiedente al nameserver che gestisce gli indirizzi “com”.

• Server TLD

Continuando dal nostro esempio precedente, l'entità richiedente invierà ora la richiesta all'indirizzo IP (fornito dal root server). Nel caso di “ blog.cloudsigma.com”, il name server “com” cercherà i suoi record nei suoi file di zona.

Non ci sarà un record corrispondente alla richiesta. Tuttavia, troverà un record che elenca l'indirizzo IP del nameserver responsabile di “ cloudsigma.com”.

• Nameserver a livello di dominio

Ora, l'entità richiedente ha l'indirizzo IP del nameserver che ospita effettivamente le informazioni su “ blog.cloudsigma.com”. Ora invierà una nuova richiesta al server, chiedendo di risolvere “www.cloudsigma.com”.

Come prima, il nameserver controllerà i suoi file di zona e troverà quello associato a “ cloudsigma.com”. All'interno di questo file risiederà una voce per l'host “www”. Questo record descrive dove si trova l'host. La risposta finale viene quindi trasmessa all'entità richiedente.

• Nameserver di risoluzione

Nell'esempio, abbiamo menzionato un'entità richiedente. Di cosa si tratta? Nella maggior parte dei casi, il richiedente sarà un “nameserver di risoluzione”. Si tratta di un server configurato per porre domande ad altri server. Funge da server intermediario per gli utenti. Memorizza i risultati nella cache per migliorare la velocità.

Qualsiasi utente avrà solitamente un paio di nameserver di risoluzione configurati sul proprio sistema. In genere, i nameserver di risoluzione sono offerti dall'ISP o da altre organizzazioni. Ad esempio, Google offre server DNS di risoluzione pubblici da interrogare. Puoi configurarlo manualmente sul tuo sistema.

Quando si inserisce un URL nel browser web, questo cerca la posizione della risorsa. Innanzitutto, la ricerca viene eseguita localmente. Ciò include il file “hosts” (e alcune altre posizioni). Se non viene trovata, la richiesta viene inviata al nameserver di risoluzione. Dopo aver ricevuto la richiesta, il nameserver di risoluzione cerca la risposta nella sua cache. Se non viene trovata, segue i passaggi menzionati in precedenza.

I nameserver di risoluzione semplificano il processo di richiesta per l'utente finale. Il client deve solo chiedere ai nameserver di risoluzione la posizione di una risorsa. Il nameserver indagherà e restituirà la risposta finale.

• File di zona

Abbiamo già discusso i concetti di “file di zona” e “record”. Ebbene, come funzionano?

I file di zona fungono da database per i nameserver, memorizzando le informazioni sui domini di cui sono a conoscenza. Tutti i domini di cui un nameserver è a conoscenza saranno memorizzati nel suo file di zona. Tuttavia, la maggior parte delle richieste che arrivano a un nameserver non vengono risolte dal file di zona. Se la configurazione del server è tale da gestire query ricorsive (nameserver di risoluzione, ad esempio), allora restituirà la risposta. Altrimenti, reindirizzerà la parte richiedente verso un altro luogo in cui cercare.

Più file di zona ospita un nameserver, più autorevoli saranno le sue risposte. I file di zona descrivono una “zona” DNS (un sottoinsieme dell'intero sistema di denominazione DNS). In genere, un file di zona contiene i dati di configurazione di un solo dominio. Può contenere numerosi record che definiscono la posizione delle risorse del dominio in questione.

Il $ORIGIN parametro di una zona è uguale al livello più alto di autorità della zona. Ad esempio, un file di zona per “ cloudsigma.com” avrà il suo $ORIGIN come “ cloudsigma.com”. Il valore del parametro può essere memorizzato all'inizio del file di zona o nella configurazione del server DNS. In entrambi i casi, il parametro descrive per quale zona il file è autorevole.

Il $TTL imposta le informazioni sul “time to live” (tempo di vita) del risultato fornito. Può essere descritto come un timer che un server di caching può utilizzare per tenere traccia della validità delle risposte memorizzate nella cache. Se il valore TTL scade, la risposta non è più valida e viene scartata.

• Tipi di record

I file di zona sono costituiti da numerosi record. Esistono diversi tipi di record. Di seguito esamineremo alcuni dei tipi di record più comuni (e obbligatori):

Record SOA

Il record Start of Authority (in breve, SOA) è obbligatorio in tutti i file di zona. Deve essere il primo record reale nel file. Tuttavia, voci come $ORIGIN o $TTL possono apparire in precedenza.

Il record SOA è uno dei tipi di record più complessi. La sua struttura si presenta all'incirca così:

Analizziamolo nel dettaglio:

• • example.com: Questa parte definisce la radice della zona. In questo esempio, il file di zona è per il dominio “ example.com”. A volte, il valore può essere sostituito con @ (un segnaposto per sostituire il valore di $ORIGIN).

  • IN SOA: Il termine “IN” significa “internet”. Lo troverai in molti record. Il termine “SOA” indica che si tratta di un record SOA.

  • ns1.example.com: Questo valore contiene il nameserver primario per il dominio “ example.com”. I nameserver possono essere primari o secondari. Se è stato configurato con DNS dinamico, deve esserci un server “primario”. Se non è stato configurato alcun DNS dinamico, sarà uno dei nameserver primari.

  • admin.example.com: Qui va l'indirizzo email dell'amministratore della zona. Nota che la @ viene sostituita con . qui. Se l'indirizzo email originale contiene un punto, questo viene sostituito con un \. Ad esempio, “ my.domain@example.com” diventerebbe “ my\domain.example.com”.

  • 12083: È il numero di serie del file di zona. Ogni volta che il file di zona viene modificato, il numero deve essere aggiornato affinché il file si propaghi correttamente. I server secondari utilizzano questo numero di serie per verificare se i propri file di zona sono aggiornati.

  • 3h: Rappresenta l'intervallo di aggiornamento per la zona. I server secondari attenderanno questo periodo di tempo prima di verificare la presenza di aggiornamenti del file di zona.

  • 30m: Questo valore rappresenta l'intervallo di tentativo della zona. Se un server secondario non riesce a connettersi al server primario una volta scaduto il periodo di aggiornamento, attenderà questo periodo di tempo prima di interrogare nuovamente il primario.

  • 3w: Questo valore rappresenta il periodo di scadenza. Se un server secondario non riesce a connettersi al server primario per questo periodo di tempo, smetterà di restituire risposte come “autorevole”.

  • 1h: Questo valore rappresenta il periodo di tempo per cui il nameserver memorizzerà nella cache un errore di nome se questo non è stato trovato nel suo file di zona.

Record A e AAAA

Questi record stabiliscono una mappatura tra un host e un indirizzo IP. Qui, il record “A” indica la mappatura IPv4 verso l'host e AAAA la mappatura IPv6.

Questa è la struttura fondamentale dei record A e AAAA:

Nell'esempio del record SOA, abbiamo chiamato il nameserver “ ns1.exampel.com”. Il nameserver rientra nel dominio “ example.com”. Ecco come si presenterebbe il suo record A:

Notate che non abbiamo dovuto fornire il nome completo. Con il solo hostname (senza l’FQDN), il server DNS può completare il resto con il valore di $ORIGIN. Tuttavia, possiamo ancora utilizzare l’FQDN:

Ecco come definire il server web come “www”:

Dovremmo anche includere la mappatura al dominio di base. La voce sarebbe simile a questa:

In alternativa, possiamo usare il @ simbolo per indicare il dominio di base (invece del suo nome completo):

È buona norma includere una voce jolly (wildcard) che consenta di risolvere qualsiasi cosa sotto questo dominio che non sia stata definita esplicitamente:

La stessa struttura si applica ai record AAAA. L’unica differenza sono gli indirizzi IPv6.

Record CNAME

I record CNAME fungono da alias per il nome canonico del server (definito da un record A o AAAA). Date un’occhiata al seguente esempio:

Qui abbiamo usato “server1” come alias per definire il nome “www”. Si noti che tali scorciatoie comportano costi in termini di prestazioni, poiché il server deve eseguire query aggiuntive per ottenere la risposta finale. A seconda del numero di livelli di alias, ciò può facilmente causare un notevole costo in termini di prestazioni. Tuttavia, c’è un caso specifico che trae vantaggio dall’aliasing CNAME, ad esempio la fornitura di una risorsa al di fuori della zona corrente.

Record MX

I record MX definiscono i server di posta (mail exchange) per il dominio. Aiutano l’e-mail ad arrivare correttamente al server. A differenza di altri record, i record MX non mappano un host a qualcosa, poiché sono applicabili all’intera zona. Questo è il motivo per cui i record MX si presentano in questo modo:

Notate che non c’è alcun hostname all’inizio della voce. Noterete anche che c’è un valore aggiuntivo nella riga. Si tratta del numero di preferenza che aiuta a decidere a quale server inviare la posta (se sono definiti più server di posta). Più basso è il numero, maggiore è la priorità.

Un record MX dovrebbe puntare a un host definito da un record A o AAAA (non da un CNAME). Tenendo presente questo, se sono configurati due server di posta, i record si presenteranno così:

In questo esempio, a giudicare dal numero di preferenza, “mail1” è il server preferibile rispetto a “mail2”. Possiamo abbreviare ulteriormente il codice omettendo il nome di dominio completo:

Record NS

Questi record definiscono i nameserver per la zona specifica. Ora, la domanda ovvia è: se il file di zona risiede all’interno del nameserver, perché richiede un riferimento a se stesso? Una risposta alla domanda risiede nei molteplici meccanismi di caching del sistema DNS. Il file di zona potrebbe in realtà essere una copia memorizzata nella cache su altri server.

Similmente ai record MX, i record NS si applicano all’intera zona. Pertanto, non hanno alcun host specifico per impostazione predefinita. Le voci dei record NS si presenteranno in questo modo:

Si raccomanda di definire due nameserver nel caso in cui uno di essi non funzioni correttamente. Inoltre, la maggior parte dei server DNS rifiuterà un file di zona se contiene un solo nameserver.

Dovreste anche includere la mappatura degli host con record A o AAAA:

Record PTR

I record PTR sono l'inverso di un classico record A o AAAA. Questi record vengono utilizzati per definire un nome associato a un indirizzo IP. Questi record hanno una proprietà unica in quanto iniziano alla .arpa root e rappresentano il proprietario dell'indirizzo IP. Sono i RIR (Regional Internet Registries) a distribuire gli indirizzi IP a organizzazioni e fornitori di servizi. I RIR includono APNIC, AFRINIC, LACNIC, RIPE NCC e ARIN.

Ad esempio, un record PTR per 111.222.333.444 apparirebbe in questo modo:

Nel prossimo esempio di record PTR, diamo un'occhiata al server DNS IPv6 di Google 2001:4860:4860::8888:

Possiamo usare lo strumento dig con il flag -x per cercare il nome DNS inverso di un indirizzo IP. Ad esempio, controlla l'indirizzo IP DNS inverso di 8.8.4.4:

I server Internet utilizzano i record PTR per tenere traccia dei nomi di dominio nelle voci di registro, prendere decisioni informate sulla gestione dello spam e mostrare informazioni facili da leggere su altri dispositivi.

I server di posta elettronica comunemente usati cercheranno il record PTR dell'indirizzo IP da cui è stata inviata l'e-mail. Se il record PTR è vuoto, c'è un'alta probabilità che l'e-mail sia spam (quindi rifiutata). Nota che la corrispondenza tra l'FQDN e il nome di dominio del record PTR non è il problema principale. Il fattore importante è se un record PTR valido è associato a un record A diretto corrispondente.

In genere, i router di rete su Internet hanno record PTR corrispondenti alla loro posizione fisica. Ad esempio, “NYC” o “CHI” sono riferimenti validi per i router situati a New York e Chicago. Questa tecnica è utile quando si esegue un traceroute o un MTR e si esamina il percorso seguito dai pacchetti.

Record CAA

Questi record specificano le CA (Certificate Authorities) che possono emettere certificati SSL/TLS per il tuo dominio. Dall'8 settembre 2017, tutte le CA sono tenute a controllare i record CAA prima di emettere un certificato. Se non esiste alcun record CAA, qualsiasi CA può emettere un certificato. In caso contrario, solo CA specifiche sono autorizzate a emettere certificati. I record CAA possono essere applicati a singoli host o a un intero dominio.

Ecco un esempio di record CAA:

La parte specifica del CAA della voce è 0 issue "letsencrypt.org". Ci sono tre parti coinvolte in questa sezione:

• Flag: è un valore intero che indica come una CA dovrebbe gestire i tag che non comprende. Se il valore del flag è impostato su 0, il record verrà ignorato. Se il valore è 1, la CA deve rifiutarsi di emettere il certificato.
• Tag: queste sono stringhe che indicano lo scopo di un record CAA. Al momento, i valori validi includono issue (che autorizza una CA a emettere certificati per un dominio specifico), issuewild (che autorizza certificati wildcard) e iodef (che definisce un URL in cui le CA segnalano le violazioni delle policy).
• Valori: queste sono stringhe associate al tag del record. Se il tag è issue o issuewild, il valore sarà solitamente il dominio della CA a cui stai concedendo l'autorizzazione. Se il tag è iodef, sarà l'URL di un modulo di contatto o un link mailto: per il feedback via e-mail.

Possiamo usare lo strumento dig per recuperare i record CAA:

Per informazioni più approfondite sui record CAA, consulta RFC 6844.

Considerazioni finali

Questa guida descrive varie terminologie relative al DNS. Descrive inoltre come tutti i componenti si integrano tra loro. Con questa panoramica approfondita, dovresti avere una buona comprensione del funzionamento del sistema DNS. Sebbene l'idea generale sia semplice e facile da capire, le complessità diventano intricate molto rapidamente. Per gli amministratori inesperti, può essere difficile applicare questi concetti e strategie.

Sei un cliente CloudSigma? Allora dai un'occhiata a gestione e aggiornamento dei record DNS inversi/PTR per la tua infrastruttura CloudSigma.

Buon computing!