CyberGreen DNS delegation health survey

What this is

CyberGreen runs a measurement survey of the health of the DNS delegations behind the websites of US health facilities. The list of domains comes from public US federal datasets of health facilities, matched to each facility's website.

For each domain, the survey checks whether its delegation is set up correctly and is resilient. It asks whether the parent zone and the domain's own nameservers agree, whether the nameservers answer over UDP and TCP and handle EDNS correctly, whether DNSSEC is deployed and valid, and whether the nameservers are diverse enough that one outage cannot take the domain offline. It also asks whether any of them answer queries they should refuse: open recursion and public zone transfers.

The results score each domain's delegation health from 0 to 100.

If you operate nameservers, you are probably seeing us because you serve DNS for one or more of these domains, or for the top-level domain above them.

Where the traffic comes from

The dedicated measurement host

Both addresses have reverse DNS that points to probe.cybergreen.net, and that name resolves forward to the same two addresses. The host is dedicated to this survey.

Google Cloud, for now and for some traffic permanently

Until the move of the DNS measurements to that host is complete, some or all of them come from Google Cloud's shared outbound addresses instead. Those addresses are shared with other Google Cloud customers and change over time, so we cannot list them, and their reverse DNS does not name us.

The lookups to domain registries described below will keep coming from Google Cloud even after the move. For those, the User-Agent string (where the protocol carries one) is how to recognize us.

Public resolvers

Some of our lookups go through the public recursive resolvers at 1.1.1.1 (Cloudflare) and 8.8.8.8 (Google). Your nameservers may see those queries arriving from those resolvers' addresses, not from ours.

What DNS traffic we send

All DNS traffic is to port 53, over UDP and TCP. Every packet is a well-formed DNS message. We never send to private, loopback, link-local, multicast or other non-public addresses, even when a zone's own data points there.

To the top-level domain (parent) servers

• NS for the domain, to read the delegation. We stop after two parent servers agree, and ask the rest only if they disagree.
• SOA for the parent zone.
• DS for the domain and DNSKEY for the parent zone, with the DNSSEC OK (DO) bit set.

To the domain's own nameservers

Ordinary queries are sent with recursion desired (RD) off and EDNS0 with a 1232-byte buffer. If a server returns FORMERR we retry once without EDNS, and if an answer is truncated (TC) we retry it over TCP.

• NS and SOA for the domain.
• DNSSEC queries with the DO bit set and a 4096-byte EDNS buffer: DNSKEY, SOA and NS. If the domain is signed, we also send CDS, CDNSKEY and NSEC3PARAM, and one A query for a random 16-letter name under the domain. That last query checks that the server returns a valid proof that the name does not exist.

To each nameserver address, we also send a short set of protocol-conformance probes. Each one is a single SOA query for the domain, with RD off.

The EDNS-version, unknown-option and cookie probes are only sent to an address that already answered the plain and EDNS0 queries correctly.

Two checks for things a nameserver should refuse

Zone transfer (AXFR). We send one AXFR request for the domain over TCP to each of its nameserver addresses. A correctly configured server refuses it. If a server starts a transfer, we read only the first response message, close the connection, and record only that the server allowed it. We do not keep or read the zone contents. There is no retry, and the request is skipped for an address that has already stopped answering our queries about the same domain.

Open resolver. We send one UDP query, A for the name xx., with recursion desired (RD) on, to each nameserver address. xx is not a real top-level domain, so an authoritative-only server should refuse or not recurse. A server that recurses, or makes up an answer, is reported as an open resolver. There is no retry.

Through public resolvers

To find each domain's zone and its nameservers, we send ordinary recursive lookups through the resolvers named above: SOA lookups walking up from the website's hostname, and NS, A, AAAA and MX lookups for the nameservers, the SOA's primary-server and contact names, and the nameservers' own domains. If the domain is signed, we also ask the resolver for its SOA with DNSSEC to see whether it validates.

What we do not send

No IXFR, no CHAOS-class queries (such as version.bind), no NSID requests, no client-subnet options, and no traffic to any port other than 53 on your nameservers. No ICMP, traceroute or port scanning.

Other traffic: registries and reference data

Domain registration lookups

Once an hour, a separate job looks up the registration record of the registered domain behind each website, and behind nameserver names in other domains. It reads only the expiry date, status and registrar. It does not read registrant contact fields.

• RDAP over HTTPS: one request per domain to the registry's RDAP server, found through IANA's bootstrap file at https://data.iana.org/rdap/dns.json. We fetch that file once per hourly pass.
• WHOIS over TCP port 43: only for top-level domains for which IANA lists no RDAP service. We send the domain name and a line ending, nothing else, so WHOIS carries no identifier.

Each domain is looked up again after about 24 hours. Domains near expiry or in an error state are looked up more often, down to hourly.

Each registry gets its requests one at a time, never in bursts. The rate starts at one request per second and stays between one every five seconds and five per second. Rejected or throttled requests halve the rate. We honor Retry-After, and wait 30 seconds when a throttling response (HTTP 429 or 503) has none. If more than half of the recent requests to a registry fail, we stop sending to it for five minutes, and put off the domains not yet tried for six hours.

These lookups come from Google Cloud (see above).

Reference data downloads

• The combined RIR delegation statistics file from ftp.ripe.net, over HTTPS: once per daily run, plus a 1-byte range request to check it is reachable.
• The GeoLite2 Country database from download.maxmind.com: once per daily run.
• Public routing-table archives from archive.routeviews.org: once a week. This uses a third-party tool (pyasn), which does not send our User-Agent.

What we never do

• No exploitation, fuzzing, or deliberately malformed packets. The unusual queries above (EDNS version 1, an unknown EDNS option, a mixed-case name) are standard conformance tests, each sent once.
• No authentication attempts, password guessing, or login traffic of any kind.
• No load or stress testing, and no measurement of amplification. Rate limits (below) exist to keep our load on any one server small.
• No attempt to change anything on your systems. Every query only reads.

How fast, and how often

Rate limits on queries to nameservers

Queries sent straight to nameservers (everything in the DNS section except the lookups through public resolvers) are paced with token buckets. Production uses these settings:

• The rates hold on average. A query that would wait more than 10 seconds goes out anyway, and the next queries to that target wait longer to make up for it.
• When an address, or a /24 or /48, stops answering after it has answered before, its rate is halved per step, down to a quarter of the figures above. Each minute without trouble gives one step back. The whole-survey rate never backs off.
• Separately, at most 10 domains under the same top-level domain query its servers at once, and at most 6 of one domain's nameserver queries run at the same time.
• A typical domain costs about 69 DNS queries in total, across the parent servers, its own nameservers and the public resolvers (measured in September 2026).

How often

The survey runs once a day, starting at 04:00 UTC, and checks at most 36,000 domains per run. Each domain is due for a check once a week. To spread the load, a domain can come due up to two days early.

How to opt out or report abuse

Email abuse@cybergreen.net. Please include:

1. The domain name(s), or the addresses or address range, the traffic concerns.
2. The time you saw the traffic, with time zone.
3. A sample of the log lines: source address, destination, and the query or request.

What happens next

Opting out works by domain name. An entry for a name covers that name and everything below it.

• We stop sending DNS queries about that name and everything below it, from the next daily run after the entry is recorded.
• We stop registration lookups for its registered domain from the next hourly pass. For example, an entry for clinic.example.com stops lookups of example.com. A registry holds nothing below the registered domain, so this may stop lookups for names that belong to others too. We prefer that to missing yours.

We cannot yet exclude a nameserver address or range by itself. If you run nameservers for many domains and want our queries to them to stop, send us the address range. We will reply with what we can exclude, which today means the domain names you serve.

User-Agent strings

Every HTTPS request made by the survey's own code carries one of these User-Agent strings, each ending in a link to this page:

Before this page was published, registration lookups identified themselves as del-checker-registration-monitor/1.0 (+mailto:del-checker-notify@trustabledns.com), and the other downloads carried shorter strings with no link. Those are the same survey.

DNS and WHOIS have no field for an identifier. For those, the reverse DNS of the source address is how to recognize us.