Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Stephane Bortzmeyer]

On Wed, Sep 28, 2016 at 06:44:27PM +0200,
 Ralf Weber  wrote 
 a message of 26 lines which said:

> I consider anything in the cache where the TTL is still valid to be
> valid data that can be send to clients even if below the nxdomain
> cut. My understanding is that this is how the current draft is
> written.

Yes (with "MAY" instead of "can").

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

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Stephane Bortzmeyer]

On Tue, Sep 27, 2016 at 07:28:57PM +,
 White, Andrew  wrote 
 a message of 284 lines which said:

> True. When a resolver gets an NXDOMAIN for, say x.example.com, would
> it better to say the resolver SHOULD drop from cache all descendents
> of x.example.com, or MAY?

The current state of the draft is "approved by IESG". Which means
that, unless a serious bug is discovered, it will be published as a
RFC with only editorial changes (by the RFC editor). I don't think it
is a good idea to reopen a discussion which triggered aleady many
emails.

> It may be computationally expensive to search cache to remove cached
> NXDOMAIN responses below x.example.com, and I see no harm in letting
> those cached entries expire as their TTL runs out.

Which is exactly what the draft is saying:

   But if a resolver has cached data under the NXDOMAIN cut, it MAY
   continue to send it as a reply (until the TTL of this cached data
   expires), since this may avoid additional processing when a query is
   received.  Section 6 provides more information about this.

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

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Stephane Bortzmeyer]

On Tue, Sep 27, 2016 at 03:46:16PM -0700,
 Matthew Pounsett  wrote 
 a message of 137 lines which said:

> My rationale is that if foo.bar.example.org were still a valid name

By "valid name", do you mean "something which existed less than $TTL
seconds ago"?

> at the time that the bar.example.org NXDOMAIN response was issued,
> then NXDOMAIN was not the correct response.  It would be
> inappropriate to answer for foo.bar.example.org out of the cache in
> that case.

The DNS is full of these (minor) inconsistencies. As Mark Andrews
said, temporal issues are not new.

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

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Stephane Bortzmeyer]

On Wed, Sep 28, 2016 at 01:42:19PM +,
 Edward Lewis  wrote 
 a message of 84 lines which said:

> As far as DNSSEC, this only works with DNSSEC in place, right?  You
> need the missing span proofs or you are NXDOMAIN'ing entire zones,
> not just entire domains (within a zone).

This is covered in section 8 of the draft (and also in 9, about
Unbound). If people want to spend time on an already-approved draft,
could they at least read it?

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

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Shumon Huque]

On Wed, Sep 28, 2016 at 2:37 PM, Matthew Pounsett 
wrote:

>
>
> On 28 September 2016 at 10:29, Shumon Huque  wrote:
>
>> On Wed, Sep 28, 2016 at 11:39 AM, Matthew Pounsett 
>> wrote:
>>
>>>
>>>
>>> On 28 September 2016 at 06:42, Edward Lewis 
>>> wrote:
>>>
 On 9/27/16, 18:46, "Matthew Pounsett"  wrote:
 >Would it be better then to leave early expiry as an implementation
 choice


 Ultimately, the goal of the draft is to tell a recursive server that if
 it can conclusively deduce existence of a name from what it has cached, it
 is allowed to do so.  Today if the conclusion is positive, that's how it
 is.  The draft proposes to add negative conclusions as well.  Perhaps
 getting into the details of managing what's in the cache, which is not
 covered beyond TTL expiry "rules" is causing the wrapping around the axle.
 (We are talking about the fairly odd example of there being conflicting
 data.)


>>> Taking the view that this is only about interoperability, then I would
>>> say the implementor MAY treat names below the NXDOMAIN response as
>>> nonexistent, and MAY choose to expire those names early... perhaps with a
>>> suggestion that this might be the better choice for data coherence, but
>>> still leave it up to the implementor if they've got a better reason to do
>>> it otherwise.
>>>
>>
>> The draft (by working group consensus) is written as "SHOULD treat names
>> below as non-existent", but "MAY continue to answer existing positive
>> cached entries". I think this managed to cover or at least placate all
>> positions expressed by working group participants leading up to the last
>> call.
>>
>> I'm not sure we'll get new agreement on your proposed revision.
>>
>> I phrased that badly.  Since we were on the subject of cached entries
> already, I assumed that context in my wording.   I should have said "MAY
> treat positively cached names below the NXDOMAIN response as nonexistent,
> and MAY choose to expire those cached names early."  I think that's in
> keeping with the intent of the current text.
>
> There's probably some value in rewording that text though, if it's going
> to cause confusion for implementors.  Maybe invert the text?
>
> # When an interative caching DNS resolver receives a response NXDOMAIN, it
> # SHOULD store it in its negative cache.  It MAY choose to immediately
> remove
> # from its positive cache any previously cached names at or below the
> NXDOMAIN
> # response.  If the cached entries below the NXDOMAIN response are not
> # removed, it MAY choose to continue to answer positively for those names
> # until the cached entries expire.
>
> # The resolver SHOULD treat all other names at or below NXDOMAIN response
> as
> # nonexistant and SHOULD respond negatively to queries for such names.
>
>
I'll wait first for others to weigh in on your proposed rewrite.

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

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Matthew Pounsett]

On 28 September 2016 at 10:29, Shumon Huque  wrote:

> On Wed, Sep 28, 2016 at 11:39 AM, Matthew Pounsett 
> wrote:
>
>>
>>
>> On 28 September 2016 at 06:42, Edward Lewis 
>> wrote:
>>
>>> On 9/27/16, 18:46, "Matthew Pounsett"  wrote:
>>> >Would it be better then to leave early expiry as an implementation
>>> choice
>>>
>>>
>>> Ultimately, the goal of the draft is to tell a recursive server that if
>>> it can conclusively deduce existence of a name from what it has cached, it
>>> is allowed to do so.  Today if the conclusion is positive, that's how it
>>> is.  The draft proposes to add negative conclusions as well.  Perhaps
>>> getting into the details of managing what's in the cache, which is not
>>> covered beyond TTL expiry "rules" is causing the wrapping around the axle.
>>> (We are talking about the fairly odd example of there being conflicting
>>> data.)
>>>
>>>
>> Taking the view that this is only about interoperability, then I would
>> say the implementor MAY treat names below the NXDOMAIN response as
>> nonexistent, and MAY choose to expire those names early... perhaps with a
>> suggestion that this might be the better choice for data coherence, but
>> still leave it up to the implementor if they've got a better reason to do
>> it otherwise.
>>
>
> The draft (by working group consensus) is written as "SHOULD treat names
> below as non-existent", but "MAY continue to answer existing positive
> cached entries". I think this managed to cover or at least placate all
> positions expressed by working group participants leading up to the last
> call.
>
> I'm not sure we'll get new agreement on your proposed revision.
>
> I phrased that badly.  Since we were on the subject of cached entries
already, I assumed that context in my wording.   I should have said "MAY
treat positively cached names below the NXDOMAIN response as nonexistent,
and MAY choose to expire those cached names early."  I think that's in
keeping with the intent of the current text.

There's probably some value in rewording that text though, if it's going to
cause confusion for implementors.  Maybe invert the text?

# When an interative caching DNS resolver receives a response NXDOMAIN, it
# SHOULD store it in its negative cache.  It MAY choose to immediately
remove
# from its positive cache any previously cached names at or below the
NXDOMAIN
# response.  If the cached entries below the NXDOMAIN response are not
# removed, it MAY choose to continue to answer positively for those names
# until the cached entries expire.

# The resolver SHOULD treat all other names at or below NXDOMAIN response
as
# nonexistant and SHOULD respond negatively to queries for such names.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Shumon Huque]

On Wed, Sep 28, 2016 at 11:39 AM, Matthew Pounsett 
wrote:

>
>
> On 28 September 2016 at 06:42, Edward Lewis 
> wrote:
>
>> On 9/27/16, 18:46, "Matthew Pounsett"  wrote:
>> >Would it be better then to leave early expiry as an implementation choice
>>
>>
>> Ultimately, the goal of the draft is to tell a recursive server that if
>> it can conclusively deduce existence of a name from what it has cached, it
>> is allowed to do so.  Today if the conclusion is positive, that's how it
>> is.  The draft proposes to add negative conclusions as well.  Perhaps
>> getting into the details of managing what's in the cache, which is not
>> covered beyond TTL expiry "rules" is causing the wrapping around the axle.
>> (We are talking about the fairly odd example of there being conflicting
>> data.)
>>
>>
> Taking the view that this is only about interoperability, then I would say
> the implementor MAY treat names below the NXDOMAIN response as nonexistent,
> and MAY choose to expire those names early... perhaps with a suggestion
> that this might be the better choice for data coherence, but still leave it
> up to the implementor if they've got a better reason to do it otherwise.
>

The draft (by working group consensus) is written as "SHOULD treat names
below as non-existent", but "MAY continue to answer existing positive
cached entries". I think this managed to cover or at least placate all
positions expressed by working group participants leading up to the last
call.

I'm not sure we'll get new agreement on your proposed revision.

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

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Shumon Huque]

On Wed, Sep 28, 2016 at 12:44 PM, Ralf Weber  wrote:

> Moin!
>
> On 28 Sep 2016, at 17:21, Shumon Huque wrote:
> > To be precise, I would say we are not necessarily always pruning out
> entire
> > zones. For a leaf zone, we are pruning all names within that zone below
> the
> > nxdomain-cut, modulo cached entries, i.e. a subset of the zone. But yes,
> > for non-leaf zones, all zones below too are pruned.
> I think we've been down that argument before. Not all cache implementations
> have a DNS tree structure and nothing in the DNS protocol requires this
> AFAIK.
> I consider anything in the cache where the TTL is still valid to be valid
> data
> that can be send to clients even if below the nxdomain cut. My
> understanding
> is that this is how the current draft is written.
>

Not exactly. The draft does NOT say that all unexpired cached data below
the NXDOMAIN boundary is still valid. It leaves that up to implementers.
Paraphrasing without 2119 keywords, it says that resolvers should consider
all names below the cut non-existent, but may continue to return positive
answers for existing cached entries. This text was the end result of many
long discussions on the topic earlier this year. I think this accommodates
your position.


> For new records/delegations of course this would go NXDomain, but what to
> do
> with stuff already in the cache is an implementation choice.
>

Yes.

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

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Ralf Weber]

Moin!

On 28 Sep 2016, at 17:21, Shumon Huque wrote:
> To be precise, I would say we are not necessarily always pruning out entire
> zones. For a leaf zone, we are pruning all names within that zone below the
> nxdomain-cut, modulo cached entries, i.e. a subset of the zone. But yes,
> for non-leaf zones, all zones below too are pruned.
I think we've been down that argument before. Not all cache implementations
have a DNS tree structure and nothing in the DNS protocol requires this AFAIK.
I consider anything in the cache where the TTL is still valid to be valid data
that can be send to clients even if below the nxdomain cut. My understanding
is that this is how the current draft is written.

For new records/delegations of course this would go NXDomain, but what to do
with stuff already in the cache is an implementation choice.

I also don't think this is different with DNSSEC as stuff below the NXDomain
cut still is valid until TTL expires.

So long
-Ralf

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

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Matthew Pounsett]

On 28 September 2016 at 06:42, Edward Lewis  wrote:

> On 9/27/16, 18:46, "Matthew Pounsett"  wrote:
> >Would it be better then to leave early expiry as an implementation choice
>
>
> Ultimately, the goal of the draft is to tell a recursive server that if it
> can conclusively deduce existence of a name from what it has cached, it is
> allowed to do so.  Today if the conclusion is positive, that's how it is.
> The draft proposes to add negative conclusions as well.  Perhaps getting
> into the details of managing what's in the cache, which is not covered
> beyond TTL expiry "rules" is causing the wrapping around the axle.  (We are
> talking about the fairly odd example of there being conflicting data.)
>
>
Taking the view that this is only about interoperability, then I would say
the implementor MAY treat names below the NXDOMAIN response as nonexistent,
and MAY choose to expire those names early... perhaps with a suggestion
that this might be the better choice for data coherence, but still leave it
up to the implementor if they've got a better reason to do it otherwise.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Shumon Huque]

On Wed, Sep 28, 2016 at 9:42 AM, Edward Lewis 
wrote:

> On 9/27/16, 18:46, "Matthew Pounsett"  wrote:
> >Would it be better then to leave early expiry as an implementation choice
>
> I think it comes down to implementer's choice.  The goal of the (IETF in
> general) documents is interoperability. Whether or not a cache chooses to
> keep the cached entries or remove them, or the way in which it chooses
> which of two (or more) valid answers to give doesn't impact
> interoperability.  So long as the response given is protocol-appropriate.
>
> The issue is, which response (of a set of possible responses) is correct
> is not definable within the DNS protocol.  So, there's no winner here.
>

I agree, and this seems entirely in keeping with the loosely coherent
distributed database model of the DNS.

[...]

>
> As far as DNSSEC, this only works with DNSSEC in place, right?  You need
> the missing span proofs or you are NXDOMAIN'ing entire zones, not just
> entire domains (within a zone).
>

The draft does not currently require DNSSEC. It's true that without DNSSEC,
the impact of a spoofed NXDOMAIN is much larger, and for this reason the
draft does mention that implementations could choose to deploy this
enhancement only for signed data (and some implementations have already
taken this route).

To be precise, I would say we are not necessarily always pruning out entire
zones. For a leaf zone, we are pruning all names within that zone below the
nxdomain-cut, modulo cached entries, i.e. a subset of the zone. But yes,
for non-leaf zones, all zones below too are pruned.

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

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Edward Lewis]

On 9/27/16, 18:46, "Matthew Pounsett"  wrote:
>Would it be better then to leave early expiry as an implementation choice

I think it comes down to implementer's choice.  The goal of the (IETF in 
general) documents is interoperability. Whether or not a cache chooses to keep 
the cached entries or remove them, or the way in which it chooses which of two 
(or more) valid answers to give doesn't impact interoperability.  So long as 
the response given is protocol-appropriate.

The issue is, which response (of a set of possible responses) is correct is not 
definable within the DNS protocol.  So, there's no winner here.

Implementors ought to be aware of choices, but let them choose because they 
know best what's optimal for their goals.  Well, "ought" might be too strong, 
implementors just "need" to produce acceptable responses.  If this is over 
constrained, goodbye innovation.

For me, I'd never think to cull validated entries because of conflicting 
information and I'd use the routing-area principle of longest match to decide 
what to return.  But those are whimsical choices.  I can see that some might 
want to cull, I just don't see spending cycles managing that.

Ultimately, the goal of the draft is to tell a recursive server that if it can 
conclusively deduce existence of a name from what it has cached, it is allowed 
to do so.  Today if the conclusion is positive, that's how it is.  The draft 
proposes to add negative conclusions as well.  Perhaps getting into the details 
of managing what's in the cache, which is not covered beyond TTL expiry "rules" 
is causing the wrapping around the axle.  (We are talking about the fairly odd 
example of there being conflicting data.)

As far as DNSSEC, this only works with DNSSEC in place, right?  You need the 
missing span proofs or you are NXDOMAIN'ing entire zones, not just entire 
domains (within a zone).


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Shumon Huque]

On Tue, Sep 27, 2016 at 3:28 PM, White, Andrew 
wrote:

> Hi Shumon,
>
>
>
> True. When a resolver gets an NXDOMAIN for, say x.example.com, would it
> better to say the resolver SHOULD drop from cache all descendents of
> x.example.com, or MAY?
>
>
>
> It may be computationally expensive to search cache to remove cached
> NXDOMAIN responses below x.example.com, and I see no harm in letting
> those cached entries expire as their TTL runs out.
>

It depends on the implementation of the cache. I guess you missed the ~ 100
message thread on this very topic from earlier this year! :-)

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

Re: [DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Shumon Huque]

On Tue, Sep 27, 2016 at 2:48 PM, White, Andrew 
wrote:

> Hi Shumon,
>
>
> What about this?
>
>
>
> # When an iterative caching DNS resolver receives a response with RCODE
> being NXDOMAIN,
>
> # the resolver SHOULD store the response in its (negative) cache.  During
> the time the response
>
> # is cached, any query with a QNAME at or descended from the denied name
> that is not otherwise
>
> #cached (positively), can be assumed to result in a name error.  Responses
> to those queries
>
> # SHOULD set RCODE=NXDOMAIN (using the DNSSEC records cached as proof).
>
>
>
> When an iterative caching DNS resolver receives a query response with
> RCODE as NXDOMAIN,
>
> The resolver should store the NXDOMAIN response in cache. During the time
> that this response
>
> is cached, any query with a QNAME at or descended from the query that
> resulted in NXDOMAIN
>
> and that is not already in cache can be assumed to result in a name error.
> Responses to such
>
> queries SHOULD respond with RCODE as NXDOMAIN using DNSSEC records from
> cache as proof.
>
>
>
> Andrew
>

Andrew - this looks very similar to Ed's rewrite.

The problem I see with both is that it says to reply with NXDOMAIN for all
names at or below the cut, except for RRsets already positively cached. But
the current draft also allows resolvers to immediately invalidate cached
entries below the cut and also return NXDOMAIN for them. Your rewrite
appears to remove (or at least not mention) that possibility.

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

[DNSOP] Comment on section 2 of draft-ietf-dnsop-nxdomain-cut-05.txt

[Edward Lewis]

#2.  Rule
#
#   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.
#
#   But if a resolver has cached data under the NXDOMAIN cut, it MAY
#   continue to send it as a reply (until the TTL of this cached data
#   expires), since this may avoid additional processing when a query is
#   received.  Section 6 provides more information about this.

For consistency, the SHOULD's in the first paragraph ought to be MAY's.  
(Logically, it has to be.  If I treat it as SHOULD, I'd never discover data 
below that I MAY elect to return.)

As the authority server may change its version of a zone and the SOA (with 
serial) is not in every response, it's impossible (computationally undecidable) 
to know whether the answer with the NXDOMAIN was created before or after lower 
data.  Maybe the lower data is "currently correct" and the NXDOMAIN is 
stale-ish.  Or not.

DNSSEC does not solve this - the inception time of a RRSIG is a tempting metric 
of freshness but that timestamp is not reliable for that purpose.  (From the 
early days, signers would post date the signature on purpose to avoid 
then-common clock skew issues.)  This would be good to reinforce.

Given a temporally valid answer with data below a temporally denied name is 
possible (as zones change over time), I'd say that it is up to the implementer 
to choose one way or the other.  All things being static, an NXDOMAIN would 
occlude lower data.  But things are not static.

When I wrote "occlude" above I thought of the rule that an NS set occludes data 
below it the cut.  That is, hide it from answers but include it in zone 
transfers.  But that doesn't mean we NXDOMAIN the same way - because the rule 
for NS impacts authorities, the NXDOMAIN issue is in caches.



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop