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
_______________________________________________
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
