[Unbound-users] Strange result from Unbound cache
pk at denic.de
Mon Dec 13 19:28:37 UTC 2010
> 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
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