The Curious Case of aa.ns.charter.com – Mike Howells's Blog

Skip to content

The Curious Case of aa.ns.charter.com

Written by

Mike Howells

in

Active Directory & DNS

Or: how a stray entry in a Pi-hole log led me to a seven-year-old bug in Charter’s authoritative DNS.

It started with a line in a log.

I run Pi-hole on a couple of Raspberry Pis on my home network. It blocks ads and tracking and a long list of telemetry endpoints I’d rather not have my devices phoning home to. Most days I don’t think about it. But occasionally I pull up the query log just to see what’s flowing through, and I scan for anything that looks weird.

What caught my eye was this:

aa.ns.charter.com. Hourly. Blocked. From one of my domain controllers.

Charter is Spectrum, my ISP. The hostname looks like one of their nameservers. The query was coming from inside the house, so to speak. A Windows Server running Active Directory was asking my Pi-hole to resolve this name, on the hour, every hour, and Pi-hole was flagging it as blocked.

There are a lot of reasons something might end up in a Pi-hole log. Most of them are boring. This one looked boring at first. But I poked at it for a few minutes, and what I thought would be a five-minute mystery turned into something much more interesting.

This is what I found.

The setup

Let me sketch the environment, because some details matter and most don’t.

I run three Windows Server 2025 domain controllers on my home lab: SKYE, BOYD, and EMMA. They’re all on a flat 192.168.2.0/24 subnet. They handle Active Directory and internal DNS for a domain called howells.lan.

Outbound DNS from those DCs flows through two Raspberry Pi-hole instances, Pi3 and Pi4. The DCs forward to the Pis; the Pis run dnscrypt-proxy upstream, which uses encrypted DNS to Cloudflare, Quad9, and NextDNS. Pi-hole blocks anything that’s on one of its 33 adlists, and dnscrypt-proxy enforces strict DNSSEC validation on everything that gets through.

The whole pipeline is designed to be paranoid in a particular way: every external lookup is encrypted, validated, and filtered, with redundancy at every layer.

The query I noticed was hitting Pi3, logged against SKYE as the client (192.168.2.11), asking for an A record for aa.ns.charter.com. Pi-hole was returning 0.0.0.0 and marking it blocked.

My first thought was: which of the 33 adlists is catching a Charter nameserver hostname? That seemed odd. Adlists usually target ad networks and trackers, not ISP infrastructure.

The first wrong turn

Pi-hole has a built-in tool for exactly this question. It’s called "Find Domains in Lists." You type in a hostname and it tells you, definitively, which of your installed blocklists contain it.

I typed in aa.ns.charter.com.

Found 0 domains partially matching 'aa.ns.charter.com'.<br>Found 0 lists partially matching 'aa.ns.charter.com'.

Number of results per type:<br>- 0 exact domain matches<br>- 0 regex domain matches<br>- 0 allowlist (antigravity) matches<br>- 0 blocklist (gravity) matches

Zero.

So whatever was happening, it wasn’t a blocklist hit. Pi-hole was flagging the query as blocked, but no list of mine was telling it to. That’s interesting. Pi-hole doesn’t just block things on a whim. Something else was producing the "blocked" status.

I checked the response time in the query log. 69 microseconds for the A record. That’s not a real upstream lookup, that’s a cached or synthesized response. Whatever Pi-hole was doing, it was returning an answer almost instantly.

I looked at what the upstream resolvers actually said. From Pi3, I ran a direct dig against the dnscrypt-proxy upstream, and then bypassed it and asked Cloudflare and Quad9 directly:

$ dig aa.ns.charter.com A +short<br>0.0.0.0

All three resolvers, my dnscrypt chain, Cloudflare’s 1.1.1.1, and Quad9’s 9.9.9.9, returned the same thing. aa.ns.charter.com resolves to 0.0.0.0.

That changed the picture entirely. Pi-hole wasn’t blocking the query in the sense of consulting a list and refusing it. Pi-hole was receiving the authoritative answer 0.0.0.0 from upstream, recognizing it as a null/sinkhole address, and flagging it in the UI as a block. That’s a default Pi-hole v6 behavior: any A record that resolves to 0.0.0.0 (or AAAA to ::) gets treated as a blocked response, regardless of source.

So the question wasn’t "why is Pi-hole blocking this." The question was "why does aa.ns.charter.com resolve to 0.0.0.0, and why is my domain controller asking about it once an hour?"

Two questions, actually. I started with the second one.

Hunting the process

If something on SKYE was generating a DNS query every hour, I figured I could find it. Windows is reasonably well-instrumented for this kind of thing if you know where to look.

I started with active network connections. Get-NetTCPConnection, filtered to anything talking outbound:

RemoteAddress RemotePort OwningProcess<br>204.79.197.203 80 7956<br>23.11.32.159 80 7956<br>20.1.248.118 443 7956<br>20.59.87.225 443 2760

PID 7956 was making three outbound...