Subject: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 28 Mar 2011 15:23:49 -0700

Forwarding due to relevancy ...

---------- Forwarded message ----------
From: D. J. Bernstein <[email-masked]>
Date: Mon, Mar 28, 2011 at 3:13 PM
Subject: Re: Fixing the NXDOMAIN/NODATA bug in tinydns
To: [email-masked]

Returning NXDOMAIN for empty nonterminals is not a bug. It is perfectly
interoperable behavior that has been used and continues to be used by
many different pieces of DNS software, including many versions of BIND.
The behavior has never caused problems for DNS users.

Fun historical fact: This behavior was put into the first version of
tinydns after a public statement by BIND maintainer Paul Vixie saying
that this behavior is _required_. Here's the exact Vixie quote:

  RFC 2308 implicitly outlawed BIND's behaviour, which is to return
  NOERROR/ANCOUNT=0 for empty nonterminals. After RFC 2308, empty
  nonterminals are signalled with NXDOMAIN.

A much more recent statement from Vixie claims that BIND never actually
did this---

  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.

---but that's totally wrong. At least five consecutive years of BIND
releases returned NXDOMAIN for empty nonterminals, contrary to Vixie's
statement. (The behavior was suddenly changed in BIND 9.2.3, RT #4715.)

Here's a more detailed message that I tried to send to namedroppers (the
IETF dnsext mailing list) on this topic a month ago. I say "tried"
because this message didn't show up on the mailing list even after I
sent it to the list, sent it again to the "moderator", and sent it once
again to the list.

---D. J. Bernstein
  Research Professor, Computer Science, University of Illinois at Chicago

Subject: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers,
       for Resiliency, Robustness, and Responsiveness
From: "D. J. Bernstein" <[email-masked]>
Date: 23 Feb 2011 22:32:37 -0000
To: [email-masked]
Message-ID: <[email-masked]>

Here's a Paul Vixie quote from a message here dated 8 December 1999
(http://groups.google.com/group/comp.protocols.dns.std/msg/69e4500e7b7d73c8):

  RFC 2308 implicitly outlawed BIND's behaviour, which is to return
  NOERROR/ANCOUNT=0 for empty nonterminals. After RFC 2308, empty
  nonterminals are signalled with NXDOMAIN.

This use of NXDOMAIN has obvious benefits for some server-side database
structures. My DNS server software, tinydns,

  * was released a few weeks later,
  * signals empty nonterminals with NXDOMAIN,
  * has become increasingly popular among DNS administrators, and
  * now publishes the DNS records for millions of second-level domains.

Many versions of BIND, and many other DNS servers currently deployed on
the Internet, also signal empty nonterminals with NXDOMAIN.

If a cache misinterprets NXDOMAIN as applying to subdomains, the cache
doesn't work correctly on the Internet today. Here's a concrete example
to make clear what this means:

  * The NS records for citysearch.com today are d.ns.citysearch.com and
    e.ns.citysearch.com.

  * ns.citysearch.com today returns NXDOMAIN.

  * If a cache follows the citysearch.com NS records to d.ns... and
    e.ns..., but then misinterprets the ns... NXDOMAIN as applying to
    d.ns... and e.ns..., then it will incorrectly conclude that
    citysearch.com has broken glue, and it will respond SERVFAIL for
    www.citysearch.com, completely screwing the user who wanted to see
    the www.citysearch.com web page.

Caches have to, and as far as I know do, apply NXDOMAIN only to "the
same <QNAME, QCLASS>" (RFC 2308, Section 5), easily avoiding this type
of interoperability problem. Anyone who believes the IETF mission
statement in RFC 3935 would expect IETF to promote interoperability by
issuing a warning saying that cache implementors MUST NOT misinterpret
NXDOMAIN as applying to subdomains---if this isn't already sufficiently
clear from the existing IETF documents such as RFC 2308.

Years after his 1999 "After RFC 2308, empty nonterminals are signalled
with NXDOMAIN" statement, Vixie suddenly changed his view and started
issuing highly irresponsible documents (such as "wcard-clarify" in 2003
and "dnsext-resimprove" in 2010) encouraging cache implementors to
misinterpret NXDOMAIN as applying to subdomains---creating exactly the
type of failures described above. At least two cache implementors have
spoken up here to say that this cache behavior _doesn't_ work, _can't_
be turned on, and _isn't_ current practice, so how can it possibly be
labelled "best current practice"?

This has been extensively discussed here before, and nowhere in any of
the discussions has there been any explanation of how this clumsy,
non-interoperable, user-antagonistic change in cache behavior would
provide any benefits for the Internet. Does someone think that the
Internet's bandwidth is being saturated by DNS queries for nonexistent
subdomains of nonexistent domains, or that users are spending noticeable
amounts of time waiting for the answers?

Bottom line: On behalf of the millions of users who rely on my DNS
software (and other deployed software that signals empty nonterminals
with NXDOMAIN), I object to any attempt to change the definition of
NXDOMAIN from the RFC 2308/Vixie 1999/BIND 9/tinydns/etc. definition
into something that applies to subdomains. In particular, I object to
the dnsext-reimprove document.

---D. J. Bernstein
  Research Professor, Computer Science, University of Illinois at Chicago

-- 
Colm

---

From: Paul Vixie <[email-masked]>
Date: Mon, 28 Mar 2011 22:31:18 +0000

thanks colm. i don't think "but bind used to do it this way" or "but paul
once said it was ok" are acceptable input to this discussion -- does anyone?

---

From: Matthew Dempsky <[email-masked]>
Date: Mon, 28 Mar 2011 15:44:50 -0700

> once said it was ok" are acceptable input to this discussion -- does anyone?

You're mischaracterizing the argument.  The concern is that servers
that follow the old behavior are still in widespread use, and suddenly
changing the interpretation will cause massive backwards compatibility
problems.

Just tie the new behavior to an EDNS option or something.  No one's
going to protest that.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 28 Mar 2011 15:46:13 -0700

> once said it was ok" are acceptable input to this discussion -- does anyone?

The first part; yes. Compatibility with implementations, legacy or
otherwise, is definitely on-topic.

-- 
Colm

---

From: Paul Vixie <[email-masked]>
Date: Tue, 29 Mar 2011 07:20:38 +0000

> Date: Mon, 28 Mar 2011 15:44:50 -0700
> From: Matthew Dempsky <[email-masked]>
> 

i don't think so.  nobody is querying intersticial names from an rbl so
even if there were millions of rbldnsd servers running on autopilot it
would not have an operational effect.  but there are at best thousands
of rbldnsd servers and none of them are on autopilot.  tinydns may have
a larger installed base, but there are very few empty nonterminals in
the tinydns datasets i have seen.  there just is no "widespread use" of
the "old behaviour".

> Just tie the new behavior to an EDNS option or something.  No one's

if it would take a wire protocol change then it's not a clarification
and i don't think anybody would say it was worth adding complexity for.
(not even me.)

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 29 Mar 2011 04:56:00 -0400

This is a meta notice about list moderation, for the record.  I
normally wouldn't bother, but I want to make sure that nobody is under
the mistaken impression that we are suppressing legitimate comment.

> sent it to the list, sent it again to the "moderator", and sent it once

I do have, still in my INBOX in fact, a message from Dr Bernstein
about his message not getting posted.  I also have my response, saying
"please send me the message if you're unable to get it posted", along
with a lot of detail of what the mailing list software is, where it is
located and by whom it is operated, what I found when I tried to find
his message, and so on.  I called attention specifically to the fact
that namedroppers was no longer the WG's mailing list and that mail to
the old address seemed to drop from the face of the earth.  I asked
him whether he had mail logs that showed his message was in fact
accepted for delivery, because I was unable to find his message
anywhere.

What I do not have is the original message that Dr Bernstein refers to
in his comments.  As far as I can tell, I never received that.

Now, it would not completely surprise me to learn that I had somehow
managed to delete not once, but three times, the same text that came
to me via three different channels.  But I would be at least mildly
surprised.

If Dr Bernstein has further difficulties, I invite him (again) to
contact me, Olafur, or both of us.  We are the moderators (or, I
guess, "moderators") of the list.  The address for the current chairs
(whoever they may be, as long as there's a WG) is
[email-masked].

If Dr Bernstein believes he was ill treated by me (I take full
responsibility -- Olafur was not involved in the conversation to my
knowledge), I regret it, and would like to know what he wishes I would
do to make this less difficult for him.

Best regards,

A

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

---

From: Florian Weimer <[email-masked]>
Date: Tue, 29 Mar 2011 09:25:05 +0000

* Paul Vixie:

> would not have an operational effect.

Will this remain true if ISC changes BIND to synthesize NXDOMAIN
responses for children of names already known to not exist?  In many
cases, it will not be too difficult to reflect a query for the
non-terminal through the MTA, and after that, the blacklist is
partially bypassed.  So I wouldn't be surprised if such queries turned
somewhat popular, suddenly.

And regarding the idea of a new EDNS option---we already have plenty
of NXDOMAIN signalling in the form of NSEC(3) records.  We just have
to agree to use it.  What's worse, it seems to me that past experience
shows that EDNS options cause interoperability issues, too.

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 29 Mar 2011 12:12:46 +0200

Could this be a result of Bernstein's use of the most obonxious[*] mail
confirmation loop tool on the planet?

[*] OK I mistyped it, but I prefer the new word, consider it defined by the
context in which it is used.

On Tue, Mar 29, 2011 at 10:56 AM, Andrew Sullivan <[email-masked]> wrote:

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

-- 
Website: http://hallambaker.com/

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 29 Mar 2011 07:40:50 -0400

> confirmation loop tool on the planet?

I would prefer not to speculate why we were unable to work out what
happened.  I merely wanted to assure the WG participants that we are
not neglecting our duty to ensure that relevant comments are brought
to the attention of the WG, regardless of their source.  There are
plenty of ways we have fallen down as chairs (see the recent report);
but this is, I am confident in asserting, not one of them.

A

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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 29 Mar 2011 13:03:47 +0000

> From: Florian Weimer <[email-masked]>
> Date: Tue, 29 Mar 2011 09:25:05 +0000
> 
> > ...  nobody is querying intersticial names from an rbl so even if
> > there were millions of rbldnsd servers running on autopilot it would
> > not have an operational effect.
> 
> responses for children of names already known to not exist?

let's assume that if reimprove passes to rfc as-is that everybody will
implement it (not just ISC for BIND) and that if it does not than nobody
will implement it (not even ISC for BIND).  as to "remain true", probably
it will, since if spammers actually cared enough to pollute caches with
negative elements -- which they don't since the RBL's aren't stopping
them and they won't make more money by bypassing them even if it was
easier than this -- ...

> In many cases, it will not be too difficult to reflect a query for the

i'm trying to guess what you mean by "not too difficult".  the RBL logic
i know about is in sendmail and postfix, which always asks for the full
name.  how would you go about getting the MTA to request something like
187.152.204.rbl.mail-abuse.org assuming that trend was using rbldnsd and
would answer with nxdomain so that one could then spam less impededly
from 204.152.187.111 ?

> shows that EDNS options cause interoperability issues, too.

this sounds like a veiled suggestion that we remove this from resimprove
and that someone get working on an aggressive negative caching proposal?

---

From: Tony Finch <[email-masked]>
Date: Tue, 29 Mar 2011 14:30:30 +0100

Paul Vixie <[email-masked]> wrote:
>
> how would you go about getting the MTA to request something like
> 187.152.204.rbl.mail-abuse.org

ehlo 187.152.204.rbl.mail-abuse.org
mail from:<[email-masked]>

etc.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fair Isle, Faeroes, South-east Iceland: Mainly southeasterly 4 or 5,
increasing 6 at times, but cyclonic at first in Southeast Iceland. Moderate or
rough. Rain or showers. Moderate or good, occasionally poor in Southeast
Iceland.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 29 Mar 2011 14:15:22 +0000

> Date: Tue, 29 Mar 2011 14:30:30 +0100
> From: Tony Finch <[email-masked]>
> 

neat! thanks.

---

From: Florian Weimer <[email-masked]>
Date: Tue, 29 Mar 2011 15:38:55 +0000

> this sounds like a veiled suggestion that we remove this from resimprove

I strongly believe that this would improve the quality of the document
(in terms of reflecting existing practice), so yes. 8-)

> and that someone get working on an aggressive negative caching proposal?

I'm not sure if it is worth the effort.  But if better negative
caching is the goal, DNSSEC data seems a reasonable candidate for
further information.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 29 Mar 2011 15:56:30 +0000

> Date: Tue, 29 Mar 2011 15:38:55 +0000
> 

is there any opposition to this change?

> caching is the goal, DNSSEC data seems a reasonable candidate for

whether using dnssec or not, aggressive negative caching would need a document.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 29 Mar 2011 11:57:43 -0400

>and that someone get working on an aggressive negative caching proposal?

In other threads I've made statements that lead me to say "no" 
because I've come to believe aggressive negative caching is in 
general not a good idea.

I think being aggressive with NXDOMAIN is workable, though.  Even if 
the NSEC/3's "clip" down the ranges they cover, there is no harm to 
the authority.  This is nothing different from what we already have 
in RFC 2308 though.

There are plenty of things caches can do to be more aggressive in the 
positive space, like pre-fetching, being more energetic in trying to 
validate a response, etc.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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!"

---

From: Edward Lewis <[email-masked]>
Date: Tue, 29 Mar 2011 11:58:29 -0400

>is there any opposition to this change?

Given the back and forth, can you summarize what "this change" refers to?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Paul Vixie <[email-masked]>
Date: Tue, 29 Mar 2011 16:09:28 +0000

> Date: Tue, 29 Mar 2011 11:58:29 -0400
> From: Edward Lewis <[email-masked]>
> 

> > (in terms of reflecting existing practice), so yes. 8-)

referring to $subject which is "NXDOMAIN/NODATA for non-terminals".

---

From: Edward Lewis <[email-masked]>
Date: Tue, 29 Mar 2011 12:18:52 -0400

>>  > > this sounds like a veiled suggestion that we remove this from resimprove

"remove this" -> remove what?  Trying to find the messages on this, 
it seems there was some mention of an EDNS option, but in

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

I don't see any mention of EDNS.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 30 Mar 2011 12:04:51 +0000

* Edward Lewis:

> "remove this" -> remove what?  Trying to find the messages on this, it
> seems there was some mention of an EDNS option, but in
>

I was referring to section 3.  I think it is misleading and would lead
to poorer service from resolvers if implemented.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 30 Mar 2011 16:27:14 -0400

>to poorer service from resolvers if implemented.

Florian, thanks for the pointer. I really had lost track of the thread.

In section 3, it mentions an ambiguity in RFC 1034.  Question: what 
ambiguity (there are a lot of them), like what section or page.  I'm 
asking out of curiosity.

Still, the point of section 3 is right.   If there were no bad code 
out there and if the data never changed then I'd say it is good.  But 
there is bad code out there.

Dan Bernstein's statement (as found in [0]) that returning NXDOMAIN 
for empty non-terminals is acceptable because buggy code did this in 
the past is an interesting point.  While technically wrong to do so, 
this code is out there and to accommodate (work around the bug), 
optimizing according what is in section 3 would be sub-optimal.  I 
would never say that NXDOMAIN for empty non-terminals is correct as a 
protocol analyst.  But if I was dealing with buggy code, I'd play the 
"be liberal in what you accept" card.

Secondly, because of the fact that things change, it might be wrong 
for a cache to synthesize, based on a cached NXDOMAIN what may now be 
in a subdomain of the zone authoritative for the NXDOMAIN.  To me, 
this is a secondary concern because we've long recognized that the 
DNS protocol is pretty much agnostic about time.  It is true that 
RFC's in the past have said an NXDOMAIN can be used by caches to 
declare data of any type at a name as non-existing - but this 
pertains to the same name, not descendents.

So, while I think in theory section 3 is correct, in practice it 
seems to be an over-optimization given an imperfect world.

[0] - http://www.ietf.org/mail-archive/web/dnsext/current/msg11084.html
(I don't see a message "directly" from him, just this forward.  In 
case the forward was a forgery my point is directed at the real 
source of the comment, not Dan Bernstein.)

---

From: Paul Vixie <[email-masked]>
Date: Wed, 30 Mar 2011 22:48:25 +0000

> Date: Wed, 30 Mar 2011 16:27:14 -0400
> ...
> Dan Bernstein's statement (as found in [0]) that returning NXDOMAIN for
> empty non-terminals is acceptable because buggy code did this in the past
> is an interesting point.  While technically wrong to do so, this code is
> out there and to accommodate (work around the bug), optimizing according
> what is in section 3 would be sub-optimal.  I would never say that NXDOMAIN
> for empty non-terminals is correct as a protocol analyst.  But if I was
> dealing with buggy code, I'd play the "be liberal in what you accept" card.

when the buggy code was bind4 and we had a 100% market share and the bug
was that all axfr's coming toward us had to have one rr per header, we
did not ask for a spec change, we declared the code bad and fixed it.

if we don't want to do that with rbldnsd given its 0.00005% market share
and that really is the consensus of the working group, we can remove the
text.  i'd like to hear from different voices to help judge consensus.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 30 Mar 2011 19:25:28 -0700

> text.  i'd like to hear from different voices to help judge consensus.

The behavior isn't limited to rbldnsd. It is also manifest in TinyDNS,
and probably other non-tree-indexed implementations.

These implementations may not have a plurality of domain names on
them, but I think they do meet the "widely deployed" bar.

Given that, it seems imprudent for resolvers to make inferences about
empty sub-trees based merely on NXDOMAIN.

At least one EDNS0 capable implementation exists that exhibits this
behavior [1] . So for the moment, making inferences on EDNS0 also
seems unwise.

Making inferences based on returning DNSSEC data may be safe, I
haven't yet found any counter-examples. I wouldn't be surprised to
find one though.

My vote would be for;

  Recommending that authoritative servers implementing DNSSEC SHOULD
NOT return NXDOMAIN for non-terminal labels.

  Recommending that caches SHOULD NOT infer empty sub-trees based on NXDOMAIN.

My reason for saying "implementing DNSSEC" is that inferring sub-tree
emptiness is another dangerous poisoning case (along with spoofed
DNAME and NS responses) that can poison a very large name-space in a
cache for very low effort. DNSSEC is a reasonable mitigation against
that problem.

On the historical point, I don't agree with djb's interpretation of
RFC2308. That RFC says;

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

It doesn't say "only returned". To say that inferences about empty sub-trees
is "outlawed" goes too far. But I think there's so little clarity in
the standards, that
no particular "side" has great support there. Greater clarity from now
on will definitely help!

[1]   dig +edns=0 terminal-label.non-terminal.notesfromthesound.com
@ns-431.awsdns-53.com
       dig +edns=0 non-terminal.notesfromthesound.com @ns-431.awsdns-53.com

-- 
Colm

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Thu, 31 Mar 2011 11:53:04 +0100

On 30 Mar 2011, at 21:27, Edward Lewis wrote:
> Dan Bernstein's statement (as found in [0]) that returning NXDOMAIN for empty non-terminals is acceptable because buggy code did this in the past is an interesting point.  While technically wrong to do so, this code is out there and to accommodate (work around the bug), optimizing according what is in section 3 would be sub-optimal.  I would never say that NXDOMAIN for empty non-terminals is correct as a protocol analyst.  But if I was dealing with buggy code, I'd play the "be liberal in what you accept" card.

I have to admit, I can't even understand the question, and after so much discussion I'm starting to feel that I never will.  I could not imagine any other behaviour than the one manifest in pretty much every DNS server I can get my hands on (BIND 9, Tinydns, MaraDNS, NSD, ...) and could not see how it would even make sense or be possible to implement the suggestion to return 0 records for non-terminal labels.  What would the authority for such a query name be?  You could hardly synthesise one, and using the SOA from the next highest delegation doesn't work, unless you also don't mind making the case of no data at query name exclusively indistinct from no data at query name except for the possibility of terminating labels.  How could you distinguish components of query names which are naturally entered and used with dots in their textual representations, without providing misleading responses to questions about the right-hand sides of such names?  And doesn't it follow that a non-terminal name isn't a name, so that it doesn't exist, rather than that it does only because it happens to use more than the usual number of labels between delegations?

And then there's all the existing points raised about the feasibility of *trusting* NXDOMAIN responses, based on the idea that the authoritative servers will distinguish terminals from non-terminals in this way, which as has been discussed before is problematic for a number of good, solid reasons (RBLs, increased work for caches with non-tree structures, etc).

If somebody could help me to understand which bit of RFC 1034-5 or succeeding documents says (or even hints at) the fallibility of multi-label names, I'd be especially interested, since so far I haven't been able to do it.  It would help me decide that much more firmly one way or the other; for now, I don't like the suggestion.  Maybe it's all about semantics, but I like things the way they are (in this regard). It's clearer and, for me, more logical and sensible, with no added gotchas.

Cheers,
Sabahattin

PS: Dan did in fact post that referenced message to his [email-masked] list.  I use tinydns, primarily, but am thinking about shuffling along to NSD.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 31 Mar 2011 07:58:47 -0400

At 11:53 +0100 3/31/11, Sabahattin Gucukoglu wrote:

>If somebody could help me to understand which bit of RFC 1034-5 or succeeding
>documents says (or even hints at) the fallibility of multi-label names, I'd be
>especially interested, since so far I haven't been able to do it.  It would
>help me decide that much more firmly one way or the other; for now, I don't
>like the suggestion.  Maybe it's all about semantics, but I like things the
>way they are (in this regard). It's clearer and, for me, more logical and
>sensible, with no added gotchas.

Try reading RFC 4592.  It has a definition of what constitutes "existence."

I can see how all this is confusing and absurd.  It's all very 
Seinfeldian [0]. It's true, what does it matter you get in a response 
if there's no data to be had?  Nothing is nothing.  But the reason 
folks are so passionate about NXDOMAIN vs. NoError/0 anwer records is 
that other parts of the protocol are impacted.  The definition of the 
wildcard mechanism for one (that's what RFC 4592 refers to).  And the 
inference of caches on what exists is another (RFC 2308 & RFC 4304/5).

[0] From http://en.wikipedia.org/wiki/Seinfeld: "The show, often 
described as being about "nothing"..."

>PS: Dan did in fact post that referenced message to his [email-masked]
>list.  I use tinydns, primarily, but am thinking about shuffling along to NSD.

Ahh, thanks.  I am not on that list.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Tony Finch <[email-masked]>
Date: Thu, 31 Mar 2011 15:27:21 +0100

> NOT return NXDOMAIN for non-terminal labels.

I believe that requirement already exists as a MUST NOT.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forth, Tyne, Dogger: West or southwest 7 to severe gale 9 backing south or
southwest 4 or 5, increasing 6 or 7 later. Moderate or rough. Rain or showers.
Good, occasionally poor.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 31 Mar 2011 12:07:45 -0400

>I believe that requirement already exists as a MUST NOT.

Although I agree that sending a NXDOMAIN for an 
empty non-terminal is a protocol error[0], I'll 
note that in the resimprove document it says:

# This is due to an ambiguity in RFC 1034 that failed to distinguish
# empty nonterminal domain names from nonexistent names.

To convert "I believe" to something more 
fact-based, it would be helpful if the ambiguity 
were identified.

[0] from this in RFC 1034, section 4.3.2:

# 3. Start matching down, label by label, in the zone.  The
#      matching process can terminate several ways:
#
#         a. If the whole of QNAME is matched, we have found the
#           node.

That is, the name/node exists, whether it has a type match remains to be seen.

#           ...skipping CNAME stuff...
#
#           Otherwise, copy all RRs which match QTYPE into the
#           answer section and go to step 6.

If there are no RRs to match (and empty 
non-terminal), none match, hence no data is put 
into the answer section.

On the other hand, of the name isn't there, here 
is the instruction for Name Error (aka NXDOMAIN):

#         c. If at some label, a match is impossible (i.e., the
#            corresponding label does not exist), look to see if a
#            the "*" label exists.
#
#            If the "*" label does not exist, check whether the name
#            we are looking for is the original QNAME in the query
#            or a name we have followed due to a CNAME.  If the name
#            is original, set an authoritative name error in the
#            response and exit.  Otherwise just exit.

RFC 2308, section 2.1 shows NXDOMAINs where the 
name is not original.  Reducing the logic that 
would mean the above reads as:

              If the "*" label does not exist, set an authoritative name
              error in the response and exit.  Otherwise just exit.