On Wed, Apr 15, 2020 at 10:08 am, Florian Weimer <fweimer@xxxxxxxxxx>
wrote:
* 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.
Well I've proposed it for everywhere, because it seems desirable to
have everywhere. But if Server or another product doesn't want it, we
could do Workstation-only. It's already been approved by the
Workstation WG.
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.
Hm, it sounds like this is the main outstanding issue from this
discussion. It is beyond my expertise. I guess we'll need a bug report
where the relevant experts can figure out whether we need to change
Kubernetes or systemd here.
You're right that continuing to use nss-dns would avoid any such
problems while maintaining the other benefits of systemd-resolved. That
could be a fallback plan if needed.
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.)
Well they were always serious security bugs, just bugs that we were
unable to solve without a local resolver. I don't think it's going to
require constant work. It's a problem already solved by NetworkManager
as long as you use either dnsmasq and systemd-resolved for DNS.
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).
It works out of the box, yes, and should work with any other VPN plugin
as well, at least for VPNs that create separate tun interfaces for each
connection like OpenVPN does. I think some VPN plugins might not do
that (AnyConnect?).
I hadn't considered discussing a Fedora OS change with infosec. Anyway,
the current behavior is insecure, and the proposed behavior is correct.
;) A sinkholing hack used by one company is nice to avoid some
phishing, but it's still just a hack, not something we should design
our OS around. And certainly not worth compromising the privacy of
Fedora users. That said, any company's IT department can change
whatever defaults they want on managed systems, configure
systemd-resolved however they please, disable it entirely, whatever.
It may also need to changes to Postfix (for DANE/TLSA handling in
particular, depending on the level of DNSSEC support, see below).
Based on Tom's mail, it sounds like this will be a problem. I guess the
simple solution is to mention this in the release notes and suggest
that users enable DNSSEC if running Postfix. We can also warn the
Postfix developers to document this problem. I guess that should
suffice?
libvirt may need changes as well, for its internal DNS relay.
I'm not familiar with this; what would require changes in libvirt? Are
you concerned about nss-libvirt?
The manual page resolv.conf(5) needs to be updated.
Good catch, I would have forgotten that.
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.)
I don't understand this. Why would an application have to link to
pthread to dlopen a shared object that uses it?
Michael
_______________________________________________
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
