The French courts yesterday handed down an unfavorable ruling against Quad9 in a major case that undermines the transparency and stability of the internet. As a result, Quad9 will no longer be able to offer its free cyberprotection service to users located in France effective November 24.

https://quad9.net/news/blog/au-revoir-france/

#DNS #InternetIntegrity #infosec

🔒 Aggiornato l'articolo sui DNS privati!

Abbiamo ricontrollato tutto. Via AhaDNS, che ha smesso di funzionare senza alcun annuncio: il sito è in errore e i server non rispondono più. Via anche Mullvad DNS, che chiude il 2 novembre:

Mullvad ora sostiene economicamente Quad9 e consiglia di usare quello.

Aggiornati DeCloudUs, RethinkDNS e AdGuard, sistemati link e app per Android e iOS.

AhaDNS l'abbiamo tolto anche da lealternative.it.

👉 https://blog.lealternative.it/2022/07/13/quali-dns-privati-utilizzare/

@lealternative@feddit.it

#update #dns

I came across a user mentioning the .irish TLD is owned by American capitalists, but that’s only the tip of this iceberg. Since I went down this road of “who is my TLD operator” already, here’s a brief introduction to the Identity Digital / Donuts empire.

Using a country, region or populace is a valid objection to ICANN. The outdoor brand Patagonia wanted .patagonia, but Argentina filed an objection and the brand withdrew their application.

I don’t see a single objection to .irish in the 2014 public comments, which is unfortunate. But a lot of sketchy and questionable things snuck through back then—.zip anyone?

A corporation shouldn’t own a nationality or diaspora TLD.

Where was the ICANN’s GAC (Governmental Advisory Committee)? Well..

Identity Digital, who now operates .irish, is a mess of companies, ironically originally founded in Ireland in 1999, now “operating” in Bellevue, WA, US. It was acquired by Afilias (who then owned irish) and later Donuts. All backed by American PE, Ethos Capital. If that PE firm sounds familiar, they tried to gain private control of .org for $1B in 2021.

And the CEO of this PE firm? Here’s a screenshot of his own LinkedIn, where he was previously ICANN’s President.

Your TLD owner and operator matter. The political control and financial damage a misaligned corporation can inflict is worrisome. My best recommendation is to pursue well governed and protected ccTLDs. Or a non-profit with an aligned mission statement, like .meow.

#dns #icann #tld

Si parla di:

Toggle

Per qualche giorno, a fine settembre 2026, è stato possibile ottenere un certificato HTTPS perfettamente valido per #google.com e #youtube.com senza mai aver violato un solo server di Google. Bastava impossessarsi del registro sbagliato: quello di un piccolo ccTLD nazionale. È la dimostrazione plastica di un rischio che gli esperti di PKI denunciano da anni, ma che raramente si materializza con un bersaglio così visibile: la #sicurezza del web non dipende solo da quanto è solida la tua infrastruttura, ma anche da quella del più debole dei domini che condividono la stessa catena di fiducia #DNS.

Tre registri nazionali, un’unica tecnicaIl 6 ottobre 2026 il #Chrome Secure Web and Networking Team ha pubblicato un resoconto in cui conferma di aver rilevato, nella settimana precedente, il compromesso di tre registri di domini di primo livello nazionali: .gh (Ghana), .sl (Sierra Leone) e .as (Samoa Americane). Google è stata chiara su un punto: “gli aggressori hanno compromesso i ccTLD di terze parti”, non l’infrastruttura di Google. Il problema è che un ccTLD compromesso espone chiunque possieda un dominio sotto quel suffisso, inclusi marchi globali che di quei territori non hanno nulla a che fare se non una registrazione difensiva o regionale.

Il meccanismo è concettualmente semplice e per questo pericoloso. Chi controlla i record DNS autoritativi di un dominio può superare qualsiasi procedura di domain control validation (DCV): le autorità di certificazione, per verificare che il richiedente sia il legittimo proprietario, chiedono tipicamente di pubblicare un record TXT con un valore casuale, oppure verificano la risposta su un percorso HTTP del dominio. Chi ha già in mano il DNS supera questi controlli senza sforzo, perché è lui stesso a decidere cosa rispondere. Una volta superata la DCV, la richiesta di un certificato di dominio validato (DV) a una CA pubblica è una formalità automatizzata, ed è esattamente qui che il sistema, pur funzionando esattamente come progettato, produce un risultato disastroso.

Cosa raccontano i log di Certificate TransparencyA ricostruire la cronologia sono stati i log pubblici di Certificate Transparency (CT), obbligatori per ogni certificato pubblico dal 2018 e proprio per questo diventati lo strumento principale di rilevamento di #abusi come questo. The #Hacker News, incrociando i dati con servizi come ctlogs.dev e #Cert Spotter, ha trovato che fino al 10 settembre le uniche emissioni legittime per i domini coinvolti erano quelle di Google Trust Services. Poi la sequenza si è rotta: il 22 settembre compaiono i primi certificati fraudolenti per il ccTLD .gh, il 25 settembre per .sl, il 27 settembre per .as. In tutto sono stati individuati 12 certificati per 7 nomi di dominio diversi, tutti di tipo DV: due per google.com.gh e youtube.com.gh, sei per il ccTLD .sl (google.sl, google.com.sl, youtube.sl) e quattro per .as (google.as, youtube.as). Undici sono stati emessi da Let’s Encrypt, uno da ZeroSSL.

Matthew McPherrin, rappresentante di Let’s Encrypt, ha confermato pubblicamente sul forum della CA: “sì, sono stati emessi certificati per Google e YouTube, e sono stati revocati”. Google, da parte sua, non attribuisce colpe alle autorità di certificazione coinvolte: nessuna delle due ha sbagliato alcunché, hanno semplicemente verificato un controllo DNS che, in quel momento, era davvero nelle mani sbagliate. I due certificati .gh e quello ZeroSSL sono stati revocati già il 26 settembre; i rimanenti nove certificati Let’s Encrypt sono stati revocati il 1° ottobre, quindi con un certo ritardo rispetto alla prima emissione fraudolenta.

Perché un certificato “vero” è più pericoloso di uno falsoUn certificato emesso legittimamente da una CA pubblica, anche se ottenuto con l’inganno, non genera alcun avviso nel browser: il lucchetto resta verde, la connessione risulta cifrata. Combinando il controllo del DNS con un certificato HTTPS valido per lo stesso dominio, un attaccante può costruire una pagina di phishing indistinguibile dall’originale o posizionarsi come man-in-the-middle su traffico che l’utente crede protetto end-to-end. Google ammette i limiti della propria visibilità: “non possiamo garantire che la nostra analisi abbia individuato tutti i domini coinvolti”, e conferma che sono stati compromessi certificati anche per “diversi marchi globali di primo piano e servizi online molto diffusi”, senza nominarli.

La risposta: CRLSet, revoche e un limite dichiaratoLa prima mitigazione è arrivata lato Chrome: Google ha bloccato l’utilizzo dei certificati fraudolenti per i propri domini tramite CRLSets, il meccanismo di revoca distribuito via aggiornamenti del browser che non richiede di contattare in tempo reale l’infrastruttura OCSP delle CA. In parallelo ha ottenuto dalle CA emittenti la revoca formale, estendendo la protezione anche a chi non usa Chrome. L’analisi dei log CT ha poi fatto emergere altre organizzazioni colpite, per cui Chrome ha aggiunto proattivamente ulteriori certificati alla blocklist, avvisando dove possibile i diretti interessati.

Ma lo stesso post di Google contiene un avvertimento che vale la pena leggere per intero, perché ribalta la narrazione rassicurante del “gli utenti Chrome non devono fare nulla”: “l’intervento lato browser non dovrebbe essere la misura su cui fare affidamento per proteggere i propri utenti”. In altre parole, chi possiede domini non può delegare la propria sicurezza TLS al fatto che Google se ne accorga e blocchi i certificati incriminati: la finestra di esposizione, prima che qualcuno individui l’abuso nei log CT, resta comunque aperta.

Cosa possono fare davvero i proprietari di dominiMonitorare in modo continuativo i log di Certificate Transparency per l’intero portafoglio di domini posseduti, inclusi quelli parcheggiati, regionali o acquisiti a scopo puramente difensivo: sono proprio i domini meno sorvegliati quelli più comodi da sfruttare.

Pubblicare record CAA (RFC 8659) che limitino esplicitamente quali CA possono emettere per il proprio dominio, vincolandoli dove possibile al proprio account tramite CAA Account URI binding (RFC 8657): questo impedisce che un attaccante, dopo aver perso il controllo del DNS, riutilizzi una validazione già in cache per emettere nuovi certificati. Il CAA non blocca l’emissione durante un hijack attivo, ma diventa decisivo subito dopo il ripristino del controllo legittimo.

In caso di certificato non richiesto scoperto nei log CT, inviare un Certificate Problem Report alla CA emittente: i Baseline Requirements del CA/Browser Forum impongono di indagare e dare una prima risposta entro 24 ore.

Ricordare che oggi una validazione di dominio può essere riutilizzata fino a 200 giorni (in calo a 100 da marzo 2027 e a 10 da marzo 2029): più lunga la finestra, più a lungo un hijack temporaneo del DNS può tradursi in emissioni fraudolente anche dopo la risoluzione del problema.

Resta sullo sfondo la domanda più scomoda, quella a cui né Google né le CA coinvolte hanno ancora risposto pubblicamente: come sono stati compromessi i tre registri ccTLD, chi c’è dietro e quanti altri domini, oltre ai sette individuati nei log CT, abbiano avuto certificati fraudolenti emessi a loro insaputa. Finché quella domanda resta aperta, ogni organizzazione che possiede proprietà digitali sotto un ccTLD gestito da un operatore terzo dovrebbe considerare il proprio DNS, non solo i propri server, come parte della superficie di attacco da sorvegliare.

Cronologia essenziale10 set 2026 - Ultima data nei log CT con sole emissioni legittime (Google Trust Services)
22 set 2026 - Primi certificati fraudolenti per il ccTLD .gh (Ghana)
25 set 2026 - Primi certificati fraudolenti per il ccTLD .sl (Sierra Leone)
26 set 2026 - Revocati i 2 certificati .gh e il certificato ZeroSSL
27 set 2026 - Primi certificati fraudolenti per il ccTLD .as (Samoa Americane)
1 ott 2026 - Revocati i restanti 9 certificati Let's Encrypt
6 ott 2026 - Google pubblica "Chrome's response to recent ccTLD registry hijacks"
7 ott 2026 - The Hacker News verifica indipendentemente i certificati via ctlogs.dev e Cert Spotter

Domini coinvolti (certificati DV, poi tutti revocati):
google.com.gh, youtube.com.gh
google.sl, google.com.sl, youtube.sl
google.as, youtube.as

CA emittenti: Let's Encrypt (11 certificati), ZeroSSL (1 certificato)
Fonti: Google (blog.google/security/chromes-response-to-recent-cctld-registry-hijacks), The Hacker News, BleepingComputer, Infosecurity Magazine.

Mullvad chiude i server DNS cifrati pubblici e sceglie di sostenere Quad9
#mullvad #Quad9 #DNS
Mullvad annuncia la chiusura dei suoi server DNS cifrati pubblici entro novembre 2026 e passa al sostegno di Quad9. Ecco cosa cambia per gli utenti.

https://www.marcosbox.com/2026/09/06/mullvad-chiude-dns-pubblici-quad9/

@opensource@diggita.com

Si parla di:

Toggle

Cinquantotto domini registrati, delegati ai nameserver del gruppo, ma senza un solo indirizzo IP associato. Invisibili a qualunque feed di reputazione, a qualunque sistema di blocklist automatica, a qualunque scansione passiva #DNS che cerchi record A da correlare a infrastrutture malevole già note. È la “riserva” di comando e controllo pre-posizionata che i ricercatori di Whisper #Security hanno mappato dietro Prince of Persia, il gruppo di #cyberspionaggio iraniano meglio noto come #Infy, attivo — con intermittenze significative — da oltre un decennio.

La frase che riassume meglio la scoperta è di Kaveh Azarhoosh, Community & Research Lead di Whisper, autore del #report: “Sono in stand-by, non live: nel momento in cui uno qualunque di questi domini ottiene un record di indirizzo, un nuovo server di comando è appena entrato in funzione — ed è visibile prima ancora che il server faccia alcunché”. È una descrizione precisa di cosa significhi, oggi, difendersi da un attore state-sponsored che ha imparato a costruire infrastruttura offensiva in anticipo, tenendola dormiente fino al momento dell’attivazione operativa.

Chi è Prince of Persia / InfyInfy (tracciato anche come Prince of Persia) è uno dei gruppi di cyberspionaggio iraniani più longevi e meno appariscenti sulla scena. A differenza di attori più aggressivi legati al Corpo delle guardie della rivoluzione islamica, Infy ha costruito la propria reputazione su campagne mirate e di lunga durata contro dissidenti, giornalisti e obiettivi ad alto valore, privilegiando la persistenza silenziosa alla distruzione visibile. È il profilo tipico dell’#intelligence offensiva pura: raccolta di informazioni, non sabotaggio.

Il gruppo era rimasto sostanzialmente silente per anni prima di riemergere, a partire da dicembre 2025, in una serie di report firmati SafeBreach che ne hanno ricostruito una decade di attività. La prima parte della ricerca SafeBreach ha documentato l’infrastruttura storica basata su Domain Generation Algorithm (DGA) e server di comando dedicati; una seconda parte, pubblicata a febbraio 2026, ha rivelato la migrazione verso un tasking basato su #Telegram, con i #malware della famiglia Foudre/Tornado e Tonnerre capaci di ricevere comandi sia via HTTP sia tramite bot Telegram, garantendo ridondanza operativa anche in caso di #takedown di uno dei due canali.

La prova del collegamento con Teheran: il blackout di gennaioUno degli elementi più interessanti dell’intera vicenda, emerso proprio nei report SafeBreach, è la correlazione temporale tra l’attività del gruppo e le decisioni delle autorità iraniane. L’8 gennaio 2026, per la prima volta da quando i ricercatori monitoravano l’infrastruttura, gli operatori di Infy hanno smesso di mantenere i propri server di comando — esattamente lo stesso giorno in cui il governo iraniano ha imposto un blackout internet a livello nazionale. Ancora più significativo: il 25-26 gennaio il gruppo ha ripreso a registrare nuovi domini DGA e a raccogliere dati esfiltrati, e il blackout è terminato ufficialmente il 27 gennaio. Un anticipo di un giorno che, secondo SafeBreach, è difficilmente spiegabile senza ammettere che gli operatori disponessero di informazioni privilegiate sulla tempistica di una decisione governativa — la firma indiretta ma solida di un legame con lo stato iraniano.

Cosa ha scoperto Whisper: l’architettura a due livelliPartendo dagli indicatori pubblicati da SafeBreach, i ricercatori di Whisper hanno costruito un grafo dell’infrastruttura di rete per risalire, da un piccolo insieme di indicatori noti, all’intera architettura di backend del gruppo. Il risultato è la mappatura di un sistema a due livelli concettualmente elegante e operativamente resiliente.

Il primo livello è quello dei server di comando attivi, che sono self-authoritative: ogni server esegue il proprio nameserver, così che dominio, indirizzo IP e infrastruttura di risoluzione DNS coincidano sulla stessa macchina. Un esempio concreto individuato dai ricercatori è il dominio dmxqdlcuiryu.site, che risolve a 45.80.148.195 — lo stesso indirizzo su cui gira anche ns1.dmxqdlcuiryu.site, il nameserver che lo gestisce.

Il secondo livello, quello davvero nuovo rispetto ai report precedenti, è la riserva dormiente: domini già registrati e già delegati ai nameserver del gruppo, ma privi di un record A. In pratica, l’infrastruttura di risoluzione è pronta e configurata, ma il “puntatore” finale verso un server fisico non è stato ancora attivato. Finché resta così, il dominio non compare in nessuna telemetria passiva basata su risoluzioni effettive, ed è per questo che sfugge ai sistemi di detection tradizionali basati su reputazione storica.

51 domini nel formato principale: otto caratteri alfabetici (range j-z), es. dmxqdlcuiryu.site

7 domini in un formato esadecimale più vecchio, riconducibile a un pattern di generazione precedente

TLD utilizzati: .site e .space (già noti), più due new entry rispetto ai report precedenti — .top e .website — che suggeriscono un ampliamento dello spazio del generatore di domini

Registrar comune: Spaceship, con privacy affidata a Withheld for Privacy — una coerenza che secondo Whisper “si legge come un singolo operatore che registra in blocco”

Hosting prevalente su HOSTGW (AS204641), un piccolo reseller rumeno, non confinato a un singolo blocco di indirizzi

A questo si aggiunge un server non presente nei report SafeBreach originari, 185.244.129.70, che al 13 agosto 2026 ospitava 18 domini generati dal DGA attivi contemporaneamente, e che presenta un’anomalia operativa interessante: si appoggia a un servizio DNS commerciale per almeno uno dei domini che ospita, invece di gestire in proprio la risoluzione come fa il resto dell’infrastruttura self-authoritative.

Segnali di crescita operativaTre elementi osservati durante il periodo di ricerca (dati infrastrutturali al 13 agosto, pubblicazione il 24 agosto 2026) indicano che l’infrastruttura non è statica ma in espansione attiva: il numero di domini live sul server 185.244.129.70 è salito da 17 a 18 nel corso dell’osservazione; la riserva dormiente è passata da 56 a 58 domini tra luglio e agosto; e la comparsa dei nuovi TLD .top e .website suggerisce che il generatore di domini del gruppo stia ampliando il proprio spazio dei nomi, verosimilmente in previsione di operazioni future.

Sul fronte del malware, l’arsenale documentato da SafeBreach e ripreso da Whisper comprende Tornado/Foudre come primo stadio di reconnaissance (con controlli anti-sandbox e comunicazione ridondante HTTP/Telegram), Tonnerre come infostealer di secondo stadio, e una catena ZZ Stealer che scarica una variante modificata di StormKitty — un infostealer open source rimaneggiato per esfiltrare screenshot, file del desktop e credenziali verso un canale Telegram dedicato. Le vittime mappate attraverso le esfiltrazioni intercettate nel periodo 2021-2024 coprono almeno 46 indirizzi IP distinti in una ventina di paesi, con concentrazioni significative negli Stati Uniti, in Russia e in Germania — a conferma di una targeting list ampia e non limitata alla sola diaspora iraniana o ai soli obiettivi mediorientali.

Due righe per i difensoriLa lezione operativa più importante di questo report riguarda il timing della difesa. Un’infrastruttura DNS pre-registrata ma dormiente non genera traffico, non compare nelle liste di reputazione, non attiva alcun sistema di detection basato su comportamento di rete: è invisibile fino al momento esatto in cui viene attivata, e a quel punto il difensore parte già in ritardo. Il valore del lavoro di Whisper sta proprio nell’aver reso pubblica questa riserva prima che diventi operativa, trasformando 58 domini “innocui” in altrettanti indicatori di early warning.

Per i team di threat intelligence e i SOC che monitorano organizzazioni potenzialmente nel mirino di attori legati all’Iran — ONG, giornalisti, ricercatori, obiettivi diplomatici o aziende con esposizione mediorientale — il consiglio pratico è di integrare nei propri sistemi di monitoraggio DNS passivo non solo le blocklist di domini già noti come malevoli, ma anche il pattern di naming e la lista dei 58 domini di riserva pubblicata da Whisper, così da ricevere un alert nell’istante stesso in cui uno di essi acquisisce un record A — prima ancora che il server dietro di esso inizi a comunicare con un impianto.

Indicatori di compromissioneGruppo: Prince of Persia / Infy (Iran, cyberspionaggio state-sponsored)
Ricerca: Whisper Security, "Prince of Persia: Mapping the Backend
and a Reserve of Domains Staged for What Comes Next" (24 ago 2026)
Basata su: SafeBreach "Prince of Persia" Part I (dic 2025) e Part II (feb 2026)

Server C2 pubblicati (self-authoritative):
45.80.148.195 (domini .site)
45.80.149.3 (domini .space)
185.244.129.70 (non riportato in precedenza; 18 domini DGA
attivi al 13/08/2026; usa DNS commerciale per
almeno un dominio, anomalia rispetto al resto)

Esempio dominio self-authoritative:
dmxqdlcuiryu.site -> 45.80.148.195
ns1.dmxqdlcuiryu.site -> 45.80.148.195

Riserva dormiente (nessun record A, delegati ai NS del gruppo):
58 domini totali

• 51 nel formato 8 caratteri alfabetici (range j-z)
• 7 nel formato esadecimale legacy
  TLD: .site, .space, .top (nuovo), .website (nuovo)

Registrar: Spaceship (privacy: Withheld for Privacy)
Hosting: HOSTGW, AS204641 (reseller rumeno)

Malware associato: Tornado/Foudre (recon, HTTP+Telegram C2),
Tonnerre (infostealer), ZZ Stealer -> StormKitty modificato
(canale Telegram di esfiltrazione dedicato)

Hash noti (SHA-256):
Tornado v51 SFX: 5db4ed7d07ab028ab6ceba8efec5f667d86a419020d2a8c86e90a3125aa31bb9
ZZ Stealer 3.81: f9b963235b954c521096256a10d8e8dce0092c9ca054e78dce3cac63756d0976
StormKitty var.: 4398063cd50c77b8d28f15c35b5948165b356f33dd7c4504eeac0c328fe97487

Raccomandazione: integrare la lista dei 58 domini di riserva nel
monitoraggio DNS passivo per rilevare l'attivazione di un nuovo
record A prima dell'inizio delle comunicazioni C2.

Recent events and a thought that had already been lingering in my mind for some time prompted me to register two new domains:

bsdcafe.eu
bsdcafe.it

The first is under European control, the second Italian.

Although as of today I have no reason for doubts or misgivings, having domains managed by European entities gives me a bit more peace of mind. How to put them to use will be a matter of reflection over the coming months.

Stay tuned!

#BSDCafe #Domains #DNS

Perché la risoluzione DNS su Linux è più complicata di quanto sembriChiunque amministri server Linux prima o poi si scontra con il fastidioso “Temporary failure in name resolution” o con un DNS che risolve alcuni domini e non altri. La causa quasi sempre non è il DNS in sé, ma la catena di componenti che sta tra un comando come curl e la vera query verso un nameserver: /etc/nsswitch.conf, /etc/resolv.conf, e — sulle distribuzioni moderne — systemd-resolved o NetworkManager che gestiscono tutto al posto nostro, spesso silenziosamente.

In questo articolo ricostruiamo l’intera catena di risoluzione dei nomi su Linux, i comandi giusti per ispezionarla e un metodo pratico per isolare il problema in pochi minuti, invece di procedere per tentativi.

L’ordine di risoluzione: nsswitch.confIl primo file da guardare non è resolv.conf, ma /etc/nsswitch.conf. La riga che interessa è quella che inizia con hosts:, tipicamente:

hosts: files dns myhostnameQuesto significa che il sistema consulta prima /etc/hosts (voce files), poi il DNS, e infine risolve il proprio hostname locale. Se un dominio dovrebbe risolvere correttamente ma non lo fa, e in /etc/hosts c’è una voce residua o sbagliata, il DNS non c’entra affatto: la query non arriva nemmeno a un resolver.

Chi gestisce davvero /etc/resolv.confSulle distribuzioni Linux di qualche anno fa, /etc/resolv.conf era un file statico che si editava a mano. Da Ubuntu 18.04 in poi, e su gran parte delle distribuzioni moderne (Fedora, molte immagini cloud di Debian/RHEL), quel file è generato dinamicamente — modificarlo a mano spesso non produce alcun effetto persistente, perché viene sovrascritto al prossimo evento di rete.

Il modo più veloce per capire chi ha il controllo è guardare cosa punta il file:

ls -la /etc/resolv.confSe è un file regolare, probabilmente la configurazione è statica.

Se è un symlink verso /run/systemd/resolve/stub-resolv.conf, il sistema usa systemd-resolved.

Se punta a /run/NetworkManager/resolv.conf, è NetworkManager a gestire il DNS.

Sapere quale dei due componenti è “al comando” evita l’errore più comune: editare resolv.conf a mano, vederlo funzionare per pochi secondi, e poi ritrovarsi la modifica cancellata al riavvio dell’interfaccia di rete.

Il formato di resolv.confnameserver 1.1.1.1
nameserver 8.8.8.8
search example.com
options ndots:5Alcuni dettagli spesso ignorati ma rilevanti in produzione:

nameserver — Linux ne considera al massimo tre; gli altri vengono ignorati.

search — suffisso di dominio aggiunto automaticamente a hostname “corti” (senza punti o con pochi punti).

options ndots:5 — controlla quando un nome viene considerato “già qualificato” e quando invece riceve il suffisso di search. È un parametro che in ambienti Kubernetes causa non pochi grattacapi, perché una query con pochi punti può generare fino a 5 lookup DNS prima di andare a buon fine.

systemd-resolved: il resolver locale che (quasi) nessuno vedeSulla maggior parte delle distribuzioni moderne, le query DNS delle applicazioni non vanno direttamente a Internet: passano per un listener locale su 127.0.0.53:53, gestito da systemd-resolved, che si occupa di caching e — dove configurato — di DNSSEC. Lo strumento per interagirci è resolvectl.

Stato completo per interfaccia

resolvectl status

Query esplicita tramite systemd-resolved

resolvectl query esempio.it

Svuotare la cache (utile dopo un cambio DNS o un test)

sudo resolvectl flush-caches

Statistiche su cache hit/miss

resolvectl statisticsPer impostare server DNS validi per l’intero sistema, indipendentemente dall’interfaccia attiva, si edita /etc/systemd/resolved.conf:

[Resolve]
DNS=1.1.1.1 1.0.0.1
FallbackDNS=8.8.8.8 8.8.4.4e si riavvia il servizio:

sudo systemctl restart systemd-resolveddig, getent e la differenza che fa risparmiare ore di debugIl tool principale per interrogare direttamente un server DNS è dig (pacchetto dnsutils su Debian/Ubuntu, bind-utils su Fedora/RHEL):

dig esempio.it
dig @8.8.8.8 esempio.it # interroga un resolver specifico
dig esempio.it MX # record di posta
dig esempio.it AAAA # IPv6
dig esempio.it NS # nameserver autoritativi
dig -x 104.21.1.1 # reverse lookup
dig +short esempio.it # output compatto
dig +trace esempio.it # ricostruisce l'intera catena, dai root server in giù
dig +dnssec esempio.it # verifica la firma DNSSECIl punto chiave, spesso sottovalutato: dig ignora completamente /etc/nsswitch.conf e /etc/hosts. Parla direttamente con un server DNS. Questo lo rende perfetto per isolare i problemi, ma pericoloso se usato come unico strumento diagnostico: dig può funzionare perfettamente mentre l’applicazione continua a fallire, perché il problema è nel percorso NSS (Name Service Switch), non nel DNS.

Per replicare esattamente quello che fa un’applicazione, si usa getent:

getent hosts esempio.itSe dig funziona ma getent no, il problema non è di rete: è nella configurazione NSS, in /etc/hosts, o nel modulo myhostname. È una distinzione che vale la pena memorizzare, perché sposta immediatamente l’indagine nella direzione giusta.

Un metodo, non solo comandi: la checklist di troubleshootingDi fronte a un errore di risoluzione, seguire un ordine preciso evita di girare a vuoto:

Controllare che /etc/resolv.conf contenga un nameserver valido e capire chi lo gestisce (ls -la).

Verificare che /etc/nsswitch.conf includa dns nella riga hosts.

Testare un resolver pubblico direttamente: dig @1.1.1.1 google.com. Se funziona, la rete verso l’esterno è a posto.

Testare il resolver locale: dig google.com. Se qui fallisce ma il passo precedente no, il problema è nella configurazione locale (systemd-resolved, NetworkManager, o un resolver aziendale irraggiungibile).

Controllare lo stato del servizio: systemctl status systemd-resolved.

Guardare gli assegnamenti DNS per interfaccia con resolvectl status — particolarmente utile in scenari con VPN e split-DNS.

Svuotare la cache con resolvectl flush-caches se si sospettano record stale.

Confrontare dig e getent: se divergono, il problema è nel percorso NSS.

Per fallimenti persistenti e inspiegabili, dig +trace ricostruisce l’intera catena di delega dai root server fino all’autoritativo, rivelando problemi come delegazioni NS rotte o glue record mancanti.

Split-DNS e VPN: un caso che confonde moltiCon una VPN aziendale attiva, resolvectl status mostra a quale interfaccia è associato ciascun dominio DNS. Se il dominio associato al link VPN è ~., quell’interfaccia diventa la route DNS predefinita per tutte le query. Se invece è qualcosa come ~interna.azienda.it, solo le query per quel dominio specifico vengono instradate sul tunnel — le altre continuano a passare per il resolver pubblico. Non riconoscere questa differenza è una causa frequente di “il sito interno non si risolve, ma internet funziona” o viceversa.

Fissare un DNS statico senza che venga sovrascrittoSu sistemi gestiti da NetworkManager, il modo corretto non è editare resolv.conf ma dire a NetworkManager di non sovrascrivere le impostazioni manuali:

nmcli con mod "Wired connection 1" ipv4.dns "1.1.1.1 8.8.8.8"
nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes
nmcli con up "Wired connection 1"Su sistemi con systemd-resolved, la via pulita è impostare DNS= e FallbackDNS= in resolved.conf, come visto sopra. Solo come ultima risorsa — ad esempio su container minimali senza questi servizi — ha senso rendere resolv.conf immutabile:

sudo chattr +i /etc/resolv.conf # blocca il file
sudo chattr -i /etc/resolv.conf # sblocca per un aggiornamento futuroQuale resolver sceglierePer server in produzione, affidarsi al solo router di casa/ufficio è rischioso: se il router si blocca o si riavvia, cade anche la risoluzione DNS di tutti i servizi a valle. Tra i resolver pubblici più usati in ambito professionale: Cloudflare (1.1.1.1 / 1.0.0.1, orientato a bassa latenza e privacy), Google (8.8.8.8 / 8.8.4.4, rete anycast molto ridondata) e Quad9 (9.9.9.9, che filtra domini noti per malware già a livello di resolver).

ConclusioneLa risoluzione DNS su Linux non è un singolo componente ma una catena — NSS, resolv.conf, systemd-resolved o NetworkManager, e infine il resolver remoto. La maggior parte dei problemi “misteriosi” si risolve rapidamente se si segue la catena nell’ordine giusto invece di riavviare servizi a caso. Tenere a mente la differenza tra dig (parla direttamente col DNS) e getent (replica il percorso reale delle applicazioni) è probabilmente il singolo accorgimento che fa risparmiare più tempo in debug.

Fonte: Linux Nameservers and DNS Resolution — LinuxBlog.io