What the DNS check
reads, and what it cannot see.

The DNS check reads how a domain itself is served: the addresses it answers with, the servers its zone is delegated to, the record at the top of that zone, and whether the DNSSEC chain its parent anchors still holds. This page says what is read, what is graded and what is only reported, and the limits that apply to every check it runs.

What is read

Records the domain published for anyone to read. The addresses at the name (A and AAAA), the alias at it (CNAME) where there is one, the servers the zone is delegated to (NS) and the addresses of each of those, the record at the top of the zone (SOA), the text records (TXT), the digest the parent holds (DS) and the keys the zone publishes (DNSKEY).

Almost nothing is connected to. Every question above goes to the resolver the scanning machine already uses, so the domain being read sees none of it.

Three questions are put to servers directly, because a resolver cannot answer them: whether each server the delegation names answers for the zone as its own, whether a server inside the domain also answers questions about domains it has nothing to do with, and which servers the zone above this one hands out. Those go over TCP on port 53, to the addresses published for the servers in question, through the guard that refuses private, loopback and reserved destinations. Nothing else is sent, and no zone transfer is ever attempted. A server belonging to a provider is asked the first question and never the second: its behaviour is its operator's business, not this zone's.

The third goes to one server of the zone above — for example.dev, a server of dev — and asks it about this domain by name, with recursion off. What comes back is a referral: the list that zone hands out, which is what a resolver starting at the root actually follows. A resolver cannot be asked this, because it answers from the zone itself. Nothing about the zone above is reported.

An installation asks those three only where control of the domain has been proven; the command line asks them always, because it runs on the operator's own machine from their own address.

DNS cannot list what a domain publishes. There is no question that means "give me everything": a name and a type are asked for, and the answer covers that. Names beneath the one asked about — a subdomain nobody linked to — cannot be discovered by asking, and this check does not guess at them.

What is graded, and what is not

DNS carries more advice than any other part of the internet and fewer requirements. A serial number in a particular shape, a refresh timer inside somebody's preferred range: these are the "errors" other reports open with, and no document calls them errors. RFC 1912 calls its ranges recommendations, and a zone whose records are written by an interface has no reason to carry a serial a person can read.

Graded, because each one stops a resolver:

• Fewer than two name servers. RFC 1034 requires two, and RFC 2182 — a best current practice — says why: one server is one power supply and one maintenance window between a domain and everybody trying to reach it.
• Every server on one network. The same rule one step out. Judged by address prefix, because which company an address belongs to cannot be read from the address, and asking somebody else on every scan is not something this does.
• A server that resolves to nothing. RFC 1912 calls it a lame delegation: a resolver that tries it waits, then tries another.
• A zone above that hands out different servers. RFC 1912 asks for one list, not two. A resolver starting at the root follows the parent's, so a name only the parent hands out is where some lookups go, and whatever is at that address answers them — whether or not it still holds this zone.
• A DNSSEC chain that does not check out, and an alias at the top of a zone, which RFC 1034 and RFC 2181 both forbid.

Reported and not graded: the addresses, the servers and their addresses, the text records, the record at the top of the zone with its serial and its four timers, whether the zone is signed at all, which algorithm signs it, and a digest of a type this does not compute — which is said as that, never as a chain that failed.

Whether absent names are proved with hashed names or plain ones is reported too. Plain names let anybody list a whole zone by asking for one that is not there and following the answers; that is how DNSSEC worked before RFC 5155, nothing requires the hashed kind, and a zone whose names are not secret loses nothing by it. What is graded is only the one thing a document settles: the iteration count.

The DNSSEC chain

A signed zone publishes keys, and its parent — the registry above it — publishes a digest of one of them. A validating resolver follows that link down from the root, and if any step does not match it returns nothing at all: not the wrong answer, no answer. The domain stops existing for everybody behind such a resolver, which is most of the internet, while it keeps working perfectly for whoever runs it.

This check takes the keys the zone publishes, computes the digest of each the way RFC 4034 defines it, and compares that with what the parent holds. So the finding rests on arithmetic done here rather than on somebody else's opinion. What it does not do is verify the signature over every record: that is what a validating resolver does, and where the resolver says it did, the report says so as the resolver's word.

An alias, and a target that is gone

Where the name is an alias, the report says what it points at and whether that target exists. A target that has been deleted is worth a second look: the name resolves to nothing, and where the target is a name at a provider that hands out unclaimed ones — a bucket, an application, a page host — whoever claims it next answers for this name, and can obtain a certificate for it, because obtaining one takes answering for the name.

That is reported rather than graded. No document sets a rule about an alias whose target is gone, and a rule this project invented would be one nobody could argue with.

Everything here came from one resolver

Almost every answer here came from the resolver this installation uses, so what is reported is what that resolver returns today, which may be an answer it still holds from earlier. Three questions cannot be answered that way and are put to servers directly, over TCP on port 53, where this installation is allowed to ask them: whether each server the zone names answers for the zone as its own; whether a server inside the domain being checked — never one belonging to a provider — also answers questions about domains it has nothing to do with; and, of one server of the zone above this one, which servers it hands out for this domain. Nothing else is sent to them, and no zone transfer is attempted. That last answer is one server's, so a zone above whose own servers disagree would be read from whichever of them answered first. The DNSSEC chain is checked here by taking the digest of the keys this zone publishes and comparing it with what the parent holds; whether the signatures over every record verify is the resolver's work, and where it says it did that, the report says so as its word rather than as this program's.

What else is written down

This check has its own rule set, separate from the ones that grade a TLS handshake, a website and a domain's mail. What those can and cannot see is on the Transport page, the Reach page and the Mail page.

Every property this project holds itself to is in docs/invariants.md, and this check's is R24. What changed between rule sets is in docs/policy-changes.md.

What is recorded about a check here, and how to have a domain excluded, are on the privacy page.