[Unbound-users] Strange result from Unbound cache

Peter Koch pk at denic.de
Mon Dec 13 19:28:37 UTC 2010

Hi Wouter,

> So, unbound does not introduce duplicates itself.  It does transmit the

understood, but "be conservative in what you send".

> 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

First, I think nlogn is closer to reality (sort, then compare and collapse),
but then the numbers n are small enough that O() probably isn't too helpful
at all.  Most RRSets will contain a single RR anyway.

Second, to borrow from another thread, the performance penalty for this
protocol compliance feature is cheaper than the one introduced by "RTT
banding" (SCNR).

Doesn't the validator have to canonicalize the RRSet anyway?
And finally, the invalid RRSet has to be dealt with anyway, then why not
do it once at the recursor instead of multiple times at the stub or
within the consumin application?


More information about the Unbound-users mailing list