On 2013-03-20 at 07:55 -0400, Joe Abley wrote: > I think if an application wants to _rely_ on DNSSEC, then it should be > setting the DO bit and the CD bit, and doing its own validation.
This violates encapsulation and segregation of concerns. For an MTA with a caching validating resolver on localhost (since all but the validating part is common best practice today): If validation logic goes into an MTA, then the MTA needs to be updated to know about new signing algorithms, deal with yet more discovered flaws in DNSSEC handling, and generally process UDP data received over the network as the mail run-time user. By contrast, letting the DNS resolver handle validation lets the work be done right, by the experts, and updated accordingly. It lets trust anchor management be done by DNS software, not mail-software. It lets the cache, cache only the data that validates. Since all SMTP mail-servers need a DNS cache near them to perform at all acceptably, making sure that the cache is well managed and that the mail-server works cooperatively with the cache is critical. For Exim, we set DO, we check AD, and if the administrator sets things up insecurely, that's their problem. The most I might do is add a check that the resolver IP is 127/8 or ::1 or other local system IP address, (in Exim speak, matches the @[] addresslist) and require a second option dnssec_really_trust_offhost_validator when that doesn't match. Even that would be dubious, leading to more debugging issues and insecurity in practice, I suspect ... "DANE worked, until the localhost resolver failed and resolution failed over to the resolver on the machine next door, across a network with anti-spoof rules at the ingress". I don't see any way I'd be happy moving the rest of the validation logic into the MTA. We let Unbound do what Unbound is good at, and trust it. Exim works _with_ other systems and is already pretty damned large for a security-sensitive component, without deciding we can't trust any other part of the OS and its facilities and replicating them internally. In fact, I'm going to go so far as to say "Hell no!" -- we won't be smoking that crack. -Phil _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
