On Mon, Jul 31, 2017 at 09:57:11AM -0400, Paul Wouters wrote: > But we know people are already building software and systems that DO > trust the AD bit, even with non-localhost resolv.conf entries. This > saves them the overhead of adding a dnssec library to their application, > and saves them from running a system resolving understanding dnssec.
Are there applications specifically trusting AD=1 and behaving differently than with AD=0? Or are they just ignoring it and trusting every answer equally? I would have expected the latter, but I confess to being surprised if there are people going out of their way to implement "DNSSEC validation" by just buying whatever magic beans some dude in the forest has for sale. > > Some of the error codes might be trustworthy enough if you're using COOKIE > > or TCP; that would enusre at least that it wasn't an off-path forgery. > > That's a very small use case with pervasive monitoring and > coffeeshop and hotel wifi. In case I wasn't clear, I'm suggesting that TCP and COOKIE would be adequate protection for any error code where the worst case scenario is no worse than what any MITM can do. If you've already got control of the channel, then I can't see how sending the client "Prohibited" or "Lame" messages gives you any more of an advantage than you already had. However, any response that says anything about DNSSEC validity should be presumed guilty until proven innocent. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
