DNS
DNS-Monitoring
Dass es aufgelöst wird und die Antwort genau das ist, was du erwartest.
Jetzt ausprobieren
Ein Test, von einem Ort, jetzt sofort, und nichts wird gespeichert. Ein Monitor prüft von jedem Standort, den wir betreiben, und bestätigt einen Ausfall von zwei anderen Kontinenten, bevor jemand geweckt wird, was ein einzelner Blick dir nicht zeigen kann.
Wofür es ist
Jeder andere Check in dieser Liste hängt von DNS ab, und DNS ist das eine, das fehlschlagen kann, während alles, worauf es zeigt, vollkommen gesund ist. Ein fehlgeschlagener Zonentransfer, ein bearbeitetes Registrar-Panel, eine abgelaufene Delegation: Die Seite ist online und nicht erreichbar.
Der Fehler, für den es sich lohnt zu zahlen, ist enger gefasst. Ein Record kann schnell aufgelöst werden, von jedem Resolver, und auf die Adresse von jemand anderem zeigen. Nichts, was überprüft, ob DNS antwortet, wird das jemals sehen. Gib uns die Antwort, die du erwartest, und wir überprüfen stattdessen diese.
Wie jeder Check hier läuft er von Amsterdam, New York, Sydney and Singapore, und ein Fehler wird von zwei anderen Kontinenten bestätigt, bevor jemand geweckt wird. Wie das funktioniert.
Was du einstellen kannst
Alles unten steht im Formular, wenn du einen hinzufügst, in jedem Tarif.
- Eintrag
- A, AAAA, MX, TXT, NS, CNAME oder SOA.
- Erwartete Antwort
- Leer überprüft, ob der Name überhaupt aufgelöst wird. Ausgefüllt überprüft es, ob die Antwort immer noch richtig ist, was der Fehler ist, den nichts anderes erfasst.
- Übereinstimmung
- Irgendeiner oder genau diese. Nur genau diese bemerken, wenn ein Eintrag hinzugefügt wird, statt geändert.
- Diesen Resolver fragen
- Gib deinen eigenen autoritativen Server an, und du siehst eine Änderung in dem Moment, in dem sie gemacht wird, statt erst wenn der Resolver, den wir zufällig nutzen, seinen Cache löscht.
Fragen
Welche Eintragstypen kannst du überwachen?
A, AAAA, CNAME, MX, TXT, NS und SOA sind im Formular, und CAA, PTR und SRV werden ebenfalls akzeptiert. Die Liste ist absichtlich kürzer als alles, was DNS speichern kann: Jeder hier ist ein Eintrag, dessen Änderung ein Kunde bemerken würde, und nur solche sind eine Warnung wert.
Was ist der Unterschied zwischen NXDOMAIN und SERVFAIL?
NXDOMAIN bedeutet, dass der Name nicht existiert: ein Tippfehler, ein gelöschter Eintrag oder eine abgelaufene Delegation. SERVFAIL bedeutet, dass die Nameserver gefragt wurden und keiner eine brauchbare Antwort gab, was eine kaputte Zone oder ausgefallene Server sind. Ein dritter Fall, bei dem der Name existiert, aber kein Eintrag dieses Typs vorhanden ist, wird separat gemeldet, da alle drei unterschiedliche Lösungen haben.
Kannst du mir sagen, ob eine Änderung propagiert wurde?
Teilweise, und es lohnt sich, genau zu sein, was Propagation ist: Nichts breitet sich aus, Caches laufen einfach in ihrem eigenen Tempo ab. Checks laufen von drei Kontinenten aus, sodass eine Änderung, die auf einem angekommen ist und auf einem anderen nicht, als Abweichung angezeigt wird. Gib deinen eigenen autoritativen Server an, und du siehst die Änderung stattdessen in dem Moment, in dem sie gemacht wird.
Würde das einen DNS-Hijack erkennen?
Das ist der Fehler, für den es existiert. Ein Eintrag kann schnell aufgelöst werden, von jedem Resolver, mit einer gesunden TTL, und auf die Adresse von jemand anderem zeigen; nichts, das nur fragt, ob DNS geantwortet hat, wird das jemals sehen. Gib die Antwort ein, die du erwartest, und ein Eintrag, der woanders hinzeigt, schlägt innerhalb eines Intervalls fehl.
Prüfst du die TTL oder validierst du DNSSEC?
Nein, und wir sagen das, statt etwas anderes zu implizieren. Die TTL ist, was deine Zone sagt, und das wird nicht überprüft, und DNSSEC-Signaturen werden nicht validiert. Geprüft wird die Antwort, die zurückkommt, und ob sie immer noch die ist, die du erwartest, was der Fehler ist, den der Rest deiner Überwachung nicht sehen kann.
Was macht das genaue Abgleichen, was das beliebige Abgleichen nicht macht?
Irgendeiner besteht, wenn dein erwarteter Wert irgendwo in der Antwort ist, was du für einen Namen hinter einem Pool von Adressen willst. Genau diese schlägt fehl, wenn etwas hinzugefügt wurde, und das Hinzufügen ist, wie der Schaden normalerweise kommt: ein zusätzliches A- oder MX-Eintrag neben deinem ist eine Erkennung von Eintragsänderungen, die nichts anderes erfasst.
Warum nicht dig aus einem Skript ausführen?
Das kannst du, und für das einmalige Prüfen eines Eintrags ist es das richtige Werkzeug. Das Problem ist, dass es so etwas wie die Antwort nicht gibt: Was dein Resolver zurückgibt und was ein Resolver in Sydney zurückgibt, kann sich so lange unterscheiden wie eine TTL, und ein Skript auf einer Maschine, das einen Resolver fragt, sieht eine dieser Antworten. Das fragt von vier Kontinenten aus und kann auf einen bestimmten Resolver gerichtet werden, was eine Abfrage in einen Vergleich verwandelt.
Mein Registrar schickt mir eine E-Mail, wenn ein Eintrag geändert wird. Reicht das nicht?
Behalte es, es ist eine echte Prüfung und die schnellste Möglichkeit herauszufinden, dass jemand aus deinem Team etwas geändert hat. Es deckt den Fall ab, bei dem die Änderung über deinen Registrar erfolgt ist, was der Fall ist, über den du dir am wenigsten Sorgen gemacht hast. Es sagt nichts, wenn ein Eintrag bei einem Anbieter geändert wird, den du ebenfalls nutzt, wenn ein Zonentransfer schiefgeht oder wenn ein Resolver irgendwo etwas zurückgibt, das dein Registrar nie veröffentlicht hat. Das sind die Fehler, die so aussehen, als wäre nichts falsch.