Ricerca DNS

Come funziona

1. Inserisci un dominio: digita un nome di dominio, inclusi i sottodomini, nel campo.
2. Seleziona i tipi di record: scegli quali tipi di record DNS interrogare: A, AAAA, MX, CNAME, TXT, NS, SOA o tutti.
3. Visualizza i risultati: i risultati vengono recuperati da un fornitore DNS-over-HTTPS pubblico e mostrati con i valori TTL e i dati dei record.
4. Diagnostica problemi: confronta i risultati di diversi tipi di record per identificare configurazioni errate, ritardi di propagazione o record mancanti.

Perché usare il lookup DNS?

I problemi DNS sono tra le cause più comuni di indisponibilità di siti web, fallimenti di consegna email e problemi di migrazione di dominio. Poter interrogare i record DNS direttamente dal browser, senza ricorrere a strumenti da riga di comando come dig o nslookup, è prezioso per sviluppatori, ingegneri DevOps e amministratori di sistema. Questo strumento interroga i record tramite DNS-over-HTTPS per privacy e bypass dei firewall. Usalo per verificare i record MX dopo un cambio di provider email, confermare i record A/CNAME dopo una migrazione DNS, controllare i record TXT per l'autenticazione SPF/DKIM e diagnosticare ritardi di propagazione.

Tipi di record DNS

• A, indirizzo IPv4 di un dominio
• AAAA, indirizzo IPv6 di un dominio
• MX, record dei server di posta per il routing email
• CNAME, alias di nome canonico che punta a un altro dominio
• TXT, record di testo per SPF, DKIM, verifica del dominio
• NS, server di nomi autoritativi per il dominio

40 anni di DNS: da RFC 882 a DNS over QUIC

Il Domain Name System è stato progettato da Paul Mockapetris alla USC/ISI e specificato in RFC 882 e RFC 883 (novembre 1983), sostituendo il file piatto HOSTS.TXT che ARPANET aveva superato. Il sistema è stato rivisto e formalizzato in RFC 1034 e RFC 1035 (novembre 1987), i documenti ancora citati oggi. Jon Postel ha coordinato l'assegnazione dei 13 nameserver root originali, etichettati da a.root-servers.net a m.root-servers.net, un numero fissato non dalla capacità ma dal limite di dimensione del pacchetto UDP di 512 byte dell'epoca. Due grandi shock hanno rimodellato il DNS in questo secolo. Nel luglio 2008, Dan Kaminsky ha divulgato un attacco di cache-poisoning che permetteva agli attaccanti di iniettare record falsificati nei resolver in pochi secondi. L'industria ha risposto con una patch coordinata (randomizzazione della porta di origine) e rinnovato interesse per DNSSEC (RFC 4033-4035, marzo 2005), che firma i record crittograficamente. Il secondo shock è stata la privacy: le query viaggiavano in chiaro sulla porta UDP 53 per 35 anni. DNS over TLS (DoT, RFC 7858, maggio 2016) avvolge le query in TLS sulla porta 853. DNS over HTTPS (DoH, RFC 8484, ottobre 2018) incapsula le query attraverso HTTPS sulla porta 443, nascondendo persino il fatto che il DNS sta avvenendo. DNS over QUIC (RFC 9250, maggio 2022) è il più recente, utilizzando lo stesso trasporto che alimenta HTTP/3. I resolver pubblici 1.1.1.1 (Cloudflare, lanciato il 1° aprile 2018), 8.8.8.8 (Google Public DNS, dicembre 2009) e 9.9.9.9 (Quad9, novembre 2017) supportano tutti DoH e DoT oggi.

Tipi di record in profondità

• A (RFC 1035). Indirizzo IPv4 a 32 bit. Un dominio può avere molti record A per il bilanciamento del carico; i resolver ruotano tra di essi (DNS round-robin).
• AAAA (RFC 3596, 2003). Indirizzo IPv6 a 128 bit. Pronunciato «quad-A». A partire dal 2024, circa il 45% del traffico di Google è IPv6.
• CNAME (RFC 1035). Alias: «segui questo nome e cerca i suoi record invece». Non può coesistere con nessun altro record allo stesso nome. È per questo che example.com non può avere sia un CNAME che un MX o A all'apice; le alternative moderne usano ALIAS o ANAME (specifici del fornitore) o record HTTPS (RFC 9460, 2023).
• MX (RFC 1035, aggiornato da RFC 7505 «null MX»). Server di scambio mail con un valore di priorità. Una priorità inferiore è preferita; le parità sono randomizzate. 0 . (RFC 7505, giugno 2015) dice esplicitamente «questo dominio non riceve mail», bloccando lo spam ai domini senza casella postale.
• TXT (RFC 1035). Stringhe di testo a formato libero. Ora porta autenticazione critica: SPF (RFC 7208, 2014), DKIM (RFC 6376, 2011), DMARC (RFC 7489, 2015), e verifica della proprietà per Google Search Console, Microsoft 365, sfide ACME (Let's Encrypt) DNS-01.
• NS (RFC 1035). Nomi dei nameserver autoritativi. Sempre almeno due per la ridondanza. I «glue record» nella zona padre forniscono IP così un resolver ricorsivo può raggiungere il nameserver senza ricerche circolari.
• SOA (RFC 1035). Start of Authority. Singolo record per zona che elenca il nameserver primario, l'email dell'admin (con il primo . sostituito da @), il numero seriale (incrementato sulle modifiche), refresh, retry, expire e TTL minimo.
• CAA (RFC 8659, 2019; originariamente RFC 6844, 2013). Certificate Authority Authorisation. Elenca quali CA sono autorizzate a emettere certificati per il dominio. Controllo obbligatorio per i requisiti baseline del CA/Browser Forum da settembre 2017.
• SRV (RFC 2782, 2000). Localizzazione del servizio: protocollo, priorità, peso, porta, host di destinazione. Microsoft Active Directory, XMPP, SIP, federazione Matrix utilizzano tutti record SRV per la scoperta del servizio.
• PTR (RFC 1035). DNS inverso. Mappa un IP indietro a un dominio. Vive nelle zone in-addr.arpa (IPv4) o ip6.arpa (IPv6). Richiesto da molti mail server per accettare email; un PTR mancante è un segnale spam comune.
• DNSKEY / DS / RRSIG (RFC 4034-4035). Impianto DNSSEC. Il DNSKEY pubblica le chiavi di firma della zona; DS nella zona padre è il puntatore crittografico «ecco il prossimo anello della catena»; RRSIG porta la firma effettiva per ogni set di record.

Dove il DNS lookup aiuta davvero

• Configurazione email su un nuovo dominio. Verifica che i record MX puntino al provider giusto (Google Workspace aspmx.l.google.com, Microsoft 365 example-com.mail.protection.outlook.com, Fastmail, ProtonMail). Controlla SPF (v=spf1 include:_spf.google.com ~all), DKIM (selector._domainkey), DMARC (_dmarc TXT).
• Migrazione del dominio e propagazione. Dopo aver aggiornato i nameserver presso il registrar, interroga sia i vecchi che i nuovi server autoritativi per confermare che la modifica si sia propagata globalmente. Resolver diversi memorizzano nella cache per durate diverse (il TTL è un suggerimento, non un contratto).
• Risoluzione dei problemi di certificato TLS / SSL. La sfida ACME DNS-01 usata da Let's Encrypt e simili richiede di posizionare un record TXT su _acme-challenge.example.com. Controlla il valore prima di attivare l'emissione del certificato per evitare sprechi di tentativi di rate-limit.
• Rilevamento del rischio di subdomain takeover. Un CNAME che punta a un servizio non registrato (app Heroku eliminata, bucket S3 rilasciato) permette agli attaccanti di registrarlo e servire contenuti sul tuo sottodominio. Un audit CNAME veloce cattura i puntatori penzolanti.
• Verifica CDN e bilanciatore di carico. Conferma che un dominio CNAME al giusto endpoint Cloudflare, Fastly, Akamai, CloudFront o Vercel dopo il deploy. Rileva quando staging punta accidentalmente alla produzione.
• Confronto DNS geografico. Alcuni siti servono record A diversi per regione (GeoDNS). Interrogare da endpoint DoH diversi (Cloudflare 1.1.1.1 vs Google 8.8.8.8) suggerisce come un utente a Francoforte vs Mumbai vede il sito.
• Sicurezza e risposta agli incidenti. Cerca record NS inaspettati (sequestro del registrar), record TXT sospetti o record MX aggiunti recentemente. Usa il numero seriale SOA per tracciare quando una zona è cambiata l'ultima volta.

Errori DNS che rompono siti ed email

• CNAME all'apice. RFC 1034 proibisce di mettere un CNAME su example.com stesso (solo su sottodomini come www.example.com). Cloudflare, Route 53, DNSimple lo aggirano con CNAME flattening o record ALIAS; Vercel, Netlify usano record di binding di servizio HTTPS (RFC 9460). Provarlo sul pannello DNS di un registrar basic rompe silenziosamente l'email.
• Dimenticare di abbassare il TTL prima di una migrazione. Se il tuo record A ha TTL 86400 (24 ore) e lo cambi la mattina del passaggio, i resolver in tutto il mondo continueranno a distribuire il vecchio IP fino a un giorno. Abbassa i TTL a 300 secondi alcuni giorni prima del cambio.
• Record SPF con troppi lookup DNS. RFC 7208 limita SPF a 10 lookup DNS per valutazione. Concatena troppe direttive include: e il tuo record SPF fallisce con permerror, che DMARC tratta come fallimento. Appiattisci o consolida con strumenti come SPF Surveyor.
• CNAME penzolante dopo lo smantellamento del servizio. Eliminata l'app Heroku ma il CNAME app.example.com punta ancora a example.herokuapp.com? Chiunque può registrare quel nome di app e ospitare il suo contenuto sul tuo sottodominio. Audita e rimuovi i CNAME orfani.
• Nessun record CAA. Senza un record CAA, qualsiasi CA nel WebPKI (~50 in tutto il mondo) può emettere un certificato per il tuo dominio. Blocchialo a una o due CA fidate: 0 issue "letsencrypt.org". Controllo CA obbligatorio da settembre 2017.
• Record wildcard che mascherano voci mancanti. Un record A *.example.com fa risolvere ogni sottodominio con errore di battitura, nascondendo errori di configurazione reali. Combina attentamente con regole MX esplicite per evitare spam agli indirizzi con errori di battitura.
• Mescolare DNSSEC e zone non firmate durante il cutover. Abilitare DNSSEC presso il registrar prima che i nuovi nameserver servano record firmati produce SERVFAIL per ogni resolver di validazione (Cloudflare 1.1.1.1, Quad9). Firma sempre prima, poi pubblica il record DS.

Altre domande frequenti

Strumenti correlati