Un report completo di delega e DNS
DNS e record
Lookup DNS Tutti i record DNS per qualsiasi dominio Lookup record A Indirizzi IPv4 di un dominio Lookup record AAAA Indirizzi IPv6 di un dominio Lookup MX Server di posta di un dominio Lookup NS Name server autoritativi Lookup TXT Record TXT, SPF, verifica Lookup CNAME Record di nome canonico (alias) Lookup SOA Record Start of Authority Lookup SRV Record di localizzazione dei servizi Lookup CAA Quali CA possono emettere certificati DNS inverso (PTR) Da indirizzo IP a hostname Verifica DNSSEC Il dominio è firmato e validato? Diagnostica DNS Un report completo di delega e DNSRecapitabilità email
Verifica SPF Valida il tuo record Sender Policy Framework Verifica DMARC Esamina e valuta la tua policy DMARC Verifica DKIM Trova e valida la tua chiave pubblica DKIM Verifica blacklist Verifica un IP rispetto alle blocklist email (DNSBL) Test SMTP Connettiti a un server di posta e verifica STARTTLS Verifica MTA-STS Policy TLS forzata per la posta in entrata Verifica BIMI Record del logo del brand per l'email Verifica TLS-RPT Policy di reportistica SMTP TLSRete e web
Verifica certificato SSL Esamina il certificato TLS e la scadenza di un sito Verifica header HTTP Esamina header di risposta, redirect e sicurezza Ping (TCP) Raggiungibilità e latenza su TCP Verifica porte Quali porte comuni sono aperteDominio
Lookup WHOIS Dati di registrazione per domini, IP e ASNUna diagnostica DNS esamina come un dominio è delegato e configurato dall'inizio alla fine, non solo un singolo tipo di record. Chiede ai server del padre (il TLD) cosa pubblicano per il tuo dominio, poi interroga direttamente i tuoi nameserver e confronta i due. Le discrepanze tra il padre e i tuoi server — glue mancante, liste di NS che non coincidono, seriali SOA non sincronizzati, nameserver lame o con ricorsione aperta — sono esattamente i problemi che causano un DNS lento, intermittente o silenziosamente rotto. IPeek esegue ogni controllo e ti spiega, in linguaggio semplice, perché ciascuno conta e come risolverlo.
Ogni interrogazione al tuo dominio parte dalla zona padre — il registro del TLD (per esempio .it o .com) — che custodisce i record NS che indirizzano i resolver verso i tuoi nameserver. Se quei nameserver risiedono dentro il tuo stesso dominio, il padre deve anche pubblicare i loro indirizzi IP come «glue», altrimenti i resolver finiscono in un circolo vizioso dell'uovo e della gallina. Una delega sana ha il padre e i tuoi server che concordano sullo stesso insieme di NS, con il glue presente dove serve. Quando non coincidono, alcuni resolver seguono informazioni obsolete e le tue modifiche funzionano per certi utenti ma non per altri.
L'RFC 2182 raccomanda più nameserver su reti diverse, in modo che un singolo guasto non metta mai il dominio offline. Ciascuno deve rispondere in modo autoritativo per la tua zona — un server «lame» che non lo fa è un buco di affidabilità silenzioso. I tuoi server autoritativi dovrebbero inoltre rifiutare la ricorsione agli sconosciuti: un nameserver con ricorsione aperta può essere sfruttato per il cache poisoning e l'amplificazione DDoS. IPeek interroga direttamente ciascuno dei tuoi nameserver per confermare che rispondano, che lo facciano in modo autoritativo, che concordino tra loro, che supportino il TCP e che tengano la ricorsione chiusa.
Il record SOA contiene il numero di serie della tua zona e i suoi valori di temporizzazione; ogni nameserver deve riportare lo stesso seriale, altrimenti la zona è desincronizzata e le modifiche si propagano in modo non uniforme. Il seriale dovrebbe seguire la convenzione YYYYMMDDnn, e i timer refresh/retry/expire/minimum dovrebbero rientrare negli intervalli raccomandati dagli RFC. Sul versante della posta, i record MX devono essere nomi host (mai IP nudi né CNAME) che risolvano a indirizzi pubblici. Infine, il dominio radice dovrebbe pubblicare un indirizzo ma non un CNAME, che l'RFC 1912 vieta accanto ad altri record.
Una ricerca DNS ti mostra i record visti attraverso un resolver ricorsivo. Una diagnostica va oltre: interroga direttamente i server del TLD padre e ciascuno dei tuoi nameserver, poi li confronta. Questo permette di individuare problemi di delega che una semplice ricerca nasconde: glue mancante, discrepanze di NS tra padre e figlio, nameserver lame o in disaccordo e seriali SOA non sincronizzati.
Il glue è l'indirizzo IP di un nameserver, pubblicato dalla zona padre accanto al record NS. È obbligatorio quando i tuoi nameserver sono dentro lo stesso dominio che servono (per esempio ns1.esempio.com che serve esempio.com), perché altrimenti i resolver dovrebbero risolvere il nameserver prima di poter risolvere qualsiasi cosa. Se in quel caso il glue manca, la risoluzione si rompe; se i tuoi nameserver sono su un altro dominio, il glue è opzionale e fa risparmiare solo una ricerca aggiuntiva.
I nameserver autoritativi dovrebbero rispondere solo per le zone che ospitano. Un nameserver che esegue la ricorsione per chiunque (un «resolver aperto») può essere sfruttato per attacchi di amplificazione DDoS ed è più esposto al cache poisoning. Se la diagnostica segnala ricorsione aperta, disattiva la ricorsione sul server autoritativo oppure separa i ruoli autoritativo e ricorsivo su host distinti.
Il seriale SOA è un numero di versione della tua zona. Quando i tuoi nameserver riportano seriali diversi, almeno uno serve dati obsoleti — di solito un secondario che non è riuscito a trasferire l'ultima zona dal primario. Il risultato sono risposte incoerenti a seconda del server che il resolver capita di interrogare. Controlla i trasferimenti di zona (AXFR/IXFR), la configurazione NOTIFY del primario e il timer refresh del SOA.
Nessuno dei due è un errore, ma entrambi sono punti singoli di guasto. Con un solo MX, la posta può andare persa se quel server resta giù abbastanza a lungo; un MX di backup aggiunge resilienza. Due nameserver è accettabile secondo l'RFC 2182, ma tre o più su reti diverse è più sicuro. La diagnostica li segnala come avvisi, non come errori — vale la pena migliorarli, non sono emergenze.