ad flag for RRSIG queries

[Casey Deccio]

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