Current DNS server systemd-resolved

At work we have 2 DNS servers (172…, 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 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
       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:
       DNS Servers:

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 :slight_smile:

If you’re saying that only should be used and never, then you should remove 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.

1 Like

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 :slight_smile:

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 and (on different LAN segments). Then, their local DNS servers should perform recursive lookups for the client using, say, and The organization should not configure Google as their secondary since Google does not know about their local installation.

Also see documents like Cisco’s DNS Best Practices, Network Protections, and Attack Identification.

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 :slight_smile:

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 was to secure connection if case of drop out I will try suggest to limit internal dns to resolving internal names only :slight_smile:

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?

I don’t believe resolved supports mDNS at all.

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.

# /etc/dnsmasq.d/servers.conf

This would tell dnsmasq to forward all queries to or, whichever is now faster. With exception of any name ending with, which would be forwarded to just single 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.