On Mon, 28 Sep 2020, Zbigniew Jędrzejewski-Szmek wrote:
This change is harmful to network security, impacts existing installations
depending on DNSSEC security, and leaks private queries for VPN/internal
domains to the open internet, and prefers faster non-dnssec answers
over dnssec validated answers. It fails various types of queries,
misimplements part of the DNS protocol. Not only according to me, but
to 20years+ developers of the bind software as well.
You're mixing a few different things here. We decided to not enable
DNSSEC in resolved with this change, at least initially. For most
users, DNSSEC is problematic because various intermediary DNS servers
found in hotspots and routers don't support DNSSEC properly, leading
to hard-to-debug validation failures. DNSSEC support in resolved can
be enabled through resolved.conf. This may be a reasonable thing to do in
an environment where the configured dns servers are known to support dnssec
properly.
If you want to do innovate new things with hotspot detection, the place
to do the protocol work is at the IETF Captive Portal Working Group:
https://datatracker.ietf.org/wg/capport/charter/
Work done there include an architecture docoument:
https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/
Captive Portal API: https://tools.ietf.org/html/rfc8908
DHCP and RA options: https://tools.ietf.org/html/rfc8910
These are efforts with big vendor signon. These will be compatible with
new hotspots and work similar to other network devices. This is
preferred over homegrown solutions.
leaks private queries for VPN/internal domains to the open internet
It's a complicated subject, but that statement is not true in general.
It was true when we had a DNSSEC systemd meeting in Brno about five years
ago when I raised it as a privacy issue and was told my use case was
"not valid". And it still seems to be true.
With Tommy Pauly of Apple, I co-write Split DNS for IKEv2 VPNs, that saw
a major discusison in the security area of IETF (specifically SAAG and
TLS) to ensure every one (including browser vendors) were okay with
the resulting DNS reconfiguration requirements of VPN servers. This
is especially important now that we are storing certificates as TLSA
records in DNS, storing encrypted SNI in DNS, and the current draft SVCB
and HTTPS service binding DNS records that are used in Apple's IOS14.
These records contain information that must not be vulnerale to spoofing
or rogue DNS server redirection and should be DNSSEC signed.
The designers of systemd-resolved will find it a useful read:
https://tools.ietf.org/html/rfc8598
systemd-resolved uses the servers it is told to use. Sometimes we're not
sure what to tell it, see https://bugzilla.redhat.com/show_bug.cgi?id=1863041
for a long discussion.
If that worked, I wouldn't have even found out that my system got
upgraded to systemd-resolved. Clearly this is broken. Furthermore,
I doubt the rhbz will take into account the various risks of
reconfiguring DNS and DNSSEC trust anchors or how to limit certain
forwarders to certain domains. We are not talking about bugs that need
fixing. We are talking about design decisions that I objected to five
years ago that are now starting to cause damage.
and prefers faster non-dnssec answers over dnssec validated answers
Not exactly. It uses a single server, unless the server is deemed non-responsive
and then it switches to the next one one, round-robin. Whether the server
does dnssec or not does not directly factor into this. (Except that if
resolved is configured to require dnssec, it won't want to talk to non-dnssec
servers.) If dnssec is enabled, it shall only accept validated answers.
This is better thant it was five years ago. I'm glad some things were
at least successfully conveyed in the Brno meeting. However, this still
leaks queries meant for the LAN or VPN onto the wide internet and is
still a privacy and security concern. Some of these issues might look
like minor unimportant bugs, but could be life changing for some people.
I recommend the systemd-resolved people look into the Human Rights
Protocol Considerations Research Group (https://irtf.org/hrpc) and its
draft documents.
Please file bugs if something is not working as it should. But please be
detailed, because there are a lot of unstated expectations based on how things
worked in the past that don't necessarily makes sense now.
My servers had functional DNSSEC. After an upgrade they don't. No more
detailed reports are needed. You know what you need to do to address
this bug. I see Florian had already filed a rhbz a few days ago:
https://bugzilla.redhat.com/show_bug.cgi?id=1879028
systemd-resolved should not be a required base system package. You know
what you need to do to fix this as well. If you want to make it part of
the graphical desktop install that is okay. But it must not be included
in server installs.
(Like with the name
servers accessible over vpn: some people think a server on vpn should be used
by default for *everything*, while others say that it shouldn't be used unless
configured so. Both options make sense depending on whom you trust more, but
resolved cannot guess by itself.)
See RFC 8598 for a detailed instruction on how you must implement this
for IKEv2 / IPsec VPNs. Other VPN technologies should do something
similar. It is very clear how you should act. And yes, some of that
might depend on the VPN provisioning configuration.
libreswan already implements support for the unbound DNS server to
reconfigure DNS limited to the domains covered by the VPN. This can be
extended to support systemd-resolved if you point me to a documentation
API.
Paul
_______________________________________________
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
