In your letter dated Tue, 21 Aug 2018 18:19:39 +0200 you wrote: >Ehm, we somehow forgot that this thread is supposed to be about DHCP, so >that's only the "uninteresting" case where you do trust the ISP and want >to use their DNS over a secure channel :-D
There are still plenty of use cases. An ISP may not want to run a recursive resolver and instead refer to a public resolver using DHCP. Additionally, on an open wifi, encrypting DNS traffic can help against snooping. So it is in the ISP's interest to announce that the local recursive resolvers support DoH >Well, DoT has been standardized for some time, and we now have multiple >open-source implementations for client- and daemon-side, and some large >public services support it. DoH is a little later, but it might gather >more speed eventually. From *my* point of view the SNI is the biggest >hindrance ATM; other technical issues don't seem bad, at least not for >most motivated users. (Finding a trusted service might be problem for >some people, I suspect.) For DNS, code is not enough. You need to get admins of recursive resolvers to upgrade. And there are lots of those resolvers. Many of them almost unmanaged. DNS is for a large part not end-to-end. You have the recursive resolvers as middle men. >Defense against changing DNS is something else than privacy - we have >DNSSEC for that, so you don't even need to trust the server sending you >the data, but I think we're getting too much off-topic anyway... DNSSEC is part of the puzzle, but leaves a lot of holes: - Currently very few systems ship with locally validating resolvers. So most systems can be attacked on the last mile. - Many domains are not signed for one reason or another. - Even with DNSSEC, an on path attacker can see the queries and selectively mount a denial of service attack. DoH protects the last mile from all of those attacks.
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
