On ansiblesrv01, querying srv01.sym.local through the local resolver at 127.0.0.53 returns SERVFAIL, but querying the authoritative DNS server at 10.16.1.1 directly returns 192.168.0.225. The environment inherited the .local domain, and I know it is not recommended because .local is reserved for multicast DNS. I plan to rename the domain eventually, but for now I need to understand whether this is caused by mDNS, DNSSEC validation, or resolver configuration—and whether every VM must be changed individually.
3 Answers
You generally cannot solve this reliably by changing only the authoritative DNS server. Each client’s resolver decides how .local is handled, so any workaround usually has to be applied to every VM or through the image/configuration management used to provision them. A firewall rule is not a dependable fix because mDNS uses link-local multicast and blocking it may create other problems while not changing the resolver’s name-selection behavior.
For a new internal namespace, use a subdomain of a real domain you own, such as internal.example.com. Names like .internal, .private, or .home are seen in existing networks, but they still are not as clean as using a domain under your control. The special-use status of .local is why relying on it tends to produce inconsistent behavior across operating systems and resolver libraries. Once the zone is renamed, update DHCP, search domains, certificates, automation, and any hard-coded hostnames.
The main issue is almost certainly the use of .local, not DNSSEC. Modern Linux resolver stacks commonly treat .local as an mDNS name and may send it to the multicast DNS service instead of forwarding it to your normal DNS server. That explains why the direct query works while the system resolver returns SERVFAIL. You can temporarily disable or remove mDNS handling on the affected systems, but the proper long-term fix is to move the internal zone to a registered domain that you control, or another suitable internal namespace.
That makes sense. I was hoping a central change could avoid touching every VM, but I’ll treat disabling mDNS as temporary and prioritize renaming the zone.