Re: [DNSOP] [internet-dra...@ietf.org: New Version Notification for draft-sullivan-dns-class-useless-01.txt]

[Rob Austein]

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 clear that A records are only defined for IN.

RFC 882, page 10; RFC 1034, page 13.

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

Re: [DNSOP] [internet-dra...@ietf.org: New Version Notification for draft-sullivan-dns-class-useless-01.txt]

[Mark Andrews]

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't believe that this is relevant.  I do think that putting the
> > class and type fields after the variable length name field in a question
> > or in an RR was an unfortunate choice.
> > 
> > However I think it's a long stretch to get from there to assigning any
> > blame on the packet format for any failure of the class field to fulfill
> > its potential.
> 
> Well, the point is that the class can't do the job it was supposed to
> (select one of many parallel delegation sets) because the names are
> prior to the classes.  I didn't intend to blame anything, but to
> suggest that if names were supposed to be subsidiary to classes then
> being able to tell which class you were in before selecting the name
> would be handy.

No.  The order in RRset is irrelevent.  It is the 
tuple that is used to select answers.  The  tuple is
used to select the zone (which is defined to be single class).

> For example, suppose that instead of the IDNA kludge (I think even the
> authors will concede this description -- no disrespect to the effort
> intended), we had used a class to indicate additional conventions for
> name matching and so on.  This would have been a big help, if only
> because case folding outside ASCII is sort of a pain in the neck.  But
> you can't do any of that, because instead of classes actually
> differentiating name spaces, the whole tree is expected to be
> basically the same across classes.

No, the problem was that rules for name matching are independent
of the class.  This is not the same as names come first.  Now it
would be possible to define that class X names are UTF-8 strings
with 'a' - 'z' being case folded when matching.  We could even do
that for class IN.

One could easily have XXX (code point 1000) and YYY (code point
1000) where both XXX and YYY are class specific and the two classes
are different.

If we want to achieve this then we need to be stricter on allocating
class independent RR types or else there will be no codepoints to
share across classes.  We still have room for ~4 billion record
types.  Only a couple of 10  are currently
specified.

NXDOMAIN means the name is not in that qclass (qclass != *).

> I suspect that the real goal was to make the DNS useful for
> non-Internet networking technologies, and the idea was that anyone
> using these various other technologies would likely have Internet
> presence as well.  As a practical matter, though, the Internet
> technology basically swallowed everything else anyway.  The one
> counter-example that's widely deployed we have is mDNS -- it basically
> uses a piece of the Internet technology that doesn't really work at
> Internet scale and effectively makes the network function differently.
> Yet a different class was not selected; instead, we got a new protocol
> with a wire format and operational conventions very similar to
> traditional DNS.
> 
> I'll try to make all of this clearer in the next go-round.  Thanks for
> the comment!
> 
> A
> 
> -- 
> Andrew Sullivan
> a...@anvilwalrusden.com
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Ted Lemon]

> 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 name, it will need to figure out which class you
> are asking about before it can start the label-by-label matching.
> There is no guarantee that there's an answer in every class for a name
> that is in one class.  (If there were, the DNS would be broken today:
> the root servers won't give you delegation information about non-IN
> classes, as far as I can tell.)

Thanks.   The two streams crossed in my head when I read Paul's comment 
earlier, and I had a bit of a wibble about whether there was some new clever 
DDoS attack to be had here, but further sober reflection and some questions 
answered by a colleague suggest that there is not.   But even if there were, 
based on your kind and learned interpretation of the holy writ, it appears that 
this would not be the place to address it.   :)

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Andrew Sullivan]

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 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 name, it will need to figure out which class you
are asking about before it can start the label-by-label matching.
There is no guarantee that there's an answer in every class for a name
that is in one class.  (If there were, the DNS would be broken today:
the root servers won't give you delegation information about non-IN
classes, as far as I can tell.)

Best regards,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Ted Lemon]

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 think DNS 
caches will forward such queries by default, so this may not be an important 
question to answer, but perhaps it should be included nevertheless?

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Ted Lemon]

> 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 caching the
> nxdomain for , or would you retain the old type=1 element, such
> that when the nxdomain expires, you could once again answer questions
> for  using the  you started out with?

Sorry, I didn't mean to blow past this point.  The correct answer depends on 
whether the two answers arrived in the correct order.   If they did, purging 
the cached answer is a no-brainer.   If they did not, caching the NXDOMAIN and 
purging the cached answer is wrong.   But this has nothing to do with 
nxdomain-cut.   RFC 2308 doesn't give any guidance on this; it seems obvious 
though that the spirit of the current state of the art is that the cached RRset 
should be purged--an out of order answer is quite a bit less likely than an 
in-order answer, and consistency is not paramount.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [internet-dra...@ietf.org: New Version Notification for draft-sullivan-dns-class-useless-01.txt]

[Andrew Sullivan]

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 in figuring out who is to blame, though.
I'm more worried that we have this quite old example sitting there
festering, and even it isn't handled right in the registries.  What
hope does a new class have?

Best regards,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] [internet-dra...@ietf.org: New Version Notification for draft-sullivan-dns-class-useless-01.txt]

[Andrew Sullivan]

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 variable length name field in a question
> or in an RR was an unfortunate choice.
> 
> However I think it's a long stretch to get from there to assigning any
> blame on the packet format for any failure of the class field to fulfill
> its potential.

Well, the point is that the class can't do the job it was supposed to
(select one of many parallel delegation sets) because the names are
prior to the classes.  I didn't intend to blame anything, but to
suggest that if names were supposed to be subsidiary to classes then
being able to tell which class you were in before selecting the name
would be handy.

For example, suppose that instead of the IDNA kludge (I think even the
authors will concede this description -- no disrespect to the effort
intended), we had used a class to indicate additional conventions for
name matching and so on.  This would have been a big help, if only
because case folding outside ASCII is sort of a pain in the neck.  But
you can't do any of that, because instead of classes actually
differentiating name spaces, the whole tree is expected to be
basically the same across classes.

I suspect that the real goal was to make the DNS useful for
non-Internet networking technologies, and the idea was that anyone
using these various other technologies would likely have Internet
presence as well.  As a practical matter, though, the Internet
technology basically swallowed everything else anyway.  The one
counter-example that's widely deployed we have is mDNS -- it basically
uses a piece of the Internet technology that doesn't really work at
Internet scale and effectively makes the network function differently.
Yet a different class was not selected; instead, we got a new protocol
with a wire format and operational conventions very similar to
traditional DNS.

I'll try to make all of this clearer in the next go-round.  Thanks for
the comment!

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] [internet-dra...@ietf.org: New Version Notification for draft-sullivan-dns-class-useless-01.txt]

[Mark Andrews]

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
> > completely different RDATA format and meaning. It isn't listed on the
> > DNS parameters page, but it is implemented so by BIND and you can find a
> > description here:
> > 
> > http://victor.se/bjorn/its/chaos-dns.php
> 
> Wow.  Well, that's helpful to know, so thanks.  The fact that people
> in the world are defining RRTYPEs in a class-dependent way without
> putting anything in the registry is kinda awful, though.  Certainly
> another way in which classes appear to be loaded and aimed at feet.
> Thanks for the reference!

It's more that the registry failed to scoop up all the old definitions.
 
> A
> 
> -- 
> Andrew Sullivan
> a...@anvilwalrusden.com
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Ted Lemon]

> 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 trade-off, please propose one, being aware that i'll be
> reviewing its scaling properties.

I agree.   I was simply pointing out that you are being inconsistent: you 
demand that the view of the DNS be consistent when an NXDOMAIN is cached, but 
do not further demand that NXDOMAINs not be cached in order to promote 
consistency.   A cached NXDOMAIN will prevent a more current view of the 
network from being seen, if the missing domain name comes into existence during 
the lifetime of the cached NXDOMAIN.

> note that i'm not requiring that you actually purge, only that you
> effectively purge. i don't know if that changes your appreciation.

Unfortunately it does not.   I haven't heard an argument that makes me 
understand why it is important that we make this a normative requirement.

> i cracked a smile at about 2am. thanks for that.

:)

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

Re: [DNSOP] [internet-dra...@ietf.org: New Version Notification for draft-sullivan-dns-class-useless-01.txt]

[Andrew Sullivan]

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, but it is implemented so by BIND and you can find a
> description here:
> 
> http://victor.se/bjorn/its/chaos-dns.php

Wow.  Well, that's helpful to know, so thanks.  The fact that people
in the world are defining RRTYPEs in a class-dependent way without
putting anything in the registry is kinda awful, though.  Certainly
another way in which classes appear to be loaded and aimed at feet.
Thanks for the reference!

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] [internet-dra...@ietf.org: New Version Notification for draft-sullivan-dns-class-useless-01.txt]

[Andrew Sullivan]

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
is to get a document out that effectively deprecates these bits, in an
effort to lay the ground for formal deprecation later and a possible
eventual re-use in some far off future.  Before any of that can
happen, we have to admit we have a problem :)

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Paul Vixie]

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 rather than a clarification.


You can't really purge lazily. TTL or LRU are your best bets. Purging
lazily requires you to take the performance hit John and I were
arguingabout. Sure, it can be done, but ouch.


if the purge burden is one label-stripping cache management action per 
transmitted response, then the cost is small compared to the network i/o 
cost. even given your live-lock observation, this level of 
implementation detail is not something that dns as a system notices.



however, back to the topic at hand, the implementation costs are not
germane to system correctness. if nominum CNS and/or nlnetlabs Unbound
can't implement the clarified nxdomain semantics, then they just won't.
your customers and your investors can decide what this means to them.


This is the core of our disagreement, I think. You appear now to be
saying that system correctness demands that a cache purge subdomains of
an NXDOMAIN.  ...


no. it requires the effect of a purge, or "an effective purge". as long 
as what happens on the wire is the same as what would have happened in 
the event of an actual purge, then whether you actually purged or not 
makes no difference to dns at the system level. besides which, the 
nominum and nlnetlabs software teams are at the top echelon of the 
field, and i think they will be better than i at designing their code.



... That simply isn't true. An answer whose TTL hasn't expired is a
valid answer. A caching server that responds to a query for a cached
name with the data that was cached is operating correctly. ...


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 caching the 
nxdomain for , or would you retain the old type=1 element, such 
that when the nxdomain expires, you could once again answer questions 
for  using the  you started out with?


if so, then we should talk about what best efforts means when applied to 
distributed cache coherency. if not, then we should talk about why you 
would treat previously cached  values, since the 
meaning of the nxdomain in the context of  is the same as the 
meaning of the nxdomain in the context of . in other words, let's 
first agree on what exactly it is that we disagree about.



inconsistency is in that sense a known hazard, but not a benefit. we
call the system "best efforts" because we know it won't be consistent
but we want everyone involved to do their best anyway.


It's true that inconsistency is not a benefit, but it's standard
operating procedure, and we have to deal with it every day.


well, so is spam, and so are outages, but we do all we can reasonably do 
to minimize those activities. i'm not saying minimize at all imaginable 
costs, of course. engineering economics says minimize at all reasonable 
or in-budget costs. where a cost would require upgrading somebody else's 
network, we say that's not in-budget. where a cost would require adding 
logic to our own product or patching or upgrading technology in our own 
network, we can at least argue as to what the budget should be.


saying that the dns specification ought not specify visible on-the-wire 
behaviour by a recursive server after it receives an nxdomain, because 
that will make life harder for recursive servers whose caches are 
implemented as flat hash tables, when there are extant recursive servers 
who don't use flat hash tables and thus see no special burden, would 
strike me as at best "odd." since the specification as written already 
implies this behavious for subdomains, and is universally already 
implemented for domains, you are arguing from a position of weakness: 
you're asking for lassitude due to code you already deployed, and to 
accommodate you, we would have to loosen, not merely clarify, the 
specification.



... One reason we have to deal with it is that, quite annoyingly, DNS
caches cache NXDOMAINs.   Ping a nonexistent host, add its name to
the authoritative server, and ping it again, and you will get a
"host unknown" error both times, because the NXDOMAIN from the first
ping attempt was cached.   This is bad behavior that we have codified
into a standard because it improves performance.


since it is identically true of positive cache elements that they can be 
annoying since they allow use of old data even after the authority has 
changed its zone contents, i must be missing the point, because i do not 
see 

Re: [DNSOP] [internet-dra...@ietf.org: New Version Notification for draft-sullivan-dns-class-useless-01.txt]

[Andrew Sullivan]

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 least to tidy everything
else up.

> Section 2.1 "Class data is in the wrong part of a resource record" says
> that you can't have a server for class IE at the same time as EG,
> right? (At least as the protocol is currently defined.) That's not the
> same as saying that if you have IE then EG is impossible, right?

The problem as I see it is that, while STD 13 suggests that in
principle these are parallel name spaces, there's no way actually to
ensure that; and if they really are, then the chances are excellent
that the same server _would_ end up serving both classes (since NS is
class-independent).  I guess that isn't clear in the text, so I'll try
again.

They're certainly not mutually exclusive in terms of definition, no.

> I think there may also be a missing "Section 2.4", which is "most
> software only supports IN with some special-casing for CH", and perhaps
> "adding a new class is likely to break loads of stuff", and also "how
> do I specify 'class' when I type in google.com?"

On the "most software" claim, I fear I haven't done the survey and
don't even know how to start.  That's why you only see the discussion
of some people hard-wiring IN.  That part I know happens, because I've
seen it.

I suspect that adding a new class would actually break nothing except
the new class: I predict that virtually nobody would be able to use it
sucessfully.

The point about most user applications assuming IN is a good one; I'll
add it.  (I am struggling to imagine the user interface that allowed a
user to do something like this.  It strikes me, actually, that the
URL/URI definition might not even consider class.  If that's true,
then it's yet another argument.  I'll check.  Thanks for the suggestion.)

> In the end, I'd suggest not including Section 4 "define new RRTYPEs for
> all classes" and instead make Section 3 stronger and declare classes as
> only CH for special cases, IN for everything else, and I guess don't
> break on HS because MIT?

Are you arguing that this draft should be stronger, and recommend
closing the registry?  That's how I started out, and I shied away
because it seemed like work for little benefit.  But I could restore
that text :) It'd be a bigger deal, though, because it would then need
to update the DNS registry IANA considerations document.

Thanks very much,

A


-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Ted Lemon]

>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 
care enough to not cache NXDOMAINs.   And of course, we do not care enough to 
not cache NXDOMAINs, nor should we, because not caching NXDOMAINs would 
probably melt the root and TLD servers at this point.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[George Michaelson]

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 to be able to control the cache behaviour.
Hard, in an unconstrained hinted distributed system.

Since the TTL is set in the parent of the delegation, the defence is
both requiring of consideration by the parent, of the TTL to assert
over the zone, *and* ownership of a time machine to adjust this down,
when under attack.

I'm delighted to seek funds to do the time machine part. Somebody else
is going to have to get funded to do the cache coherence and flushing
protocol in- or out- of band.

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?

ie, under load, the cache deliberately lowers retention on negative
cache state, so it can adapt to changes in that negativity?


-G

On Wed, Mar 16, 2016 at 10:23 AM, 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.
>
>> an authority server operator experiencing a PRSD DDoS might wish to add
>> a zone cut or even remove a name in order to manage their defense costs.
>> when they hand out authoritative content to recursive servers, they will
>> find that some recursive servers will honor the clarified subdomain
>> semantics of nxdomain and others will not. this is not an
>> interoperability problem, but it's a very real problem well deserving
>> our attention here.
>
> The obvious place to do a PRSD attack is on a subdomain that contains valid 
> data, so that you can't NXDOMAIN the parent domain.   So adding a zone cut 
> appears unlikely to help.   Do you know of a situation where it would?
>
>> you're distracting me. i used to be a programmer and this is an
>> interesting problem. as others have pointed out up-thread, you don't
>> have to do the purge at nxdomain time; you can purge lazily when you are
>> responding on an affected qname; or you can purge never and just send
>> the nxdomain instead of the unreachable content, and let the unreachable
>> content expire naturally (TTL or LRU or whatever.) or you can refactor
>> your cache to be a hierarchy of hash tables rather than a flat hash table.
>
> You can't really purge lazily.   TTL or LRU are your best bets.   Purging 
> lazily requires you to take the performance hit John and I were arguing 
> about.   Sure, it can be done, but ouch.
>
>> however, back to the topic at hand, the implementation costs are not
>> germane to system correctness. if nominum CNS and/or nlnetlabs Unbound
>> can't implement the clarified nxdomain semantics, then they just won't.
>> your customers and your investors can decide what this means to them.
>
> This is the core of our disagreement, I think.   You appear now to be saying 
> that system correctness demands that a cache purge subdomains of an NXDOMAIN. 
>  That simply isn't true.   An answer whose TTL hasn't expired is a valid 
> answer.   A caching server that responds to a query for a cached name with 
> the data that was cached is operating correctly.   The product name is Vantio 
> Cacheserve 7, by the way, and to quote a well-loved customer, it is faster 
> than greased bat.
>
>> note that interposing a new zone cut should ideally also cause a purge,
>> either real or effective. this is nowhere written down, but has the same
>> reasoning: a new authority ought to be given a fresh chance to populate
>> caches. this is related to, and similar to, but not the same as the
>> ns-rrset reverification logic proposed in resimprove-00, and will cause
>> very similar implementation problems for flat-hash caches.
>
> I agree that this will produce a more consistent view of the DNS, but these 
> consistency changes will occur by happenstance, not reliably, so they don't 
> really make the view through a cache significantly more correct.   And there 
> are better ways to make bouillabaisse than to boil the ocean--this would be a 
> very expensive way to get a not very big improvement in consistency.
>
>> inconsistency is in that sense a known hazard, but not a benefit. we
>> call the system "best efforts" because we know it won't be consistent
>> but we want everyone involved to do their best anyway.
>
> It's true that inconsistency is not a benefit, but it's standard operating 
> procedure, and we have to deal with it every day.   One reason we have to 
> deal with it is that, quite annoyingly, DNS caches cache NXDOMAINs.   Ping a 
> nonexistent host, add its name to the authoritative server, and ping it 
> again, and you will get a "host 

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Mark Andrews]

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 -- you
> >> wouldn't say that we should continue to send positive responses for
> >> other data perhaps based on qtype as a differentiator, because the
> >> definition of nxdomain is qtype-independent, i.e., it applies to a name.
> >
> > If proves that from the instance of the zone as served by that
> > server at that time.  It says zero about latest zone as that cache
> > has no way to learn if the answer is from the latest zone.
> >
> > Removing  cached records assumes the NXDOMAIN response is from the
> > latest zone.  Now that may well be a reasonable assumption to make
> > but we need to acknowledge that it is a assumption.
> 
> if that assumption weren't also being made by all implementations of 
> negative caching to date, and was thus not specific to the subdomain 
> clarification for nxdomain treatment, i'd agree, we ought to mention it.
> 
> instead i'll say, perhaps it's time to revise RFC 2308 along these 
> lines. i think a higher cost system than DNS which was willing to trade 
> resources to get coherence, all answers would be SOA.SERIAL tagged.

There really is no reason for authoritative servers which are not
using AXFR/IXFR for zone transfers to keep SOA serials in sync.
Even if you are using AXFR/IXFR you don't need all the authoritative
servers to keep the serials in sync, you just need to not cross the
streams.

Current examples of configurations that don't keep the serials in
sync include:

* Parallel inline signers feeding from the same unsigned source
  don't keep serials in sync as there is no need.

* Microsoft AD managed zones don't keep the serials in sync.

* There are a number of database to zone converters operated by
  TLDs that don't keep serials in sync.

Mark

> -- 
> P Vixie
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Tony Finch]

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 implementation blocks.

Tony.
-- 
f.anthony.n.finch    http://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.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Ted Lemon]

> 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 wish to add
> a zone cut or even remove a name in order to manage their defense costs.
> when they hand out authoritative content to recursive servers, they will
> find that some recursive servers will honor the clarified subdomain
> semantics of nxdomain and others will not. this is not an
> interoperability problem, but it's a very real problem well deserving
> our attention here.

The obvious place to do a PRSD attack is on a subdomain that contains valid 
data, so that you can't NXDOMAIN the parent domain.   So adding a zone cut 
appears unlikely to help.   Do you know of a situation where it would?

> you're distracting me. i used to be a programmer and this is an
> interesting problem. as others have pointed out up-thread, you don't
> have to do the purge at nxdomain time; you can purge lazily when you are
> responding on an affected qname; or you can purge never and just send
> the nxdomain instead of the unreachable content, and let the unreachable
> content expire naturally (TTL or LRU or whatever.) or you can refactor
> your cache to be a hierarchy of hash tables rather than a flat hash table.

You can't really purge lazily.   TTL or LRU are your best bets.   Purging 
lazily requires you to take the performance hit John and I were arguing about.  
 Sure, it can be done, but ouch.

> however, back to the topic at hand, the implementation costs are not
> germane to system correctness. if nominum CNS and/or nlnetlabs Unbound
> can't implement the clarified nxdomain semantics, then they just won't.
> your customers and your investors can decide what this means to them.

This is the core of our disagreement, I think.   You appear now to be saying 
that system correctness demands that a cache purge subdomains of an NXDOMAIN.  
That simply isn't true.   An answer whose TTL hasn't expired is a valid answer. 
  A caching server that responds to a query for a cached name with the data 
that was cached is operating correctly.   The product name is Vantio Cacheserve 
7, by the way, and to quote a well-loved customer, it is faster than greased 
bat.

> note that interposing a new zone cut should ideally also cause a purge,
> either real or effective. this is nowhere written down, but has the same
> reasoning: a new authority ought to be given a fresh chance to populate
> caches. this is related to, and similar to, but not the same as the
> ns-rrset reverification logic proposed in resimprove-00, and will cause
> very similar implementation problems for flat-hash caches.

I agree that this will produce a more consistent view of the DNS, but these 
consistency changes will occur by happenstance, not reliably, so they don't 
really make the view through a cache significantly more correct.   And there 
are better ways to make bouillabaisse than to boil the ocean--this would be a 
very expensive way to get a not very big improvement in consistency.

> inconsistency is in that sense a known hazard, but not a benefit. we
> call the system "best efforts" because we know it won't be consistent
> but we want everyone involved to do their best anyway.

It's true that inconsistency is not a benefit, but it's standard operating 
procedure, and we have to deal with it every day.   One reason we have to deal 
with it is that, quite annoyingly, DNS caches cache NXDOMAINs.   Ping a 
nonexistent host, add its name to the authoritative server, and ping it again, 
and you will get a "host unknown" error both times, because the NXDOMAIN from 
the first ping attempt was cached.   This is bad behavior that we have codified 
into a standard because it improves performance.

So if you want to tell me that, for the sake of correctness, I have to go purge 
entries out of my hashed cache because I got an NXDOMAIN, then I will tell you 
for the sake of correctness that we should never cache NXDOMAINs, and we will 
both glare at each other sternly until one of us cracks a smile.   This is a 
silly argument.   If correctness were our first and only concern, DDoS attacks 
would be even easier than they are.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Paul Vixie]

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 data perhaps based on qtype as a differentiator, because the
definition of nxdomain is qtype-independent, i.e., it applies to a name.


If proves that from the instance of the zone as served by that
server at that time.  It says zero about latest zone as that cache
has no way to learn if the answer is from the latest zone.

Removing  cached records assumes the NXDOMAIN response is from the
latest zone.  Now that may well be a reasonable assumption to make
but we need to acknowledge that it is a assumption.


if that assumption weren't also being made by all implementations of 
negative caching to date, and was thus not specific to the subdomain 
clarification for nxdomain treatment, i'd agree, we ought to mention it.


instead i'll say, perhaps it's time to revise RFC 2308 along these 
lines. i think a higher cost system than DNS which was willing to trade 
resources to get coherence, all answers would be SOA.SERIAL tagged.


--
P Vixie

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Paul Vixie]

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 interoperability (which is what ietf normally 
measures, since the bits on the wire have senders and receivers) is the 
wrong way to understand end-to-end utility and correctness in the dns.


an authority server operator experiencing a PRSD DDoS might wish to add 
a zone cut or even remove a name in order to manage their defense costs. 
when they hand out authoritative content to recursive servers, they will 
find that some recursive servers will honor the clarified subdomain 
semantics of nxdomain and others will not. this is not an 
interoperability problem, but it's a very real problem well deserving 
our attention here.



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.



if i had rrsets cached at a name, and then i heard an nxdomain for that
name, and then that nxdomain expired, i would not "feel alright about"
answering with the old rrsets. why would subdomains be different?


This is all certainly true as far as it goes. However, if every
NXDOMAIN requires a full cache traversal, as it will for any hashed
cache with the restriction you've proposed, then NXDOMAIN suddenly
becomes a _really_ powerful DoS attack.  ...


you're distracting me. i used to be a programmer and this is an 
interesting problem. as others have pointed out up-thread, you don't 
have to do the purge at nxdomain time; you can purge lazily when you are 
responding on an affected qname; or you can purge never and just send 
the nxdomain instead of the unreachable content, and let the unreachable 
content expire naturally (TTL or LRU or whatever.) or you can refactor 
your cache to be a hierarchy of hash tables rather than a flat hash table.


however, back to the topic at hand, the implementation costs are not 
germane to system correctness. if nominum CNS and/or nlnetlabs Unbound 
can't implement the clarified nxdomain semantics, then they just won't. 
your customers and your investors can decide what this means to them.


note that interposing a new zone cut should ideally also cause a purge, 
either real or effective. this is nowhere written down, but has the same 
reasoning: a new authority ought to be given a fresh chance to populate 
caches. this is related to, and similar to, but not the same as the 
ns-rrset reverification logic proposed in resimprove-00, and will cause 
very similar implementation problems for flat-hash caches.



It is worth noting that there's a generally accepted principle,
which has been tossed in my face one or two times on this mailing
list, that the DNS is not required to be consistent.  ...


inconsistency is in that sense a known hazard, but not a benefit. we 
call the system "best efforts" because we know it won't be consistent 
but we want everyone involved to do their best anyway.


--
P Vixie

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

[DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-00.txt

[internet-drafts]

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: draft-ietf-dnsop-attrleaf-00.txt
Pages   : 12
Date: 2016-03-14

Abstract:
   Historically, any DNS RR may occur for any domain name.  Recent
   additions have defined DNS leaf nodes that contain a reserved node
   name, beginning with an underscore.  The underscore construct is used
   to define a semantic scope for DNS records that are associated with
   the parent domain.  This specification explores the nature of this
   DNS usage and defines the "underscore names" registry with IANA.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Mark Andrews]

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 proposed in draft-vixie-dnsext-resimprove:
> >> "When an iterative caching DNS resolver stores an NXDOMAIN in its
> >> cache, all names and RRsets at or below that node should be deleted
> >> since they will have become unreachable."
> >
> > There's nothing wrong with doing that. I just don't see why it's any
> > more correct than believing the TTL that the server provided.
> 
> 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 data perhaps based on qtype as a differentiator, because the 
> definition of nxdomain is qtype-independent, i.e., it applies to a name.

If proves that from the instance of the zone as served by that
server at that time.  It says zero about latest zone as that cache
has no way to learn if the answer is from the latest zone.

Removing  cached records assumes the NXDOMAIN response is from the
latest zone.  Now that may well be a reasonable assumption to make
but we need to acknowledge that it is a assumption.

> for the same reason and in the same way, nxdomain applies to all 
> subdomains. it is not just talking about the qname.
>
> -- 
> P Vixie
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Ted Lemon]

> 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 rrsets of all subdomains, will be interesting.

> if i had rrsets cached at a name, and then i heard an nxdomain for that
> name, and then that nxdomain expired, i would not "feel alright about"
> answering with the old rrsets. why would subdomains be different?

This is all certainly true as far as it goes.   However, if every NXDOMAIN 
requires a full cache traversal, as it will for any hashed cache with the 
restriction you've proposed, then NXDOMAIN suddenly becomes  a _really_ 
powerful DoS attack.   The best part is that there don't even have to be any 
entries in the cache to prune: every time you get an NXDOMAIN you're going to 
have to traverse the whole hash.   So all I have to do to bring a server to its 
knees is send it a bunch of queries for names in .COM that don't exist.   This 
is _seriously_ not a good idea.

It is worth noting that there's a generally accepted principle, which has been 
tossed in my face one or two times on this mailing list, that the DNS is not 
required to be consistent.   A zone's contents for any serial number are 
expected to be the same, but caches don't cache zones--they cache answers.   At 
the level of answers, as opposed to zones, consistency is always on a 
best-effort basis.   Arguing that not pruning the tree when you get an NXDOMAIN 
is inelegant isn't sufficient to justify the proposed normative language, true 
though it may be.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Paul Vixie]

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 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.


if i had rrsets cached at a name, and then i heard an nxdomain for that 
name, and then that nxdomain expired, i would not "feel alright about" 
answering with the old rrsets. why would subdomains be different?


noting as before: all of this is implied by the base dns specification, 
so this really is a clarification as to impact, not a protocol change.


--
P Vixie

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[神明達哉]

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 are allowed but
> >>should be considered minor exceptions.
>
> > Agree. That's the whole point of the draft. Slide 3 at the Yokohama meeting
> > 
>
> I believe that Jinmei-san was proposing one of two positions the
> working group could take, so you aren't agreeing with him

Correct (perhaps I wasn't clear enough in my message).

Now that I'm more certain that the intent of the draft is above "A",
I'd suggest:

- make it even clearer in the draft
- explain why this can't just be up to the implementor's choice (I know
  it's discussed in the thread, but I don't think it's super clear in
  the current text of the draft).

We can then discuss whether that's the wg consensus.  I personally
don't have a strong opinion, but I don't think that part of discussion
is over yet.

--
JINMEI, Tatuya

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[John R Levine]

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, all names and RRsets at or below that node should be deleted
since they will have become unreachable."


There's nothing wrong with doing that.  I just don't see why it's any 
more correct than believing the TTL that the server provided.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Tony Finch]

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 and sadly it isn't
very easy to analyze, e.g. there's some search-path-related junk under
com.ac.uk and net.ac.uk but no negative entries for com.ac.uk or net.ac.uk
themselves (because, no qname minimization).

One analysis I can do fairly easy is count the number of cache entries in
nonexistent TLDs; this cache has 4617 out of 1945116 total names.

We have a relatively well policed network, and I don't get to see the
worst traffic from the student accommodation or the mail servers, so I'm
smugly unsurprised my numbers are relatively unconvincing :-)

sed -E '/^([0-9a-z_.-]+)[.][].*/!d;
s//\1/;
s/^.*[.]//' named_dump.db |
perl -e 'my %root;
for (qw('"$(
dig axfr . |
sed -E '/^([a-z0-9-]+)[.][  ].*/!d;
s//\1/' |
uniq)"')) {
$root{$_} = 1
}
my ($y,$n);
while (<>) {
chomp;
if ($root{$_}) { ++$y }
else { ++$n }
}
END {
print "y $y\nn $n\n"
}'

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Shannon, Rockall: Southeast 4 or 5, increasing 6 at times. Moderate or rough.
Fair. Good.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Stephane Bortzmeyer]

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 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 a violation of the tree model of the DNS. I find more
elegant if cache replies NXDOMAIN.

Note that both behaviour will have the same result for the upstream
servers: in both cases, the cache won't send a query to them.


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[John Levine]

>> 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 an entry in the cache, why wouldn't
it use it?

R's,
John

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Shumon Huque]

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
> cache, not on the authoritative server.
>
>
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 being response rate limited.

-- 
Shumon Huque
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Stephane Bortzmeyer]

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 still inelegant (it violates the tree model
of domain names).

> Given the current thread, we should probably revise the draft to
> remove text that 'sounds' like implementation advice.

I'm not convinced if we have just one person, who sees in the draft
things that nobody else sees.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Ted Lemon]

> 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.

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

Re: [DNSOP] [internet-dra...@ietf.org: New Version Notification for draft-sullivan-dns-class-useless-01.txt]

[Ray Bellis]

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 in a question
or in an RR was an unfortunate choice.

However I think it's a long stretch to get from there to assigning any
blame on the packet format for any failure of the class field to fulfill
its potential.

kind regards,

Ray

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Shumon Huque]

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 caching provisions of RFC 1034 and 1035 will be
> called "speed hacks". After all, the DNS would work as well without
> caches.
>
> "NXDOMAIN cut" is not purely an internal optimization because it
> changes the observable behavior of a resolver. It therefore has an
> effect on other servers. It reveals brokenness in other servers (the
> one who reply NXDOMAIN for an ENT). It is not just a matter for the
> implementer.
>

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 efficient by correctly
interpreting the NXDOMAIN signal. To regurgitate part of my earlier
message: "why should resolvers make unnecessary outbound queries
for names that don't exist, and why should authoritative servers receive
those queries?"

As an implementation note, doing this only on a cache miss sounds to me
like a reasonable choice. Given the current thread, we should probably
revise the draft to remove text that 'sounds' like implementation advice.
I also favor "SHOULD", but let's see where WG deliberations lead us.

-- 
Shumon Huque
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Tony Finch]

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 don't see a problem with this, but I also don't see any argument for
> making a normative requirement to implement it.  Do you?

It neatly avoids a lot of wasteful authoritative queries.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Forties: Northeast 3 or 4. Slight. Fog banks. Moderate or poor, occasionally
very poor.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Ted Lemon]

> 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, but I also don't see any argument for making a 
normative requirement to implement it.   Do you?

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Tony Finch]

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 for
the QNAME, and return that, otherwise recurse as usual.

This uses the same memory for the cache as it would without nxdomain-cut,
and requires the same quantity of hash lookups (one) when there is a cache
hit.

Note that when recursing you have to search up the cache anyway, to find
the authoritative servers that can answer this query. So you can combine
the NXDOMAIN search with the NS search, so it doesn't cost any more CPU.

When you get an NXDOMAIN response at a parent of existing cache entries,
don't clean the cache eagerly, allow normal TTL cleaning to deal with
them lazily.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Dover, Wight, Portland, Plymouth: East or northeast 4 or 5, increasing 6 at
times. Slight or moderate. Mainly fair. Moderate or good, occasionally poor.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Stephane Bortzmeyer]

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, the DNS would work as well without
caches.

"NXDOMAIN cut" is not purely an internal optimization because it
changes the observable behavior of a resolver. It therefore has an
effect on other servers. It reveals brokenness in other servers (the
one who reply NXDOMAIN for an ENT). It is not just a matter for the
implementer.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Tony Finch]

John Levine  wrote:
>
> How deep do you expect the name tree to get?

ip6.arpa :-)

Tony.
-- 
f.anthony.n.finch    http://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.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Ted Lemon]

>> 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.

> Agree. That's the whole point of the draft. Slide 3 at the Yokohama meeting
> 

I believe that Jinmei-san was proposing one of two positions the working group 
could take, so you aren't agreeing with him--you are saying what your opinion 
is as to what the working group's position should be.   And the slide you've 
referenced as a supporting document is a slide from a presentation you wrote 
which does not say anything about making this a normative requirement!

I think that you should explain what the interoperability problem is that this 
proposed normative requirement addresses, and otherwise we should drop it and 
let implementors decide how best to treat this.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Stephane Bortzmeyer]

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 behavior.  Other behaviors are allowed but
>should be considered minor exceptions.

Agree. That's the whole point of the draft. Slide 3 at the Yokohama
meeting


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Ted Lemon]

> 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).

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Ted Lemon]

> 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 performance, but 
caches that handle large amount of traffic do not measure performance per 
query: they measure performance at a particular query load.   This means that 
although any given query is never CPU bound, when figuring out how many DNS 
cache servers you are going to have to install, you still very definitely need 
to account for CPU utilization.   Unless you simply aren't seeing any 
significant query load, you figure out what your steady-state query load is, 
and you figure out what your maximum query load is, and you figure out from 
that how many servers you need to deploy.   If you triple the per-query CPU 
load, then you need to buy three times as many servers.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[John Levine]

>> 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. If the cost of performing a few extra hashes
>and extra hash table lookups add significant expense to answering a
>query, then the rest of the system has been impressively well-optimized.

Perhaps we could compare it to the cost of a DNSSEC validation.

R's,
John

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[John R Levine]

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 extra local hashes avoid upstream queries, it 
is likely to be an overall performance win.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[Ted Lemon]

> 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 that is likely to produce very little actual benefit in 
practice other than in the presence of certain kinds of PRSD attacks.   So the 
current draft makes an algorithm which apparently works well for several 
implementations work less well in order to get a benefit the magnitude of which 
is unclear, but likely small.

As a matter of principle, of course, what you are saying is true.   However, 
remember that what we are debating here is not whether to clarify the rules for 
handling NXDOMAINs, but rather whether to add normative language strongly 
urging implementations to do this optimization.   We all, I think, agree that 
the clarification is good.   By your argument, we should not add the normative 
language--we should just clarify the spec, and then see what happens.   If we 
see widespread implementation of this optimization, then we can conclude that 
it was worth doing.   If nobody implements it, or only tree-structured caches 
implement it, then we can conclude that whatever benefit may have come from 
doing the optimization wasn't sufficient to justify widespread implementation.

More likely, though, what we will see if we make this clarification without 
adding normative language, is that implementors make intelligent use of the 
optimization, as Wouter suggests, based on what will work most efficiently with 
their implementation.   So once again I urge the working group to make this a 
clarification and not a normative requirement, so that smart implementors can 
do what makes the most sense in the context of their implementations.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

[W.C.A. Wijngaards]

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



signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop