Ted Lemon wrote:
The issue here is that there is no interoperability problem that
these SHOULDs are addressing, so you can't have a discussion about
the exceptions.
as a hop by hop matter, this is true. as an end to end matter, this is
false.
in any case i think this SHOULD/MUST discussion
At Thu, 17 Mar 2016 10:55:09 -0700,
Paul Vixie wrote:
> we should describe the positive benefits to the dns system (without
> mentioning any benefit or cost to any implementor or implementation style).
>
> "As implied by STD 13 and as made explicit herein, an authoritative
> response of code 3 (N
On Thu, Mar 17, 2016 at 09:57:02AM +1100,
Mark Andrews wrote
a message of 82 lines which said:
> It is a SHOULD not a MUST. Having a existing cache entry is a
> reasonable exception to the SHOULD.
Yes. So, it's already allowed by the draft.
To make it clearer-than-clear, We could add after
>On Wed, Mar 16, 2016 at 1:44 PM, 神明達哉
>mailto:jin...@wide.ad.jp>> wrote:
>> So I wonder: should we as wg keep requiring the SHOULD for the already
>> cached subdomains or can we loosen the requirement specifically for
>> that case?
> I've already stated I'm okay with relaxing the SHOULD for the
In message
, =?UTF-8?B?56We5piO6YGU5ZOJ?= writes:
> At Wed, 16 Mar 2016 14:41:36 +0100,
> Stephane Bortzmeyer wrote:
>
> > > > you have to do the "rm -rf $qname" when you receive the nxdomain.
> > >
> > > The draft says you have to do this, yes.
> >
> > No, it does not. draft-vixie-dnsext-resi
> (so, ted, we appear to agree after all.)
Sweet!
Sorry for the excessive use of vernacular... :)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
At Wed, 16 Mar 2016 14:41:36 +0100,
Stephane Bortzmeyer wrote:
> > > you have to do the "rm -rf $qname" when you receive the nxdomain.
> >
> > The draft says you have to do this, yes.
>
> No, it does not. draft-vixie-dnsext-resimprove-00 did but
> draft-ietf-dnsop-nxdomain-cut-01 does not. You m
Ted Lemon wrote:
(so, ted, we appear to agree after all.)
Sweet!
to be clear, we disagree that the flat hash nature of some recursive
servers is a good enough reason to not say SHOULD here. our agreement on
not saying SHOULD is a coincidence. as a clarification, i'm sure that
this docume
On Wed, Mar 16, 2016 at 1:44 PM, 神明達哉 wrote:
>
>
> So I wonder: should we as wg keep requiring the SHOULD for the already
> cached subdomains or can we loosen the requirement specifically for
> that case?
>
I've already stated I'm okay with relaxing the SHOULD for the case of
already
cached subdo
Mark Andrews wrote:
> In message
> ,
> =?UTF-8?B?56We5piO6YGU5ZOJ?= writes:
> >
> > In my understanding the latest major concern is about the first
> > paragraph of Section 2:
> >
> >When an iterative caching DNS resolver receives a response NXDOMAIN,
> >it SHOULD store it in its cache a
On Wed, Mar 16, 2016 at 10:50:55AM +1000,
George Michaelson wrote
a message of 84 lines which said:
> How about if under load, a cache is permitted to convert NXDOMAIN
> ttl to 1/nth of the apparent ttl, based on some understood algorithm
> which relates to a load threshold?
IMHO, it is alrea
Tony Finch wrote:
Mark Andrews wrote:
In message,
=?UTF-8?B?56We5piO6YGU5ZOJ?= writes:
In my understanding the latest major concern is about the first
paragraph of Section 2:
When an iterative caching DNS resolver receives a response NXDOMAIN,
it SHOULD store it in its cache and al
Ted Lemon wrote:
> >On Wed, Mar 16, 2016 at 1:44 PM, 神明達哉
> >mailto:jin...@wide.ad.jp>> wrote:
> >> So I wonder: should we as wg keep requiring the SHOULD for the already
> >> cached subdomains or can we loosen the requirement specifically for
> >> that case?
>
> > I've already stated I'm okay wi
On Tue, Mar 15, 2016 at 05:23:55PM +,
Ted Lemon wrote
a message of 8 lines which said:
> > you have to do the "rm -rf $qname" when you receive the nxdomain.
>
> The draft says you have to do this, yes.
No, it does not. draft-vixie-dnsext-resimprove-00 did but
draft-ietf-dnsop-nxdomain-c
i've been a bit anxious about ted's use of the word "normative", so i
looked it up:
adjective
1. of or relating to a norm, especially an assumed norm regarded as
the standard of correctness in behavior, speech, writing, etc.
2. tending or attempting to establish such a norm, especially by the
p
>>>When an iterative caching DNS resolver receives a response NXDOMAIN,
>>>it SHOULD store it in its cache and all names and RRsets at or below
>>>that node SHOULD then be considered to be unreachable. Subsequent
>>>queries for such names SHOULD elicit an NXDOMAIN response.
>> It
Moin!
On 15 Mar 2016, at 15:16, Shumon Huque wrote:
> More generally, it also reduces demands on authoritative servers by
> not sending them a set of unnecessary queries.
>
> I have not viewed this as a 'speed hack', or in fact any hack, but as a
> way to make the entire DNS ecosystem more efficie
> FWIW, I believe that, according to the matching rules in STD 13,
> NXDOMAIN is class-bound. This is in fact related to the argument
> about how the class selector fails to do what we'd have needed it to:
> if you ask a name server that serves two different classes for the
> same name about that
On Wed, Mar 16, 2016 at 01:36:21AM +, Ted Lemon wrote:
> it might be worth anticipating whether an NXDOMAIN for class=X should also
> result in an NXDOMAIN answer for the same name with class Y, where Y != X.
>
FWIW, I believe that, according to the matching rules in STD 13,
NXDOMAIN is c
It occurs to me that given Andrew's draft which is being discussed on another
thread, draft-sullivan-dns-class-useless, it might be worth anticipating
whether an NXDOMAIN for class=X should also result in an NXDOMAIN answer for
the same name with class Y, where Y != X. In practice I don't thin
> two days ago i might have agreed with you. but putting resimprove-00
> into the blender and making me drink it has made me obstreperous as
> follows: if an answer of is in cache and you hear a
> question for and forward it and you then hear nxdomain,
> then would you purge the element when cac
> negative caching is like response rate limiting: we can't operate the
> network at current or projected scale without them. the incorrectness
> (specifically: the incoherence) we allow due to caching (of both
> positive and negative elements) was a trade-off for scale. if you want a
> different t
Ted Lemon wrote:
this is getting pretty good. anyone who stopped reading before now, may
want to delve back in at this point.
I on the other hand am a little frustrated because a while back I
thought we agreed, and now it appears that we don't.
i wrongly remembered this as an optimization r
>I don't personally think cacheing NXDOMAIN is bad per se:
Nor do I. I was using that argument to contrast with Paul's position on
NXDOMAIN subdomain purging. If we care so much about consistency that we are
willing to purge subdomains when we get an NXDOMAIN that contains them, then we
car
I don't personally think cacheing NXDOMAIN is bad per se: the question
is with what negative cache time, and what consequence in the context
of a change in zone delegation structure in order to achieve DDoS
mitigation. When there is no DDoS you want the cache to do its job.
When there is, you want
In message <56e8a0e6.9010...@redbarn.org>, Paul Vixie writes:
>
>
> Mark Andrews wrote:
> > In message<56e83f6e.2040...@redbarn.org>, Paul Vixie writes:
> >> an authoritative nxdomain proves that there is nothing below that qname.
> >> this obviates all prior positive responses for that qname --
Paul Vixie wrote:
>
> however, how you'd go about justifying the removal of all rrsets at some
> name when you learn that this name does not exist, without also removing
> all rrsets of all subdomains, will be interesting.
There's a risk of interesting attacks if you require rm -rf $qname
and the
> this is getting pretty good. anyone who stopped reading before now, may
> want to delve back in at this point.
I on the other hand am a little frustrated because a while back I thought we
agreed, and now it appears that we don't.
> an authority server operator experiencing a PRSD DDoS might wi
Mark Andrews wrote:
In message<56e83f6e.2040...@redbarn.org>, Paul Vixie writes:
an authoritative nxdomain proves that there is nothing below that qname.
this obviates all prior positive responses for that qname -- you
wouldn't say that we should continue to send positive responses for
other d
this is getting pretty good. anyone who stopped reading before now, may
want to delve back in at this point.
Ted Lemon wrote:
no. it's not an interoperability matter.
If it's not an interoperability matter, then there shouldn't really
beany normative language.
i think hop-by-hop interoperab
In message <56e83f6e.2040...@redbarn.org>, Paul Vixie writes:
> John R Levine wrote:
> >>> it can at that time flush any entries with names under the it. I
> >>> suppose that means that we need a cache where you can look down the
> >>> tree as well as up.
> >>
> >> Which was exactly what was propo
> no. it's not an interoperability matter.
If it's not an interoperability matter, then there shouldn't really be any
normative language.
> however, how you'd go about justifying the removal of all rrsets at some
> name when you learn that this name does not exist, without also removing
> all rr
Ted Lemon wrote:
you have to do the "rm -rf $qname" when you receive the nxdomain.
The draft says you have to do this, yes. That's what I'm objecting
to.Is there some reason why this is required for interoperability?
no. it's not an interoperability matter.
however, how you'd go about just
At Tue, 15 Mar 2016 13:34:07 +,
Ted Lemon wrote:
> >> If this observation is correct, I think what we should first agree on
> >> is the real intent of the draft:
> >> A. nxdomain-cut is "the correct behavior" and implementations SHOULD
> >>generally support the behavior. Other behaviors
> you have to do the "rm -rf $qname" when you receive the nxdomain.
The draft says you have to do this, yes. That's what I'm objecting to. Is
there some reason why this is required for interoperability?
___
DNSOP mailing list
DNSOP@ietf.org
https:/
Ted Lemon wrote:
Oh, here's some text that our engineering team proposes:
A plain reading of the first paragraph of section 2, which section
5supports, is that *all* subsequent queries for information beneath the
NXDOMAIN name point SHOULD return NXDOMAIN. In particular, this includes
queri
John R Levine wrote:
it can at that time flush any entries with names under the it. I
suppose that means that we need a cache where you can look down the
tree as well as up.
Which was exactly what was proposed in draft-vixie-dnsext-resimprove:
"When an iterative caching DNS resolver stores an
Oh, here's some text that our engineering team proposes:
> A plain reading of the first paragraph of section 2, which section 5
> supports, is that *all* subsequent queries for information beneath the
> NXDOMAIN name point SHOULD return NXDOMAIN. In particular, this includes
> queries that wou
Ted Lemon wrote:
It neatly avoids a lot of wasteful authoritative queries.
This is an interesting statement. Do you have any numbers on this,
oris this based on intuition?
In order to measure this, you would need to measure it on a fairly
active cache, not on the authoritative server.
my i
> I haven't seen any measurement studies. But at a recent DNS-OARC
> meeting, Bert Hubert mentioned that PowerDNS were driven
> to implement this based on a real operational problem: too many
> NXDOMAIN eliciting queries from one of their large resolvers to the
> F.ROOT server resulting in them bei
Ted Lemon wrote:
so whenever i hear words like "that'll be slow for flat-hash dns caches"
it reminds me of the joke that begins "doctor, it hurts when i do $this"
and ends with "well, then don't do $this".
This sounds like a really good rejoinder until you realize that we
are talking about an
it can at that time flush any entries with names under the it. I
suppose that means that we need a cache where you can look down the
tree as well as up.
Which was exactly what was proposed in draft-vixie-dnsext-resimprove:
"When an iterative caching DNS resolver stores an NXDOMAIN in its
cache,
On Tue, Mar 15, 2016 at 11:31:15AM -0400,
John R Levine wrote
a message of 21 lines which said:
> it can at that time flush any entries with names under the it. I
> suppose that means that we need a cache where you can look down the
> tree as well as up.
Which was exactly what was proposed in
00:00:00 Cache receives a reply with a record for foobar.example, with a
TTL of 86400
01:00:00 Cache receives a reply NXDOMAIN when asking QNAME=example
02:00:00 Cache receives a request for foobar.example
With today's software, the cache will reply (the TTL is not over). I
find that
Stephane Bortzmeyer wrote:
> On Tue, Mar 15, 2016 at 10:16:52AM -0400,
> Shumon Huque wrote
> a message of 93 lines which said:
>
> > As an implementation note, doing this only on a cache miss sounds to
> > me like a reasonable choice.
>
> Reasonable for the "traffic intensity and protection ag
Ted Lemon wrote:
> > It neatly avoids a lot of wasteful authoritative queries.
>
> This is an interesting statement. Do you have any numbers on this, or
> is this based on intuition?
Based on discussions of attack traffic and junk queries.
I've had a look at the contents of one of my caches an
On Tue, Mar 15, 2016 at 03:03:28PM -,
John Levine wrote
a message of 12 lines which said:
> If the query finds an entry in the cache, why wouldn't it use it?
00:00:00 Cache receives a reply with a record for foobar.example, with a
TTL of 86400
01:00:00 Cache receives a reply NXDOMA
>> As an implementation note, doing this only on a cache miss sounds to
>> me like a reasonable choice.
>
>Reasonable for the "traffic intensity and protection against random
>QNAME attacks", yes. But still inelegant (it violates the tree model
>of domain names).
I'm confused. If the query finds
On Tue, Mar 15, 2016 at 10:36 AM, Ted Lemon wrote:
> > It neatly avoids a lot of wasteful authoritative queries.
>
> This is an interesting statement. Do you have any numbers on this, or is
> this based on intuition?
>
> In order to measure this, you would need to measure it on a fairly active
On Tue, Mar 15, 2016 at 10:16:52AM -0400,
Shumon Huque wrote
a message of 93 lines which said:
> As an implementation note, doing this only on a cache miss sounds to
> me like a reasonable choice.
Reasonable for the "traffic intensity and protection against random
QNAME attacks", yes. But sti
> It neatly avoids a lot of wasteful authoritative queries.
This is an interesting statement. Do you have any numbers on this, or is this
based on intuition?
In order to measure this, you would need to measure it on a fairly active
cache, not on the authoritative server.
On Tue, Mar 15, 2016 at 9:52 AM, Stephane Bortzmeyer
wrote:
> On Sun, Mar 13, 2016 at 06:29:37PM +,
> Ted Lemon wrote
> a message of 27 lines which said:
>
> > If it's a speed hack, there shouldn't be any normative language
> > associated with implementing it.
>
> Next time, all the cachin
Ted Lemon wrote:
> > There's an easy way which I think is a clear optimization:
>
> > When there is a cache miss, before recursing, search the cache for a
> > parent NXDOMAIN entry. If you find one, add an NXDOMAIN cache entry for
> > the QNAME, and return that, otherwise recurse as usual.
>
> I
> There's an easy way which I think is a clear optimization:
> When there is a cache miss, before recursing, search the cache for a
> parent NXDOMAIN entry. If you find one, add an NXDOMAIN cache entry for
> the QNAME, and return that, otherwise recurse as usual.
I don't see a problem with this,
Ted Lemon wrote:
>
> I have no idea how you would implement this efficiently with a hashed
> cache:
There's an easy way which I think is a clear optimization:
When there is a cache miss, before recursing, search the cache for a
parent NXDOMAIN entry. If you find one, add an NXDOMAIN cache entry
On Sun, Mar 13, 2016 at 06:29:37PM +,
Ted Lemon wrote
a message of 27 lines which said:
> If it's a speed hack, there shouldn't be any normative language
> associated with implementing it.
Next time, all the caching provisions of RFC 1034 and 1035 will be
called "speed hacks". After all,
On Tue, Mar 15, 2016 at 11:39:03AM +,
Ted Lemon wrote
a message of 14 lines which said:
> This sounds like a really good rejoinder until you realize that we
> are talking about an optimization that is likely to produce very
> little actual benefit in practice
Side question: why did you no
John Levine wrote:
>
> How deep do you expect the name tree to get?
ip6.arpa :-)
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Trafalgar: Westerly or southwesterly 4 or 5, increasing 6 at times, becoming
variable 3 or 4 later. Moderate or rough. Fair. Moderate or good.
___
On Mon, Mar 14, 2016 at 08:12:24PM +,
Ted Lemon wrote
a message of 7 lines which said:
> 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
On Mon, Mar 14, 2016 at 08:31:45PM -0400,
Robert Edmonds wrote
a message of 59 lines which said:
> Could the rule be relaxed so that the process of considering whether
> a cached NXDOMAIN in a parent zone is applicable to the name being
> looked up can be delayed until immediately prior to tra
>> If this observation is correct, I think what we should first agree on
>> is the real intent of the draft:
>> A. nxdomain-cut is "the correct behavior" and implementations SHOULD
>>generally support the behavior. Other behaviors are allowed but
>>should be considered minor exceptions.
>
On Mon, Mar 14, 2016 at 11:59:19AM -0700,
神明達哉 wrote
a message of 50 lines which said:
> If this observation is correct, I think what we should first agree on
> is the real intent of the draft:
> A. nxdomain-cut is "the correct behavior" and implementations SHOULD
>generally support the be
On Fri, Mar 11, 2016 at 08:52:20PM +,
Ted Lemon wrote
a message of 49 lines which said:
> Right here:
>
>When an iterative caching DNS resolver receives a response NXDOMAIN,
>it SHOULD store it in its cache and all names and RRsets at or below
>that node SHOULD then be conside
> Perhaps we could compare it to the cost of a DNSSEC validation.
Which is why DNSSEC validation is most effectively done by the resolver, not
the intermediate cache, much as we might wish it to be otherwise (e.g. for
cache poisoning protection).
___
> Beyond that, there are some obvious tradeoffs. Unless your DNS cache is
> 100% compute bound, if a few extra local hashes avoid upstream queries, it
> is likely to be an overall performance win.
John, have you ever heard of "livelock"?
I think you are thinking about this in terms of per-query
>> so whenever i hear words like "that'll be slow for flat-hash dns caches" it
>> reminds me of the joke that begins "doctor, it hurts when i do $this" and
>> ends with "well, then don't do $this".
>
>OTOH, modern non-cryptographic hash functions (e.g., xxHash, CityHash,
>etc.) are extremely fast.
so whenever i hear words like "that'll be slow for flat-hash dns caches" it
reminds me of the joke that begins "doctor, it hurts when i do $this" and
ends with "well, then don't do $this".
Beyond that, there are some obvious tradeoffs. Unless your DNS cache is
100% compute bound, if a few ext
> so whenever i hear words like "that'll be slow for flat-hash dns caches"
> it reminds me of the joke that begins "doctor, it hurts when i do $this"
> and ends with "well, then don't do $this".
This sounds like a really good rejoinder until you realize that we are talking
about an optimization t
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 t
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 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
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
In message <56e64398.7010...@redbarn.org>, Paul Vixie writes:
>
>
> Mark Andrews wrote:
> > ... please explain how RFC 1034 Section 4.3.2. Algorithm can return
> > a Name Error for a empty non-terminal. I don't see it unless there
> > is a missing delegation and that is a configuration error.
Mark Andrews wrote:
... please explain how RFC 1034 Section 4.3.2. Algorithm can return
a Name Error for a empty non-terminal. I don't see it unless there
is a missing delegation and that is a configuration error. I have
zero problems with a cache returning Name Error if there is a
configurat
In message <56e63c71.1080...@redbarn.org>, Paul Vixie writes:
>
>
> Mark Andrews wrote:
> > ...
> > NXDOMAIN at a empty non terminal only came about as the result of
> > bad wording in RFC 2535. "no names" should have been "no names
> > with data" (the difference is crucial in determining which
Mark Andrews wrote:
...
NXDOMAIN at a empty non terminal only came about as the result of
bad wording in RFC 2535. "no names" should have been "no names
with data" (the difference is crucial in determining which rcode
is returned). Only RFC 2535 nameservers are allowed to return
NXDOMAIN for
In message
, abby pan writes:
> Ted Lemon
>
> >
> > I think this document could be made a lot simpler if it simply said what
> > it says in the abstract, without placing new requirements on DNS caches.
> > Right now it says DNS caches SHOULD take an NXDOMAIN on a particular
> > domain as apply
Ted Lemon 于2016年3月11日周五 下午12:26写道：
>
> I think this document could be made a lot simpler if it simply said what
> it says in the abstract, without placing new requirements on DNS caches.
> Right now it says DNS caches SHOULD take an NXDOMAIN on a particular
> domain as applying to all names under
> what i'm urging here is great caution both for the authors and the
> reviewers. improving the readability of this topic over what we wrote in
> resimprove-00 seems necessary but is not a simple proposition.
I don't think this is actually all that complicated. The problem is that you
are tryin
Ted Lemon wrote:
On Saturday, March 12, 2016 01:58, Paul Vixie wrote:
Ted, I think you're reading it wrong. The implementation doesn't matter
at all. As Co-Chair Woolf kindly and classily 2x4'd me last year, an RFC
should be of the form "if you want to do X, here's a way to do it
interoperably
On Saturday, March 12, 2016 01:58, Paul Vixie wrote:
> Ted, I think you're reading it wrong. The implementation doesn't matter
> at all. As Co-Chair Woolf kindly and classily 2x4'd me last year, an RFC
> should be of the form "if you want to do X, here's a way to do it
> interoperably."
With all d
Ted Lemon wrote:
i took the words "at or below" to mean "in-bailiwick". caches that are
not organized as tree-like data structures still have to be able to find
the closest encloser, which means they do know ancestor/descendent
relationships, even if the data structure itself is otherwise flati
> i took the words "at or below" to mean "in-bailiwick". caches that are
> not organized as tree-like data structures still have to be able to find
> the closest encloser, which means they do know ancestor/descendent
> relationships, even if the data structure itself is otherwise flatishly
> hashli
> Perhaps we can make it explicit that the tree here is conceptual, and
> not an implementation required data structure?
That's not the point. The point is that if the _cache_ is represented as a
tree, then you can talk about names being "under" other names; if it's not,
then that relationship
On Fri, Mar 11, 2016 at 3:52 PM, Ted Lemon wrote:
> > It is certainly not the goal. Can you tell exactly where it is
> > assumed? Section 2 is supposed to be implementation-neutral.
>
> Right here:
>
>When an iterative caching DNS resolver receives a response NXDOMAIN,
>it SHOULD store it
Ted Lemon wrote:
It is certainly not the goal. Can you tell exactly where it is
assumed? Section 2 is supposed to be implementation-neutral.
Right here:
When an iterative caching DNS resolver receives a response NXDOMAIN,
it SHOULD store it in its cache and all names and RRsets at or
1 - 100 of 105 matches
Mail list logo
