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"? 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. 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. 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... > 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.) > 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. 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. Lennart -- Lennart Poettering, Berlin _______________________________________________ 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
