Subject: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 21 Feb 2011 03:45:24 -0500

The chairs have received a request to Last call this draft.
http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00

This draft is clearly in scope of the Working Group.

As there has not been much discussion on this draft the chairs are
not ready at this point to start a Last Call but would like to get a 
sense of the working group participants' feelings on the draft.

The draft is aimed at BCP status; thus there is no RFC2119 language in 
the draft.

Background: The draft contains three recommendation on how resolvers 
operate,
     A. Re-validating a delegation when a parent NS RRset TTL expires.
     B. Stopping a downward cache search when an NXDOMAIN is encountered.
     C. Upgrading the credibility of NS RRsets upon delegation event.

All of these have been suggested in various forms over the years.

Following opinions are sought:
1. Are the suggestions in the draft something people think is a good
    idea?

2. Is the draft clear in its message?  If not, please suggest improvements.

3. After (if any) editing fixes is this draft ready for WG Last Call?

     Olafur and Andrew
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: David Blacka <[email-masked]>
Date: Mon, 21 Feb 2011 13:58:27 -0500

On Feb 21, 2011, at 3:45 AM, Olafur Gudmundsson wrote:

> not ready at this point to start a Last Call but would like to get a sense of the working group participants' feelings on the draft.

I was not aware of this draft's existence until now, but I just read it.

> 
> The draft is aimed at BCP status; thus there is no RFC2119 language in the draft.
> 
> Background: The draft contains three recommendation on how resolvers operate,

I'm unsure, although I'm leaning toward thinking that they are not good ideas.

(A) is (I think) trying to solve issues caused by "cache pinning" when moving a zone from one set of nameservers to another.  Actually, it goes further than that (if I understand the draft correctly, which I very well may not) by effectively removing entire delegation chains when the ancestor NS RRset expires.  So, e.g., every time the com NS RRset expires, all delegations below it effectively expire.  I have no idea what problem this overall behavior solves, although I suspect that it defeats a great deal of the value of a cache.

(B) is about having resolvers actually believe NXDOMAIN responses.  While I think it might be nice if we could trust that NXDOMAIN actually meant that the name didn't exist, I don't see how this improves the "resiliency" or "robustness" of the *resolver*.

(C) is about working around delegation scenarios that favor parent-side delegation information by instructing the resolver to directly query the child nameservers for NS records.  I don't know what actual problem this is attempting to solve.

> 2. Is the draft clear in its message?  If not, please suggest improvements.

It is entirely unclear to me what problems the various proposals are actually trying to solve.

> 3. After (if any) editing fixes is this draft ready for WG Last Call?

Not in my opinion.  I don't think the ideas are clearly BCPs.

--
David Blacka                          <[email-masked]> 
Principal Engineer    Verisign Platform Product Development

---

From: Brian Dickson <[email-masked]>
Date: Mon, 21 Feb 2011 15:51:20 -0400

I have read the draft, and also David's comments, and have comments of
my own in-line below.

Briefly, however, I'd say:
- the things in the draft are all good ideas
- the draft is good, should be adopted, requires only a small amount
of work, and once that is done, is probably fine for WGLC.
- s few clarifications will go a long way to addressing both David's
issues, and making the document useful
- all of the above are "IMIHO"

See below for in-line comments.

Brian

> (A) is (I think) trying to solve issues caused by "cache pinning" when moving a zone from one set of nameservers to another.  Actually, it goes further than that (if I understand the draft correctl…

My read on the draft, and I'm reasonably confident it's what the
author intended, is that "stale" delegations be "refreshed" (or have a
"refresh" attempted) before they are used.
It is analogous to the "refresh" between master and slave authority
servers for a given zone, e.g. verifying the SOA SN if the "refresh"
timer fires off.

And, basically, the "refresh" is to make sure the delegation
(non-authoritative) NS records are "reasonably consistent" with what
was already cached, and if so, re-establishes the validity, re-sets
the TTL, and re-populates the NS set if some changes have occurred.
No expiration occurs, unless both (a) the TTL expires, and (b) the new
delegation NS RRSET has nothing in common with the cached RRset - in
which case, the child side and all descendants MUST be discarded.

It actually is better than blindly discarding the children, which I
think might have to happen currently. Only if the delegation points
elsewhere, when the TTL expires, do the children need to be discarded.

> (B) is about having resolvers actually believe NXDOMAIN responses.  While I think it might be nice if we could trust that NXDOMAIN actually meant that the name didn't exist, I don't see how this im…

This is one place where I think some updates to the ID need to be done.

Basically, we need a reference (i.e. to RFCs in standard I-D style)
to the changes to the standard(s) that differentiate 1034's "Name
Error" from the two cases we now know about, "NXDOMAIN", and "empty
non-terminal" (a node with no RRs itself, which has descendants,
inside a zone).

If I understand it, things should now work as follows:
- if an empty non-terminal matches a QNAME, the *answer* should be
empty, but there should *not* be any error code.
- if no domain exists (and that means neither  the domain nor any
children exist), there *should* be an error code of NXDOMAIN

And, given the logic immediate above, this means that NXDOMAIN can and
should be cached (if and only if the above applies), and when an
NXDOMAIN is cached, children of that node get discarded, and
subsequent queries to the *resolver* below that NXDOMAIN can
themselves be guaranteed to be NXDOMAINed, and there is no need to
send the query to the authority server for the given zone.

But, this should be clarified in the text of the draft.

I agree that it is a suitable optimization, and as I understand it,
correct behavior.

> (C) is about working around delegation scenarios that favor parent-side delegation information by instructing the resolver to directly query the child nameservers for NS records.  I don't know what…

I *believe* it is working around situations where different
implementations of authority server have interpreted existing RFCs
differently, and arguably both interpretations are technically
correct.
And, that it is also always preferable to have the most authoritative
(correct) NS data in the cache, even if it wasn't returned in the
authority section of the authority server.
I believe this is particularly relevant in order to also do (A) above.

It would be helpful, perhaps, to differentiate the behavior of a
resolver, when it does have, and when it does not have, the apex NS
RRSET, and when that might trigger different behavior to a client of
the resolver.
(E.g. when the resolver path includes things like: "client ->
recursive resolver -> bigger recursive resolver -> authority
server(s)".)

---

From: Tony Finch <[email-masked]>
Date: Mon, 21 Feb 2011 21:28:53 +0000

On 21 Feb 2011, at 18:58, David Blacka <[email-masked]> wrote:.
> (A) is (I think) trying to solve issues caused by "cache pinning" when moving a zone from one set of nameservers to another.  Actually, it goes further than that (if I understand the draft correctl…

There are a couple of other things that worry me about this section of the draft.

Firstly, it suggests that there can be multiple different TTLs on the delegation NS RR set - it talks about the minimum TTL. It needs fixing to understand that the whole RR set has the same TTL.

Secondly, it is basically suggesting that the TTL of the non-authoritative spoofable delegation NS RR set should override the TTL of the authoritative signed apex NS RR set. This seems to me to be contrary to DNS and DNSSEC authority semantics.

Tony.
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Feb 2011 22:31:09 +0000

there are replies to three messages here.

---

> From: David Blacka <[email-masked]>
> Date: Mon, 21 Feb 2011 13:58:27 -0500
> ...

i figured as much from the silence.  hopefully this thread will stimulate
other readers.

> ... I'm unsure, although I'm leaning toward thinking that they are not
> good ideas. 

you've misunderstood the text, indicating that the writing quality is
too low.  i won't go point by point on your misgivings and concerns,
since...

---

> Date: Mon, 21 Feb 2011 15:51:20 -0400
> From: Brian Dickson <[email-masked]>
> 

...since brian dickson's point by point followup is accurate and on target.

> - all of the above are "IMIHO"

this echos my own view.  we were not expecting to go to WGLC on -00, and
in fact there is a -01 in the wings (sweeping in a fourth topic that was
flying solo out of CNNIC) and we should see that posted before the cutoff
for prague.  what the authors were hoping for from -00 is exactly the kind
of review and feedback that is occurring right now.  so, let's pull back
from WGLC and fix the editorial problems noted by dave blacka and put this
on the prague agenda?

---

> From: Tony Finch <[email-masked]>
> Date: Mon, 21 Feb 2011 21:28:53 +0000
> 
> Firstly, it suggests that there can be multiple different TTLs on the
> delegation NS RR set - it talks about the minimum TTL. It needs fixing
> to understand that the whole RR set has the same TTL.

well, so, the protocol gives each RR a TTL and the original specification
does not say what to do if the TTLs in an RR set differ.  in BIND4 4.9, i
decided to discard the whole RR set if any of its TTLs reached zero since
otherwise we'd be modifying RR sets during TTL expiration.  in RFC 2136 i
enshrined this behaviour into the protocol by declaring "RR set atomicity".
but editorially speaking i still think it's wise to say "discard when the
minimum TTL in the RR set is reached" since the wire protocol allows TTLs
to be different across an RR set and sending them out that way is not an
error or a protocol violation.

> Secondly, it is basically suggesting that the TTL of the
> non-authoritative spoofable delegation NS RR set should override the
> TTL of the authoritative signed apex NS RR set. This seems to me to be
> contrary to DNS and DNSSEC authority semantics.

again, the quality of the writing is evidently low, and i wrote this
section of the resimprove draft so i'll take the hit for that.  it is
NOT an override.  it's a freshness guaranty.  if upon parent (non-auth)
expiry the refresh (from the parent) shows that the delegation still
exists then no change is made to the child (auth) data then in cache.
however, if the delegation has disappeared in the parent, then we want
the child GONE.  e-criminals periodically use million-second TTLs on
their zone data and by the time they're done with a spam run using that
name it's ineffective to delete the delegation since by that time child
data is widely held in caches.  using the parent TTL as a freshness
guaranty just means the registrar and registry operators can put shorter
TTLs on the delegation than the child has at their apex, and cause
periodic refreshes of this, for the purpose of having domains disappear
from cache if their delegation disappears.  it has no dnssec or other
semantic effects.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 21 Feb 2011 17:43:51 -0500

No hat.

> error or a protocol violation.

My reading of RFC 2181, section 5.2 says that it is an error and a
protocol violation.  Does that need more clarification?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 21 Feb 2011 23:28:08 +0000

> Date: Mon, 21 Feb 2011 17:43:51 -0500
> From: Andrew Sullivan <[email-masked]>
> 

yes. no initiator i know of discards rrsets just due to ttl variance.
therefore the guideance to initiators is effectively "do what BIND4
4.9 did" in other words treat the whole rr set as though it had the
ttl of the lowest rr therein.  if rfc 2181 does not make this clear
then it is not providing reasonable and actionable guideance.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 22 Feb 2011 11:31:22 +0100

Hi,

I read (and implemented) this draft (as config options) some time ago.
They are pretty good ideas, but I have some concerns, below.

> servers for a given zone, e.g. verifying the SOA SN if the "refresh"

Yes, I appreciate the utility of picking up new delegation changes
once-in-a-while.

> which case, the child side and all descendants MUST be discarded.

I think discarding the tree below is cache-management strategy, and was
not the aim of point A.  The usual DNS time shifted coherency is the goal.

> children exist), there *should* be an error code of NXDOMAIN

Yes this problem exists.

> I agree that it is a suitable optimization, and as I understand it,

I do not think you could enable this by default today, because very old
software might still have bugs in handling empty nonterminals and send
NXDOMAINs for them.

>> (C) is about working around delegation scenarios that favor parent-side delegation information by instructing the resolver to directly query the child nameservers for NS records.  I don't know wha…

Sounds like an idea of a Dutch guy.  Disabled by default ...

>> It is entirely unclear to me what problems the various proposals are actually trying to solve.

Yes, that is not a part of the text.  Perhaps a light-weight fix can be
applied.

>>> 3. After (if any) editing fixes is this draft ready for WG Last Call?

That would be a little too quick.

Best regards,
   Wouter

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 22 Feb 2011 09:10:16 -0500

No hat.

> then it is not providing reasonable and actionable guideance.

Well, here's the section in toto:

5.2. TTLs of RRs in an RRSet

   Resource Records also have a time to live (TTL).  It is possible for
   the RRs in an RRSet to have different TTLs.  No uses for this have
   been found that cannot be better accomplished in other ways.  This
   can, however, cause partial replies (not marked "truncated") from a
   caching server, where the TTLs for some but not all the RRs in the
   RRSet have expired.

   Consequently the use of differing TTLs in an RRSet is hereby
   deprecated, the TTLs of all RRs in an RRSet must be the same.

   Should a client receive a response containing RRs from an RRSet with
   differing TTLs, it should treat this as an error.  If the RRSet
   concerned is from a non-authoritative source for this data, the
   client should simply ignore the RRSet, and if the values were
   required, seek to acquire them from an authoritative source.  Clients
   that are configured to send all queries to one, or more, particular
   servers should treat those servers as authoritative for this purpose.
   Should an authoritative source send such a malformed RRSet, the
   client should treat the RRs for all purposes as if all TTLs in the
   RRSet had been set to the value of the lowest TTL in the RRSet.  In
   no case may a server send an RRSet with TTLs not all equal.

To me, it's pretty clear (1) that having different TTL values on RRs
in the RRset is an error, (2) that you should just ignore such RRsets
if they're not authoritative, (3) that is is a protocol error to send
an RRset with different TTLs on different RRs in the set, and (4) that
any client receiving such a set should use the lowest TTL in the set
for everything.  My own view is that the requirements are crystal
clear, and since RFC 2181 updates all of 1034, 1035, and 1123 I think
it changes the protocol.  According to STD1, it's a Proposed Standard. 

A

---

From: Doug Barton <[email-masked]>
Date: Tue, 22 Feb 2011 14:49:41 -0800

> I read (and implemented) this draft (as config options) some time ago.

Can you elaborate?

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Florian Weimer <[email-masked]>
Date: Wed, 23 Feb 2011 09:53:36 +0000

> software might still have bugs in handling empty nonterminals and send

A lot of DNSBLs are hosted on servers which send NXDOMAIN for empty
non-terminals.

I don't think this change is worth the effort.  I would rather prefer
official blessing of NXDOMAIN synthesis from NSEC/NSEC3 records.  This
would be both more deterministic and more effective.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Paul Vixie <[email-masked]>
Date: Wed, 23 Feb 2011 10:11:56 +0000

> From: Florian Weimer <[email-masked]>
> Date: Wed, 23 Feb 2011 09:53:36 +0000
> 
> > I do not think you could enable this by default today, because very
> old > software might still have bugs in handling empty nonterminals
> and send > NXDOMAINs for them.
> 

those servers are lying and/or seriously broken/nonconformant.  i don't
like walking as if on on eggshells to avoid offending them.  they ought
to be fixed, not tolerated.

consider BIND4 4.8's odd AXFR behaviour. it only looked at the first
answer in each message, and only sent one answer per message. it had a
100% market share. we fixed the problem in 4.9.3 and added configuration
knobs defaulting to sending single-answer output (to avoid causing older
noncompliant initiators to reject the transfers) but allowing this to be
overridden. eventually we just changed the default. microsoft, whose
correct DNS implementation was not compatible with BIND, had to do the
same thing. they deserved an apology from me, which they got, not excuses.
the standards weren't changed as a result. again, at the beginning of
this debacle the offending DNS implementation had a 100% market share.

> would be both more deterministic and more effective.

while i'd like the DNSSEC solution you propose to also be done, i note
that RBLDNSD operators are among the most technically adept name server
operators in the history of the internet.  a campaign to get this
software patched and to get upgrades installed would have a very short
tail (shorter than the BIND4 AXFR example cited earlier).  this does seem
to me worth doing since i'm not expecting all zones to be signed and since
the specification with respect to empty non-terminals was never unclear.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Florian Weimer <[email-masked]>
Date: Wed, 23 Feb 2011 10:44:36 +0000

> to be fixed, not tolerated.

But there's no significant benefit from this protocol change (at least
none that I can see).  On the contrary, it adds one more case where
stub queries which are not observed regularly can result in
drastically altered resolver behavior.  That's quite an annoying
inconsistency.

> consider BIND4 4.8's odd AXFR behaviour.

I don't want to sound flippant, but I don't see how this is relevant
here and now.

> tail (shorter than the BIND4 AXFR example cited earlier).

For a while, I've been sitting on another rbldnsd/resolver interaction
bug and have been given the run-around so far.  I'm not convinced that
deploying new code is simple.

> this does seem to me worth doing since i'm not expecting all zones
> to be signed and since the specification with respect to empty
> non-terminals was never unclear.

If it wasn't unclear, why did almost everyone implement the old
behavior?

---

From: Paul Vixie <[email-masked]>
Date: Wed, 23 Feb 2011 15:20:14 +0000

> Date: Wed, 23 Feb 2011 10:44:36 +0000
> 

sometimes it takes a code fork if the author is no longer supporting a thing.

> If it wasn't unclear, why did almost everyone implement the old behavior?

who is everyone?  i don't think bind or nominum or microsoft's or
american internet's (now cisco's) authority servers have ever sent
nxdomain on an empty non-terminal, and for a long time that was 100%
of the market.  nlnetlabs nsd and verisign atlas both understood the
spec in this regard also.

the behaviour everyone implemented was on the initiator side, wherein
they did not stop a downward traversal on a cached nxdomain, even with
an rfc 2308 proof in cache, thus shortcutting iteration and forwarding.
the specification was not ambiguous on this point; it was utterly silent.
however, given that the authority server's behaviour (send NOERROR with
ANCOUNT=0) has always been unambiguous, this silence looks like a missed
implication to me rather than omission by intent.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Florian Weimer <[email-masked]>
Date: Wed, 23 Feb 2011 15:48:24 +0000

* Paul Vixie:

> of the market.

The handling of empty non-terminals was changed in BIND 9.2.3,
probably prompted by the standardization work on DNSSECbis.  According
to the CHANGES file, this is RT #4715 in your bug tracker.

> nlnetlabs nsd and verisign atlas both understood the spec in this
> regard also.

Actually, ATLAS sent NXDOMAIN instead of NODATA for existing,
non-delegated names with a missing RRset (that is, empty terminals) at
one point in the not too-distant past.  I don't remember if they
implemented the old BIND behavior, too, but it would be odd to send
NXDOMAIN for empty terminals, and NODATA for empty non-terminals.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 23 Feb 2011 16:19:37 +0000

> NXDOMAIN for empty terminals, and NODATA for empty non-terminals.

Off-list, I was told that my terminology is off, which is true.
Please read "empty RRsets" for "empty terminals".

---

From: Brian Dickson <[email-masked]>
Date: Wed, 23 Feb 2011 12:52:56 -0400

> Please read "empty RRsets" for "empty terminals".

So, this is an interesting data point, arguably in support of Paul,
because of the following:
- it was clearly broken behavior (really, really broken)
- you won't find a shorter tail than that - the vendor *is* the *only*
user of the software (!!)
- it helps illustrate the difference between NODATA and NXDOMAIN (and
when the latter is the wrong answer)
- wow - see point 1 :-)
- it shows that regardless of deployment scope, there should be
pressure to fix broken deployments, rather than to ankylose (rigidly
anchor, forever) that broken-ness into the specifications (IMHO)

Brian

---

From: Edward Lewis <[email-masked]>
Date: Wed, 23 Feb 2011 14:04:15 -0500

>http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00

Some comments on the document.

# 1. Introduction
#
#   1.1. Iterative caching DNS resolvers can be both compliant and
#   interoperable without also being optimal. Indeed a wide range of
#   optimizations, mechanisms, and outright "tricks" can be employed
#   without affecting correctness or interopability. Such optimizations
#   could be recommended but never required.

The first use of the word "optimal" is a problem.  First, is there 
really a definition by which an "iterative caching" resolver can be 
deemed compliant?  Second, is there any way to measure the degree to 
which it is optimal.

This is a wording nit.  I'd suggest something along this line:

1.1. Iterative caching DNS resolvers can be interoperable with other 
servers yet vary in speed of obtaining an answer, safety in believing 
answers, efficient in use of computing resources, and so on. 
Interoperability is of the utmost importance, but there are some 
useful optimizations that deserve to be documented.

(A rough reworking.  The point is to remove comparative words, like 
"optimal" and "compliant," when there's nothing being compared.)

#   1.3. Three practices are described here:
#
#      A. Revalidating a delegation when a parent NS RRset TTL expires.

What does it mean to "validate" a delegation?  We have a definition 
of validation in the context of DNSSEC.  I am sure this is different.

#      B. Stopping a downward cache search when an NXDOMAIN is encountered.

I'm not so sure this is a good one.  It goes against RFC 2308.

#      C. Upgrading the credibility of NS RRsets upon delegation events.

A mistake I've made many times: the term is "trustworthiness," not 
credibility.  See RFC 2181, 5.4.1. Ranking data.

# 3. Stopping Downward Cache Search on NXDOMAIN
#
#   3.1. In virtually all existing resolvers, a cached NXDOMAIN is not
#   considered "proof" that there can be no child domains underneath.
#   This is due to an ambiguity in RFC 1034 that failed to distinguish
#   empty nonterminal domain names from nonexistent names.  For DNSSEC,
#   the IETF had to distinguish this case, but the implication on non-
#   DNSSEC resolvers wasn't fully realized.

FWIW, the ambiguity was addressed in RFC 4592 to fix wild cards, not DNSSEC.

#   3.2. When searching downward in its cache, an iterative caching DNS
#   resolver should stop searching if it encounters a cached NXDOMAIN.
#   The response to the triggering query should be NXDOMAIN.
#
#   3.3. 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.

This is in conflict with RFC 2308, section 5:

RFC A negative answer that resulted from a name error (NXDOMAIN) should
RFC be cached such that it can be retrieved and returned in response to
RFC another query for the same <QNAME, QCLASS> that resulted in the
RFC cached negative response.

This says that the cached NXDOMAIN only applies to the FQDN itself, 
not it's domain.  Ok, ok, that's just paper fighting paper, but this 
switch in requirements has to be addressed.

And I have a sneaking suspicion that this optimization isn't all that 
good of an idea.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
Son: "Waah!"
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Edward Lewis <[email-masked]>
Date: Wed, 23 Feb 2011 14:04:15 -0500

# 1. Introduction
#

---

From: Mark Andrews <[email-masked]>
Date: Thu, 24 Feb 2011 11:31:09 +1100

> spec in this regard also.

The early DNSSEC RFCs specified that NXDOMAIN was to be returned
and named did.  It took some arguing by me, internally and then to
dnsext, to get that reversed.  While this is listed as a bug it was
a protocol bug which was then corrected in code.

1416.   [bug]           Empty node should return NOERROR NODATA, not NXDOMAIN.
                        [RT #4715]

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Paul Vixie <[email-masked]>
Date: Thu, 24 Feb 2011 04:45:17 +0000

> Date: Wed, 23 Feb 2011 14:04:15 -0500
> From: Edward Lewis <[email-masked]>
> 
> What does it mean to "validate" a delegation?  We have a definition of
> validation in the context of DNSSEC.  I am sure this is different.

in this context it means making sure the delegation still exists.

> I'm not so sure this is a good one.  It goes against RFC 2308.

see below.

> This says that the cached NXDOMAIN only applies to the FQDN itself, not
> it's domain.  Ok, ok, that's just paper fighting paper, but this switch in
> requirements has to be addressed.

it does not say "only", which would have been overprescriptive, and the
resimprove proposal could be seen as a 2308 amendment to the effect that
in addition to what 2308 says, and is not in conflict with it.  if so then
it would make resimprove a standards track document not a bcp.

> And I have a sneaking suspicion that this optimization isn't all that good
> of an idea.

please say more when your suspicions become less sneaky?
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Brian Dickson <[email-masked]>
Date: Thu, 24 Feb 2011 01:36:10 -0400

I have some questions, which this discussion has caused me to consider...

(I apologize if they are answered in some RFC or another already,
and/or they may need to be addressed in some future -bis document if
they don't belong here.)

> in this context it means making sure the delegation still exists.

Delegations come from referrals and authority sections thereof...
(restating the obvious.)

There is an odd corner case to consider, but I'm not sure if it's been
considered, and I think it is something which is slightly more likely
to occur nowadays than in the distant past:

Suppose a nameserver serves both a particular zone, and a
great(^n)-grandchild zone.
(E.g. a nameserver serving some TLD, and simultaneously doing DNS
hosting for third parties.)
Suppose also, that some intermediate zone(s), great(^n-1)-grandchild,
parent of the great(^n)-grandchild zone, is *not* served by this
nameserver,. but is delegated elsewhere. That "other" server then
delegates back to "this" server, for the great(^n)-grandchild zone.

An iterative resolver, directed to this (TLD) server by the root
server(s), when querying for the great(^n)-grandchild zone, gets back
an answer for the great(^n)-grandchild *directly* (no passing "go"),
including that zone's authority data.
It gets that without ever chaining through the delegations from the
TLD through the great(^n-1)-grandchild zone(s).

(Obviously in the DNSSEC case, there would need to be explicit DS
chasing and proofs included in serving the answer, if DO=1 on the
client query.)

Should not the iterative resolver look for the intermediate referrals,
if they aren't already in the cache?
I think it *needs* those to "validate" the delegation... (i.e. for the
optimization of the present proposal.)

Have I lost everyone yet?

> please say more when your suspicions become less sneaky?

Here's a sneaky-by-proxy observation and/or question:

Consider a query for "foo.bar.no-chickens.example.net.".

Suppose that "no-chickens.example.net." does not exist (NXDOMAIN and
no descendants).

The authority server for example.net returns "NXDOMAIN", which applies
to the FQDN of the original query (and gets cached there only),
"foo.bar.no-chickens.example.net."

I don't think there's anything in the answer that indicates *where* in
the FQDN, while matching downward, that there was an NXDOMAIN.

For optimization purposes, it would be good (I think) to establish the
"best" place to put an NXDOMAIN.
I.e. Query downward from the zone apex, iteratively, until an NXDOMAIN
is found. QTYPE = NS is benign and/or informative. This should be in
parallel, since it isn't needed for answering the original query.

(While it might be "interesting" to somehow signal this in the first
NXDOMAIN answer, I can't imagine how to do this without breaking lots
of software... like, all of it. E.g. what would happen if the answer
section (also) included the "shorter" NXDOMAIN FQDN, e.g.
"no-chickens.example.net", with RTYPE = ANY instead of matching the
QTYPE?)

Putting the NXDOMAIN as close to the root of the DNS tree as possible
is a clear optimization, since subsequent queries for any sibling of
the first query, wouldn't succeed.

It doesn't change the number of NXDOMAINs required from the current
state, it just moves the NXDOMAIN to a new node.

And, it not only reduces (theoretical) load to the authority server,
it also prevents lots of leaf NXDOMAINs from populating the cache,
below the "real" place that the NXDOMAIN should be.

(It even lowers the impact on the cache, as the "match downwards" will
terminate sooner.)

I'm sure there's a more succinct way to word this, for adding text to
the document.

Brian

---

From: Paul Vixie <[email-masked]>
Date: Thu, 24 Feb 2011 08:17:53 +0000

> Date: Wed, 23 Feb 2011 15:48:24 +0000
> 

as marka has explained, this was a dnssec protocol bug, which bind9 tracked.

---
> Please read "empty RRsets" for "empty terminals".

either way this is unrelated to empty nonterminals, which atlas never had
to deal with anyway, i should not have mentioned it.

---

> Date: Wed, 23 Feb 2011 12:52:56 -0400

right.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 24 Feb 2011 08:44:33 +0000

> Date: Thu, 24 Feb 2011 01:36:10 -0400

that's fine.

> chasing and proofs included in serving the answer, if DO=1 on the

yes.

> optimization of the present proposal.)

no.

resimprove does not propose any change to the delegation model.  if a
cached ns rrset is received from the servers for the closest bailiwick
then known (for example, from a server for the root zone or a server for
a tld zone) then the 1034/1035 assumption (wrong though it may be, as
shown by your example) is that there are no zone cuts between the
bailiwick and the referral, and this assumption is still valid for a
resimprove implementation.

---

right.

> parallel, since it isn't needed for answering the original query.

that's way more traffic and complexity than we're proposing in resimprove.

> the first query, wouldn't succeed.

agreed but that would be a protocol change which we're not proposing here.
in effect, this is what i took florian to mean when he suggested that a
caching recursive name server be able to synthesize nxdomain based on a
cached and secure NSEC or NSEC3.  that's a good idea but it's beyond the
scope of the resimprove proposal.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Tony Finch <[email-masked]>
Date: Thu, 24 Feb 2011 12:48:00 +0000

> TLD through the great(^n-1)-grandchild zone(s).

See for example audns.net.au.

I seem to remember the Australian 1LD / 2LD nameserver situation being
rather tangly until some time relatively recently, though I can't right
now find any documents describing the changes.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Portland, Plymouth, North Biscay: Southerly or southwesterly 4 or 5,
occasionally 6 later. Moderate or rough. Occasional rain, drizzle, fog
patches. Moderate or poor, occasionally very poor.
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext