Paul Vixie wrote:
> Ted Lemon wrote:
> >>How deep do you expect the name tree to get? I rarely see anything
> >>more than four levels deep, and three times through the loop isn't
> >>a whole lot.
> >
> >Er, if on average you have to do three hash lookups instead of one,
> >and hash lookups are the
Ted Lemon wrote:
How deep do you expect the name tree to get? I rarely see anything
more than four levels deep, and three times through the loop isn't
a whole lot.
Er, if on average you have to do three hash lookups instead of one,
and hash lookups are the main expense to answering a query,
> Because DNS caches aren't compute bound.
And this in turn is why CPU utilization on large DNS caches tends to be close
to zero, I suppose...
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
How deep do you expect the name tree to get? I rarely see anything
more than four levels deep, and three times through the loop isn't
a whole lot.
Er, if on average you have to do three hash lookups instead of one, and
hash lookups are the main expense to answering a query, then that would
be
> How deep do you expect the name tree to get? I rarely see anything
> more than four levels deep, and three times through the loop isn't
> a whole lot.
Er, if on average you have to do three hash lookups instead of one, and hash
lookups are the main expense to answering a query, then that would
> 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 t
Stephane Bortzmeyer wrote:
> On Thu, Mar 10, 2016 at 12:59:49PM -0800,
> internet-dra...@ietf.org wrote
> a message of 47 lines which said:
>
> > Title : NXDOMAIN really means there is nothing underneath
> > Filename: draft-ietf-dnsop-nxdomain-cut-01.txt
> ...
> >
On Mon, Mar 14, 2016 at 6:59 PM, 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 r
>I have no idea how you would implement this efficiently with a hashed cache:
>either you search every parent domain of
>a particular name before answering to see if there's an NXDOMAIN higher in the
>hierarchy, or else when you get an
>NXDOMAIN for a name you traverse the entire hash table looki
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 convin
神明達哉 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
I think that's a good summary, Jinmei-san--thank you!
I have no idea how you would implement this efficiently with a hashed cache:
either you search every parent domain of a particular name before answering to
see if there's an NXDOMAIN higher in the hierarchy, or else when you get an
NXDOMAIN
At Mon, 14 Mar 2016 16:31:47 +,
Ted Lemon wrote:
> > No, it does not.
>
> Yes, it does. You are not calling it implementation advice, but
> that's what it is. A normative requirement to do a particular
> optimization is nothing other than implementation advice.
I guess one key point to d
> No, it does not.
Yes, it does. You are not calling it implementation advice, but that's what
it is. A normative requirement to do a particular optimization is nothing
other than implementation advice.
___
DNSOP mailing list
DNSOP@ietf.org
https:/
On Tue, Mar 08, 2016 at 02:09:12PM +,
Alain Durand wrote
a message of 207 lines which said:
> draft-adpkja-dnsop-special-names-problem-01 has been posted today.
[One warning: I think the entire idea is bad. There is no "problem" to
solve, we have RFC 6761 and it works (it worked for Apple
On Mon, Mar 14, 2016 at 02:55:50AM +,
Ted Lemon wrote
a message of 14 lines which said:
> The reason the WG is getting pushback from me on this is precisely
> that the draft gives implementation advice
No, it does not.
___
DNSOP mailing list
DN
In message
, abby pan writes:
>
> Mark Andrews
>
> >
> > > another choice : Authority Server return NODATA/NXDOMAIN as nxdomain
> > cut,
> > > but no change on DNS cache. Some impact on NSEC/NSEC3 records.
> > >
> > > - no names under foo.example => NXDOMAIN at foo.example
> >
> > If you wan
John Levine wrote:
> it's also true that DNS servers (not just BIND) reject an entire master
> file if there are any syntax errors at all, so a little fuzziness is not
> harmless.
Yes. This is a common source of DNSSEC signer failures.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Biscay: Eas
Mark Andrews 于2016年3月14日周一 下午12:01写道：
>
> > another choice : Authority Server return NODATA/NXDOMAIN as nxdomain
> cut,
> > but no change on DNS cache. Some impact on NSEC/NSEC3 records.
> >
> > - no names under foo.example => NXDOMAIN at foo.example
>
> If you want to signal NOERROR + bottom
19 matches
Mail list logo
