DNS
DNS-monitoring
Dat het oplost, en dat het antwoord precies is wat je verwacht.
Probeer het nu
Eén check, vanaf één plek, direct, en niets wordt opgeslagen. Een monitor checkt vanaf elke locatie waar we draaien en bevestigt een fout vanaf twee andere continenten voordat iemand wordt gewekt, wat één blik je niet kan laten zien.
Waar het voor is
Elke andere check in deze lijst hangt af van DNS, en DNS is het enige dat kan falen terwijl alles waar het naar wijst perfect gezond is. Een zone transfer die misging, een registrar panel dat iemand heeft aangepast, een verlopen delegatie: de site is online en onbereikbaar.
De fout die het waard is om voor te betalen is specifieker dan dat. Een record kan snel oplossen, vanuit elke resolver, en wijzen naar het adres van iemand anders. Niets dat controleert of DNS-antwoorden dit ooit zullen zien. Geef ons het antwoord dat je verwacht en wij controleren dat in plaats daarvan.
Zoals elke check hier draait het vanaf Amsterdam, New York, Sydney and Singapore, en een fout wordt bevestigd vanaf twee andere continenten voordat iemand wordt gewekt. Hoe dat werkt.
Wat je kunt instellen
Alles hieronder staat op het formulier wanneer je er een toevoegt, bij elk abonnement.
- Record
- A, AAAA, MX, TXT, NS, CNAME of SOA.
- Verwachte antwoord
- Leeg controleert of de naam überhaupt oplost. Ingevuld controleert het of het antwoord nog steeds klopt, wat de fout is die niets anders opvangt.
- Match
- Een van hen, of precies deze. Precies deze is de enige manier om te merken dat een record wordt toegevoegd in plaats van gewijzigd.
- Vraag deze resolver
- Noem je eigen authoritative server en je ziet een wijziging op het moment dat deze wordt gemaakt, in plaats van wanneer de resolver die we toevallig gebruiken zijn cache laat verlopen.
Vragen
Welke recordtypes kun je monitoren?
A, AAAA, CNAME, MX, TXT, NS en SOA staan op het formulier, en CAA, PTR en SRV worden ook geaccepteerd. De lijst is bewust korter dan alles wat DNS kan bevatten: elk record hier is er een waarvan een wijziging door een klant zou worden opgemerkt, en dat is de enige soort die een alert waard is.
Wat is het verschil tussen NXDOMAIN en SERVFAIL?
NXDOMAIN betekent dat de naam niet bestaat: een typfout, een verwijderd record, of een verlopen delegatie. SERVFAIL betekent dat de nameservers zijn gevraagd en geen van hen een bruikbaar antwoord gaf, wat een kapotte zone of servers die down zijn betekent. Een derde geval, waarbij de naam bestaat maar er geen record van dat type is, wordt apart gemeld, omdat alle drie verschillende oplossingen hebben.
Kun je me vertellen of een wijziging is doorgevoerd?
Gedeeltelijk, en het is de moeite waard om precies te zijn over wat propagatie is: niets verspreidt zich naar buiten, caches verlopen gewoon in hun eigen tempo. Checks worden uitgevoerd vanaf drie continenten, dus een wijziging die op de ene is aangekomen en niet op de andere verschijnt als een verschil. Stel je eigen autoritatieve server in en je ziet de wijziging meteen zodra die is gemaakt.
Zou dit een DNS-hijack opmerken?
Daarvoor bestaat deze check. Een record kan snel resolven, vanaf elke resolver, met een gezonde TTL, en wijzen naar het adres van iemand anders; niets dat alleen vraagt of DNS antwoordt zal dit ooit zien. Vul het antwoord in dat je verwacht en een record dat ergens anders naar wijst faalt binnen één interval.
Controleren jullie de TTL, of valideren jullie DNSSEC?
Nee, en dat zeggen we ook in plaats van iets anders te impliceren. De TTL is wat je zone aangeeft en hier wordt daar niets over gezegd, en DNSSEC-handtekeningen worden niet gevalideerd. Wat wordt gecontroleerd is het antwoord dat terugkomt en of het nog steeds het antwoord is dat je verwacht, wat de fout is die de rest van je monitoring niet kan zien.
Wat doet exact matchen dat matchen op alles niet doet?
Elk van hen slaagt wanneer je verwachte waarde ergens in het antwoord staat, wat is wat je wilt voor een naam achter een pool van adressen. Precies deze faalt wanneer er iets is toegevoegd, en toevoegen is hoe de schade meestal arriveert: een extra A-record of een extra MX naast die van jou is recordwijzigingsdetectie die niets anders oppikt.
Waarom niet dig vanuit een script draaien?
Dat kan, en voor het controleren van één record één keer is het het juiste hulpmiddel. Het probleem is dat er niet zoiets bestaat als hét antwoord: wat jouw resolver teruggeeft en wat een resolver in Sydney teruggeeft kan verschillen zolang een TTL duurt, en een script op één machine dat één resolver vraagt ziet één van die antwoorden. Dit vraagt vanaf vier continenten en kan gericht worden op een specifieke resolver, wat een lookup verandert in een vergelijking.
Mijn registrar mailt me wanneer een record verandert. Is dat niet genoeg?
Houd het, het is een echte check en het is de snelste manier om te ontdekken dat iemand in je eigen team iets heeft veranderd. Wat het dekt is het geval waarin de wijziging via je registrar is gegaan, wat degene is waar je je het minst zorgen over maakte. Het zegt niets wanneer een record wordt gewijzigd bij een provider die je ook gebruikt, wanneer een zone transfer fout gaat, of wanneer een resolver ergens iets teruggeeft dat je registrar nooit heeft gepubliceerd. Dat zijn de fouten die eruitzien alsof er niets mis is.