[Unbound-users] Strange result from Unbound cache

[lst_hoe02 at kwsoft.de]

Zitat von "W.C.A. Wijngaards" <wouter at NLnetLabs.nl>:

> -----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 ..

The even potential harm done by simply provide duplicated RRs is low  
IMHO (second connect to the same IP for example), so i would not vote  
for making Unbound slower and more complex to solve this. It is an  
error orginating in the zone after all and it is not the resolvers  
duty to fix it.

Regards

Andreas