I inherited an internal DNS namespace using the .local suffix and am planning to migrate it later. From a VM, querying the local stub resolver at 127.0.0.53 returns SERVFAIL for srv01.sym.local, but querying the authoritative internal DNS server at 10.16.1.1 works and returns 192.168.0.225. The failure appears related to how modern Linux systems handle .local through mDNS, though I also wonder whether DNSSEC validation could be involved because the internal zones are not signed. Is there a temporary centralized workaround, or would mDNS behavior need to be changed on every VM until the namespace is renamed?
3 Answers
If you need a replacement namespace, use a domain you control and delegate an internal subdomain from it. Names such as .internal or .home are commonly seen, but a registered domain or subdomain avoids collisions and gives you a cleaner migration path. The special-use .alt namespace also exists for private naming, although client and tooling support should be checked before adopting it.
As a short-term measure, disable or remove mDNS from the name-resolution path on the affected systems, such as through the relevant Avahi, Bonjour, or resolver configuration. This generally has to be applied where the resolver runs, so a firewall rule alone usually will not make the local stub resolver treat .local as ordinary unicast DNS. A centrally managed VM configuration or image change can reduce the work, but the long-term answer is still renaming the zone.
The main problem is the .local suffix. It is reserved for multicast DNS, so many Linux resolver stacks detect .local and send those queries to mDNS instead of forwarding them to your normal DNS server. That is why a direct query to 10.16.1.1 succeeds while the system resolver fails. DNSSEC is probably not the root cause here. The durable fix is to move the internal zone to a properly registered domain or another suitable internal namespace, then update clients and records.
That makes sense. I was hoping the broken behavior was just related to the DNSSEC change, but the mDNS handling explains why direct queries still work.
A firewall workaround is unlikely to be reliable because mDNS uses multicast and the resolver may simply fail when that traffic is blocked. It is better to change the resolver or mDNS settings temporarily.