* Wietse Venema: > Florian Weimer: >> * Wietse Venema: >> >> > Vladimir Lomov: >> >> I'm a bit bewildered. Does this mean that all is Ok with glibc 2.31 with >> >> 'options trust-ad' and postfix 3.5.0 or it is depend strongly on used >> >> 'options'? >> > >> > This patch avoids the need to add options to resolv.conf. >> >> Does Postfix perform its own DNSSEC validation? I suppose not, >> otherwise you would not need the AD bit. > > Correct. Until now, Postfix asserts RES_USE_DNSSEC to request > validation in a resolver.
RES_USE_DNSSEC is unfortunately misnamed. All it does is set the DO bit in queries. This bit is named “DNSSEC answer Okay”. It was added after it was realized that some clients would choke on the records of unknown type that DNSSEC servers added to responses (unconditionally at first). However, “DNSSEC answer Okay” is also misnamed: The bit was introduced for the first version of DNSSEC. We are now to the second or third version (depending on how you look at it). If an older implementation (of the first DNSSEC version, or DNSSECbis without NSEC3 support) encounters current responses, they contain unknown records again because the record numbers have changed, so it's essentially the same situation that prompted the introduction of the DO bit. But these clients are obviously okay with that, otherwise we would have needed another DO bit to request the newer DNSSEC records. This tells me that DO is not really about DNSSEC in practice. It only means that the client indicates that it is (in some sense) modern and willing to discard unknown records and flags. As a side effect of setting DO in the query, AD becomes available. A second way to achieve that is to set AD in the query. > Postfix then uses the ad bit to trust that information is > authentic. The sysadmin has responsibility to ensure that (the path > to) their resolver is secure. But it often was not, so the AD bit is not a strong indicator. What we tried with the glibc change was to make sure that the AD bit is trustworthy. In general, we found no way to do this except through opt-in from the system administrator. If the operating system has a way to launch a preconfigured local DNS resolver (on 127.0.0.1), this mechanism needs to be enhanced to add the trust-ad option (perhaps after a review that the AD bit handling in that implementation is reasonable). I forgot to arrange for the second part to be implemented in Fedora 32 (and Debian), for which I need to apologize. I filed a NetworkManager bug here: <https://bugzilla.redhat.com/show_bug.cgi?id=1825285> cloud-init needs some work as well: <https://lists.launchpad.net/cloud-init/msg00267.html> And for Debian's resolvconf: <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958045> >> The intent of this change in glibc was that NetworkManager (or >> whatever generates /etc/resolv.conf) figures out whether the >> configured resolver performs DNSSEC validation and can be trusted to >> set the AD bit accordingly. > >> If you patch Postfix to add back the flag unconditionally, >> disregarding the name server trust status, then maybe handling the AD >> bit in this way was not such a good idea after all. > > My patch does not make security any worse than it was prior to > GLIBC 2.31. This is all I can do for stable Postfix releases: > ensure that shit does not stop working after an OS update. > > Any 'improvements' in Postfix DNSSEC support will have to be developed > in the Postfix 3.6 release cycle. The results from those 'improvements' > will never be merged back into Postfix 3.5 and earlier. I'm trying to understand why you were trusting the AD bit. Is it because you consider the requirement in the RFC to perform DNSSEC validation optional? 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. The behavior is already configurable at the glibc layer. It does not make sense to me to add another knob to Postfix itself. 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. (The -fcommon part of your patch is unrelated to all that, of course.)
