Cos'è il DNS: guida per chi gestisce un VPS

Che cos'è il DNS e perché il tuo dominio non raggiunge ancora il VPS

Il DNS (domain name system) converte un nome come example.com in un indirizzo IP (internet protocol) come 203.0.113.10. Un browser non può connettersi a un nome. Si connette a un indirizzo, quindi ogni caricamento di pagina inizia con una richiesta DNS e una risposta. Se hai appena acquistato un dominio e un VPS di tua proprietà e non viene caricato nulla, è vera una di queste due condizioni: non esiste ancora alcun record che associ il nome all'indirizzo del server oppure il record esiste, ma un componente del percorso sta ancora fornendo una risposta precedente.

Entrambe le situazioni sono normali e nessuna indica un problema. Le sezioni seguenti affrontano gli aspetti nell'ordine in cui li incontrerai, partendo da quello che fa perdere più tempo: quale pannello di controllo gestisce effettivamente i tuoi record.

Per tutti i controlli descritti qui viene usato dig, che non è installato per impostazione predefinita su una macchina Ubuntu o Debian appena installata.

sudo apt update && sudo apt install -y bind9-dnsutils

Registrar, nameserver e host DNS: quale devi modificare

Questi tre termini indicano ruoli diversi. Confonderli è il motivo più comune per cui una modifica non produce alcun effetto.

• Il registrar è la società presso cui hai acquistato il dominio. Il suo compito principale è la delega: comunica al registry che gestisce il tuo TLD (dominio di primo livello, la parte .com) quali nameserver sono autorevoli per il dominio.
• I nameserver autorevoli contengono i record effettivi della tua zona. Una zona comprende il dominio e i relativi nomi.
• Il DNS host è il soggetto che gestisce questi nameserver. Può essere il registrar, un provider separato oppure bind9 in esecuzione su un server di tua proprietà.

Acquisti il dominio presso il registrar. Modifichi i record presso il DNS host. Se hai spostato il dominio sui nameserver di un altro provider, il pannello DNS del registrar continua a mostrarti una zona, continua a salvare le modifiche e nessuno su Internet interroga mai quella zona. I record esistono. Semplicemente, non vengono mai consultati.

Verifica quale zona viene interrogata:

dig example.com NS +short
dig +trace example.com

Il primo comando mostra i nameserver che rispondono oggi per il dominio. Il secondo segue la catena a partire dai root server e mostra la delega restituita dai server del TLD, cioè la delega controllata dal registrar. Se quei nomi appartengono a un provider che non riconosci, è il pannello di quel provider che devi utilizzare.

Come viaggia una singola richiesta

Sono coinvolti quattro soggetti e ciascuno conserva una copia delle informazioni apprese.

1. Lo stub resolver del computer. Non esegue ricerche. Interroga un solo server configurato e considera valida la risposta ricevuta. Su Ubuntu, /etc/resolv.conf è in genere un collegamento simbolico a /run/systemd/resolve/stub-resolv.conf e indica 127.0.0.53, cioè systemd-resolved in esecuzione localmente con una propria cache.
2. Il resolver ricorsivo. È il resolver gestito dal proprio ISP (provider di servizi Internet), da un servizio pubblico come 1.1.1.1 oppure da un resolver gestito autonomamente. Esegue il lavoro effettivo di ricerca della risposta.
3. I server root e TLD. Il resolver ricorsivo interroga un server root, che non conosce il vostro indirizzo ma risponde indicando i server .com. Questi rispondono indicando i vostri nameserver.
4. Il nameserver autoritativo. Non interroga altri server. Risponde utilizzando la propria zona e contrassegna la risposta come autoritativa.

dig +trace example.com mostra questo processo perché parte direttamente dal root e stampa ogni referral invece di interrogare una cache. È il modo più rapido per verificare se la delega e la zona sono coerenti.

I record DNS importanti quando si esegue un server

• A: associa un nome a un indirizzo IPv4. example.com. A 203.0.113.10. Questo è il record che indirizza il dominio al VPS.
• AAAA: associa un nome a un indirizzo IPv6, ad esempio 2001:db8::10. Pubblicarlo solo quando il servizio è effettivamente in ascolto su quell'indirizzo. I client sulle reti IPv6 provano prima la risposta AAAA, quindi un indirizzo su cui non risponde alcun servizio aggiunge un ritardo a ogni accesso.
• CNAME: è un alias da un nome a un altro nome. www.example.com. CNAME example.com. invia i visitatori di www alla destinazione risolta dal dominio principale. Un CNAME non può essere usato all'apice (il example.com senza sottodominio), perché l'apice deve contenere i propri record SOA (start of authority) e NS, mentre un CNAME non può condividere il nome con altri record. I provider offrono soluzioni alternative con nomi come ALIAS, ANAME o CNAME flattening.
• MX: indica dove viene consegnata la posta del dominio. Contiene un hostname e un numero di preferenza; viene provato per primo il numero più basso. Un MX deve puntare a un nome che dispone di un record di indirizzo. Puntare a un CNAME non è valido e alcuni server di invio rifiutano questa configurazione.
• TXT: testo libero, usato per verifiche e criteri. Qui vengono pubblicati i record di autenticazione della posta (SPF, DKIM, DMARC), oltre al token ACME (automatic certificate management environment) che consente di emettere un certificato wildcard.
• NS: indica quali nameserver servono la zona. La copia che stabilisce dove il resto di Internet invia le richieste si trova nella zona padre e deriva dalla delega del registrar, non dalla copia contenuta nella zona gestita autonomamente.

Due dettagli causano più confusione dei tipi di record stessi. Un nome che termina con un punto è assoluto, quindi www.example.com. indica esattamente quel nome e nient'altro. La maggior parte dei pannelli prevede un nome relativo e aggiunge automaticamente il dominio. Di conseguenza, inserendo www.example.com nel campo del nome si ottiene www.example.com.example.com, che non viene risolto da alcun client. L'altro dettaglio è @, che in quasi tutti i pannelli indica l'apice: il dominio senza sottodominio.

Indicare un record A verso il VPS

Per prima cosa recupera l'indirizzo che Internet vede per il server:

curl -4 https://ifconfig.me
ip -brief -4 address show

Quindi crea un record presso il tuo provider DNS: tipo A, nome @, valore uguale a quell'indirizzo, TTL (time to live) 300. Aggiungi un secondo record per www: può essere un altro A con lo stesso indirizzo oppure un CNAME che punti al dominio apex.

Ora verifica che la risoluzione funzioni, preferibilmente dal laptop e non direttamente dal server:

dig example.com A +short
dig @1.1.1.1 example.com A +short
dig @ns1.your-dns-host.net example.com A +short

Il primo comando usa il normale percorso di rete della macchina, cache inclusa. Il secondo ignora la cache locale e interroga un resolver ricorsivo pubblico. Il terzo interroga direttamente il nameserver autoritativo, quindi restituisce il dato corrente senza cache lungo il percorso. Se il terzo comando restituisce il tuo indirizzo e il primo no, la configurazione DNS è corretta e devi solo attendere che scada una copia in cache della risposta precedente.

La risoluzione del nome non funziona

Una risoluzione del nome dimostra che il DNS funziona. Non dimostra nulla sul server web. Quando dig restituisce l'indirizzo corretto, verifica la connessione:

curl -I http://example.com

curl: (6) Could not resolve host: example.com è un problema DNS. curl: (7) Failed to connect to example.com port 80 after 21 ms: Connection refused non è un problema DNS: il nome è stato risolto e il pacchetto è arrivato, quindi il problema è che nessun processo era in ascolto su quella porta. Una richiesta che resta in attesa e poi va in timeout indica generalmente che un firewall ha scartato il pacchetto in modo silenzioso, invece di rifiutarlo. A questo punto il DNS non è più il problema: entrano in gioco le porte e i socket in ascolto e le regole del firewall ufw sul VPS. Quando la connessione è completata, il caricamento della pagina prosegue tramite il funzionamento di HTTP.

Perché il browser mostra ancora il vecchio host

Non viene propagato nulla. Nessun server invia la modifica agli altri sistemi. Il nameserver autorevole contiene il nuovo valore nel momento in cui lo salvi, mentre ogni copia memorizzata della risposta precedente resta valida fino alla scadenza del relativo timer. Quel timer è il TTL, espresso in secondi, associato al record quando viene restituito.

Le copie vengono mantenute in più punti di quanto si pensi: nella cache breve del browser, nello stub resolver del computer, nel resolver ricorsivo usato dalla rete e in eventuali resolver installati da una VPN sul client. Ognuno conserva la propria copia per un periodo massimo pari al TTL ricevuto. Due persone su due reti diverse possono visualizzare risposte diverse per ore, e in entrambi i casi i computer funzionano correttamente.

Monitora il conto alla rovescia tramite un resolver con caching:

dig @1.1.1.1 example.com +noall +answer

Eseguilo due volte, a distanza di pochi secondi. Il TTL nella risposta diminuisce. Quando raggiunge zero, il resolver elimina il record e interroga nuovamente il tuo nameserver.

Esiste una seconda cache che quasi nessuno considera: le risposte negative. Quando un resolver riceve l'informazione che un nome non esiste, memorizza anche quell'NXDOMAIN per il periodo definito dall'ultimo campo del record SOA della zona.

dig example.com SOA +short

L'ultimo numero di quella riga è il TTL negativo, spesso 3600. Di conseguenza, cercare staging.example.com prima di crearlo può impedirti di vedere il record per un'ora intera dopo la sua creazione. Crea prima il record, quindi interrogalo.

Cambiare i nameserver è più lento che modificare un record, per un motivo tecnico preciso. I record di delega nella zona .com vengono distribuiti con un TTL di 172800 secondi, cioè due giorni. Per questo, un resolver che ha memorizzato i vecchi nameserver può continuare a interrogarli per quel periodo. Da qui deriva il consiglio di "attendere fino a 48 ore". Si applica alle modifiche dei nameserver, non alle normali modifiche dei record.

Pianifica una migrazione in base al TTL, invece di cercare di aggirarlo:

1. Riduci il TTL del record a 300 e salvalo.
2. Attendi più del vecchio TTL, in modo che ogni copia memorizzata con il vecchio valore sia scaduta.
3. Modifica l'indirizzo.
4. Dopo lo spostamento del traffico, aumenta nuovamente il TTL a 3600 o a un valore superiore, perché un TTL basso impone a ogni resolver di interrogare i tuoi nameserver molto più spesso.

Per eliminare i dati conservati dal computer:

resolvectl flush-caches
resolvectl statistics

resolvectl statistics visualizza una sezione relativa alla cache con i contatori degli hit e dei miss. Subito dopo il flush, quindi, la query successiva viene registrata come miss. I browser mantengono una cache separata: Chrome può quindi continuare a usare una risposta precedente anche dopo lo svuotamento della cache di sistema. Svuota anche quella in chrome://net-internals/#dns. Controlla anche /etc/hosts, perché una riga residua in quel file ha precedenza sul DNS su quel computer e solo su quel computer. getent hosts example.com mostra la risposta che il sistema utilizzerà effettivamente, incluso /etc/hosts.

I certificati wildcard vengono convalidati tramite un record TXT

Una CA (certificate authority) verifica il controllo su un nome prima di rilasciare un certificato. La challenge HTTP-01 pubblica un file sulla porta 80 per quell'hostname esatto, una procedura adatta a un singolo nome. Un certificato wildcard copre *.example.com, cioè un insieme aperto di hostname dal quale la CA non può recuperare un file. Per questo Let's Encrypt rilascia i certificati wildcard soltanto tramite la challenge DNS-01. Devi pubblicare un record TXT all'indirizzo _acme-challenge.example.com, contenente un token fornito dalla CA. Il controllo della zona DNS costituisce la prova.

Questo rende il provider DNS parte del rinnovo del certificato. A ogni rinnovo, Certbot deve creare ed eliminare automaticamente quel record TXT. Per farlo, ha bisogno di un'API e del plugin corrispondente per il provider. Quando la convalida non riesce, il messaggio usuale è DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com. Significa che la CA ha eseguito la verifica prima che il record fosse visibile: il record non è mai stato salvato oppure una risposta negativa era ancora memorizzata nella cache. La procedura completa è disponibile nella guida ai certificati wildcard con la challenge DNS-01.

Quando una VPN prende il controllo del resolver

Un client VPN (virtual private network) sostituisce normalmente il resolver di sistema mentre è connesso, perché inviare le richieste al resolver della rete locale rivelerebbe a quella rete il nome di ogni sito visitato. Questo comportamento è corretto, ma può fallire in due modi.

Se il tunnel viene stabilito e i nomi non vengono più risolti mentre gli indirizzi continuano a funzionare, il resolver installato dal client non è raggiungibile dall'interno del tunnel. ping 1.1.1.1 ha esito positivo e curl https://example.com restituisce curl: (6) Could not resolve host: example.com. Se invece il tunnel viene stabilito e le richieste continuano a essere inviate alla rete a cui si è connessi, il traffico passa nel tunnel mentre il resolver locale continua a vedere ogni nome richiesto.

resolvectl status

Il comando mostra il resolver utilizzato per ogni collegamento. In questo modo è possibile verificare quale resolver ha installato il tunnel e se corrisponde a quello previsto. Un tunnel WireGuard imposta questo valore tramite la direttiva DNS = nella configurazione del client. La guida correggere il DNS quando WireGuard prende il controllo del resolver descrive in dettaglio i casi relativi a systemd-resolved e resolvconf.

I codici di risposta e le informazioni che forniscono

• NXDOMAIN: un server autorevole indica che il nome non esiste. Controlla l’ortografia, verifica che il suffisso del dominio non sia duplicato e assicurati di aver modificato la zona a cui punta la delega.
• NOERROR con un ANSWER SECTION vuoto: il nome esiste, ma non contiene un record del tipo richiesto. Una richiesta di AAAA quando esiste soltanto un A produce esattamente questo risultato.
• SERVFAIL: il resolver ha effettuato il tentativo, ma non è riuscito a produrre una risposta. Le due cause più comuni sono server autorevoli che non rispondono mai e un errore nella convalida DNSSEC (domain name system security extensions). Esegui il test con dig @1.1.1.1 example.com A +cd, che disabilita la convalida. Se senza questa opzione ottieni +cd e SERVFAIL, il problema riguarda le firme. Questo accade dopo lo spostamento di un nameserver, quando il parent pubblica ancora il record DS (delegation signer) precedente.
• REFUSED: il server interrogato non risponderà a questa domanda, in genere perché hai puntato dig a un server autorevole per un dominio che non gestisce.
• ;; connection timed out; no servers could be reached: dig non ha raggiunto alcun resolver. Si tratta di un problema di rete o del resolver locale, quindi il dominio non è la causa.

ping: example.com: Temporary failure in name resolution è la stessa classe di errore segnalata da glibc anziché da dig.

Eseguire i nameserver sul proprio VPS?

È possibile. bind9, knot o nsd possono servire la zona dal server e permettono di approfondire il funzionamento del DNS più di qualsiasi pannello. Le criticità sono pratiche. Un dominio dovrebbe avere almeno due nameserver su reti separate. Un singolo VPS diventerebbe quindi un punto singolo di guasto per tutti i servizi del dominio, posta inclusa. I nameserver il cui nome appartiene al dominio che servono richiedono glue record presso il registrar. Il glue record contiene l'indirizzo di ns1.example.com memorizzato nella zona padre. Senza questo dato, la risoluzione non può iniziare. Se un resolver non riesce a raggiungere il nameserver, non ripiega sul sito web. Per quell'utente, l'intero dominio risulta irraggiungibile. Per la maggior parte degli utenti, il DNS gestito con API è la scelta a rischio minore. Eseguire un resolver di caching sul VPS per le proprie macchine è un'attività diversa e richiede un impegno molto più contenuto.

FAQ

Perché la modifica DNS non è ancora stata propagata?

Non c'è nulla da propagare. I nameserver autorevoli contengono il nuovo valore nel momento in cui lo salvi e ogni resolver che lo ha già richiesto conserva la propria copia nella cache fino alla scadenza del TTL ricevuto. Interroga direttamente il server autorevole con dig @ns1.your-dns-host.net example.com A +short. Se restituisce il nuovo indirizzo, la modifica è attiva e il ritardo restante dipende solo dalla cache. Se hai modificato i nameserver invece dei record, il completamento richiede molto più tempo, perché le deleghe TLD vengono distribuite con un TTL di due giorni.

Come posso verificare quali nameserver utilizza effettivamente il mio dominio?

dig example.com NS +short mostra i nameserver che rispondono ora per il dominio, mentre dig +trace example.com mostra la catena di referral dalla root, inclusa la delega fornita dai server TLD. Se quei nomi non appartengono al provider il cui pannello hai modificato, questo è il problema. Modifica i record presso il provider indicato nella delega oppure cambia la delega presso il registrar, in modo che punti alla destinazione desiderata.

Il dominio viene risolto, ma il sito continua a non caricarsi. Cosa devo fare?

Il DNS è configurato correttamente non appena dig example.com A +short restituisce l'indirizzo del server. Da quel momento il problema riguarda la connessione. Se curl -I http://example.com restituisce Connection refused, significa che nessun processo è in ascolto su quella porta. Una richiesta che rimane in attesa fino al timeout indica che un firewall ha scartato il pacchetto. Verifica che il web server sia in esecuzione e associato all'indirizzo pubblico, quindi controlla il firewall del server e il firewall di rete separato disponibile nel pannello di controllo del provider.

Perché non posso inserire un CNAME nel dominio root?

Un CNAME indica che un nome è un alias di un altro nome e un nome che ha un CNAME non può contenere altri record. Il dominio root deve contenere record SOA e NS per poter esistere come zona, quindi non può essere anche un CNAME. Usa un record A che contenga l'indirizzo nella root oppure usa la funzionalità del provider commercializzata come ALIAS, ANAME o CNAME flattening. Questa funzionalità memorizza un nome e risponde alle query con l'indirizzo attualmente associato a quel nome.