DNS
Monitoraggio DNS
Che risolva, e che la risposta sia esattamente quella che ti aspetti.
Provalo ora
Un controllo, da un solo posto, subito, e nulla viene salvato. Un monitor controlla da ogni posizione in cui operiamo e conferma un errore da altri due continenti prima che qualcuno venga svegliato, cosa che un singolo controllo non può mostrarti.
A cosa serve
Ogni altro controllo in questa lista dipende dal DNS, e il DNS è l'unica cosa che può fallire mentre tutto ciò a cui punta è perfettamente funzionante. Un trasferimento di zona andato male, un pannello del registrar modificato da qualcuno, una delega scaduta: il sito è attivo e irraggiungibile.
Il fallimento per cui vale la pena pagare è più ristretto di così. Un record può risolversi rapidamente, da ogni resolver, e puntare all'indirizzo di qualcun altro. Nulla che controlli se le risposte DNS lo vedranno mai. Dacci la risposta che ti aspetti e controlliamo quella invece.
Come ogni controllo qui, viene eseguito da Amsterdam, New York, Sydney and Singapore, e un errore viene confermato da altri due continenti prima che qualcuno venga svegliato. Come funziona.
Cosa puoi impostare
Tutto ciò che segue è nel modulo quando ne aggiungi uno, su ogni piano.
- Record
- A, AAAA, MX, TXT, NS, CNAME o SOA.
- Risposta attesa
- Vuoto controlla che il nome si risolva. Compilato, controlla che la risposta sia ancora corretta, che è il fallimento che nient'altro rileva.
- Corrispondenza
- Qualsiasi di questi, o esattamente questi. Esattamente questi è l'unico modo per notare l'aggiunta di un record invece di una modifica.
- Chiedi a questo resolver
- Indica il tuo server autoritativo e vedrai una modifica nel momento in cui viene fatta, invece di aspettare che il resolver che usiamo scada la sua cache.
Domande
Quali tipi di record puoi monitorare?
A, AAAA, CNAME, MX, TXT, NS e SOA sono nel modulo, e anche CAA, PTR e SRV sono accettati. La lista è volutamente più corta di tutto ciò che DNS può contenere: ogni record qui è uno il cui cambiamento un cliente noterebbe, ed è l'unico tipo che merita un avviso.
Qual è la differenza tra NXDOMAIN e SERVFAIL?
NXDOMAIN significa che il nome non esiste: un errore di battitura, un record eliminato o una delega scaduta. SERVFAIL significa che i nameserver sono stati interrogati e nessuno ha dato una risposta utilizzabile, il che indica una zona rotta o server offline. Un terzo caso, il nome esistente senza record di quel tipo, viene segnalato separatamente, perché tutti e tre richiedono soluzioni diverse.
Puoi dirmi se una modifica si è propagata?
In parte, ed è importante essere precisi su cosa sia la propagazione: nulla si diffonde verso l'esterno, le cache semplicemente scadono al loro ritmo. I controlli vengono eseguiti da tre continenti, quindi una modifica visibile in uno e non in un altro appare come una discrepanza. Indica il tuo server autoritativo e vedrai la modifica nel momento in cui viene fatta.
Questo rileverebbe un DNS hijack?
Questo è il fallimento per cui esiste. Un record può risolversi rapidamente, da ogni resolver, con un TTL valido, e puntare all'indirizzo di qualcun altro; nulla che chieda solo se DNS ha risposto lo vedrà mai. Inserisci la risposta che ti aspetti e un record che punta altrove fallirà entro un intervallo.
Controlli il TTL o validi DNSSEC?
No, e lo diciamo chiaramente invece di implicare il contrario. Il TTL è quello che dice la tua zona e questo non lo verifica, e le firme DNSSEC non vengono validate. Ciò che viene controllato è la risposta che arriva e se è ancora quella che ti aspetti, che è il fallimento che il resto del tuo monitoraggio non può vedere.
Cosa fa il confronto esatto che il confronto generico non fa?
Qualsiasi di questi passa quando il valore che ti aspetti è presente nella risposta, che è ciò che vuoi per un nome dietro un pool di indirizzi. Esattamente questi fallisce quando qualcosa è stato aggiunto, e l'aggiunta è il modo in cui di solito arriva il danno: un record A extra o un MX extra accanto al tuo è una rilevazione di cambiamenti che nient'altro cattura.
Perché non usare dig da uno script?
Puoi farlo, e per controllare un record una volta è lo strumento giusto. La difficoltà è che non esiste una risposta unica: ciò che restituisce il tuo resolver e ciò che restituisce un resolver a Sydney possono differire per tutta la durata di un TTL, e uno script su una macchina che interroga un resolver vede solo una di queste risposte. Questo controlla da quattro continenti e può essere puntato su un resolver specifico, trasformando una ricerca in un confronto.
Il mio registrar mi invia un'email quando un record cambia. Non basta?
Tienilo, è un controllo reale ed è il modo più veloce per scoprire che qualcuno del tuo team ha cambiato qualcosa. Copre il caso in cui la modifica è passata attraverso il tuo registrar, che è quello di cui eri meno preoccupato. Non dice nulla quando un record viene modificato presso un provider che usi anche tu, quando un trasferimento di zona va storto, o quando un resolver da qualche parte restituisce qualcosa che il tuo registrar non ha mai pubblicato. Questi sono i fallimenti che sembrano non avere nulla di sbagliato.