Proposed variable name is: use-connection-dns

Implementing details should be the responsibility of dnsconfd, maybe systemd-resolved or alternative dns NM plugin. But NM needs to specify along with global DNS server connection parameters, how it should work with other servers. Should not be in global-dns-domain-.mode or similar property, similar to global-dns-domain-*.servers? Update: nope, only once defined globally, static global-dns vs dynamic per link configurations only. (names in brackets are proposed values for use-connection-dns NM property).

• Exclusive (no) - global DNS server is used for everything, no other server is used. This is what Zero Trust architecture needs for its protective DNS server. This makes configuration static and does not require updates during machine lifetime. Static unbound + /etc/resolv.conf configuration is enough for this.
  • In fully static configuration, this would not work on networks requiring captive portal passing. If they block global DNS access until some action is done using local network specific servers, it will never get connected. Limited captive portal passing ability may need to relax this.
  • Explicitly specified VPN domains might still need to be sent to a different server. But such domains must be configured by a trusted administrator, not read from an unauthenticated network. Otherwise it would not be Zero Trust compliant.

• Exclusive+search (searches-only) - global DNS is used for all queries, but at least dns-search is used and applied into /etc/resolv.conf. This needs cooperation with NM and using some of the information provided by the network. IE. ipv[46].dns-search would be used, but  ipv[46].dns would not be.
  • This would still be Zero Trust compliant.
• Primary (subdomains) - global DNS is used for most queries. Connection provided dns-search domains would be redirected to link specified servers. This is a good default for more relaxed networks, I think the desired default for Fedora or RHEL desktops. This allows access to content existing only on local networks, but not on global servers. Very useful for split-tunneling, like our redhat.com internal domain when on VPN.
  • This can be achieved with systemd-resolved on Fedora, when -DefaultRoute is set to false on the link. Then interface servers are used only for search and routing domains.
  • Zero Trust incompatible. Allows hiding some zones from protective DNS.
  • Domains, which can be redirected this way, should be somehow restricted. While redirecting .lan or .internal zone is safe, redirecting .com would allow privacy leaks or forging responses for large part of domains.
  • Link domain list can be obtained from Provisioning Domains, RFC 8801: Discovering Provisioning Domain Names and Data, protected by TLS certificate. But not yet implemented in NM.
  • Some possible issues are described in RFC 6418: Multiple Interfaces and Provisioning Domains Problem Statement

• Backup+dual (yes) - global DNS is used together with link DNS servers for all queries. This is what systemd-resolved does when it has +DefaultRoute on the link.
  • Current default on Fedora, if the interface has also default route.
  • Advantage of this solution is it works the most often somehow, even if connection does not provide a complete list of connection specific domains.
  • Disadvantage is it reduces privacy significantly. Both global dns and link dns server receive complete resolution history.
  • This is what happens when systemd-resolved has specified DNS= server in resolved.conf
  • Such mode is not implemented by any other resolvers. Not possible in unbound, dnsmasq or bind9.
  • Zero Trust incompatible.
  • [pemensik] I do not think this should be used unless privacy reduction is explained well to the user. This DNS mode is not desired, although it is easiest to configure on Fedora with the default systemd-resolved now.

• Backup+iteration (yes) - global DNS is used most of the time, but it allows falling back to its own iteration from root hints in case a forwarder fails. Iteration can be prevented by restricting port 53 access to external servers, which is done in the Red Hat offices network.
  • Zero Trust incompatible. Iteration from root hints is explicitly mentioned, it must be disabled.
  • Implemented by classic DNS recursive servers, like unbound, bind9, knot-resolver or pdns-recursor. Not possible with dnsmasq or systemd-resolved.
  • Iteration from root hints do not yet allow full encrypted resolution, leaking possibly part of resolution.
  • Does leak less than Backup+dual however, if global-dns works.