DNS
DNS monitoring
That it resolves, and that the answer is exactly what you expect it to be.
Try it now
One check, from one place, right now, and nothing is saved. A monitor checks from every location we run and confirms a failure from three continents before anybody is woken, which a single look cannot show you.
What it is for
Every other check in this list depends on DNS, and DNS is the one thing that can fail while everything it points at is perfectly healthy. A zone transfer that went wrong, a registrar panel somebody edited, an expired delegation: the site is up and unreachable.
The failure worth paying for is narrower than that. A record can resolve quickly, from every resolver, and point at somebody else's address. Nothing that checks whether DNS answers will ever see it. Give us the answer you expect and we check that instead.
Like every check here, it runs from Amsterdam, New York, Sydney and Singapore, and a failure is confirmed from three continents before anybody is woken. How that works.
What you can set
Everything below is on the form when you add one, on every plan.
- Record
- A, AAAA, MX, TXT, NS, CNAME or SOA.
- Expected answer
- Blank checks that the name resolves at all. Filled in, it checks the answer is still right, which is the failure nothing else catches.
- Match
- Any of them, or exactly these. Exactly these is the only way to notice a record being added rather than changed.
- Ask this resolver
- Name your own authoritative server and you see a change the moment it is made, rather than whenever the resolver we happened to use expires its cache.
Questions
Which record types can you watch?
A, AAAA, CNAME, MX, TXT, NS and SOA are on the form, and CAA, PTR and SRV are accepted as well. The list is deliberately shorter than everything DNS can hold: each one here is a record whose changing is something a customer would notice, which is the only kind worth an alert.
What is the difference between NXDOMAIN and SERVFAIL?
NXDOMAIN means the name does not exist: a typo, a deleted record, or a delegation that expired. SERVFAIL means the nameservers were asked and none of them gave a usable answer, which is a broken zone or servers that are down. A third case, the name existing with no record of that type, is reported apart from both, because all three have different fixes.
Can you tell me whether a change has propagated?
Partly, and it is worth being precise about what propagation is: nothing spreads outward, caches simply expire at their own pace. Checks run from three continents, so a change that has landed in one and not another shows up as a disagreement. Name your own authoritative server and you see the change the moment it is made instead.
Would this catch a DNS hijack?
That is the failure it exists for. A record can resolve quickly, from every resolver, with a healthy TTL, and point at somebody else's address; nothing that asks only whether DNS answered will ever see it. Fill in the answer you expect and a record pointing anywhere else fails within one interval.
Do you check the TTL, or validate DNSSEC?
No, and we say so rather than implying otherwise. The TTL is whatever your zone says and this does not assert on it, and DNSSEC signatures are not validated. What is checked is the answer that comes back and whether it is still the one you expect, which is the failure the rest of your monitoring cannot see.
What does matching exactly do that matching any does not?
Any of them passes when your expected value is somewhere in the answer, which is what you want for a name behind a pool of addresses. Exactly these fails when anything has been added, and adding is how the damage usually arrives: an extra A record or an extra MX beside yours is record change detection that nothing else catches.
Why not run dig from a script?
You can, and for checking one record once it is the right tool. The difficulty is that there is no such thing as the answer: what your resolver returns and what a resolver in Sydney returns can differ for as long as a TTL, and a script on one machine asking one resolver sees one of those. This asks from four continents and can be pointed at a specific resolver, which is what turns a lookup into a comparison.
My registrar emails me when a record changes. Is that not enough?
Keep it, it is a real check and it is the fastest way to find out that somebody on your own team changed something. What it covers is the case where the change went through your registrar, which is the one you were least worried about. It says nothing when a record is changed at a provider you also use, when a zone transfer goes wrong, or when a resolver somewhere returns something your registrar never published. Those are the failures that look like nothing is wrong.