DNS Monitoring

A DNS monitor asks for one record type on one name and reports what came back. It answers two questions: does the name resolve at all, and does it resolve to the value you expect. It says nothing about the service behind the name — that is a different monitor.

What It Is For

What It Is Not For

A DNS monitor reads a record. It never connects to whatever that record points at:

What Every Check Does

DNS is checked only from checkers, not from the PingZen server: from the Moscow checker by default, or from the checkers you choose in the monitor form. A monitor created without a checker through the API, MCP or a CSV import gets a public checker, Moscow first.

By default, one query for the record type you picked goes to Google Public DNS (8.8.8.8). If 8.8.8.8 times out, returns SERVFAIL for a reason other than DNSSEC, refuses the query or gives no usable answer, the check asks the same question once more through Cloudflare (1.1.1.1) and goes by its answer, so a hiccup at one resolver does not fail the check. NXDOMAIN, a missing record, a DNSSEC failure and an answer that differs from the expected values are final and are not asked again. When 8.8.8.8 fails and 1.1.1.1 answers without an expected value, the error message names both resolvers: Expected values not found: 9.9.9.9. Got: 1.2.3.4 (8.8.8.8: timeout 10 s; 1.1.1.1: answered).

With a DNS server of its own, the monitor asks only that server and goes by its answer. Either way, the check records:

• The resolved values — the full list of records that came back, kept with every check result
• Resolution time — how long the answer took, in milliseconds

By default the query goes through a public recursive resolver, so you see what the public internet sees, cached answers included. A record you changed a minute ago can take until the old TTL runs out to show up here. That is normally what you want from a monitor: it reports the answer your users are actually getting. With a DNS server of your own, you see that server’s answer instead.

Record Types

Those eight are the whole list. Any other type — SRV, CAA and the rest — is refused when the monitor is saved, through the API and MCP alike, with a message listing the supported types.

Expected Values

Leave the expected values empty and the monitor only asks whether the name resolves. Fill them in and every value you listed has to appear in the answer.

• Each value you list has to match a whole value in the answer. It is not a substring search and not a pattern.
• The answer may contain more than you listed. Two A records when you listed one is fine; the listed one just has to be there.
• If any listed value is missing, the check fails and the error message shows both what was missing and what came back instead, so you can see the new value without leaving the monitor.
• The resolved values are still recorded on a failed check, exactly as on a passing one.
• Names match in any case, with or without the trailing dot: Mail.Example.com matches the answer mail.example.com.. TXT values are compared exactly as written, case and spaces included. MX values carry the priority in front, so write it too: 10 mail.example.com.
• Up to 100 values per monitor.

Expected values are set in the monitor form, one value per line, and through the API or the MCP tools.

Status Logic

A DNS monitor is up or down. There is no degraded state and no slow-answer threshold — a lookup that takes a long time but returns the right answer is still up. An answer that differs from the expected values is DOWN and red like any other failure, but its badge reads “Answer differs” (“Mismatch” where space is short), so you can tell it from a name that stopped resolving.

Each of these failures has its own reason on the monitor page — “Domain does not exist”, “No record of this type”, “DNSSEC signature check failed”, “The domain’s DNS servers failed”, “No answer from public DNS”, “Your DNS server did not answer or refused”, “The answer differs from the expected values”. When the resolvers fail, the error message shows what each of them said, for example DNS servers failed for example.com (8.8.8.8: REFUSED; 1.1.1.1: SERVFAIL). Google’s 8.8.8.8 sometimes reports a broken DNSSEC signature as a plain SERVFAIL; the check then asks 1.1.1.1, and its answer names DNSSEC as the reason. With a DNS server of your own, its answer is final: 1.1.1.1 is not asked, and the error names your server, for example DNS servers failed for example.com (10.0.0.53: SERVFAIL).

Under the status header the page shows the Current answer card: the latest answer a check received, and the server the checks ask. When the answer differs from the expected values, the card shows which expected values are missing from the answer and which values are not in the expected list; if you changed the record yourself, Yes, accept the new answer makes the current values the expected ones. Any other failure gets a banner above the card with the reason in plain words and one next step.

One failed lookup is not an outage: as with every monitor, DOWN is confirmed only after several failing checks in a row, three by default. See incidents for what happens next.

Configuration

Key Features

• Eight record types: A, AAAA, CNAME, MX, TXT, NS, SOA and PTR
• Optional expected values, with the missing and the actual values both shown on failure
• Resolved values and resolution time recorded on every check, passing or failing
• A plain reason and one next step for each way a lookup can fail, instead of one flat “down”
• Sees the answer a public resolver gives, which is the answer your users get
• Can ask your own DNS server instead, an address in a local network too, through your private checker there