Overriding one name in a public domain without breaking the domain
A single internal zone for the domain makes the resolver authoritative for all of it, so mail and the public site start returning NXDOMAIN to everyone in the house.
Some of my services have the same name inside the house and outside it, and inside I want them to resolve to a LAN address instead of going out to the internet and coming back.
The domain is real and public, so the resolver on the LAN has to override individual names in it and leave everything else alone.
That’s easy to lose.
If you create an example.com zone on the internal resolver it becomes authoritative for the whole domain, and then the apex, www, the mail records and everything else you never thought about return NXDOMAIN to every client on the network.
One zone per name
So we need to give each overridden name its own primary zone instead.
A zone for ha.example.com holds one A record at its own apex and answers only for that name, while every other name in the domain still goes to Cloudflare.
The apex record is a plain address, because an apex can’t hold a CNAME.
Technitium’s proprietary ANAME would work, and a real address is simpler, needs no resolution at query time, and doesn’t depend on another zone being healthy.
dig +short @192.168.178.5 ha.example.com # 192.168.178.3dig +short @1.1.1.1 ha.example.com # 188.114.96.0The record that walks around the override
The A record isn’t the whole answer any more.
A name behind Cloudflare’s proxy is automatically issued an HTTPS record, type 65, carrying an ipv4hint and an ECH configuration, and a browser that asks for it will use what’s in there:
dig +short @1.1.1.1 ha.example.com HTTPSSo we publish an empty one in the override zone, and the internal answer then exists and says nothing:
ha.example.com. 600 IN TYPE65 \# 3 000100dig +short @192.168.178.5 ha.example.com HTTPS # 1 .If you want to check it, a bare 1 . is the answer, with no hints and no ECH config for a browser to follow past the override.
That name stays behind Cloudflare on purpose, so the strip is permanent and not transitional.
AAAA leaks out of a forwarder zone
The local zone is a Forwarder and not a Primary, and in a Forwarder zone a name holding only an A record doesn’t return an authoritative NODATA for an AAAA query.
It forwards the AAAA upstream, upstream has an answer, and the client gets the public IPv6 address of a name that’s supposed to be overridden:
dig +short @192.168.178.5 kasm.ig3.c.example.com Adig +short @192.168.178.5 kasm.ig3.c.example.com AAAAFive names do that here, and it’s harmless because this network has no IPv6 at all, so clients have nothing to prefer and they use the A record.
It’s worth knowing anyway, because turning IPv6 on would silently break those five and nothing else would change.
Names answered by a CNAME are immune either way, and a Primary zone returns NODATA properly.
Deleting an override is not deleting a line
I removed one of these and it kept answering.
The role that builds the zones only removes them during a full rebuild, and that loop is driven by the current list of overrides, so a name I’d deleted from the list was no longer in the list that decides what gets deleted.
There’s now a separate list of zones to remove, and entries can stay in it forever, because deleting a zone that isn’t there is not an error.
One thing that isn’t a problem
The domain has no DS record and answers come back without the AD flag, so it’s unsigned and these overrides break no chain of trust.