An answer proves nothing at all

Nobody thinks about DNS while it works. It appears in no risk register as an entry of its own, has no maintenance contract and no metric. Until a domain's resolution belongs to somebody else.

In March 2026 NIST reissued its guide to secure DNS operation, SP 800-81 in revision 3. The previous edition dated from 2013. We implemented the checks from it over the past days, and the instructive part was not what to check but how easily a check measures the wrong thing.

The expired contract as a takeover route

A zone names its own nameservers, and the parent zone names them too. Normally the two agree. Where they differ you have a lame delegation, and that is more than a cosmetic flaw.

When a contract with a DNS host expires, the zone disappears there. The host's name stays in the parent zone's delegation, because nothing changes there by itself. Anyone who now opens an account with that same host and creates exactly this zone takes over the resolution. The world keeps asking the same server, and it now answers for somebody else.

So the probe first checks what the parent says. What a zone claims about itself is secondary: what counts is the registry entry, because it decides where the questions go.

Why an answer proves nothing

An authoritative nameserver should be authoritative and nothing else. If it also answers questions about foreign names it is an open resolver: a reflector for flooding attacks and a surface for cache poisoning at the same time.

The obvious test is to query a foreign name, and if an answer arrives, the server is open. That test is precisely wrong. The code carries a table of real measurements explaining why:

Three of four servers answer, yet only one is open. The reason is unspectacular: the server queried may simply be responsible for the probe name itself. Pick a well-known domain whose zone happens to sit with the same provider and you get an answer that says nothing at all about recursion.

The distinction is not whether an answer comes back but what the answer's header says: is the server authoritative for this name, and does it offer recursion at all. Only both together yield a verdict.

Where you ask decides what you learn

With DNSSEC this continues. A zone's keys live in the zone content, so you have to ask the authoritative server, and without recursion, so the answer does not come from a cache. The record anchoring those keys in the parent zone sits precisely there instead, not in the zone itself. Ask the wrong server and a correctly signed zone looks unanchored.

And to see how a zone answers a question about a non-existent name, you need a name that certainly does not exist. So a random one.

A second rating instead of changed weights

The results feed a separate school-style rating for DNS infrastructure. Extending the existing domain rating with the new checks would have been the obvious move. One argument spoke against it, and it has nothing to do with DNS.

The existing rating is essentially an assessment of email security and is kept as history. Change its weights and every past rating shifts retroactively, every trend line kinks, without anything having changed on a single domain. For the same reason the new rating's weight table was complete from the start even though the checks arrived in three waves: that way each wave only added data and lowered a rating solely where a genuine flaw was found.

A metric that changes because the tool got better is worthless as a trend.

More on the attack surface management module page.