* Ben Cotton: > Enable systemd-resolved by default. glibc will perform name resolution > using nss-resolve rather than nss-dns. Is this intended for Fedora Server and others as well, or just Workstation? I assume it's for everywhere. > systemd-resolved has been enabled by default in Ubuntu since Ubuntu > 16.10, but please note we are doing this differently than Ubuntu has. > Ubuntu does not use nss-resolve. Instead, Ubuntu uses the traditional > nss-dns provided by glibc upstream, so glibc on Ubuntu continues to > read /etc/resolv.conf, as is traditional. This extra step is not > useful and not recommended by upstream. We want to follow upstream > recommendations in using nss-resolve instead. I cannot find documentation of the systemd stub resolver behavior: how it handles search list processing, and how it decides which upstream name servers to query. Most Kubernetes/OKD clusters assume that both single-label and multi-label query names are forwarded over DNS (contrary to ICANN recommendations), and that DNS servers are processed in listed order for all queries (no parallel queries, no randomized server selection). If systemd-resolved behaves differently, it can make Fedora incompatible with Kubernetes clusters. (This is one reason why glibc still not follows the ICANN recommendations.) With the Ubuntu approach, search list processing still resides within glibc, so their Kubernetes experience would not necessarily match ours. > === Split DNS === > > When systemd-resolved is enabled, users who use multiple VPNs at the > same time will notice that DNS requests are now sent to the correct > DNS server by default. Previously, this scenario would result in > embarrassing "DNS leaks" and, depending on the order that the VPN > connections were established, possible failure to resolve private > resources. These scenarios will now work properly. For example, > consider the scenario of Distrustful Denise, who (quite reasonably) > does not trust her ISP. Denise uses a public VPN service, > public-vpn.example.com, to hide her internet activity from her ISP, > but she also needs to use her employer's corporate VPN, > corporation.example.com, in order to access internal company resources > while working from home. Using the Network panel in System Settings, > Denise has configured her employer's VPN to "use this connection only > for resources on its network." Distrustful Denise expects that her > employer's VPN will receive all traffic for corporation.example.com, > and no other traffic. And while this mostly works in Fedora 32, she > discovers that it does not work properly for DNS: Will Fedora treat such cross-VPN leaks as security bugs going and forward and fix them? (I suspect it would require constant work, and lots of it.) Is this expected to work with the Red Hat VPN out of the box, or do we have to disable all this and use a custom configuration? Has this been discussed with Infosec? It looks like this will break their DNS sinkholing for domains such as REDHAT[.]CO (not COM). > == Scope == > * Other developers: This change requires coordination with the systemd > and authselect maintainers. It may also need to changes to Postfix (for DANE/TLSA handling in particular, depending on the level of DNSSEC support, see below). libvirt may need changes as well, for its internal DNS relay. The manual page resolv.conf(5) needs to be updated. Since libnss_resolve.so.2 is still linked against libpthread and we might not be able to remove libpthread from glibc as a separate library in time for Fedora 33, some applications may have to start linking against libpthread explicitly even though they do not actually need it. (This is due to a long-standing limitation of loading libpthread via dlopen.) > === DNSSEC === > > systemd-resolved's DNSSEC support is known to cause compatibility > problems with certain network access points. Per recommendation from > the systemd developers, we will change the default value of this > setting in Fedora from the upstream default `DNSSEC=allow-downgrade` > to `DNSSEC=no` by building systemd with the build option > `-Ddefault-dnssec=no`. The upstream default attempts to use DNSSEC if > it is working, but automatically disable it otherwise, allowing > man-in-the-middle attackers to disable DNSSEC. Sadly, even the > allow-downgrade setting suffers known compatibility problems. Because > Fedora is not prepared to handle an influx of DNSSEC-related bug > reports, we will disable this feature altogether. We anticipate that > enabling DNSSEC by default will not be possible in the foreseeable > future, or perhaps ever. Instead, enabling DNS over TLS (when > supported by the DNS server) seems likely in the near future. Will the built-in DNS server still support DNSSEC without validation, passing through the records if they are requested by the client over the DNS interface? The section above is not clear. Thanks, Florian _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
