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/
Si parla di:
Toggle
Cinquantotto domini registrati, delegati ai nameserver del gruppo, ma senza un solo indirizzo IP associato. Invisibili a qualunq
Altro...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
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
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!
Perché la risoluzione DNS su Linux è più complicata di quanto sembriChiunque amministri server Linux prima o poi si scontra con il fastidioso “Tempora
Altro...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.
resolvectl status
resolvectl query esempio.it
sudo resolvectl flush-caches
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
