Zitat von "W.C.A. Wijngaards" <[email protected]>:
-----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
_______________________________________________
Unbound-users mailing list
[email protected]
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
