Maintained by: NLnet Labs

[Unbound-users] Strange result from Unbound cache

W.C.A. Wijngaards
Mon Dec 13 17:08:51 CET 2010


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

Hi Peter,

On 12/13/2010 04:03 PM, Peter Koch wrote:
> On Tue, Nov 30, 2010 at 04:20:28PM +0100, W.C.A. Wijngaards wrote:
> 
>> Yes.  It caches what the authority server sends.  For speed reasons it
>> does not (try to) remove duplicates.  Except in special corner cases
>> where it does remove duplicates (where it tries to make sense of RRSIGs
>> that are in the wrong section of the message, and when it thus adjusts
>> the message it removes duplicates).
> 
> this is another challenge for the robustness principle, but RFC 2181
> introduced the "RRSet" and deprecated (even recommended removing
> duplicate RRs.  This was later confirmed (in DNSSEC context, though)
> by section 6.3 of RFC 4034.  More importantly, it appears more
> consumer/application friendly to me to suppress the duplicates. YMMV.

So, unbound does not introduce duplicates itself.  It does transmit the
upstream duplicates to clients.  As a feature it could suppress the
duplicates; is that really worth it?  It makes RR parsing O(n^2) for the
number of RRs in an RRset; or for more O(nlogn) solutions the overhead
becomes high as well; thus I think performance would suffer.  I figured
an authority server that sends out duplicates can then have duplicates
for their domain and the issues ..

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

iEYEARECAAYFAk0GRRMACgkQkDLqNwOhpPghNQCeI8JB2159rXBR/CNb1p4AFxij
SR4An1ZjMayvijM/io1Qve8ZQTviFVwL
=dR1U
-----END PGP SIGNATURE-----