[Unbound-users] Strange result from Unbound cache

[Olafur Gudmundsson]

On 13/12/2010 11:08 AM, W.C.A. Wijngaards wrote:
> -----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

I think Unbound is doing the right thing. Authoritative servers sending 
duplicate records should be exposed to the end systems.
If a validator "fails" to duplicates before verifying the RRset may or 
may not fail as it is just as likely that the set was signed with 
duplicates in it.

The principle no DNS protocol element should not change RRsets that 
originate at another protocol element.

	Olafur