Hi Paul, is there any generic protocol exchanging what (sub)domains should be targetted to specific DNS server? I know dnssec-trigger/unbound is able to send queries only to specified search domains received by DHCP server.
Are you aware of any implementation independent way to store domains for each interface? I think there should be just single way for connection provider to specify, which domains should go to its DNS server. Then any split-DNS capable software (unbound, dnsmasq, systemd-resolved) should just implement its layer to execute such redirection in runtime. Without special hooks in connection provider to running DNS stub. I doubt there is already generic interface, but it seems it SHOULD be created. Because connection should not be pushing anything to resolved. It should push it to (whatever) network manager and resolved should pull it from there. Can you point me to your support for unbound? Regards, Petr On 9/28/20 4:28 PM, Paul Wouters wrote: > 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 -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
