denyfirst.

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.

Four 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 each of them will hand the whole zone to anybody who asks, 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. A server belonging to a provider is asked about this zone and never about its own behaviour: whether it hands out your zone is your exposure, and whether it answers for strangers is its operator's business.

The transfer is asked for and never taken. A server that restricts transfers refuses, and one that does not begins sending the zone — the reply's header says which, and the connection is closed there, before any of it is read. What that establishes is that the zone can be read whole; what is in it is not read, not counted and not reported. It is your data, and a scanner that copied it to tell you it was copyable would be the thing it is warning you about.

The last of the four 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 four only for a domain it has been shown control of, and it checks no other. The command line asks them too, and it also checks only domains proven to it, by the same record.

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:

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 the servers hold the same copy of the zone is reported too, and it comes out of the answers already in hand: each server that is asked whether it serves the zone says which serial it holds. A difference immediately after a change is ordinary and lasts as long as the transfer; one that stays means a server is no longer receiving the zone, and half the resolvers asking for it get the older copy. Nothing here grades it, because no document says how long a transfer may take.

Whether the zone can be read whole is reported and not graded, and that is RFC 5936 rather than caution. Section 5 says a general-purpose implementation ought to let an operator open transfers to everybody, while saying it must not be the default, and it says in as many words that the arguments for concealing a zone have been argued to be questionable. So no document calls an open transfer a fault. What the report says instead is what it costs: every name in the zone at once, including the ones nobody publishes a link to — and that this check did not take them.

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. Four 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 each of them will hand the whole zone to anybody who asks; 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. The transfer is asked for and not taken: the first reply's header says whether the server began one, the connection is closed there, and nothing the zone contains is read or reported. 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.