DNS Chronicles - Part 2

Mar 26, 2026

Sahil Dhiman

GNU/Linux Network Engineer

We’re back with another round of DNS observations from running authoritative and recursive name servers at Hopbox. If you haven’t read Part 1, the format is simple — short observations in no particular order, each with a dig output or packet capture to back it up.

As before, these come from serving ~240k queries/hour across 900+ sites. Some of these are amusing, some are mildly infuriating, and a few genuinely surprised us.

HTTPS/SVCB Records Are Showing Up More Than You’d Think

We started seeing HTTPS (type 65) queries hit our authoritative servers a while back, but the volume has been climbing steadily. Browsers — Chrome and Firefox in particular — now query for HTTPS records alongside A/AAAA as part of their connection setup. If you’re not serving them, you’re handing back NODATA responses all day.

$ dig @ns1.hopbox.net example-customer.com HTTPS +short
1 . alpn="h2,h3" ipv4hint=203.0.113.10 ipv6hint=2001:db8::10

The interesting part: most zones don’t have HTTPS records configured, so the majority of these queries result in empty answers. That’s a lot of wasted round trips. If you run an authoritative server, it’s worth checking how much of your query volume is type 65 NODATA.

$ dig @ns1.hopbox.net some-legacy-site.com HTTPS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41823
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
some-legacy-site.com.   3600    IN      SOA     ns1.hopbox.net. hostmaster.hopbox.net. 2026032401 3600 900 604800 86400

DNS-over-HTTPS Client Prevalence on Our Recursors

Our recursors see a mix of traditional UDP/TCP and DoH traffic. We enabled DoH on our PowerDNS recursors a while back, and the adoption curve has been interesting. A non-trivial chunk of queries now come in over HTTPS, mostly from browsers that have DoH enabled by default.

$ curl -s -H 'accept: application/dns-json' \
    'https://recursor.hopbox.net/dns-query?name=example.com&type=A' | python3 -m json.tool
{
    "Status": 0,
    "TC": false,
    "RD": true,
    "RA": true,
    "AD": false,
    "CD": false,
    "Question": [
        {
            "name": "example.com.",
            "type": 1
        }
    ],
    "Answer": [
        {
            "name": "example.com.",
            "type": 1,
            "TTL": 86400,
            "data": "93.184.216.34"
        }
    ]
}

What we didn’t expect: a measurable number of clients send DoH queries but don’t validate DNSSEC. They get the transport encryption but skip the data integrity layer. It’s like locking your front door but leaving the windows open.

TTL Abuse Is Everywhere

We’ve seen both extremes. Some zones set TTLs to 0 or 1 second, forcing recursors to re-query on every single lookup. Others set TTLs to 604800 (one week) or higher on records that change regularly, causing stale data to linger in caches long after the record has been updated.

The worst offender we’ve seen recently:

$ dig @ns1.example-cdn.com cdn-node.example.com A +noall +answer
cdn-node.example.com.   0       IN      A       198.51.100.50

A TTL of 0. On a CDN node. That means every single resolution hits the authoritative server. At scale, this is brutal — both for the authoritative servers and for the recursors that can never cache the answer.

On the other end:

$ dig @8.8.8.8 old-static-site.example.org A +noall +answer
old-static-site.example.org. 604800 IN A       192.0.2.100

A week-long TTL on what turned out to be a record that the owner wanted to migrate. They changed the IP, then spent a week wondering why some users still hit the old server. Classic.

EDNS Client Subnet Quirks

EDNS Client Subnet (ECS) is supposed to help authoritative servers return geographically appropriate answers by including a truncated version of the client’s IP in the query. In practice, it’s a mess.

Some recursors send ECS data, some don’t. Some send /24 prefixes, others send /20 or even /16. And a surprising number of queries come in with ECS set to 0.0.0.0/0, which is the “I have no idea where this client is” sentinel value.

$ dig @ns1.hopbox.net geo-balanced.example.com A +subnet=203.0.113.0/24

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; CLIENT-SUBNET: 203.0.113.0/24/24
;; ANSWER SECTION:
geo-balanced.example.com. 300   IN      A       198.51.100.10

versus:

$ dig @ns1.hopbox.net geo-balanced.example.com A +subnet=0.0.0.0/0

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; CLIENT-SUBNET: 0.0.0.0/0/0
;; ANSWER SECTION:
geo-balanced.example.com. 300   IN      A       198.51.100.99

The fallback IP in the second case is our “default” answer — usually a node with decent global connectivity. But it means ECS-unaware clients sometimes get suboptimal routing. We’ve been tracking ECS coverage rates and it varies wildly by upstream resolver.

Surprising NXDOMAIN Traffic Patterns

A solid chunk of our query volume — more than you’d expect — is for names that simply don’t exist. NXDOMAIN responses are a constant companion when you run authoritative DNS.

Some of it is expected: typos, old bookmarks, scanners. But the patterns get weird. We regularly see bursts of queries for random subdomains under customer zones:

$ dig @ns1.hopbox.net asdkjh3kj.customer-site.com A
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 52918
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
customer-site.com.      86400   IN      SOA     ns1.hopbox.net. hostmaster.hopbox.net. 2026031501 3600 900 604800 86400

This is almost certainly subdomain enumeration — someone (or some bot) is brute-forcing random subdomain names trying to discover hosts. It’s noisy, and while NXDOMAIN responses are cheap, the volume adds up.

The other common NXDOMAIN source: _dmarc, _domainkey, and other underscore-prefixed names that clients query for but the zone owner never set up. Email authentication records are the most commonly missing DNS records we see, by a wide margin.

$ dig @ns1.hopbox.net _dmarc.small-business-site.com TXT
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39104
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
small-business-site.com. 86400  IN      SOA     ns1.hopbox.net. hostmaster.hopbox.net. 2026022001 3600 900 604800 86400

That’s it for Part 2. We keep a running list of these observations and will keep publishing them as they pile up. If you run DNS infrastructure and have your own quirks to share, we’d love to hear about them.

v1.7.9