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
There have been very vocal discussion at the IETF of browsers vendors vs enterprise vendors on how good/bad DNS reconfigurations are. Some discovery methods, and a protocol for Adaptive DNS by Apple have been discussed at the IETF ADD working https://datatracker.ietf.org/wg/add/documents/
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.
What we do not need is systemd-resolved making up its own incompatible and unsuspected protocols.
Paul