1 26/04/2026 10 min

Quando il ping fallisce solo in IPv6, il problema non è sempre il DNS

Se su Linux il nome host risolve correttamente ma ping verso un record IPv6 fallisce, il primo errore è dare per scontato che il DNS sia il colpevole. In pratica ci sono almeno tre livelli da separare: risoluzione del nome, raggiungibilità IPv6 e comportamento del resolver locale. Un host può avere un AAAA valido, ma non avere una route IPv6 funzionante; oppure può avere un resolver che restituisce solo IPv4 per policy locale; oppure ancora può soffrire di un problema di Happy Eyeballs o di precedence nelle librerie di sistema.

La regola utile è questa: se il nome risolve ma il ping IPv6 non parte, non stai ancora guardando il DNS. Stai guardando la parte di rete o la politica di selezione degli indirizzi. Il DNS entra davvero in causa quando il record AAAA manca, è sbagliato, è servito da una zona non aggiornata, oppure il resolver locale sta filtrando o alterando la risposta.

Classificazione del problema: troubleshooting con impatto potenzialmente lato produzione

Qui il caso tipico è troubleshooting su host Linux, spesso in ambiente server o VPS. L’obiettivo non è “far andare il ping” in sé: il ping è solo un indicatore. Quello che conta è capire se l’IPv6 è realmente operativo, se il DNS sta pubblicando il record giusto e se il sistema locale è configurato per preferire o escludere IPv6 in modo coerente.

Stato atteso vs osservato: ci si aspetta che un host con connettività IPv6 attiva risolva un AAAA e riesca a raggiungere il target; in caso contrario, si osserva che il nome risolve ma il ping fallisce, oppure che il ping usa un indirizzo IPv4 perché il sistema ha evitato IPv6.

Distinguere il layer giusto in meno di cinque minuti

Prima di toccare configurazioni, verifica i tre punti minimi: risposta DNS, route IPv6 e raggiungibilità del target. Se uno solo dei tre è rotto, hai già ristretto il campo. Se tutti e tre risultano sani, il problema è quasi certamente nell’applicazione che lancia il ping o nel resolver usato da quel processo.

Usa questi comandi nell’ordine. Sono non distruttivi e ti dicono subito dove guardare.

getent ahosts example.com
resolvectl query example.com
ip -6 addr
ip -6 route
ping -6 -c 3 example.com
ping -6 -c 3 2001:db8::1

Interpretazione rapida: getent ahosts mostra gli indirizzi che il resolver locale restituisce; resolvectl query conferma cosa vede systemd-resolved, se presente; ip -6 addr e ip -6 route dicono se la macchina ha un indirizzo e una route IPv6 operativi; ping -6 verso un nome e verso un indirizzo numerico separa il DNS dalla connettività.

Ipotesi ordinate per probabilità

1. IPv6 non è realmente operativo sull’host o sulla rete. È il caso più comune: il DNS restituisce AAAA, ma non esiste una route, manca il gateway, il prefisso è errato o il provider non instrada IPv6. Si falsifica in pochi secondi con ip -6 addr e ip -6 route. Se non vedi né un indirizzo globale né una default route, il problema non è il DNS.

2. Il resolver locale filtra o preferisce un’altra famiglia. Alcune configurazioni con systemd-resolved, nsswitch.conf o policy applicative possono alterare la scelta. Si falsifica con resolvectl query, getent ahosts e confrontando il risultato con dig AAAA example.com. Se dig vede l’AAAA e getent no, il problema è nel resolver locale o nella libreria NSS.

3. Il record AAAA è errato o non propagato. Qui il DNS è davvero il responsabile: TTL non scaduto, zona secondaria non allineata, record puntato a un indirizzo sbagliato, oppure split-horizon mal configurato. Si falsifica interrogando più resolver e confrontando la risposta autoritativa con quella cache.

Verifiche immediate sul DNS

Se il nome non si risolve in IPv6, non limitarti al resolver locale. Verifica anche la zona autoritativa. L’idea è capire se il problema è a monte o a valle della cache.

dig AAAA example.com +short
dig AAAA example.com @1.1.1.1 +short
dig AAAA example.com @8.8.8.8 +short
dig +trace example.com AAAA

Se i resolver pubblici restituiscono AAAA e il tuo host no, il problema è locale. Se nessuno restituisce AAAA, guarda la zona DNS. Se +trace mostra una delega incompleta o un authoritative che non risponde, hai un problema di pubblicazione DNS, non di Linux.

In ambiente con provider DNS esterno o pannello hosting, controlla il record AAAA nel campo dedicato alla zona, non solo nella schermata di overview. Spesso il record è presente ma punta a un indirizzo vecchio, oppure è stato creato nel dominio sbagliato per un errore di suffisso. La verifica da fare è banale: confronto tra output di dig AAAA e indirizzo IPv6 atteso del server.

Verifiche immediate sulla rete IPv6 del server

Se il DNS è coerente ma il ping IPv6 non funziona, passa alla connettività. Qui la domanda non è “il nome esiste?”, ma “la macchina può uscire in IPv6 e ricevere risposta?”.

ip -6 addr show
ip -6 route show
ping -6 -c 3 2606:4700:4700::1111
curl -6 -I https://example.com

ping -6 verso un indirizzo noto, ad esempio un resolver pubblico, ti dice se la connettività IPv6 base funziona. curl -6 -I aggiunge il livello HTTP e ti fa capire se il problema è limitato al protocollo ICMP o è più generale. Se ping -6 fallisce ma curl -6 funziona, hai un blocco ICMP o un firewall che filtra il ping; se falliscono entrambi, il problema è di routing o connettività.

Su sistemi con NetworkManager o configurazioni statiche, controlla anche che l’indirizzo globale non sia solo link-local. Un host con solo fe80::/64 può parlare sul segmento locale, ma non raggiungere Internet. La presenza di una default route IPv6 è il discriminante principale.

Resolver locale: systemd-resolved, nsswitch e preferenze IPv4/IPv6

Su molte distribuzioni recenti il resolver effettivo è systemd-resolved. In quel caso non basta guardare /etc/resolv.conf, perché spesso è un symlink. Il punto da verificare è se il nome viene risolto in IPv6 dal servizio locale e se la policy di preferenza non sta di fatto schiacciando l’uso di IPv6.

ls -l /etc/resolv.conf
resolvectl status
cat /etc/nsswitch.conf | grep '^hosts:'

Se hosts: in nsswitch.conf non include resolve o dns nel modo atteso, il comportamento può cambiare tra shell, applicazioni e servizi. È un dettaglio che crea falsi positivi: il ping lanciato a mano funziona, mentre il demone no, o viceversa.

Un altro caso comune è la preferenza per IPv4 dettata da policy locali. In Linux la selezione della famiglia può dipendere da /etc/gai.conf. Se qualcuno ha alterato la precedence, i client possono scegliere IPv4 anche quando IPv6 è disponibile. Prima di modificare, leggi il file e verifica se c’è una regola custom.

grep -v '^[#[:space:]]' /etc/gai.conf

Se compare una configurazione non standard, valuta se è davvero voluta. In molti casi si tratta di un residuo di troubleshooting fatto mesi prima per aggirare un malfunzionamento temporaneo di IPv6 e poi dimenticato lì.

Soluzione consigliata passo-passo

La soluzione non è unica, perché dipende dal layer rotto. Però l’ordine corretto è sempre lo stesso: correzione minima, verifica, solo dopo eventuale consolidamento. Evita di cambiare più cose insieme, altrimenti non saprai quale modifica ha risolto o rotto il problema.

  1. Se il record AAAA è sbagliato, correggi la zona DNS. Aggiorna l’indirizzo IPv6 nel pannello DNS o nel file di zona, poi verifica la propagazione con dig AAAA example.com @resolver. Se il provider usa TTL alti, considera il tempo di cache prima di aspettarti l’effetto globale.
  2. Se il server non ha IPv6, ripristina la connettività di rete. Aggiungi o correggi l’indirizzo globale, il gateway e la route predefinita. La verifica minima è ip -6 addr con indirizzo globale e ip -6 route con default route. Se usi configurazione persistente, applica la correzione nel file di rete della tua distro o nel pannello del provider cloud.
  3. Se il resolver locale è incoerente, riallinea NSS o systemd-resolved. Riavvia solo dopo aver salvato la configurazione. Per esempio, su sistemi con systemd-resolved puoi verificare lo stato con resolvectl status e poi riavviare il servizio se necessario: systemctl restart systemd-resolved. Prima di farlo, controlla il blast radius: impatta la risoluzione nomi dell’host, quindi meglio in finestra di manutenzione se il nodo serve traffico critico.
  4. Se il ping è bloccato ma HTTP funziona, non inseguire il DNS. Molti firewall filtrano ICMPv6. In quel caso il test corretto è curl -6 -I o un check applicativo reale. Se devi aprire ICMPv6, fallo con criterio: è utile per Path MTU Discovery e diagnostica, ma va consentito in modo selettivo e non “a caso”.

Se vuoi una verifica rapida di correzione DNS senza attendere troppo, prova da un host esterno e da uno interno. Il confronto tra i due ti dice subito se stai combattendo contro una cache locale o una pubblicazione errata.

dig AAAA example.com @1.1.1.1 +short
ssh user@server 'dig AAAA example.com +short'

Un caso pratico che inganna spesso

Scenario tipico: il dominio ha un record AAAA corretto, il server ha IPv6 attivo, ma ping example.com continua a usare IPv4 o fallisce in modo incoerente. Qui spesso il problema non è nella rete, ma nella politica di selezione degli indirizzi. Qualcuno ha aggiunto una preferenza custom in /etc/gai.conf, oppure l’applicazione usa una libreria che preferisce IPv4 quando il round-trip stimato di IPv6 sembra più alto.

In questi casi la correzione strutturale non è “forzare ping a usare IPv6” per sempre. La correzione vera è rimuovere la causa della preferenza errata, verificare la connettività IPv6 end-to-end e poi lasciare che il sistema scelga l’indirizzo in modo naturale. Se devi tenere una preferenza temporanea per mitigare un guasto del provider, documentala e metti una scadenza, altrimenti ti ritrovi con un workaround permanente che maschera il problema reale.

Rollback e blast radius quando tocchi la rete

Ogni modifica a DNS, route o resolver ha un blast radius concreto: può impattare non solo il ping, ma la risoluzione di tutti i servizi dell’host. Per questo conviene avere sempre un rollback chiaro. Prima di cambiare un file, fai una copia; prima di riavviare un servizio di risoluzione, verifica che l’accesso al nodo sia disponibile anche via console o out-of-band, se sei in produzione.

cp /etc/gai.conf /etc/gai.conf.bak.$(date +%F-%H%M%S)
cp /etc/resolv.conf /root/resolv.conf.bak.$(date +%F-%H%M%S)

Attenzione: su sistemi dove /etc/resolv.conf è gestito automaticamente, copiarlo non basta a preservare la configurazione reale. Il rollback vero è ripristinare il gestore corretto, non solo il file visibile. Se il file è un symlink, documenta il target prima di cambiare qualcosa.

Controlli finali che vale la pena lasciare in piedi

Dopo la correzione, non fermarti al ping. Fai almeno quattro controlli: risoluzione AAAA, route IPv6, connettività verso un target esterno e test applicativo. Il ping da solo può mentire se ICMP è filtrato; l’applicazione può funzionare anche quando il ping fallisce. Ti serve una prova più utile del semplice eco request.

getent ahosts example.com
ip -6 route show
a=ping -6 -c 3 example.com
curl -6 -I https://example.com

Se tutti i controlli passano, hai chiuso il cerchio. Se uno solo fallisce, il layer non è ancora risolto. In particolare, se il DNS risponde bene ma curl -6 fallisce, il problema è quasi sempre nella rete o nel firewall. Se curl -6 funziona ma ping -6 no, il blocco ICMP è una scelta di policy, non un guasto del DNS.

Assunzione operativa: l’host è Linux recente con strumenti standard come iproute2, ping, dig e, se presente, systemd-resolved; se la distribuzione o il pannello cambiano i file di rete, il principio di diagnosi resta identico, ma il punto di modifica va adattato al gestore locale.