Fedora and fallback DNS servers [LWN.net]

Fedora and fallback DNS servers

Posted Mar 1, 2021 15:16 UTC (Mon) by madscientist (subscriber, #16861)
In reply to: Fedora and fallback DNS servers by NYKevin
Parent article: Fedora and fallback DNS servers

I am definitely not running BIND. Every home router available these days has its own DNS service available. That doesn't mean everything always works.

> I believe this proposal is "use the DHCP DNS if one is provided, and only fall back to the public servers if DHCP gives us nothing usable."

That's not clear to me: it would be interesting to know exactly WHAT the removed behavior is. The article uses terms like "fallback mechanism" and "last resort", but without actually defining what these mean. Does that mean that if there's no DNS server _configured_ then the fallback is used, so if you have configured servers but they are wrong or don't work you're back to no DNS? Or does it mean if there's no DNS server _available_ (either no configured servers OR none of the configured servers respond to DNS requests) the fallback is used? If the latter, when is this checked?

Either way, things can still go wrong.

> My assumption is that we start from the premise of "make it easy for non-technical users, and possible to configure for technical users."

The premise we start from is "DNS is not working". If DNS does not work, because we don't get the right configuration via DHCP or for some other reason, what is the best thing to do?

to post comments

Fedora and fallback DNS servers

Posted Mar 5, 2021 10:12 UTC (Fri) by cortana (subscriber, #24596) [Link]

Does that mean that if there's no DNS server _configured_ then the fallback is used, so if you have configured servers but they are wrong or don't work you're back to no DNS

Yes, see resolved.conf(5):

FallbackDNS=

A space-separated list of IPv4 and IPv6 addresses to use as the fallback DNS servers. Please see DNS= for acceptable format of addresses. Any per-link DNS servers obtained from systemd-networkd.service(8) take precedence over this setting, as do any servers set via DNS= above or /etc/resolv.conf. This setting is hence only used if no other DNS server information is known. If this option is not given, a compiled-in list of DNS servers is used instead.

See also systemd-resolved(8) for a general description of how it resolves names via unicast DNS:

The following query routing logic applies for unicast DNS traffic:
If a name to look up matches (that is: is equal to or has as suffix) any of the configured routing domains (search or route-only) of any link, or the globally configured DNS settings, "best matching" routing domain is determined: the matching one with the most labels. The query is then sent to all DNS servers of any links or the globally configured DNS servers associated with this "best matching" routing domain. (Note that more than one link might have this same "best matching" routing domain configured, in which case the query is sent to all of them in parallel).
In case of single-label names, when search domains are defined, the same logic applies, except that the name is first suffixed by each of the search domains in turn. Note that this search logic doesn't apply to any names with at least one dot. Also see the discussion about compatibility with the traditional glibc resolver below.
If a query does not match any configured routing domain (either per-link or global), it is sent to all DNS servers that are configured on links with the DefaultRoute= option set, as well as the globally configured DNS server.
If there is no link configured as DefaultRoute= and no global DNS server configured, one of the compiled-in fallback DNS servers is used.
Otherwise the unicast DNS query fails, as no suitable DNS servers can be determined.