On 28/09/2020 16:56, Paul Wouters wrote:
On Mon, 28 Sep 2020, 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.
And that's why DNS-Over-TLS (DoT) and DNS-over-HTTPS (DoH) are now
being deployed. And why browsers are, contrary to Michael Catanzaro's
wrong claim, overriding the system DNS already. See Mozilla's TRR
program https://wiki.mozilla.org/Trusted_Recursive_Resolver and
Google's chrome https://www.chromium.org/developers/dns-over-https
They solve very different problems though - they secure that
single hop but they don't verify the actual contents of the
records which are then resolved. They also break rather important
things like split horizon DNS on corporate networks. Hell even
my home network has split horizon, which is why I publish the
special record to stop firefox doing DoH.
I mean excuse me for being sceptical about the wisdom of the
likes of google trying to capture the world's DNS traffic by
baking their resolvers into chrome...
The real solution to the requirement for following spoofed DNS answers
to login to captive portals is to have a container with the "uplink"
and a sandboxed browser inside it handling the captive portal. Once
the captive portal part is done, you either use the network's DNS
server, or the user provided one. And maybe change it based on
testing the given DNS server in some way, using one of the ADD IETF
protocols. And only then mark the network as "up" to all other
applications. Or if the user prefers, only use the local DNS for
portal authentication and once there is a clean internet link, use
DoH or DoT to a known truted (non-coffeeshop) DNS server.
Spoofed DNS is one thing, but even once you're connected they
often manage to filter out critical data.
What I do know is that even on the personal and corporate networks
where I manage DNS and where I control everything systemd-resolved
is the first thing I've found where I've been happy to turn on
validation of DNSSEC without expecting things to break regularly.
I spent literally years periodically trying to turn on validation
in bind and quickly giving up again because it's so shockingly bad.
That's not so say systemd-resolved is perfect, it's not that long
since I provided a patch for it to fix a DNSSEC issue after all, but
it's pragmatic approach seems to be doing better than any of the
other things I have tried, be that bind, unbound, dnssec-trigger
or whatever.
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
_______________________________________________
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
