At work we have 2 DNS servers (172…, 8.8.8.8.8). The problem is that we are supposed to use internal DNS for internal address recognition, but for some reason on Fedora 35/36 from time to time on my local ntb it sets 8.8.8.8 and sometimes 172.
I haven’t changed anything within the DNS configuration, I use systemd-resolved by default.
How exactly does systemd-resolved set the current dns server? Because, as was told to me, windows users have zero problems with this configurations.
[admin@fedora ~] $ resolvectl status
Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 3 (wlp0s20f3)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 8.8.8.8
DNS Servers: 172.16.53.8 8.8.8.8
Link 4 (virbr0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Link 7 (enp0s13f0u3u1)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
What method have you used in the past to tell the system which DNS resolver should be used for which names? It can’t guess that information
If you’re saying that only 172.16.53.8 should be used and never 8.8.8.8, then you should remove 8.8.8.8 from the configuration. If your system is being given that address via DHCP, then you’d need to configure the DHCP client to suppress that address so it isn’t handed to systemd-resolved.
You definitely don’t want to rely on any ordering behavior when there are multiple addresses, that will be unreliable.
Traditionally the primary DNS server is always used. The secondary DNS server is not used unless the primary is nto available (is the behavior specified by a RFC?)
But there’s no telling what Systemd does. Poettering makes some shit up as he goes.
I’m not aware of any mechanism in DHCP to indicate ‘primary’ or ‘secondary’; there’s just a list of IP addresses in an option in the DHCP response. If the one in the first position is supposed to be considered ‘primary’ that may be common practice, but not actually specified anywhere
Yeah, each zone should have a primary and one or more secondaries. See RFC 2182. According to the RFC, a client can select the best performing server. There’s no need to select the first server listed.
I think where OP is getting in the weeds is, his organization should specify two internal DNS servers, like 172.16.1.1 and 172.16.4.1 (on different LAN segments). Then, their local DNS servers should perform recursive lookups for the client using, say, 8.8.8.8 and 4.4.4.4. The organization should not configure Google as their secondary since Google does not know about their local installation.
That RFC is related to providing authoritative name service for a zone, not for providing recursive resolver service to clients. Very different part of the DNS world
But I do agree, if usage of the internal resolvers is necessary to resolve internal names, only the addresses of the internal resolvers should be provided in the configuration (whether static or dynamic).
thx for replies, i have no idea how it was in the past, i think that there was only one dns server. the idea behind adding 8.8.8.8 was to secure connection if case of drop out 172.16.53.8. I will try suggest to limit internal dns to resolving internal names only
Well, if the DNS resolver addresses are being delivered via DHCP, there’s no mechanism to do that. If you are configuring your system locally, then you can certainly configure systemd-resolved to only use the internal resolver for names that are in the internal zone(s).
I’m not a Systemd fan so please forgive my ignorance… Is it possible to configure Systemd to use something like mDNS first for local names, and then DNS as a fallback for remote names?
Yes, it is. systemd-resolved actually implements two similar protocols. LLMNR is enabled by default and is compatible with multicast protocol used also on Windows. It allows only resolution, but does not serve the name otherwise. mDNS (Apple compatible) IS supported by systemd-resolved, but is not enabled by default. Instead nss-mdns package exist, which provides mdns resolution plugins. CUPS network printing requires more features, which are not provided by systemd-resolved implementation of mdns. Avahi is used instead to serve mdns names under .local domain. But you can enable it by uncommenting #MulticastDNS=yes in /etc/systemd/resolved.conf.
It should be possible to create entry for just selected subdomains to target local server, but default root domain might then be served by multiple of equal servers. I am not sure if this can be configured in systemd-resolved in simple way.
I will provide example for dnsmasq then, where I am sure of sytax required.
This would tell dnsmasq to forward all queries to 172.16.53.8 or 8.8.8.8, whichever is now faster. With exception of any name ending with example.net, which would be forwarded to just single 172.16.53.8 server. Network Manager can integrate with dnsmasq quite well.
Similar setup would automatically provide also dnssec-trigger package with unbound.
It is just required that your network DHCP provides search domain, which would be considered local then.
