Hi,

On 14/03/16 23:59, Robert Edmonds wrote:
> Robert Edmonds wrote:
>> 神明達哉 wrote:
>>> p.s. in my understanding Unbound adopts hash-based data structure for
>>> cached RRsets.  If it still supports nxdomain-cut as described in
>>> Section 8, an argument against the proposal by referring to that type
>>> of implementation might sound less convincing.
>>
>> My understanding is that Unbound employs at least two hash-based data
>> structures, one for whole messages (msg-cache-* parameters) and one for
>> individual RRsets (rrset-cache-* parameters).
>>
>> It's also my understanding that Unbound already implements the
>> resimprove-00 §3 behavior when configured with "harden-below-nxdomain:
>> yes", but it defaults to off (only?) because "it is not an RFC".
> 
> Actually, I was misremembering this. Unbound's harden-below-nxdomain
> behavior is much more conservative than resimprove, since it only
> considers NXDOMAINs that are DNSSEC-secure. But it still does use an
> "upwards" algorithm (successively strip labels off the QNAME) in a
> hash-based cache to find an applicable NXDOMAIN.

The dnssec choice was made for security, but also in the hope that newer
implementations that support dnssec also have correct NXDOMAIN
semantics.  And thus the nxdomain cut can be safely applied to them.
(This hope has proven to be wrong, i.e. Cloudflare, but I believe fixed
now).

Unbound implements a label-strip search through the hash table, but only
on a cache-miss.  This means existing positive information will stay in
cache until TTL.  It also mitigates performance issues.  The TTL-view is
similar to having multiple resolvers that feed off of another in the
face of this zone change.

The nxdomain feature combines well with the new qname minimisation
feature, because the qname minimisation feature tends to pull in the
higher NXDOMAIN cut for future responses.

The current implementation does nxdomain cuts everywhere, if enabled
(not just high up in the tree).  If RFC, default sounds plausible, eg.
with qname minimisation that needs the same NXDOMAIN-correctness
property for authority servers.

Best regards, Wouter

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to