At Tue, 15 Mar 2016 21:24:53 -0400, Andrew Sullivan wrote:
>
> On Wed, Mar 16, 2016 at 12:20:40PM +1100, Mark Andrews wrote:
> > It's more that the registry failed to scoop up all the old definitions.
>
> Perhaps. The documentation I could find for chaosnet is pretty thin,
> and STD 13 is pretty
In message <20160316012227.go89...@mx2.yitter.info>, Andrew Sullivan writes:
> Hi,
>
> Thanks for the comment.
>
> On Tue, Mar 15, 2016 at 02:34:43PM +, Ray Bellis wrote:
> > "But given the DNS message format, the name server cannot find the class
> > until it knows the name."
> >
> > I don
> 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
On Wed, Mar 16, 2016 at 12:20:40PM +1100, Mark Andrews wrote:
> It's more that the registry failed to scoop up all the old definitions.
Perhaps. The documentation I could find for chaosnet is pretty thin,
and STD 13 is pretty clear that A records are only defined for IN.
I'm not really interested
Hi,
Thanks for the comment.
On Tue, Mar 15, 2016 at 02:34:43PM +, Ray Bellis wrote:
> "But given the DNS message format, the name server cannot find the class
> until it knows the name."
>
> I don't believe that this is relevant. I do think that putting the
> class and type fields after the
In message <20160316011219.gn89...@mx2.yitter.info>, Andrew Sullivan writes:
> On Mon, Mar 07, 2016 at 10:01:21PM +0530, Mukund Sivaraman wrote:
> > Added to that, the "A" record type is also found in some places with RR
> > TYPE=1, with the same name "A" for the CH class, where it has a
> > compl
> 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
On Mon, Mar 07, 2016 at 10:01:21PM +0530, Mukund Sivaraman wrote:
> Added to that, the "A" record type is also found in some places with RR
> TYPE=1, with the same name "A" for the CH class, where it has a
> completely different RDATA format and meaning. It isn't listed on the
> DNS parameters page
On Mon, Mar 07, 2016 at 04:54:47PM +0100, George Michaelson wrote:
> if we defined them as 'ignored' for now, could we repurpose them in
> some mythical future?
I am earnestly hoping that I will die before the time comes in which
that repurposing argument can be held; but yes, part of my goal here
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
Hi,
Thanks for the comments. More inline.
On Mon, Mar 07, 2016 at 04:50:21PM +0100, Shane Kerr wrote:
> I generally consider CLASS to be 2 bytes in every RR that we'll never
> get back. :(
Well, yes, but I guess I'm trying to take the first step on
deprecating the whole thing in an effort at le
>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
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.
Title : DNS Scoped Data Through '_Underscore' Attribute Leaves
Author : Dave Crocker
Filename
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.
Andrew,
Thanks for writing this.
I do take minor issue with this bit:
"But given the DNS message format, the name server cannot find the class
until it knows the name."
I don't believe that this is relevant. I do think that putting the
class and type fields after the variable length name field
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
62 matches
Mail list logo
