Postfix is one but last I knew only when resolv contains localhost. I think systemd-resolved also does various tricks but haven't looked at that in a long time.
Software doesn't want to link against a dnssec library. Hopefully we can get something smaller and better if we can use query-chains (via stubby, TLS, etc) that removes most of the DNS code from getting and processing a dnssec chain. Paul Sent from my iPhone > On Jul 31, 2017, at 13:11, Evan Hunt <e...@isc.org> wrote: > >> 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
