* Viktor Dukhovni: > The RFC requirement is more than optional, it is unrealistic. Doing > DNSSEC-validation in each application is not practical, there is no > broadly deployed (on all the BSDs, Linux, Solaris, ...) library that > does this, and each application would potentially need its own > implementation of RFC-5011 trust-anchor rollover, ... and the library > would need to evolve to add/deprecate DNSSEC algorithms in a timely > manner... > > It is much saner to delegate DNSSEC validation to the local resolver, > and trust its output. That resolver can track root key changes, > implement new algorithms, deprecated old ones, support administrative > "NTAs" (negative trust-anchors for work-arounds to known breakage), > set the AD-bit for local authoritative data, ... > > If you want to enhance the stub resolver in Glibc to be a validating > stub resolver, and return the AD bit only for validated data, feel > free, but Postfix is not about to do that internally.
No, our position on the glibc side is quite similar to yours. This has to be done by a separate daemon, and there are already several reasonable choices. Even disregarding DNSSEC, a small local caching resolver makes a lot of sense because name server selection in short-lived processes does not work well (and dealing with the file permissions for persistent in-process resolver state would be way too complicated). >> We looked at this and thought we needed the flag masking in glibc, >> with an explicit configuration decision (at the glibc layer) to mark >> the resolvers as trusted to handle the AD bit as expected. > > This may be appopriate for client applications which don't expect much > or any explicit administrator configuration. For an MTA like Postfix, > DANE is not yet the default policy, and we expect any administrator who > enables DANE to have taken the time to ensure the basic requirements are > met. And in the future, this could include the trust-ad option, right? >> The behavior is already configurable at the glibc layer. It does not >> make sense to me to add another knob to Postfix itself. > > I expect that "options trust-ad" is quite likely to be missing as > upgrades to 2.31 start happening in the near-term. That's true. It will be a while until the infrastructure support for setting it will be there. >> My worry here is that if Postfix (as the de-facto secure mailer) uses >> RES_TRUSTAD in this way, others will follow suit, and then libraries >> can no longer use the AD bit to indicate successful DNSSEC validation. > > Postfix will likely have more sophisticated handling of RES_TRUSTAD in > the 3.6 release circa Feb 2021, and perhaps by then NetworkManager and > the like will begin to have better management of the new resolv.conf > option (though I expect it will take some time for such changes to > show up in distributions). > > A better sequence of events would have been: > > 1. Glibc is updated to silently skip the "trust-ad" option > (perhaps it already skip unknown options...). It does. > 2. Software that manages resolv.conf(5) is updated to set the > trust-ad bit as appropriate > > 3. Some time goes by allowing for 2) to be widely deployed. > > 4. Glibc is updated to implement the "trust-ad" option, which > is in practice already set in resol.conf(5) when appropriate. Yes, but there's a bit of a chicken-and-egg problem here, as usual. > With the Glibc change as the first step, we have no choice but to > restore the status quo ante. True, but there are different approaches. If the administrator has enabled DANE, you could check whether RES_TRUSTAD is enabled, and if not, complain loudly that the configured name servers are not marked as trusted (and may not even support DNSSEC validation). This why we expose the RES_TRUSTAD flag via _res.options: not overwrite it, but to detect this situation. Maybe that's an approach that a future Postfix version could take?
