[nsd-users] wildcard+ANY validation issue between NSD and Unbound

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hoi Miek,

On 02/24/2012 05:00 PM, Miek Gieben wrote:
> [ Quoting <peter.van.dijk at netherlabs> at 14:37 on Feb 24 in "Re:
> [nsd-users] wild..." ]
>>> That's because ANY has been loosly defined (I'm not sure there
>>> is a written down definition) as give me the records you've
>>> got. In case you hit a cache with an ANY query there is no
>>> guarantee what so ever that it should all validate. I think
>>> that even for authoritative servers you can pretty much do what
>>> you want if it receives a QTYPE = ANY.
>> 
>> While that is true, I feel that whatever an auth chooses to serve
>> up for ANY would still consist of zero or more RRsets, which
>> means the RRSIGs and NSECs that go with them could validate.
>> Right?
> 
> That would indeed be a nice thing to do if you are an auth. server.
> But such a rule still doesn't help a resolver hitting a cache
> (which, for whatever reason, just doesn't have the RRSIG).

Unbound does validate RRSIGs on data from ANY queries.  Because the
reasoning is that it has to protect its downstream client from bogus
data.  And the downstream client may be old (i.e. do ANY queries for
mail and no DNSSEC) and need to be given SERVFAIL.  Thus, it validates
the data.  It does not check if the data is complete (i.e. with the
NSEC) because it may indeed be partial from the cache.

It also validates data where someone does a +norec query to unbound
and its not in cache and thus a cache-referral is returned.  This data
is then also validated (the 'proof' consists of checking the signatures).

Unbound takes the same view to additional section RRs.  Those are not
really required always and to be validated, but to protect the client
from bogus data it will verify the RRsets there.  If some a bogus, but
the message can be make secure by simply removing it, then the
additional RRset is removed (this means, an RRSIG that does not fit at
the end does not make the message bogus).

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPR7h0AAoJEJ9vHC1+BF+NKGsQAJgeMQC6ym+ZdLwDGE7hvvkw
vH/JfnTvayXKEmJS1M2F9DKzYFpUp9WEIi+6d+BcPkQSajFKW9RkDgwswEXwgOrs
TPl9s/F8S3zPTo++xWqt9wBz7qJjUZoJw9o084/PE53e5Yr95hyq304U1e/oes+F
Qdn8JGp5wwR2JyGVwTCitQd1pVfL4YsDWTSv969FdWrXFtUznNZheIa7H4Ear+MS
AZVBGlGHj268dy5yO5A2wH88RAYolyLDqtFlmxMtUWjzEYrUl7gJAY6IM8GTMO7C
M2UqDfUOaJmIMoKlpC2q8d27JDkJQKPYmotMq79I2fV3AwZDvkAn0Tf7RcduCKYh
EcMKTIosBui9FzHMpFDhRokKSu2ueLwDDaJ4PL1qnnBOW0towhgVwOkim9jc0hqJ
MiJkz3G4I/DoWVZEA0WysgDQMPJVZxKrJWjqBtq87XpAv/BpYlksdTd8UXHoWlsg
kR0lbXrGq6ycTU3N9RHy+wJpCtyhY0O22rYm7LVZGyu/CbTeVO3Z02TFDKMBbxOQ
fqW7hwCqQC/nuBm8w10AIQbg9uLN5JrQB6zRh/OqeSOc+2C3ZG40cjkjgO8goFrj
zlpMSqusrvOTwye4YfdcNi/TvDTov1rygIcMGpeaianXOezxDpD4lJjqeMEfEUZD
x3trLKzpS5FPDECbjSaK
=FPwr
-----END PGP SIGNATURE-----