Fedora and fallback DNS servers [LWN.net]

Fedora and fallback DNS servers

Posted Feb 28, 2021 7:19 UTC (Sun) by NYKevin (subscriber, #129325)
In reply to: Fedora and fallback DNS servers by madscientist
Parent article: Fedora and fallback DNS servers

> In fact I just replace my home router last month and had this exact issue, where systems on my home network were not being seen/not available due to DNS problems.

Really? You have devices on your home network that are, completely automatically and with no human intervention, registering .home.arpa addresses, and the router has a DNS server which is letting them do that? That's amazing. I thought[1] this sort of thing was still just an IETF pipe dream. I hadn't realized people were actually going around implementing it.

[1]: I formed this impression by skimming RFC 7368, until I eventually realized that it is not a spec at all, but just a vague listing of the IETF's general aspirations for home networking on IPv6.

to post comments

Fedora and fallback DNS servers

Posted Feb 28, 2021 13:33 UTC (Sun) by madscientist (subscriber, #16861) [Link] (3 responses)

No. I don't see where I said anything like that.

I said that local systems could not see other systems on the local network because DNS was misconfigured to not use the local server, exactly as this proposal suggests should become the fallback behavior.

Fedora and fallback DNS servers

Posted Feb 28, 2021 18:25 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (2 responses)

OK. Well, people who are technical enough to run their own custom BIND server (or whatever it is that you're doing) can also figure out how to configure DHCP correctly. 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."

My assumption is that we start from the premise of "make it easy for non-technical users, and possible to configure for technical users." But perhaps you have a different set of priorities and if so, I don't think we have any common ground to debate.

Fedora and fallback DNS servers

Posted Mar 1, 2021 15:16 UTC (Mon) by madscientist (subscriber, #16861) [Link] (1 responses)

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?

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.