Provide a way to fallback to the DNS advertised by DHCP

[ShellCode33]

Component

systemd-resolved

Is your feature request related to a problem? Please describe

I don't want to default to using the DNS received from DHCP, because I don't trust them on public networks.

Yet I I'd like to be able to use it as a last resort if my main DNS is unable to resolve a given domain (because it is a local one)

I believe that such a feature would also help with captive portals, see #29869

Describe the solution you'd like

I think the best way would be to have a FallbackAdvertisedDNS=true in the configuration file.

DNS=9.9.9.9#dns.quad9.net 
FallbackDNS=1.1.1.1#cloudflare-dns.com
FallbackAdvertisedDNS=true

DNS would be used first, then FallbackDNS, then the advertised DNS.

Because most local DNS won't provide DoT, I guess an additional config key would be required to be able to downgrade the settings, something like AdvertisedDNSOverTLS=opportunistic.

Describe alternatives you've considered

An alternative could be to be able to enforce the order in which DNS servers are used.

man resolved.conf states the following about DNS= :

DNS requests are sent to one of the listed DNS servers in parallel

If I were able to set a DNSRespectOrder=true my DHCP DNS would be used as a last resort:

Link 5 (wlan0)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS DNSOverTLS=opportunistic DNSSEC=no/unsupported
       DNS Servers: 9.9.9.9#dns.quad9.net 192.168.1.3

But it would be a shame to have to disable parallel requests to be able to fallback to the advertised DNS, therefore I don't think this is a good solution.

The systemd version you checked that didn't have the feature you are asking for

254

[rpigott]

Multiple dns servers are available for redundancy. If you want more interesting zone forwarding run a local resolver like dnsmasq. The fallback dns servers are not intended for lazily merging dns zones, they are only used if no other server is known/available. sd-resolved doesn't fallback on nxdomain responses from an authoritative server.

If you already don't mind potentially sending your local domain queries to public nameservers, like your RFE does, then you would really rather just use separate .network configurations for trusted and untrusted networks to use the network advertised dns for trusted networks and a fixed dns otherwise. You can list trusted SSIDs in the Match directive if you like. This also won't incur any unnecessary traffic or timeouts. You will also likely want to consider the UseDomains, UseHostname, UseRoutes, etc. options that deal with other information advertised by a network.

[ShellCode33]

Thanks for your reply, I will investigate further.

[christophehenry]

Id on't really understand why this issue was closed. IMHO, there are many valid use-case to this option. One of them is to be able to both use the DNS provided by your internet provider's hardware to resolve names for devices on your local domaine and bypass lying DNS imposed by governement censorship. In such a use-case, Bind9 listening on 127.0.0.1:53 would have priority but systemd-resolved would fallback on DHCP-provided DNS to resolve names for devices on LAN.

Can this issue be reopened?

[Surferlul]

Another common use case I've encountered is public networks that require the use of a login page to access them. I need systemd-resolved to fallback to the network default so that I can open the network login page, but after my Internet access is enabled I want to use my private DNS.