On Mon, Jul 31, 2017 at 05:11:07PM +0000, Evan Hunt wrote:
> 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.
On Mon, Jul 31, 2017 at 02:16:37PM -0400, Paul Wouters wrote:
> Postfix is one but last I knew only when resolv contains localhost.
Not only Postfix, also Exim, and perhaps also Sendmail some day
if/when DANE support appears there, partial support is already
in the snapshot code:
ftp://ftp.sendmail.org/pub/sendmail/snapshots/sendmail.8.16.0.21.tar.gz
That code also relies on the (presumably configured local) resolver's
AD bit. In all three code bases making sure that the resolver is
actually local is up to the MTA administrator.
I expect this implementation strategy will be near universal.
> Software doesn't want to link against a dnssec library.
Correct. Software similarly also does not want to explicitly add
code to handle Kerberos, ... which is why various indirect approaches
are becoming popular for handling security "out of process". Having
a local resolver with a trustworthy "AD" bit is a feature, not a
bug.
The AD bit is exactly the right DNSSEC interface. All that's
missing from the traditional libresolv (and not missing from recent
innovations in res_ninit(), res_nsearch(), ...) is the ability to
specify the loopback address as the sole resolver in the application.
No matter how much some here might want to discourage the "AD" bit
interface, it is the main one that developers will use, if they
use DNSSEC security signalling at all. So it is up to the platform
vendors to improve security by delivering systems with a default-on
local validating resolver (that forwards to any upstream servers
that would otherwise have been used directly). This also improves
latency by bringing the cache closer to the application.
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
