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? -Peter _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
