Come risolvere una ricerca DNS lenta

Cosa misura una ricerca lenta

Caricare una pagina inizia con una ricerca del nome, poi una connessione TCP, poi un handshake TLS, poi il tempo di elaborazione del server stesso. Solo il primo di questi è DNS, ed è l'unico che spesso puoi migliorare senza toccare affatto il sito.

Qui si confondono due numeri. Una ricerca in cache non costa quasi nulla, perché la risposta è già sulla tua macchina o a un solo salto di distanza. Una ricerca a freddo può coinvolgere una query al root, un'altra al dominio di primo livello, e un'altra ancora ai nameserver del dominio stesso, ognuna un viaggio andata e ritorno sulla distanza che ti separa da quei server. Sotto i 20 ms a caldo e sotto i 100 ms a freddo non fanno notizia. Qualsiasi cosa vicina a un secondo significa che uno dei salti è lontano, sovraccarico, oppure va in timeout e viene ritentato.

Le pagine moderne peggiorano la situazione avendo molti nomi host. Font, analytics, immagini e widget di pagamento hanno ciascuno bisogno della propria ricerca, e un browser che risolve dieci nomi host a 300 ms l'uno ha speso tre secondi in DNS prima di renderizzare qualcosa di utile.

Conferma che il DNS è la parte lenta

Misura prima di cambiare qualsiasi cosa. Il comando singolo più pulito divide una richiesta nelle sue fasi:

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com

Se time_namelookup è una piccola frazione del totale, il DNS non è il tuo problema e dovresti leggere invece del tempo di risposta del server. Se è un terzo o più, continua. Per la sola ricerca, dig stampa il tempo trascorso per te:

dig example.com | grep "Query time"
dig @1.1.1.1 example.com | grep "Query time"
dig @8.8.8.8 example.com | grep "Query time"

Su Windows, PowerShell dà la stessa lettura:

Measure-Command { Resolve-DnsName www.example.com }
Measure-Command { Resolve-DnsName www.example.com -Server 1.1.1.1 }

Confronta il tuo predefinito con i resolver pubblici. Un divario ampio ti dice che la soluzione è dalla tua parte. Tempi simili ovunque indicano i nameserver del dominio stesso.

Un risultato esclude del tutto questa guida. Se un resolver risponde istantaneamente con NXDOMAIN, il nome non è pubblicato e stai guardando un problema diverso, descritto in DNS_PROBE_FINISHED_NXDOMAIN.

Perché succede

• Un resolver lontano. I servizi pubblici usano anycast, quindi lo stesso indirizzo risponde da una ubicazione vicina. Un resolver del provider o un singolo server d'ufficio no, e ogni query paga il viaggio completo.
• Il primo server nell'elenco è morto. Il client aspetta il suo timeout, poi chiede al secondo. Sui sistemi glibc il valore predefinito è 5 secondi prima del primo nuovo tentativo, che è esattamente la pausa che le persone descrivono come "si blocca, poi carica".
• TTL molto bassi. Un TTL di 30 o 60 secondi significa che quasi ogni visitatore paga per una ricerca fresca, perché la copia in cache è già scaduta.
• Catene CNAME lunghe. Ogni collegamento è un'altra ricerca. Catene di tre o quattro sono comuni dietro CDN e strumenti di marketing.
• Nameserver autoritativi lenti. Un provider DNS con poche ubicazioni risponde velocemente per una parte del mondo e lentamente per il resto.
• Validazione DNSSEC. Validare una catena aggiunge query. Di solito è economico, ma una catena parzialmente rotta causa nuovi tentativi che sembrano lentezza.
• Domini di ricerca. Un resolver configurato con suffissi prova example.com.corp.local prima di example.com, spendendo prima una query fallita per ogni suffisso.
• Ricerche AAAA senza IPv6. Il sistema chiede entrambi i tipi di record e aspetta la risposta che non può usare.
• Una VPN o un proxy di filtraggio che invia ogni query attraverso un tunnel verso un resolver su un altro continente.
• Un router che agisce da forwarder con una cache minuscola e una CPU sottodimensionata.

Come risolverlo

Sul tuo dispositivo

1. Svuota le cache così le tue misurazioni sono oneste: ipconfig /flushdns su Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder su macOS, sudo resolvectl flush-caches su Linux.
2. Guarda quali server sono configurati e in che ordine: Get-DnsClientServerAddress, scutil --dns, oppure resolvectl status. Rimuovi qualsiasi voce che non risponde più, perché una prima voce morta ti costa il timeout su ogni ricerca a freddo.
3. Su Linux, accorcia l'attesa mentre indaghi aggiungendo options timeout:2 attempts:2 a /etc/resolv.conf, e riduci i suffissi search inutilizzati.
4. Disconnetti la VPN e misura di nuovo. Se il numero si dimezza, il tunnel è la causa e la sua impostazione del resolver è ciò da cambiare.

Sulla tua rete

1. Imposta il resolver nel DHCP sul router invece che dispositivo per dispositivo, così ogni client ottiene la stessa coppia veloce.
2. Dai al forwarder del router stesso un resolver pubblico a monte invece del predefinito del provider, oppure salta del tutto il forwarder passando ai client gli indirizzi pubblici direttamente.
3. Su una rete aziendale con un proprio server DNS, controlla che inoltri invece di fare ricorsione completa da un unico sito, e che la sua cache sia abbastanza grande da sopravvivere alla giornata lavorativa.

Sul tuo dominio

1. Alza i TTL sui record che cambiano raramente. Cinque minuti sono un limite ragionevole per un record che potresti dover spostare rapidamente; un'ora o un giorno vanno bene per tutto ciò che è stabile.
2. Appiattisci le catene CNAME dove puoi. Punta il record direttamente all'obiettivo finale invece che a una catena di alias: dig www.example.com CNAME +short mostra quanto è profonda la tua.
3. Usa un provider DNS con nameserver anycast, e mantieni almeno due nameserver su reti separate.
4. Controlla che DNSSEC si validi. Confronta una query normale con una che salta la validazione: dig example.com @1.1.1.1 contro dig +cd example.com @1.1.1.1. Una differenza ampia, o un SERVFAIL solo sulla prima, significa che la catena è rotta.

Controllalo dall'esterno

I tuoi tempi descrivono una rete in un momento, che è il campione meno utile che tu possa prendere. Un resolver che è a 8 ms da te può essere a 400 ms da un cliente in un'altra regione, ed è quel cliente a lamentarsi.

Inizia misurando direttamente i server autoritativi, il che rimuove ogni cache tra te e la fonte:

dig NS example.com +short
dig @ns1.example-dns.net example.com | grep "Query time"
dig example.com +trace

L'output di +trace percorre la delega un passo alla volta, così un salto che si blocca è visibile invece di essere mediato via. Poi esegui il controllo di interrogazione DNS, che risolve il nome da postazioni in paesi diversi e riporta ciascuna separatamente. Quella è la misurazione che non puoi fare da un portatile: mostra se i tuoi nameserver sono lenti ovunque, il che indica il provider, oppure lenti da un continente, il che indica la loro impronta di rete. Se alcune ubicazioni restituiscono una risposta diversa invece che più lenta, la domanda riguarda invece la propagazione, trattata in come verificare la propagazione DNS.

Una latenza che deriva invece di rompersi

La latenza DNS raramente si rompe in modo evidente. Deriva, un nameserver perde una ubicazione, un TTL viene abbassato durante una migrazione e non viene mai più alzato, e sei settimane dopo il sito sembra lento per motivi che nessuno riesce a indicare. Una singola misurazione non può mostrare una tendenza, ed è per questo che vale la pena registrare il tempo di ricerca secondo una pianificazione dalle regioni in cui si trovano i tuoi visitatori. HostTracker monitora siti web dal 2004 e oggi osserva oltre 500.000 siti web da postazioni in 158 città, mantenendo la cronologia che rende visibile una deriva lenta. Le altre guide qui sono nel cluster risolvere, e il caso di guasto in cui non torna indietro proprio nulla è DNS server not responding.