I think the issue here is that the authenticity of an RRSIG RR doesn't really make sense without the RRset it covers, and RRSIG themselves are not signed (RFC 4035 section 2.2). The RRSIGs returned by the cache are there initially because they exist (as well as the RRsets they cover), but not because the RRsets they cover have necessarily been validated. I believe that the BIND resolver sets the AD bit if the RRset it covers has been validated (not simply exists in cache), even though it technically is undefined.
Now some guesswork to explain the behavior... From a clean cache, I make the following query: $ dig +dnssec forfunsec.org rrsig This returns two RRSIG RRs--one covering NS and one covering DS, and not AD bit. (Note that there are other RRSIGs returned if you query the authoritative server directly, but because the RRsets they cover aren't yet in cache, they are discarded [see RFC 4035 section 4.5]). Next I query the following, which validates the DS RRset for forfunsec.org: $ dig +dnssec forfunsec.org ds Then re-try the RRSIG query: $ dig +dnssec forfunsec.org rrsig Same result as before--two RRSIG RRs and no AD bit because the NS RRset is not yet validated. Now I validate the NS RRset: $ dig +dnssec forfunsec.org ns Then re-try the RRSIG query: $ dig +dnssec forfunsec.org rrsig Now the cache contains three RRSIGs (the DNSKEY RRset had to be validated to validate the NS RRset), and the RRsets covered by each has been validated, so BIND sets the AD bit. Of course, these RRSIGs are not really an "RRset", nor are they authenticated, but the data they cover is at this point. Regards, Casey _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
