On Mon, Mar 14, 2016 at 6:59 PM, Robert Edmonds <edmo...@mycre.ws> 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.
>
Yup, the DNSSEC-only behavior of Unbound is mentioned in the current
draft:
The Unbound resolver has a configuration
parameter called "harden-below-nxdomain" [2], which if set to "yes"
turns on NXDOMAIN cut behavior ("only DNSSEC-secure nxdomains are
used", see Section 7). The PowerDNS recursor has optional partial
support for NXDOMAIN cut, for the root domain only, with its "root-
nx-trust" setting, described as [3] "If set, an NXDOMAIN from the
root-servers will serve as a blanket NXDOMAIN for the entire TLD the
query belonged to. The effect of this is far fewer queries to the
root-servers.".
Whether or not to limit this to secure responses is one of the open
questions. A few people have expressed fears that resimprove will make
it easier for attackers faking (unsigned) NXDOMAIN responses to prune
out large parts of a victim's cache.
--
Shumon Huque
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
