On Tue, 2020-09-29 at 10:19 +0200, Lennart Poettering wrote: > On Mo, 28.09.20 14:29, Simo Sorce (simo@xxxxxxxxxx) wrote: > > > On Mon, 2020-09-28 at 16:02 +0100, Tom Hughes via devel wrote: > > > On 28/09/2020 15:57, Marius Schwarz wrote: > > > > Am 28.09.20 um 13:47 schrieb Zbigniew Jędrzejewski-Szmek: > > > > > DNSSEC support in resolved can be enabled through resolved.conf. > > > > Why isn't that the default, if this resolver can do it? > > > > > > Because DNSSEC is a disaster area and if you try and use it > > > on random networks you're going to get failed lookups on a > > > reasonable number - it's fine if you're on a known network > > > with decent upstream servers but once you start going out > > > and using random WiFi hotspots and things it's a very > > > different story. > > > > Surely this is better solved by using DoH toward known good servers for > > anything but the local resources ? > > Well, but how do you determine "local resources"? The same way you do now for "routing", if a name is in the search for an interface it is "local", of course other better methods can come in the future via better NM integration. > Corporate networks tend to define local zones. Home wifi routers all > do, too. There's no clear way to know what can go directly to well-known > good DNS servers and what needs to be resolved locally. This is in contradiction with other mentions about routing here ? > Also, people would react very allergic if we'd start sending all DNS > traffic to google or so. I mean, you can't believe how pissed people > are that we have a fallback in place that if no DNS servers have been > configured at all or acquired via DHCP we fall back to Cloudflare + > Google DNS servers. I would be quite pissed too if you disclosed my DNS lookups to parties I do not trust with that data, and I definitely do not trust Google DNS servers as those queries are often hijacked at the local ISP level exactly because those are known IP addresses. > Downstream distros (Debian…) tend to patch that > fallback out even... I wouldn't want to know what happens if you start > telling them we should now *prefer* them over local DNS servers, which > is what you are saying here... Nah, I am not saying you should use DoT to random servers, it should still be user configured or discovered through things like DHCP if that information will ever be populated there. > > I mean the whole point of systemd-resolved should be to make things > > better including DNSSEC ? > > Yes, resolved implements DNSSEC. But from my experience I can tell you > it's very hard to do in a way resonably compatible with DNS servers > deployed out there in particular edge ones. Things mostly work, but > DNS servers are all broken in different ways, and we can't possibly > test things on all possible cheap wifi hw... > > (One thing I definitely want to add is an option to only do DNSSEC if > DoT is also done, under the assumption that a DNS server that is good > enough and new enough to implement the latter also should be able to > do the former sanely.) I think this is fine as an option. But let's not mix DNSSEC resolution with DNSSEC validation, they are very separate things. > > As it was already pointed out it is also reasonably simple to detect if > > the local network have bad DNS servers ... > > No, it's not. It's extremely difficult. Cheap wifi router DNS servers > are broken in so many ways. They return errors in some cases, freeze > in others, return rubbish in others, or not at all in even others. If > you ask the wrong questions anything can happen. We pretty carefully > tests and probe DNS servers but this still comes at the price that on > a particular bad implementation we might take a long time until we > figure out that DNSSEC simply is not possible. I did not mean to trivialize the technical means, but current DNS libraries tend to do a reasonable job already, you could simply just use one of them to offload the problem from your shoulders. There is little value for systemd-resolved to re-implement all of DNS handling any way, the value is in the central caching and smart resolving features. > The simple fact that some DNS servers don't respond at all if you ask > the "wrong" questions is already a problem: it means you have to wait > for a timeout (which means super long lookups initially) or do queries > in parallel. That however is a problem too since other DNS servers > really don#t like it if you ask them multiple questions at > once. Bombarding DNS servers with multiple questions all at once and > see if one "sticks" isn't a workable strategy hence either. > > And then, when you figured out that the local DNS server can do some > thing but not others, and are happy you will eventually notice that > many "edge" DNS servers have a split personality: for some domains > they are just a proxy for the upstream DNS servers and other domains > they implement things locally, which means the feature set you can > probe differs vastly depending on which domains you query. That's > particular awful for reverse lookups btw, since the domain separation > is a lot more blurry there. > > So I think we do quite well in resolved on the DNSSEC front actually, > but people still are annoyed that one some local DNS servers DNSSEC > doesn't work and or we take too long to detect that it doesn't. I think you can do better by leveraging the existing mature code for these annoying aspects, and focusing on the things a resolver is uniquely positioned to do instead. DNSSEC is still evolving (I've seen NSEC5 proposal for example, and more), let the DNS experts chase those things and just reuse that work. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc _______________________________________________ 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
