Indirizzi IP e Domain Name System

Indirizzi IP e DNS

Una risoluzione DNS: il resolver ricorsivo interroga a turno la radice, il dominio di primo livello e il server autorevole, poi tiene la risposta in cache.

Indirizzo IP Numero che identifica un’interfaccia di rete e permette di instradarle i pacchetti
IPv4 32 bit, scritti come quattro numeri decimali: 172.67.204.67
IPv6 128 bit, scritti come otto gruppi esadecimali: 2606:4700:3031::ac43:cc43
DNS Database distribuito che traduce i nomi in indirizzi e altri dati
DNS definito in RFC 1034 e RFC 1035 (1987)
Trasporto del DNS UDP e TCP porta 53; DoT (853), DoH (443)
Record più comuni A, AAAA, CNAME, MX, TXT, NS, SOA, HTTPS
Estensione di sicurezza DNSSEC (DNSKEY, RRSIG, DS)
Strumenti tipici dig, getent, resolvectl, curl -4 / curl -6

Indirizzo IP	Numero che identifica un’interfaccia di rete e permette di instradarle i pacchetti
IPv4	32 bit, scritti come quattro numeri decimali: `172.67.204.67`
IPv6	128 bit, scritti come otto gruppi esadecimali: `2606:4700:3031::ac43:cc43`
DNS	Database distribuito che traduce i nomi in indirizzi e altri dati
DNS definito in	RFC 1034 e RFC 1035 (1987)
Trasporto del DNS	UDP e TCP porta 53; DoT (853), DoH (443)
Record più comuni	A, AAAA, CNAME, MX, TXT, NS, SOA, HTTPS
Estensione di sicurezza	DNSSEC (DNSKEY, RRSIG, DS)
Strumenti tipici	`dig`, `getent`, `resolvectl`, `curl -4` / `curl -6`

Un indirizzo IP è il numero che identifica l’interfaccia di rete di un dispositivo su Internet e permette ai pacchetti di dati di raggiungerlo. Il Domain Name System (DNS) è il database distribuito che traduce i nomi facili da ricordare, come wiki.daniellomario.com, in indirizzi IP, e che conserva anche altre informazioni su un dominio, per esempio quali server ricevono la sua posta.

I due sono complementari: gli indirizzi IP sono ciò che la rete usa davvero, e il DNS è lo strato che permette a persone e programmi di ignorarli. Quando qualcosa “non si carica”, la causa è molto spesso in uno dei due: un nome che risolve all’indirizzo sbagliato, un indirizzo che non risponde più, oppure una rete che supporta solo una delle due versioni di IP. Questa voce spiega come funzionano entrambi, usando come esempio la configurazione reale del dominio di questa wiki.

Indirizzi IP

L’Internet Protocol (IP) trasporta i dati in unità indipendenti chiamate pacchetti. Ogni pacchetto porta un indirizzo di origine e uno di destinazione, e ogni router lungo il percorso guarda solo la destinazione per decidere dove inoltrarlo. Un indirizzo IP ha quindi lo stesso ruolo di un indirizzo postale: dice dove qualcosa deve arrivare, non che cosa contiene.

Un indirizzo identifica un’interfaccia di rete, non un computer: un portatile con Wi-Fi e VPN ha un indirizzo diverso su ciascuna interfaccia. Identifica anche una posizione nella rete, ed è per questo che cambia quando lo stesso dispositivo passa dal Wi-Fi di casa ai dati mobili.

Oggi si usano fianco a fianco due versioni: IPv4, del 1981,¹ e IPv6, progettata negli anni Novanta per risolvere la scarsità di indirizzi IPv4.

IPv4

Un indirizzo IPv4 è un numero di 32 bit. Per renderlo leggibile lo si divide in quattro gruppi da 8 bit, chiamati ottetti, e ogni ottetto si scrive come numero decimale da 0 a 255, separando i gruppi con un punto (notazione decimale puntata):

172.67.204.67  =  10101100 . 01000011 . 11001100 . 01000011

Con 32 bit ci sono

2^{32} = 4294967296

indirizzi possibili, circa 4,3 miliardi: meno delle persone sulla Terra, e molti meno dei dispositivi connessi. Il registro centrale, IANA, ha assegnato gli ultimi blocchi liberi il 3 febbraio 2011,² e i registri regionali li hanno esauriti negli anni successivi (quello europeo, RIPE NCC, il 25 novembre 2019).³ Da allora gli indirizzi IPv4 si riusano, si condividono con il NAT e si comprano e vendono.

Classi di indirizzi

Nel progetto originale un indirizzo era diviso in una parte di rete, che identifica la rete, e una parte host, che identifica l’interfaccia dentro quella rete. Il punto di separazione era codificato nei primi bit dell’indirizzo, che ne definivano la classe:¹

Anatomia di un indirizzo di classe B
Figura 1. L’indirizzo 172.67.204.67 in decimale e in binario. I suoi primi due bit sono 10, quindi nel sistema delle classi è un indirizzo di classe B: 16 bit di rete e 16 bit di host. Sotto, le classi come intervalli del primo ottetto.

Classe	Primi bit	Primo ottetto	Bit di rete / host	Reti	Indirizzi per rete
A	`0`	0–127	8 / 24	128	16 777 216
B	`10`	128–191	16 / 16	16 384	65 536
C	`110`	192–223	24 / 8	2 097 152	256
D	`1110`	224–239	—	—	multicast
E	`1111`	240–255	—	—	riservati

Un indirizzo di classe B ha i primi due bit fissati a 10. Restano 14 bit per numerare le reti ( $2^{14} = 16384$ reti) e 16 bit per gli host ( $2^{16} = 65536$ indirizzi, di cui 65 534 utilizzabili, perché i valori di host tutti zero e tutti uno sono riservati alla rete stessa e al broadcast). Per riconoscere la classe dalla forma decimale basta il primo ottetto: se è tra 128 e 191, l’indirizzo è di classe B. L’indirizzo 172.67.204.67, uno di quelli di questa wiki, è quindi di classe B: $172 = 1010110 0_{2}$ inizia con 10. L’altro indirizzo dello stesso sito, 104.21.74.163, è di classe A, perché $104 = 0110100 0_{2}$ inizia con 0.

Il sistema delle classi sprecava spazio: un’organizzazione che aveva bisogno di 300 indirizzi era troppo grande per una classe C (256) e riceveva una classe B (65 536), lasciandone inutilizzata quasi tutta. Per questo nel 1993 le classi sono state abolite e sostituite dal CIDR.⁴ I nomi sono rimasti nel linguaggio comune, in particolare “rete privata di classe A, B o C” per gli intervalli privati (vedi sotto), ma oggi la classe di un indirizzo non ha alcun significato tecnico: i due indirizzi qui sopra, uno “di classe A” e uno “di classe B”, appartengono alla stessa azienda e si usano esattamente allo stesso modo.

CIDR e maschere di sottorete

Con il CIDR (Classless Inter-Domain Routing)⁵ il confine tra rete e host può cadere dopo un bit qualsiasi, e lo si scrive esplicitamente dopo una barra: la lunghezza del prefisso. Un blocco con prefisso $n$ contiene

N = 2^{32 - n}

indirizzi. La stessa informazione si può scrivere come maschera di sottorete, un numero di 32 bit con $n$ uni seguiti da zeri: /24 corrisponde a 255.255.255.0.

Blocco	Prefisso	Maschera	Indirizzi	Esempio
`172.64.0.0/13`	13	`255.248.0.0`	524 288	un blocco annunciato da Cloudflare, che contiene `172.67.204.67`
`172.67.0.0/16`	16	`255.255.0.0`	65 536	quella che sarebbe stata la vecchia rete di classe B
`192.168.1.0/24`	24	`255.255.255.0`	256	una tipica rete di casa
`104.21.74.163/32`	32	`255.255.255.255`	1	un singolo indirizzo

Il blocco /13 della prima riga è più grande di una classe B e non inizia al confine di una classe: è proprio ciò che le classi non potevano esprimere.

I blocchi di indirizzi sono assegnati alle organizzazioni che gestiscono una propria rete, chiamate sistemi autonomi e identificate da un numero (ASN). Cloudflare, per esempio, è l’AS13335 e l’Internet Archive l’AS7941. I sistemi autonomi si comunicano a vicenda quali blocchi sanno raggiungere con il protocollo BGP, ed è così che un router in Italia sa dove mandare un pacchetto diretto a 104.21.74.163. Siccome l’ASN dice chi gestisce un indirizzo, una regola di firewall può bloccare un’intera organizzazione con il suo numero AS invece che con un elenco di indirizzi.

Intervalli speciali

Alcuni blocchi sono riservati e non compaiono mai come destinazione sull’Internet pubblica:

Blocco	Uso	Dove si incontra
`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`	indirizzi privati⁶	reti di casa e aziendali; spesso chiamate reti private “di classe A, B e C”
`100.64.0.0/10`	spazio condiviso per il NAT degli operatori⁷	reti interne degli operatori; lo usa anche Tailscale (per esempio `100.100.100.100`, il suo resolver DNS)
`127.0.0.0/8`	loopback	`127.0.0.1` è la macchina stessa
`169.254.0.0/16`	link-local⁸	indirizzi automatici in assenza di DHCP; `169.254.169.254` è il servizio di metadati e DNS di molti provider cloud
`192.0.2.0/24`, `198.51.100.0/24`, `203.0.113.0/24`	documentazione⁹	esempi in libri e manuali, come quelli di questa voce

L’intervallo privato 172.16.0.0/12 copre esattamente 16 vecchie reti di classe B, da 172.16.x.x a 172.31.x.x. L’indirizzo 172.67.204.67 ne è fuori, e infatti è pubblico.

Traduzione degli indirizzi (NAT)

Poiché gli indirizzi IPv4 pubblici sono scarsi, una rete di casa riceve di solito un solo indirizzo pubblico, assegnato al router, e i dispositivi interni usano indirizzi privati come 192.168.1.23. Il router fa la traduzione degli indirizzi (NAT, Network Address Translation): riscrive l’indirizzo di origine dei pacchetti in uscita con il proprio e si ricorda a quale dispositivo interno appartiene ogni connessione, per consegnargli le risposte. Da fuori, tutti i dispositivi della casa appaiono come un unico indirizzo. Il NAT ha evitato che IPv4 si esaurisse molto prima, ma rende difficile raggiungere da fuori un dispositivo dentro la rete: è il problema che strumenti come Tailscale e Cloudflare Tunnel aggirano.

IPv6

Un indirizzo IPv6 ha 128 bit,¹⁰ quindi ci sono

2^{128} \approx 3, 4 \times 1 0^{38}

indirizzi, abbastanza da non avere mai bisogno del NAT. Si scrive come otto gruppi da 16 bit in esadecimale, separati da due punti, con due abbreviazioni:¹¹

gli zeri iniziali di ogni gruppo si possono omettere (0db8 → db8);
una sola sequenza di gruppi consecutivi tutti a zero si può sostituire con ::.

2606:4700:3031:0000:0000:0000:ac43:cc43   forma completa
2606:4700:3031::ac43:cc43                 forma compressa

Il :: può comparire una volta sola, altrimenti non si capirebbe quanti gruppi di zeri rappresenta ciascuno. Una curiosità di questo indirizzo in particolare: i suoi ultimi 32 bit, ac43:cc43, sono i byte ac 43 cc 43, cioè 172.67.204.67, l’indirizzo IPv4 dello stesso sito. È una scelta di Cloudflare, non una regola di IPv6.

I principali intervalli IPv6 sono:¹²

Prefisso	Tipo	Esempio
`2000::/3`	unicast globale: indirizzi pubblici	`2606:4700:3031::ac43:cc43` (Cloudflare ha `2606:4700::/32`)
`fc00::/7`	indirizzi locali unici (in pratica `fd00::/8`), l’equivalente IPv6 degli indirizzi privati	Tailscale usa `fd7a:115c:a1e0::/48`
`fe80::/10`	link-local: validi solo sul collegamento locale, ogni interfaccia ne ha uno	`fe80::1c2b:…` sul Wi-Fi
`::1/128`	loopback	la macchina stessa
`2001:db8::/32`	documentazione⁹	esempi

Doppio stack e Happy Eyeballs

Le due versioni non sono compatibili: un dispositivo solo IPv4 non può parlare direttamente con uno solo IPv6. La transizione avviene quindi con il doppio stack (dual stack): reti e server usano entrambe, e un nome può avere sia un indirizzo IPv4 sia uno IPv6. Quando un client li ha tutti e due, l’algoritmo Happy Eyeballs¹³ parte da IPv6 e, se non ottiene una connessione entro un breve ritardo (il valore consigliato è 250 ms), prova in parallelo IPv4, tenendo quello che risponde per primo.

Una rete di casa può non avere affatto IPv6: dipende dall’operatore e dal router, non dal computer, che supporta IPv6 da decenni. Su Linux lo si vede con ip -6 route: se gli unici indirizzi sono fe80:: (link-local) e quelli di una VPN, non c’è una strada verso l’Internet IPv6. In questa situazione i client ricevono comunque dal DNS gli indirizzi IPv6 dei siti, li provano e ripiegano su IPv4. Di solito non costa nulla, ma una rete configurata male, o un browser che prova per primi protocolli più recenti su IPv6, può mostrare ritardi o errori occasionali che con il solo IPv4 non capitano. Il test più rapido è confrontare curl -4 e curl -6 sullo stesso sito.

Anycast

Di solito un indirizzo corrisponde a un solo luogo. Con l’anycast, invece, lo stesso blocco viene annunciato via BGP da molti luoghi contemporaneamente, e ogni pacchetto raggiunge il più vicino. Le reti di distribuzione dei contenuti come Cloudflare funzionano così: a 104.21.74.163 rispondono centinaia di data center, e gli stessi indirizzi servono molti siti diversi, distinti dal nome che il browser richiede. Per questo l’indirizzo IP di un sito dietro una rete simile dice dove si trova la rete, non dove si trova il server del sito.

Domain Name System

Prima del DNS, i nomi delle poche centinaia di macchine di ARPANET erano conservati in un unico file, HOSTS.TXT, gestito centralmente e copiato da tutti. Il file cresceva troppo in fretta per essere gestito così, e nel 1983 Paul Mockapetris propose il Domain Name System,¹⁴ la cui definizione attuale risale al 1987.¹⁵¹⁶ Una traccia del vecchio metodo sopravvive nel file /etc/hosts, che i sistemi leggono ancora prima di chiedere al DNS.

Nomi e gerarchia

Un nome di dominio è una sequenza di etichette separate da punti, che si leggono da destra a sinistra, dalla più generale alla più specifica:

wiki . daniellomario . com . (radice)

la radice è l’etichetta vuota all’estrema destra; la forma completa di un nome termina con un punto: wiki.daniellomario.com.;
com è un dominio di primo livello (TLD, top-level domain); altri sono it, org o dev;
daniellomario è il dominio di secondo livello, la parte che si registra;
wiki è un sottodominio, che il proprietario può creare liberamente.

Ogni etichetta può essere lunga fino a 63 caratteri. L’albero è diviso in zone, parti gestite da organizzazioni diverse. La zona radice delega com ai server dell’azienda che lo gestisce, e com delega daniellomario.com ai server scelti dal suo proprietario. La delega è il motivo per cui il DNS scala: nessun server sa tutto, ma ogni server sa a chi chiedere.

Qui entrano in gioco due ruoli che si confondono spesso:

il registrar è l’azienda presso cui si compra e si rinnova il dominio; scrive nella zona del TLD quali name server sono responsabili del dominio;
il provider DNS gestisce quei name server e conserva i record veri e propri.

Possono essere la stessa azienda o due diverse. Spostare un dominio da un provider DNS a un altro significa cambiare i name server presso il registrar; l’esempio più sotto mostra che cosa può succedere nel frattempo.

Risoluzione

Alla traduzione di un nome in un indirizzo partecipano tre tipi di software:

lo stub resolver, dentro il sistema operativo del dispositivo (su Linux, per esempio, systemd-resolved), che non risolve nulla da sé ma inoltra la domanda;
il resolver ricorsivo, che fa il lavoro vero e tiene una cache: quello dell’operatore o del router, oppure uno pubblico come 1.1.1.1 (Cloudflare) o 8.8.8.8 (Google);
i server autorevoli, che conservano i record di una zona e rispondono solo per quella.

Partendo da una cache vuota, i passi sono quelli della figura nell’infobox:

il dispositivo chiede al resolver ricorsivo l’indirizzo di wiki.daniellomario.com;
il resolver chiede a un server radice, che non conosce la risposta ma risponde con i server di com;
chiede a un server di com, che risponde con i server di daniellomario.com (qui albert.ns.cloudflare.com e kayleigh.ns.cloudflare.com);
chiede a uno di questi server autorevoli, che finalmente risponde con l’indirizzo;
il resolver restituisce l’indirizzo al dispositivo e tiene ogni risposta in cache.

Le identità dei server radice sono 13, chiamate da a.root-servers.net a m.root-servers.net e gestite da 12 organizzazioni;¹⁷ grazie all’anycast ognuna di esse è in realtà un gran numero di server sparsi nel mondo. In pratica i passi 2 e 3 non avvengono quasi mai: gli indirizzi dei server di com sono nella cache di ogni resolver, e il lavoro si riduce all’ultimo passo o a niente del tutto.

Cache e TTL

Ogni record porta un TTL (time to live), il numero di secondi per cui si può tenere in cache. Per quel tempo i resolver rispondono a memoria, senza chiedere di nuovo ai server autorevoli. È ciò che rende il DNS veloce e leggero, ed è anche il motivo per cui le modifiche non sono istantanee.

Alcuni valori del dominio di questa wiki, misurati con dig:

Cosa	TTL	Significato
record A e AAAA del sito	300 s	un cambio di indirizzo lo vedono tutti entro 5 minuti
record NS nella zona	86 400 s	un giorno
delega nella zona `com`	172 800 s	due giorni: il tempo per cui un resolver può continuare a chiedere ai vecchi name server dopo un cambio
risposte negative	1 800 s	per quanto si ricorda un “questo record non esiste”

Anche il fatto che un record non esista finisce in cache (negative caching).¹⁸ La durata è la minore tra il TTL del record SOA della zona e l’ultimo campo di quel record, qui entrambi 1 800 secondi. Vuol dire che interrogare un nome prima di creare il record può “avvelenare” la risposta per mezz’ora: il record ormai esiste, ma il resolver continua a rispondere che non c’è.

Quella che comunemente si chiama propagazione del DNS non è qualcosa che viaggia: è il tempo che serve perché scadano le vecchie copie nelle cache di tutti i resolver.

Un esempio: una risposta vecchia dopo il cambio dei name server

È una situazione comune, capitata proprio mentre si metteva in piedi questa wiki. Gli indirizzi qui sotto sono esempi di documentazione.

Il dominio era registrato presso un’azienda che forniva anche il DNS, e lì il nome wiki aveva un record A che puntava a un vecchio server, 203.0.113.10.
Il sito è stato spostato dietro Cloudflare e i name server presso il registrar sono stati cambiati con quelli di Cloudflare, dove wiki ha i nuovi indirizzi.
Per un massimo di due giorni (il TTL della delega) alcuni resolver hanno continuato a usare i vecchi name server che avevano in cache, e questi rispondevano ancora con 203.0.113.10.
Il vecchio server non accettava più connessioni sulla porta 443, quindi per quegli utenti il browser mostrava “connessione non riuscita”, mentre per tutti gli altri il sito funzionava.

La soluzione è stata cancellare il vecchio record presso il provider precedente. Ne vengono due regole: quando si sposta il DNS, svuotare o allineare la vecchia zona, e per i cambi programmati abbassare i TTL qualche giorno prima.

Trasporto e privacy

Il DNS classico viaggia in chiaro sulla porta UDP 53, passando a TCP per le risposte grandi: chiunque si trovi sul percorso di rete può leggere quali nomi cerca un dispositivo e, in teoria, alterare le risposte. Due standard cifrano il traffico tra il dispositivo e il resolver:

DNS over TLS (DoT), sulla porta 853;¹⁹
DNS over HTTPS (DoH), che nasconde le domande dentro il normale traffico HTTPS sulla porta 443.²⁰

I browser possono usare DoH per conto proprio, scavalcando il resolver di sistema. In Firefox la funzione si chiama Trusted Recursive Resolver; la modalità più severa (“protezione massima”, modalità 3 in about:networking#dns) usa solo il resolver DoH, senza ripiego su quello di sistema. Dà più privacy, ma significa anche che il browser e il resto del sistema possono vedere risposte diverse o comportarsi in modo diverso sulla stessa rete. La cifratura protegge il percorso fino al resolver, non il contenuto delle risposte: quello è il compito del DNSSEC.

Record DNS

I dati di una zona sono conservati come record (resource record), ciascuno con cinque campi: nome, TTL, classe (in pratica sempre IN, Internet), tipo e dati. È così che li mostra dig:

daniellomario.com.   300   IN   A   172.67.204.67

Tipo	Contiene	Esempio da questo dominio
A	indirizzo IPv4	`172.67.204.67`
AAAA	indirizzo IPv6	`2606:4700:3031::ac43:cc43`
CNAME	alias verso un altro nome	`send` → `send.forge.rmta.net`
NS	server autorevoli della zona	`albert.ns.cloudflare.com`
SOA	dati amministrativi della zona	numero di serie, timer, TTL negativo
MX	server di posta, con priorità	`15 route3.mx.cloudflare.net`
TXT	testo libero: SPF, DKIM, DMARC, verifiche	`v=spf1 include:_spf.mx.cloudflare.net ~all`
HTTPS	parametri di connessione per un sito web	protocolli `h3` e `h2`, suggerimenti di indirizzo
PTR	nome di un indirizzo (risoluzione inversa)	—
CAA	autorità di certificazione ammesse a emettere certificati	—
DNSKEY, RRSIG, DS	chiavi e firme DNSSEC	DS `2371 13 2 5433…` nella zona `com`

A e AAAA

Il record A contiene un indirizzo IPv4 e il record AAAA (quattro A, perché l’indirizzo è quattro volte più lungo) un indirizzo IPv6. Un nome può averne diversi di ciascun tipo: i client ne scelgono uno e provano gli altri se non funziona. Il dominio di questa wiki ne ha due per tipo:

daniellomario.com.   300   IN   A      172.67.204.67
daniellomario.com.   300   IN   A      104.21.74.163
daniellomario.com.   300   IN   AAAA   2606:4700:3031::6815:4aa3
daniellomario.com.   300   IN   AAAA   2606:4700:3031::ac43:cc43

Non sono gli indirizzi di un server proprio, ma quelli della rete anycast di Cloudflare, che poi inoltra la richiesta al sito. Il sottodominio wiki ha gli stessi quattro indirizzi.

CNAME

Un record CNAME dice che un nome è un alias di un altro: chi lo risolve deve ripartire dal nome di destinazione. In questo dominio send.daniellomario.com è un alias di send.forge.rmta.net, un nome del servizio di posta, così il servizio può cambiare i propri record senza che il proprietario del dominio debba toccare nulla. Dal suo funzionamento seguono due regole:

un nome con un CNAME non può avere nessun altro record, perché il CNAME dice “tutto ciò che riguarda questo nome è là”;
per questo l’apice di una zona (daniellomario.com stesso), che deve avere i record SOA e NS, non può essere un CNAME. Alcuni provider offrono una scappatoia, come il CNAME flattening di Cloudflare, che risolve l’alias sul server e pubblica i record A e AAAA risultanti.

NS e SOA

I record NS elencano i server autorevoli di una zona; lo stesso elenco deve comparire anche nella zona superiore (com), ed è questo che fa funzionare la delega. Il record SOA (start of authority) contiene i dati amministrativi della zona:

daniellomario.com. 1800 IN SOA albert.ns.cloudflare.com. dns.cloudflare.com. 2418953318 10000 2400 604800 1800

Campo	Valore	Significato
server primario	`albert.ns.cloudflare.com`	il name server principale
contatto	`dns.cloudflare.com`	un indirizzo email in cui il primo punto sta per `@`: `dns@cloudflare.com`
numero di serie	2418953318	versione della zona, cresce a ogni modifica
refresh, retry, expire	10000, 2400, 604800	timer per i server secondari che copiano la zona
minimum	1800	TTL delle risposte negative

MX

I record MX (mail exchanger) dicono quali server ricevono la posta del dominio. Ognuno ha una priorità: chi invia prova prima il server con il numero più basso e gli altri se quello non risponde.

daniellomario.com.  300  IN  MX  15  route3.mx.cloudflare.net.
daniellomario.com.  300  IN  MX  78  route2.mx.cloudflare.net.
daniellomario.com.  300  IN  MX  91  route1.mx.cloudflare.net.

Qui i tre server sono quelli del servizio di inoltro di Cloudflare, che riceve la posta di info@ e cv@ e la passa a una casella personale. Senza record MX un dominio non può ricevere email.

TXT e autenticazione della posta

Un record TXT contiene testo arbitrario. È nato per note destinate alle persone, ma oggi serve soprattutto per dati letti dai programmi: prove di possesso del dominio chieste da servizi esterni e, soprattutto, i tre meccanismi che proteggono la posta dai mittenti falsi.

L’SPF (Sender Policy Framework)²¹ elenca quali server possono inviare posta per un dominio:

daniellomario.com.  TXT  "v=spf1 include:_spf.mx.cloudflare.net ~all"

include: importa l’elenco pubblicato da Cloudflare, e ~all (softfail) chiede di trattare come sospetta la posta da qualsiasi altro server; -all chiederebbe di rifiutarla. L’SPF controlla il dominio del mittente della busta (il Return-Path), non quello che vede chi legge, e non regge quando un messaggio viene inoltrato.

Il DKIM (DomainKeys Identified Mail)²² aggiunge una firma digitale a ogni messaggio. Il server che invia firma con una chiave privata, e la chiave pubblica viene pubblicata in un record TXT sotto un nome formato da un selettore e da _domainkey:

cf2024-1._domainkey.daniellomario.com.  TXT  "v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkq…"
resend._domainkey.daniellomario.com.    TXT  "p=MIGfMA0GCSqGSIb3DQEB…"

I selettori permettono di avere più chiavi insieme: qui una appartiene al servizio di posta di Cloudflare e una a Resend, il servizio usato per rispondere dagli indirizzi del dominio. Chi riceve legge il selettore dal messaggio, cerca la chiave e verifica che il messaggio non sia stato alterato.

Il DMARC²³ lega i due e dice cosa fare quando falliscono:

_dmarc.daniellomario.com.  TXT  "v=DMARC1; p=reject; sp=reject"

Un messaggio supera il DMARC se passa l’SPF o il DKIM e il dominio controllato è allineato con quello dell’indirizzo From: visibile, cioè è lo stesso dominio o un suo sottodominio. p=reject chiede a chi riceve di rifiutare i messaggi che falliscono, e sp=reject applica la stessa regola ai sottodomini. È la politica più severa: nessuno può inviare posta che sembri provenire da @daniellomario.com senza passare dai servizi autorizzati. Le risposte inviate con Resend passano grazie alla firma DKIM con d=daniellomario.com e a un Return-Path sul sottodominio send, allineato con il dominio principale.

HTTPS e SVCB

Il record HTTPS, una specializzazione del più generale SVCB,²⁴ dice a un browser come collegarsi prima della prima connessione: quali protocolli supporta il server e a quali indirizzi.

daniellomario.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=104.21.74.163,172.67.204.67 ech=AEX+DQBB… ipv6hint=2606:4700:3031::6815:4aa3,…

alpn="h3,h2" annuncia HTTP/3 e HTTP/2, così il browser può provare subito HTTP/3; i suggerimenti (hint) ripetono gli indirizzi per risparmiare una risoluzione; ech contiene la chiave per l’Encrypted ClientHello, che nasconde a chi osserva il traffico perfino il nome del sito richiesto.

PTR e CAA

Un record PTR fa l’opposto di un record A: associa un nome a un indirizzo. Le risoluzioni inverse usano zone speciali in cui l’indirizzo è scritto al contrario: 163.74.21.104.in-addr.arpa per 104.21.74.163, e le 32 cifre esadecimali in ordine inverso sotto ip6.arpa per IPv6. Le usano soprattutto i server di posta, che diffidano dei mittenti il cui indirizzo non ha un nome coerente.

Un record CAA elenca le autorità di certificazione ammesse a emettere certificati TLS per il dominio. Senza, come su questo dominio, qualsiasi autorità può farlo; pubblicarlo riduce il rischio che un certificato venga emesso per errore.

DNSSEC

Il DNS è stato progettato senza alcun modo di verificare le risposte. Un resolver che accetta una risposta falsa la tiene in cache e la consegna a tutti i suoi utenti per l’intero TTL: si chiama avvelenamento della cache (cache poisoning). Nel 2008 Dan Kaminsky mostrò che era molto più facile da realizzare di quanto si pensasse,²⁵ e i resolver reagirono rendendo casuali porte e identificativi delle domande. La soluzione vera è il DNSSEC,²⁶ che aggiunge firme digitali ai record:

DNSKEY: le chiavi pubbliche della zona. Il valore 257 dei flag indica la key signing key (KSK), che firma solo le altre chiavi, e 256 le zone signing key (ZSK), che firmano i dati;
RRSIG: la firma di ogni insieme di record, con il suo periodo di validità;
DS (delegation signer): un’impronta (hash) della KSK della zona figlia, pubblicata nella zona madre. È l’anello della catena di fiducia;
NSEC e NSEC3: prove firmate che un nome non esiste, così che nemmeno le risposte negative si possano falsificare.

La verifica scende lungo l’albero a partire dalla radice, la cui chiave è inclusa nei resolver: la radice firma il DS di com, le chiavi di com firmano il DS del dominio, le chiavi del dominio firmano i suoi record. La radice è firmata dal 15 luglio 2010.²⁷ Oggi il record DS di com nella zona radice è:

com.   DS   19718 13 2 8ACBB0CD28F41250A80A491389424D341522D946B0DA0C0291F2D3D771D7805A

dove 19718 identifica la chiave, 13 è l’algoritmo (ECDSA sulla curva P-256 con SHA-256) e 2 la funzione di hash dell’impronta (SHA-256).

Un resolver che completa la verifica imposta il flag AD (authenticated data) nella risposta. Il dominio di questa wiki è firmato dal 1° novembre 2026. La zona pubblica due chiavi, entrambe con algoritmo 13:

daniellomario.com.  3600  IN  DNSKEY  257 3 13 mdsswUyr3DPW132mOi8V…   (KSK, key tag 2371)
daniellomario.com.  3600  IN  DNSKEY  256 3 13 oJMRESz5E4gYzS/q6XDr…   (ZSK, key tag 34505)

e la zona com contiene il record DS che le aggancia alla catena di fiducia:

daniellomario.com.  DS  2371 13 2 54333064B9903A6B6F4F223DFCCA3EE75F4600314753C1D2F410E91F5C73DEC2

Il DS punta alla KSK (key tag 2371), la KSK firma l’insieme delle chiavi, e la ZSK (key tag 34505) firma tutti gli altri record, per esempio i record A, ciascuno con una RRSIG valida per pochi giorni. Interrogando un resolver che verifica, con dig +dnssec daniellomario.com, tra i flag compare ad. resolvectl query può comunque stampare Data is authenticated: no: quella riga si riferisce alla verifica fatta dal systemd-resolved locale, che molte distribuzioni lasciano disattivata, non a quella del resolver a monte.

Attivare il DNSSEC ha richiesto due passi, in quest’ordine: accendere la firma presso il provider DNS, che crea le chiavi, e poi inserire il record DS presso il registrar, che lo pubblica in com. L’ordine conta, e conta la precisione: un DS che non corrisponde alle chiavi rende il dominio irraggiungibile per tutti i resolver che verificano, cioè oggi la maggior parte. Prima di inserirlo conviene ricalcolare il DS dalla DNSKEY pubblicata e controllare che coincida.

Campi di un record DS

Quando si attiva il DNSSEC, il registrar chiede il record DS diviso in quattro campi. Per questo dominio sono:

Campo	Valore	Significato
Key Tag	`2371`	identificativo breve della chiave a cui il record si riferisce
Algorithm	`13`	ECDSA sulla curva P-256 con SHA-256
Digest Type	`2`	la funzione di hash usata per l’impronta: SHA-256
Digest	i 64 caratteri esadecimali del record DS qui sopra	l’impronta (hash) della chiave stessa

Key Tag. Un numero di 16 bit calcolato dal contenuto del record DNSKEY con una semplice somma di controllo.²⁸ Permette a un resolver di trovare subito a quale chiave si riferisce il DS quando la zona ne pubblica più di una, come qui (KSK e ZSK) e durante un cambio di chiave. Non è un meccanismo di sicurezza: due chiavi diverse possono avere lo stesso tag, e il controllo vero lo fa il digest.

Algorithm. Il numero, preso da un registro gestito da IANA, dell’algoritmo di firma della chiave; deve coincidere con il campo algoritmo della DNSKEY. I più comuni sono 8 (RSA con SHA-256, usato dalla radice), 13 (ECDSA P-256 con SHA-256, usato da com e da questo dominio)²⁹ e 15 (Ed25519). L’algoritmo 13 è diffuso perché chiavi e firme sono molto più corte di quelle RSA: una firma P-256 occupa 64 byte, contro i 256 byte di RSA a 2048 bit, così le risposte firmate restano abbastanza piccole da viaggiare su UDP.

Digest Type. Quale funzione di hash ha prodotto l’impronta: 1 è SHA-1, ormai deprecata, 2 è SHA-256, la scelta abituale, e 4 è SHA-384. È indipendente dall’algoritmo: l’algoritmo riguarda le firme, il tipo di digest solo il modo in cui la zona madre conserva la sua impronta della chiave.

Digest. L’hash del nome del dominio, nella forma binaria usata dal DNS, seguito dal contenuto del record DNSKEY (flag, protocollo, algoritmo e chiave pubblica):

digest = SHA - 256 (nome ∥ DNSKEY)

Con SHA-256 il risultato è di 32 byte, scritti come 64 caratteri esadecimali. Siccome il nome fa parte dell’input, la stessa chiave usata per due domini darebbe due impronte diverse. Il digest non è segreto: chiunque può leggerlo con dig DS daniellomario.com e chiunque può ricalcolarlo dalla DNSKEY pubblica. Ricalcolarlo è proprio il controllo che conviene fare prima di inserirlo presso il registrar, perché basta un carattere sbagliato per spezzare la catena di fiducia.

La zona madre conserva un’impronta invece dell’intera chiave perché deve solo garantire per la chiave, non usarla: un hash ha una dimensione breve e fissa, e la chiave, che la zona figlia può cambiare, resta nella zona figlia.

Strumenti di diagnosi

Comando	Cosa fa
`dig nome`	chiede al resolver di sistema il record A e mostra la risposta completa
`dig +short nome AAAA`	solo gli indirizzi IPv6
`dig nome @1.1.1.1`	chiede a un resolver preciso, per confrontare le risposte
`dig nome NS @a.gtld-servers.net`	chiede direttamente ai server di `com`: mostra la delega com’è davvero
`dig +trace nome`	ripete l’intera risoluzione partendo dalla radice
`dig +dnssec nome`	mostra anche le firme RRSIG
`getent hosts nome`	risolve come fanno i programmi, compreso `/etc/hosts`
`resolvectl query nome`	chiede a `systemd-resolved`, con origine e stato DNSSEC
`curl -4 -sI https://nome`	prova la connessione solo in IPv4 (`-6` solo in IPv6)
`ip -6 route`	mostra se la macchina ha una strada verso l’Internet IPv6
`about:networking#dns`	la cache DNS di Firefox e la sua modalità DoH

Quando un sito non si carica, l’ordine è: controllare che il nome risolva (dig), che risolva agli indirizzi attesi chiedendo a resolver diversi, che gli indirizzi rispondano in IPv4 e in IPv6 (curl -4, curl -6), e infine se il browser vede qualcosa di diverso dal sistema. Ogni passo esclude un livello, e il primo che fallisce dice dov’è il problema.

Glossario inglese–italiano

Termini usati comunemente in inglese anche nei contesti italiani, con una frase di esempio utile in un colloquio di lavoro.

Termine	Significato	Frase di esempio
Name resolution	Risoluzione dei nomi	Name resolution turns a hostname into an IP address.
Recursive resolver	Resolver ricorsivo	The recursive resolver does the lookup and caches the answer.
Authoritative server	Server autorevole	Only the authoritative servers hold the zone’s records.
Record	Record DNS	I added an A record and an AAAA record for the subdomain.
TTL	Durata in cache	With a TTL of 300 seconds, the change is visible within five minutes.
Propagation	Propagazione (scadenza delle cache)	Propagation is really just old cache entries expiring.
Subnet / CIDR	Sottorete / notazione CIDR	A /24 subnet has 256 addresses.
Dual stack	Doppio stack IPv4 e IPv6	The server is dual stack, so it answers on both IPv4 and IPv6.
NAT	Traduzione degli indirizzi	Behind NAT, all devices share one public IPv4 address.
Anycast	Stesso indirizzo da più luoghi	With anycast, users reach the nearest data center.
Alignment (DMARC)	Allineamento dei domini	DMARC requires SPF or DKIM to be aligned with the From domain.

Voci correlate

Note

Postel, J. (1981). Internet Protocol. RFC 791. rfc-editor.org ↩ ↩²
Number Resource Organization (2011). Free Pool of IPv4 Address Space Depleted. Comunicato stampa, 3 febbraio 2011. nro.net ↩
RIPE NCC (2019). The RIPE NCC has run out of IPv4 Addresses. 25 novembre 2019. ripe.net ↩
Fuller, V. et al. (1993). Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy. RFC 1519. rfc-editor.org ↩
Fuller, V., Li, T. (2006). Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan. RFC 4632. rfc-editor.org ↩
Rekhter, Y. et al. (1996). Address Allocation for Private Internets. RFC 1918. rfc-editor.org ↩
Weil, J. et al. (2012). IANA-Reserved IPv4 Prefix for Shared Address Space. RFC 6598. rfc-editor.org ↩
Cheshire, S., Aboba, B., Guttman, E. (2005). Dynamic Configuration of IPv4 Link-Local Addresses. RFC 3927. rfc-editor.org ↩
Arkko, J., Cotton, M., Vegoda, L. (2010). IPv4 Address Blocks Reserved for Documentation. RFC 5737. rfc-editor.org; per IPv6: Huston, G., Lord, A., Smith, P. (2004). IPv6 Address Prefix Reserved for Documentation. RFC 3849. rfc-editor.org ↩ ↩²
Deering, S., Hinden, R. (2017). Internet Protocol, Version 6 (IPv6) Specification. RFC 8200. rfc-editor.org ↩
Kawamura, S., Kawashima, M. (2010). A Recommendation for IPv6 Address Text Representation. RFC 5952. rfc-editor.org ↩
Hinden, R., Deering, S. (2006). IP Version 6 Addressing Architecture. RFC 4291. rfc-editor.org ↩
Schinazi, D., Pauly, T. (2017). Happy Eyeballs Version 2: Better Connectivity Using Concurrency. RFC 8305. rfc-editor.org ↩
Mockapetris, P. (1983). Domain Names – Concepts and Facilities. RFC 882. rfc-editor.org ↩
Mockapetris, P. (1987). Domain Names – Concepts and Facilities. RFC 1034. rfc-editor.org ↩
Mockapetris, P. (1987). Domain Names – Implementation and Specification. RFC 1035. rfc-editor.org ↩
Root Server Technical Operations Association. Root Servers. root-servers.org ↩
Andrews, M. (1998). Negative Caching of DNS Queries (DNS NCACHE). RFC 2308. rfc-editor.org ↩
Hu, Z. et al. (2016). Specification for DNS over Transport Layer Security (TLS). RFC 7858. rfc-editor.org ↩
Hoffman, P., McManus, P. (2018). DNS Queries over HTTPS (DoH). RFC 8484. rfc-editor.org ↩
Kitterman, S. (2014). Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. RFC 7208. rfc-editor.org ↩
Crocker, D., Hansen, T., Kucherawy, M. (2011). DomainKeys Identified Mail (DKIM) Signatures. RFC 6376. rfc-editor.org ↩
Kucherawy, M., Zwicky, E. (2015). Domain-based Message Authentication, Reporting, and Conformance (DMARC). RFC 7489. rfc-editor.org ↩
Schwartz, B., Bishop, M., Nygren, E. (2023). Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records). RFC 9460. rfc-editor.org ↩
CERT Coordination Center (2008). Multiple DNS implementations vulnerable to cache poisoning. Vulnerability Note VU#800113. kb.cert.org ↩
Arends, R. et al. (2005). DNS Security Introduction and Requirements. RFC 4033. rfc-editor.org ↩
IANA. Root zone trust anchors: la prima chiave della radice è valida dal 15 luglio 2010. data.iana.org ↩
Arends, R. et al. (2005). Resource Records for the DNS Security Extensions. RFC 4034. rfc-editor.org ↩
Hoffman, P., Wijngaards, W. C. A. (2012). Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC. RFC 6605. rfc-editor.org ↩

Wiki di Mario

Indice

Indirizzi IP e Domain Name System

Indirizzi IP

IPv4

Classi di indirizzi

CIDR e maschere di sottorete

Intervalli speciali

Traduzione degli indirizzi (NAT)

IPv6

Doppio stack e Happy Eyeballs

Anycast

Domain Name System

Nomi e gerarchia

Risoluzione

Cache e TTL

Un esempio: una risposta vecchia dopo il cambio dei name server

Trasporto e privacy

Record DNS

A e AAAA

CNAME

NS e SOA

MX

TXT e autenticazione della posta

HTTPS e SVCB

PTR e CAA

DNSSEC

Campi di un record DS

Strumenti di diagnosi

Glossario inglese–italiano

Voci correlate

Note

Link entranti

Wiki di Mario

Indice

Indirizzi IP e Domain Name System

Indirizzi IP

IPv4

Classi di indirizzi

CIDR e maschere di sottorete

Intervalli speciali

Traduzione degli indirizzi (NAT)

IPv6

Doppio stack e Happy Eyeballs

Anycast

Domain Name System

Nomi e gerarchia

Risoluzione

Cache e TTL

Un esempio: una risposta vecchia dopo il cambio dei name server

Trasporto e privacy

Record DNS

A e AAAA

CNAME

NS e SOA

MX

TXT e autenticazione della posta

HTTPS e SVCB

PTR e CAA

DNSSEC

Campi di un record DS

Strumenti di diagnosi

Glossario inglese–italiano

Voci correlate

Note

Footnotes

Link entranti