Subject: DNSEXT WGLC: Wildcard Clarify

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 20 Aug 2003 10:07:35 +0200

This is a last call for the 'Wildcard Clarify' document.

Title: 
Clarifying the Role of Wild Card Domains in the Domain Name System

URL:   
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-01.txt

Please read the document, send in motivated statements of support,
opposition, clarifications &c.  This protocol is on standards track,
if you disagree with that please speak up and motivate.

The last call period is a little over 2 weeks and will conclude Sunday
September 7, 2003.

If there is no discussion about this document the default action by
chairs is to advance it as the need for this document is clearly
motivated by the authors and not opposed in recent discussion.

                           --------------------

 Abstract:

  The definition of wild cards is recast from the original in RFC
  1034, in words that are more specific and in line with RFC 2119.
  This document is meant to supplement the definition in RFC 1034 and
  to alter neither the spirit nor intent of that definition.
 
 From the Introduction:

  Why is this document needed?  Empirical evidence suggests that the
  words in RFC 1034 are not clear enough.  There exist a number of
  implementations that have strayed (each differently) from that
  definition.  There also exists a misconception of operators that the
  wild card can be used to add a specific RR type to all names, such
  as the MX RR example cited above.  This document is also needed as
  input to efforts to extend DNS, such as the DNS Security Extensions
  [RFC 2535].  Lack of a clear base specification has proven to result
  in extension documents that have unpredictable consequences.  (This
  is true in general, not just for DNS.)

                           --------------------

-- Olaf
   DNSEXT Co-Chair

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "D. J. Bernstein" <[email-masked]>
Date: 26 Aug 2003 02:42:18 -0000

Suppose that AOL sets up the following records:

   aol.com SOA ...
   aol.com NS a.ns.aol.com
   aol.com NS b.ns.aol.com
   www.aol.com A 1.2.3.4
   a.ns.aol.com A 1.2.3.5
   b.ns.aol.com A 1.2.3.5

Suppose there's a query for ns.aol.com. It's safe for AOL's servers to
return NODATA. But is it safe for AOL's servers to return NXDOMAIN?

RFC 2308 says that the answer is yes. It interprets NXDOMAIN as ``there
are no records owned by the query name,'' which is exactly the situation
here. (Section 5: ``NXDOMAIN ... the same <QNAME, QCLASS> ...'')

But wcard-clarify-01 section 1.4, like RFC 1034, says that the answer is
no. It interprets NXDOMAIN as ``there are no records whose owner name
_ends with_ the query name,'' which is not the situation here.

Most servers do, in fact, return NXDOMAIN in this situation, so it would
be incredibly dangerous for a cache to apply NXDOMAIN in the way allowed
by wcard-clarify-01 and by RFC 1034. The NXDOMAIN for ns.aol.com, for
example, would nuke the a.ns.aol.com and b.ns.aol.com records.

As a practical matter, the RFC 1034 meaning of NXDOMAIN doesn't save a
noticeable percentage of queries, and the RFC 2308 meaning of NXDOMAIN
reduces programming effort for many popular server database structures,
so I don't see any reason to favor RFC 1034 over RFC 2308.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: "D. J. Bernstein" <[email-masked]>
Date: 26 Aug 2003 03:32:36 -0000

The algorithm in RFC 1034 section 4.3.2 is clearly labelled as a mere
_example_ of what servers are allowed to do.

Many servers don't work that way. In particular, tinydns follows a very
different algorithm, as do most LDAP-based DNS servers. For example,
tinydns has some support for SOA synthesis; wcard-clarify-01 is simply
wrong when it says that ``no implementation has done this.''

Does wcard-clarify-01 constrain the behavior of these servers? Does it
have any impact outside the algorithm in RFC 1034 section 4.3.2?

For example, when wcard-clarify-01 says (R2.1) that ``a domain name that
is to be interpreted as a wild card MUST begin with a label of '0000
0001 0010 1010' in binary,'' is it prohibiting the behavior of advanced
servers that allow record synthesis based on (say) regular expressions?

Similarly, when wcard-clarify-01 says (R2.2) that ``escaped'' wild cards
must be treated as wild cards, is it merely clarifying the semantics of
RFC 1034 zone files (which aren't the same as BIND zone files), or is it
trying to drag all possible DNS server configuration tools down to RFC
1034's level? Either way, why is the IETF sticking its nose into local
configuration issues?

This document seems to be a primitive implementation guide rather than a
protocol spec. I realize that wildcards appear in the AXFR and NXT
protocols, but wcard-clarify doesn't limit itself to the context of
those protocols. To the extent that wcard-clarify goes beyond issues
visible on the wire, it's violating section 6 of RFC 2119.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 25 Aug 2003 23:28:49 -0400

>_ends with_ the query name,'' which is not the situation here.

First, let's remove the use of the mnemonic and stick with 'name 
error' to describe the issue.  In the editing process I am trying to 
remain implementation neutral, and, although NXDOMAIN does appear in 
some RFCs, those RFCs are out of scope for this clarification.  (See 
the last part of this reply.)

Second, RFC 2308 is a Proposed Standard and is not what wcard-clarify 
is working against (it's working against the Full Standard 1034). 
Perhaps in the process of getting 2308 to Draft Standard we can open 
up a discussion on it's interpretation of 'name error.'

The intent of 'name error' is to convey from the server to the client 
that the name is non-existent, that the name had no bearing on the 
execution of the algorithm in section 4.3.2. of RFC 1034.  Some 
folklore I recently heard may play into this, in the early days of 
DNS there was no QTYPE - you only looked up names (and maybe class). 
'name error' meant that there was nothing to return.  When QTYPE was 
introduced, an existing name but no data didn't get tagged as 'name 
error' - for backwards compatibility.

In the given example, ns.aol.com (I'll ignore that you didn't specify 
a class and type in the query as it makes no difference here) did 
play a role in the execution of 4.3.2 - the fact that it exists (as a 
parent of a... and b...) means that section c is never executed - the 
query processing dies in case a.  (Even if the code path chooses to 
check for c before a.)

>example, would nuke the a.ns.aol.com and b.ns.aol.com records.

What do you mean by 'safe' and 'dangerous' in this context?

>so I don't see any reason to favor RFC 1034 over RFC 2308.

I don't know that this (the meaning of 'name error' and the apparent 
conflict between RFC 1034 and 2038) is an important issue, because 
wcard-clarify is not trying to have an impact on the meaning of 'name 
error' in responses. wcard-clarify is trying to define existence as 
it pertains to the execution of 4.3.2.c, i.e., whether synthesis of 
an answer is performed.  In doing so, it strays dangerously close to 
defining the semantics of 'name error' which is the topic of 2308.

Looking into the draft, I can find only 5 occurrences of 'name error' 
including one that is line wrapped.  Three times is in section 1.4 
describing the conflict of RFC 1034's definition of existence and 
it's definition of 'name error.'  The other two times are in section 
5 - once during the citation from RFC 1034 and then in the 
explanation paragraph below it.  I can't see that wcard-clarify 
enters the issue of 'name error,' or for that matter, negative 
caching.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Sponge Bob Square Pants?  I'm still trying to figure out the Macarena.

---

From: [email-masked]
Date: Tue, 26 Aug 2003 13:33:37 +1000

> here. (Section 5: ``NXDOMAIN ... the same <QNAME, QCLASS> ...'')

	No. RFC 2308 says that NXDOMAIN indicates a Name Error.

   "NXDOMAIN" - an alternate expression for the "Name Error" RCODE as
   described in [RFC1035 Section 4.1.1] and the two terms are used
   interchangeably in this document.

	RFC 2308 says that NXDOMAIN is independent of QTYPE.

	IT DOES NOT SAY THAT ALL QUERIES THAT ARE INDEPENDENT OF QTYPE
	RESULT IN NXDOMAIN.

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Tue, 26 Aug 2003 00:50:25 -0400

At 3:32 +0000 8/26/03, D. J. Bernstein wrote:

In the spirit of this being a working group...

>wrong when it says that ``no implementation has done this.''

Can you elaborate on what you have implemented?  I didn't find any 
discussion of this in the archives of the working group.  SOA 
synthesis seems like a logical thing to do, I've never come across 
any one with implementation experience with this feature that has 
been willing to describe their success.

>have any impact outside the algorithm in RFC 1034 section 4.3.2?

To answer the first question, no, it doesn't.  I'm not sure how to 
answer the second question - do you have an impact in mind?

>servers that allow record synthesis based on (say) regular expressions?

No, the requirement specifies that a name written that way is to be 
interpreted as the basis of synthesis.  It says nothing about it 
being the exclusive basis of synthesis.  wcard-clarify is just 
shoring up what is in RFC 1034 and is not proposing any advances.

>1034's level? Either way, why is the IETF sticking its nose into local

If you don't have zone files, you don't have to worry about escape 
sequences.  Personally, I would prefer to not specify zone file 
issues, but the WG has stated that zone file formats are to be 
specified.  I go along if just so that we have a format to use in 
email discussions.

Just because wcard-clarify says that you must treat even an escaped 
'*' as a (potential) wild card domain name, the document does not say 
that you must have escapes - or zone files or configuration files. 
(But *if* you do...)

>visible on the wire, it's violating section 6 of RFC 2119.

The document says nothing more than what is in RFC 1034.  The 
document makes no requirements on configuration of servers, but it 
comments on the choices *some* implementers have made.  And, as you 
mention here, the wire representation of the wild card domain name 
appears in AXFR, so it is a good thing that the definition is 
included.  The NXT is still out of scope for this document (it's one 
of those dastardly DNSSEC concepts that need fleshing out).

I am curious though about alternative approaches to synthesis of 
answers.  I would find a document on that interesting and it would be 
helpful when writing the DNSSEC handling of negative answers and 
synthentic answers.  But that's not part of the current document.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 26 Aug 2003 05:31:06 -0000

> What do you mean by 'safe' and 'dangerous' in this context?

``The NXDOMAIN for ns.aol.com, for example, would nuke the a.ns.aol.com
and b.ns.aol.com records.'' The server is expecting the cache to see the
a.ns.aol.com A record, but the cache is blinded by the NXDOMAIN. That's
an interoperability disaster.

wcard-clarify-01 says ``A QNAME and QCLASS matching an existing node
never results in'' NXDOMAIN. That statement, with the wcard-clarify-01
definition of ``existing,'' is simply not true. As I said, real servers
do generate NXDOMAIN in this situation.

To avoid triggering the interoperability disaster, caches have to limit
NXDOMAIN as indicated in RFC 2308. Perhaps you think that RFC 2308 was
wrong and that servers shouldn't actually work this way, but this view
doesn't change the danger from the cache's perspective.

Please don't mislead cache implementors. The entire purpose of your
document, apparently, is to communicate

   If there are records with owner names ending d.e.f, but no records
   with owner names ending c.d.e.f, then the only possible wildcard
   relevant to a.b.c.d.e.f is *.d.e.f.

which you can say without redefining ``existence'' and without screwing
up the NXDOMAIN semantics.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 26 Aug 2003 06:10:09 -0000

Edward Lewis writes:
> the WG has stated that zone file formats are to be specified

I don't understand. What would your ``zone file specification'' mean?
Who would it apply to? BIND has its own zone-file format (depending on
the BIND version), noticeably different from the RFC-1034-etc zone-file
format; furthermore, the semantics of a zone file depend heavily on
configuration data outside the zone file. Why do you think these local
server-configuration mechanisms are any of the IETF's business? Do you
think that RFC 1034's violation of RFC 2119 justifies new violations?

Anyway, I find it difficult to believe that the scope of wcard-clarify
is supposed to be limited to the semantics of stars in zone files.

  [ zone wildcards ]
> Can you elaborate on what you have implemented?

I can, but I'm not going to. It's not an IETF issue.

---

From: Peter Koch <[email-masked]>
Date: Tue, 26 Aug 2003 10:52:48 +0200

> do generate NXDOMAIN in this situation.

which is a bug that has been reported for some and has been fixed for others.

From an operational perspective it's more than weird to be told a name
doesn't exist which has existing descendants (i.e. subdomains). So, I really
appreciate the clarification in 1.4 of draft-ietf-dnsext-wcard-clarify-01.txt.

-Peter

---

From: Robert Elz <[email-masked]>
Date: Tue, 26 Aug 2003 19:05:15 +0700

Date:        26 Aug 2003 02:42:18 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Suppose there's a query for ns.aol.com. It's safe for AOL's servers to
  | return NODATA. But is it safe for AOL's servers to return NXDOMAIN?

No.

  | RFC 2308 says that the answer is yes.

It says nothing of the kind.   That's an unbelievable stretch of what
is written there.

Aside from anything else, 2308 is talking about what caches do, not what
servers do.   Even if one could conclude from 2308 that caches must not
rely upon the NXDOMAIN to infer that no sub-domains of the name can exist
(which I don't think 2308 actually says, but ignore that for now), that
in no way means that servers should ignore the spec (which is 1034 here)
and start doing something bogus.

  | But wcard-clarify-01 section 1.4, like RFC 1034, says that the answer is
  | no.

yes, and when 1034 says something, which isn't explicitly changed by some
later spec (and precise wording in 1034 which has been altered is very
rare) then what 1034 says always wins.   Drawing inferences from a 2308
is not nearly enough to override 1034.

  | Most servers do, in fact, return NXDOMAIN in this situation,

I have no idea how you have counted "most" there - but I assume it must
mean "most server implementations" (and even there I'd like to see the
evidence) because it certainly can't be intended to mean "most deployed
servers" can it?    We know that's BIND (BIND based) and BIND has never done
that (not even in the most ancient bug ridden versions).

  | so it would
  | be incredibly dangerous for a cache to apply NXDOMAIN in the way allowed
  | by wcard-clarify-01 and by RFC 1034.

That's probably true - it would be unwise for a cache to rely upon this,
as broken servers have been known to exist.   It would be nice to stamp
out all those broken servers (or most of them anyway) so that we could
rely upon that.

  | As a practical matter, the RFC 1034 meaning of NXDOMAIN doesn't save a
  | noticeable percentage of queries,

No, but it does give valuable information to someone making a query.

If I query for A records for abc.example.com and get NXDOMAIN, then I know it
doesn't exist, and so there's no point trying www.abc.example.com or anything
similar.   On the other hand, if I get NODATA, then I know it does exist,
and that my scribbled notation of what domain name I should be looking for
has a good chance of being right.

kre

---

From: Edward Lewis <[email-masked]>
Date: Tue, 26 Aug 2003 08:57:25 -0400

>I don't understand. What would your ``zone file specification'' mean?

The zone file specification that you referred to in your message, the 
one defined in RFC 1034 and not the one in the implementation you 
mentioned.

>think that RFC 1034's violation of RFC 2119 justifies new violations?

Again, I agree with you that the zone file is not a topic for 
interoperability, however, the WG asks for such a discussion to be 
present.  And again, it's also a nice documentation convention for 
conveying concepts in email.  You started the thread with a zone file 
like piece of text.

>is supposed to be limited to the semantics of stars in zone files.

You are right, the scope is the role played in the synthesis wild 
card domain names play in answering queries and how to recognize wild 
card domain names in zone transfers.

>I can, but I'm not going to. It's not an IETF issue.

Then I'm forced to leave in the text that not implementations have 
done SOA and zone synthesis.  It wouldn't be right to say "and 
someone claims to have done this," now, would it?  Without backing 
material that is.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Edward Lewis <[email-masked]>
Date: Tue, 26 Aug 2003 08:50:58 -0400

>do generate NXDOMAIN in this situation.

I'm confused.  In the first paragraph it seems that you are arguing 
for a no error RCODE with an empty answer section to be returned, 
otherwise caches would be blinded.  I agree with that, although I've 
always felt that negative answers ought not be interpreted by caches 
beyond the query string for which they were obtained.  (The reason I 
feel this way has to do with wild card synthesized NXT records.)

In the second paragraph, are you saying a name error should be the 
right response because implementations to that now?  From the 
semantics in 1034, I would think that the implementations are in 
error, a name error happens with the name in the query is 
non-existent.  Or are you saying that there is something wrong with 
the redefinition of existence that conflicts with name error.

The portion of the draft you are quoting is text lifted from 1034 and 
modified for new (tighter) definition of existence.  The sentence in 
question is unchanged from 1034.

>doesn't change the danger from the cache's perspective.

I don't see any reason to discuss this hear, wcard-clarify is not 
updating RFC 2308.  Wcard-clarify says nothing about negative answers 
and how they are handled in caches, it says nothing about when they 
are generated that differs from what's in RFC 1034.

>up the NXDOMAIN semantics.

The 'new' definition of existence because of the words here (from 
1034): "Each ... leaf ... (which may be empty)."  All this draft does 
us say that empty leaf nodes do not exist (they've never been assumed 
to exist), as well as all nodes in a completely empty domain.

I don't think that anyone has ever treated nodes as existing that the 
draft is defining away now.  It's just that the definition needs to 
be tighter once we try to authenticate denial of existence.

It's a paper change to pre-DNSSEC DNS.

---

From: Alan Barrett <[email-masked]>
Date: Tue, 26 Aug 2003 16:14:41 +0200

> return NODATA. But is it safe for AOL's servers to return NXDOMAIN?

The server should return NODATA.  Since ns.aol.com has descendents,
NXDOMAIN is not an appropriate response.

> RFC 2308 says that the answer is yes. It interprets NXDOMAIN as
> ``there are no records owned by the query name,'' which is exactly the
> situation here. (Section 5: ``NXDOMAIN ... the same <QNAME, QCLASS>
> ...'')

I can't find any text in RFC 2308 that implies that it's OK for a server
to respond with NXDOMAIN in this situation.  RFC2308 does say what a
cache is allowed to do if it receives NXDOMAIN.

> But wcard-clarify-01 section 1.4, like RFC 1034, says that the answer
> is no. It interprets NXDOMAIN as ``there are no records whose owner
> name _ends with_ the query name,'' which is not the situation here.

draft-ietf-wcard-clarify-01 is correct about this point.  I see no
conflict between this and RFC 2308.

> Most servers do, in fact, return NXDOMAIN in this situation,

Oh, really?

> so it would be incredibly dangerous for a cache to apply NXDOMAIN in
> the way allowed by wcard-clarify-01 and by RFC 1034. The NXDOMAIN for
> ns.aol.com, for example, would nuke the a.ns.aol.com and b.ns.aol.com
> records.

There should not be an NXDOMAIN for ns.aol.com; if there is, then the
server that sent it is in error, and should not be surprised if it
causes trouble elsewhere.

--apb (Alan Barrett)

---

From: Paul Vixie <[email-masked]>
Date: Tue, 26 Aug 2003 14:27:37 +0000

> doesn't exist which has existing descendants (i.e. subdomains). So, I
> really appreciate the clarification in 1.4 of
> draft-ietf-dnsext-wcard-clarify-01.txt.

me too.  the fuzziness of the 1034/1035 description of empty nonterminals
has led to a lot of pain and confusion, and i don't just mean in dnssec.
the wcard-clarify description does not constitute a change from 1034/1035,
it really is just a clarification, and it's a good and nec'y clarification.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 26 Aug 2003 17:44:47 -0000

I specifically raised the NXDOMAIN-semantics issue here on 1999.12.08,
under the subject line ``sub.dom with cached NXDOMAIN dom.'' Paul Vixie
responded:

   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.

There wasn't even a whisper of disagreement. There also have been no
reports of interoperability problems---i.e., of caches violating the
explicit statements in RFC 2308 by applying NXDOMAIN to subdomains.

Using NXDOMAIN for empty nonterminals has obvious benefits for some
server-side database structures. I took advantage of this in tinydns,
which I released a few weeks later, and which is now very widely used.
Other implementors have also taken advantage of the NXDOMAIN semantics.

Now, four years later, without any excuse, people here are suddenly
trying to retroactively change the NXDOMAIN semantics, prohibiting the
extremely widespread behavior of using NXDOMAIN for empty nonterminals.
Elz says that using NXDOMAIN for empty nonterminals is an ``unbelievable
stretch'' and that I'm telling server implementors to ``start doing
something bogus.''

If there's some benefit of changing the NXDOMAIN semantics, then I'm
willing to discuss whether that benefit outweighs the costs. I am not,
however, going to tolerate fraud. The wcard-``clarify'' use of NXDOMAIN
is _not_ how DNS works. _I_ am not the one proposing changes to the DNS
protocol.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 26 Aug 2003 14:35:51 -0400

>is _not_ how DNS works. _I_ am not the one proposing changes to the DNS

You're barking up the wrong tree.  No one is proposing a change to 
the DNS protocol and, in this case, no one should be.

Using grep to find NXDOMAIN finds that it appears twice, each in the 
context of why is it not used (elsewhere) in the draft.  Grepping for 
'name error' shows that is used only in the context of repeating what 
was in RFC 1034.  There is no redefinition, no reinterpretation of 
the concept.

The issue you are raising, that an empty non-terminal ought to return 
a name error for queries about it, is a valid one.  It makes sense 
that if I ask for data and there is none to return (authoritatively) 
I get back a consistent message.  Having RCODE="name error" if the 
name doesn't exist and RCODE="no error" if the name does but the data 
not makes little sense to me.

Harking back to the basis of the protocol, the Full Standard 
document, there is a difference though.  If wcard-clarify was to 
propose what you state there would be two problems.

           One, it would be a change to the Full Standard by specifying a
           different response to a query, which seems to be something you
           do not want - a change to the protocol.

           Two, the proposal would be out of scope.  This is a clarification
           of wild card domain name synthesis after all, not a discussion
           on negative answers.

But this is all off-topic for the document in last call.  Wild card 
synthesis is concerned with whether or not a name exists, hence the 
discussion of it.  Beyond that, no statements are made about what the 
server ultimately returns to the querier.

I am not sure what would make you happy.  If you want RFC 1034 to be 
altered to allow a name error to be declared for empty non-terminals, 
well, this is not the place to argue it, that would be when we get 
around to rehashing RFC 2308.

As you emphasize above, wcard-clarify is a clarification document not 
a change document, yet is seems that the issue you have is nestled in 
RFC 1034.  Your choice seems to be to rewrite wcard-clarify to alter 
RFC 1034, making the draft not a clarification but an update, or 
leave wcard-clarify as just a clarification document and fix 
implementations, such as the versions of the one you often cite, 
BIND, that are not within interpretation of the words in RFC 1034.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 26 Aug 2003 19:19:56 -0000

Edward Lewis writes:
> a name error for queries about it, is a valid one.

This isn't an issue I'm ``raising.'' It's an issue I raised in 1999.
The undisputed answer was that, after RFC 2308, NXDOMAIN was allowed---
and preferred. In fact, Vixie said that NXDOMAIN was _required_.

Most server implementations work this way. There have been no reports of
caches having trouble with it. Nobody has given any reasons to prohibit
NXDOMAIN here.

You argue that you can't be changing the protocol because you're merely
repeating RFC 1034. Your logic is flawed, and your conclusion is wrong.
Repeating this error from RFC 1034 _does_ change the protocol.

Here's a more extreme example, so you can understand the mistake in your
argument. http://cr.yp.to/djbdns/notes.html, under ``Expiring glue,''
describes a common situation where the RFC 1034 resolution algorithm
doesn't work---it's fundamentally broken. Real caches use a different
algorithm. This part of RFC 1034 is simply wrong; repeating it in a new
spec would be a serious mistake.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 26 Aug 2003 15:59:58 -0400

What part of your last message relates to wild card synthesis?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: "D. J. Bernstein" <[email-masked]>
Date: 26 Aug 2003 22:01:01 -0000

> What part of your last message relates to wild card synthesis?

What part of the wcard-clarify-01 statement ``A QNAME and QCLASS
matching an existing node never results in a response return code of
authoritative name error'' relates to wild card synthesis?

Why does this document stray into a thicket of screwy definitions and
discussions of no apparent relevance to wildcards? How can it possibly
take 663 lines to say ``If there are records with owner names ending
d.e.f, but no records with owner names ending c.d.e.f, then the only
possible wildcard relevant to a.b.c.d.e.f is *.d.e.f''?

Maybe it would help to settle the scope discussion first. I get the
feeling that wcard-clarify would be quite a bit shorter if its scope
were clarified.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 26 Aug 2003 22:55:31 -0400

>feeling that wcard-clarify would be quite a bit shorter if its scope

Life's too short to waste on this discussion.  Being that this is a 
volunteer effort, I will not further this thread (feeling no 
compelling reason to do so) and will take editing action on this 
point only if directed to do so.

---

From: Robert Elz <[email-masked]>
Date: Wed, 27 Aug 2003 15:29:37 +0700

Date:        26 Aug 2003 17:44:47 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I specifically raised the NXDOMAIN-semantics issue here on 1999.12.08,
  | under the subject line ``sub.dom with cached NXDOMAIN dom.''

Actually, you specifically asked what a cache should do, which was
definitely relevant to 2308.

  | Paul Vixie responded:

I guess I must have skipped that message, as being a topic of no
great interest but ...

  |    RFC 2308 implicitly outlawed BIND's behaviour,

"BIND's behaviour" wasn't the issue - as you pointed out in your earlier
message, it is in the DNS spec.   While it might be possible for a radom
RFC to take some undefined case, and implicitly define it, so that an
implementation that had adopted a different interpretation doesn't conform
to the new spec, it is most certainly not possible for an RFC (which is
dealingwith a different issue) to just "implicitly" define away a part of
a standard.

That would need to be done very explicitly.

Furthermore, a message from Paul cannot possibly have the effect
of giving status like that.

  | There wasn't even a whisper of disagreement.

Probably because no-one was paying much attention.

  | Now, four years later, without any excuse, people here are suddenly
  | trying to retroactively change the NXDOMAIN semantics,

No-one here is doing anything of the kind.   You seem to have assumed,
perhaps with some justification - though incorrectly - that the semantics
changed 4 years ago.   It is a little hard to believe that you really
consider what at best (for your case) is definitely "implicit" in 2308,
but which in reality isn't there at all, along with one e-mail message,
can possibly have changed 1034.

You'd be spitting rocks if someone tried a similar argument to justify
an approach that you disagreed with - you even claim that some of 2181,
which most people believe is just restating 1034 more clearly, and which
is all very explicit, is wrong and should be ignored...

  | If there's some benefit of changing the NXDOMAIN semantics, then I'm
  | willing to discuss whether that benefit outweighs the costs.

If there had been going to be a change in 1999, that would have been when
that discussion would have been appropriate, would it not?   Would you care
to point out where that discussion was held?   Or are you expecting us to
believe that a (fairly significant) change to the DNS spec was done with
no thought at all, but just, seemingly, by accident.

This part of 1034 has never been changed.

I have been told that bind 9 up to 9.2.2 got this wrong - that's not
terribly surprising, those versions got a few other things wrong too.
I haven't been able to yet test to see whether the 9.3 (still beta
I think) versions fixed this one along with all the other stuff that
got fixed there.   If not, it needs to be.

kre

---

From: Alan Barrett <[email-masked]>
Date: Wed, 27 Aug 2003 12:13:51 +0200

On Tue, 26 Aug 2003, D. J. Bernstein wrote:
> under the subject line ``sub.dom with cached NXDOMAIN dom.'' Paul
> Vixie responded:
>
> There wasn't even a whisper of disagreement.

If Paul Vixie said that, he was wrong.  His mistake does not amount to a
change of the protocol.

> trying to retroactively change the NXDOMAIN semantics, prohibiting
> the extremely widespread behavior of using NXDOMAIN for empty
> nonterminals.

You are trying to claim that the semantics changed in 1999.  I don't
blieve that the semantics changed in 1999.

> willing to discuss whether that benefit outweighs the costs.

I don't see any benefit to changing the semantics.  As far as I can see,
they were defined in RFC 1034, not changed in RFC 2308, and not changed
in draft-ietf-wcard-clarify-01.

> I am not, however, going to tolerate fraud.

It's easy to interpret your claim that the semantics changed in 1999
as fraud.

> The wcard-``clarify'' use of NXDOMAIN is _not_ how DNS works. _I_ am
> not the one proposing changes to the DNS protocol.

Yes, it it.  Yes, you are.

--apb (Alan Barrett)

---

From: Paul Vixie <[email-masked]>
Date: Wed, 27 Aug 2003 15:22:51 +0000

> If Paul Vixie said that, he was wrong.  His mistake does not amount to a

i did say it and i was wrong.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 27 Aug 2003 17:12:24 -0000

RFC 2119 does not allow the IETF to poke its nose into private
implementation issues:

   Imperatives of the type defined in this memo ... must not be used to
   try to impose a particular method on implementors where the method is
   not required for interoperability.

Does anyone have an INTEROPERABILITY argument for the wcard-clarify
restrictions? If not, those restrictions must be removed.

Robert Elz writes:
> it is most certainly not possible for an RFC (which is dealingwith a
> different issue) to just "implicitly" define away a part of a standard.

Are you trying to claim that RFC 2308 didn't change the DNS protocol?
Here's an example of how RFC 2308's explicit requirements on caches
implicitly allow extra behavior by servers:

   (1) Caches are explicitly prohibited---by RFC 2308---from applying
       NXDOMAIN except to the same (class and) name.
   (2) Caches do not, in fact, apply NXDOMAIN to subdomains. A huge
       number of servers use NXDOMAIN even when subdomains exist.
   (3) In light of #1 and #2, there is no interoperability excuse for
       discouraging or prohibiting the _server_ behavior.
   (4) Because of #3, discouraging or prohibiting the _server_ behavior
       would violate RFC 2119, section 6.
   (5) Therefore, wcard-clarify violates RFC 2119, section 6.

I realize that RFC 2119 can't go back and fix RFC 1034, but it certainly
applies to wcard-clarify.

---

From: Robert Elz <[email-masked]>
Date: Thu, 28 Aug 2003 00:56:11 +0700

Date:        27 Aug 2003 17:12:24 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | RFC 2119 does not allow the IETF to poke its nose into private
  | implementation issues:

RFC2119 does not put blinders on the IETF - any more than 1034
does, or 791, or anything else.   2119 is a bunch of definitions of
some common words that it is generally better to use in a consistent
way across RFCs, rather than, as was done before 2119, everyone
having slightly different definitions which were different and
confusing.

The rules in 2119 apply to people who choose to use 2119, and specify
how some words should be used.   And then they apply only as much as
the author/working-group decide not to override them.   They do not
constrain in any way what the working group can do.

It is certainly worth pointing out where you believe that the usage of
a 2119 word is inconsistent with its definition in 2119 - that's something
for the WG to look at, and see if there is agreement that there is a
difference, and second, whether the difference matters.   If both are
accepted, the word should be changed (and that kind of thing gets done
a lot).   If either isn't accepted, the word can stay.

  |    Imperatives of the type defined in this memo ... must not be used to
  |    try to impose a particular method on implementors where the method is
  |    not required for interoperability.
  | 
  | Does anyone have an INTEROPERABILITY argument for the wcard-clarify
  | restrictions?

If you're talking in particular about the NXDOMAIN case, then clearly
that does affect interoperability.   It specifies the meaning of data
that is carried over the wire, which must be understood correctly in
order to be meaningful - this is the very essence of interoperability.

That no implementations that we know about happen to care a lot one
way or the other is irrelevant.

  | Are you trying to claim that RFC 2308 didn't change the DNS protocol?

No, but for now, just because I haven't re-read all of it in order
to verify that.   What I was saying in the section that you quoted
is that 2308 cannot make back-door changes (by implication) to 1034.
Whatever it changed explicitly, that's fine (if there was anything).

It most certainly did not change the specification that NODATA (the
reply format that we use that pseudo-error-code to mean of course)
is the correct reply for a query of an empty non-terminal.

  | Here's an example of how RFC 2308's explicit requirements on caches
  | implicitly allow extra behavior by servers:
  | 
  |    (1) Caches are explicitly prohibited---by RFC 2308---from applying
  |        NXDOMAIN except to the same (class and) name.
  |    (2) Caches do not, in fact, apply NXDOMAIN to subdomains. A huge
  |        number of servers use NXDOMAIN even when subdomains exist.
  |    (3) In light of #1 and #2, there is no interoperability excuse for
  |        discouraging or prohibiting the _server_ behavior.

Nonsense.   2308 only applies to caches - caches aren't the only users
of DNS replies - resolvers get them too, 2308 doesn't apply at all to
resolvers.   If a resolver chooses to apply NXDOMAIN to sub-domains,
it is absolutely permitted to do so.

What's more, even beyond that, humans are consumers of DNS replies.
And humans too are not bound by 2038.   And I can assure you that I
most certainly do assume that when I see a NXDOMAIN that there are
no sub-domains.   If your serrver is saying NXDOMAIN when sub-domains
exist, then it is lying to me - causing me to fail to discover
things that I would otherwise find (that is, if I ever happened to
chance upon an implementation of your server in use anywhere, I
haven't yet, that I know of).

  |    (4) Because of #3, discouraging or prohibiting the _server_ behavior
  |        would violate RFC 2119, section 6.

False premise.

  |    (5) Therefore, wcard-clarify violates RFC 2119, section 6.

False premise.

kre

---

From: [email-masked]
Date: Thu, 28 Aug 2003 09:51:15 +1000

>        NXDOMAIN except to the same (class and) name.

	All RFC 2308 say is that if you have a NXDOMAIN response
	for foo.example.net/IN/A then you can return that NXDOMAIN
	in response to a later query for foo.example.net/IN/MX.

	NXDOMAIN is independent of TYPE not CLASS.

	It does not say that you can synthesize a NXDOMAIN response
	for xxx.foo.example.net/IN/A based on a NXDOMAIN response
	for foo.example.net/IN/A.  If you want RFC 2308 to say this
	we can deal with that when the WG looks at moving RFC 2308
	from PS to DS.

	NODATA responses on the other hand are both TYPE and CLASS
	dependent.  While RFC 2308 does not say this, you should be
	able to return a NODATA response to types other than ANY
	based on a NODATA response to ANY query.  This is also
	RFC 2308bis fodder.

	For the record RFC 2535 failed to account for empty nodes
	in the tree.  BIND 9 *was* following RFC 2535.  BIND 9.2.3
	onwards has reverted back to RFC 103[45].  BIND 8 always
	followed RFC 103[45] by returning NODATA responses to empty
	nodes.

	RFC 2535 implied that you always got a NXDOMAIN response
	between the ownername of a NXT record and the "next domain
	name".

	This lead to the ridiculous state of a "non existant" name
	influencing whether a wildcard match was made or not.

	I argued at the time that RFC 2535 was wrong, that empty
	nodes don't return NXDOMAIN.  With RFC 2535 being replaced
	is it possible to correct this error.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 28 Aug 2003 04:20:06 -0000

Robert Elz writes:
> The rules in 2119 apply to people who choose to use 2119

wcard-clarify-01: ``The key words ... are to be interpreted as
described in ... [RFC2119].''

RFC 2119: ``Imperatives of the type defined in this memo ... must not be
used to try to impose a particular method on implementors where the
method is not required for interoperability.''

(I'm not going to bother responding to your idiotic assertion that
``required for interoperability'' means ``visible on the wire.'')

Even if RFC 2119 didn't exist, having the IETF poke its nose into
private implementation issues would violate United States antitrust law.

> If a resolver chooses to apply NXDOMAIN to sub-domains,

Wrong. That would (1) violate RFC 2308 and (2) fail to interoperate with
existing servers. You're free to switch terminology---your competitors
have ``caches'' while you have an ``apply-one-answer-to-another-query
mechanism''---but your AOATAQ mechanism is, in fact, a cache, and has to
obey the same rules as any other cache.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 28 Aug 2003 04:47:30 -0000

Alan Barrett writes:
> If Paul Vixie said that,

``After RFC 2308, empty nonterminals are signalled with NXDOMAIN.''
http://groups.google.com/groups?selm=199912080700.XAA18392%40bb.rc.vix.com

> he was wrong.  His mistake does not amount to a change of the protocol.

Let me get this straight. After the BIND company

   (1) issues an RFC that clearly allows NXDOMAIN in this situation,
   (2) tells a new implementor that NXDOMAIN in this situation is fine,
   (3) publishes BIND 9, which uses NXDOMAIN in this situation, and
   (4) allows this use of NXDOMAIN to be deployed for four years,

you think it's perfectly reasonable for the BIND company to change its
mind and publish a new RFC saying---without a shred of justification---
that NXDOMAIN in this situation is prohibited?

If the answer to my question in 1999 had been ``Don't use NXDOMAIN,'' I
would have done the extra work to generate NODATA. But Vixie said that
NXDOMAIN was allowed (in fact, required). So I used NXDOMAIN.

Now, four years later, the BIND company is trying to force my users into
a completely unnecessary patch cycle. If the BIND company wants to screw
BIND users, I don't particularly care; but having the BIND company abuse
the standards process to punish _my_ users is completely unacceptable.

---

From: Alan Barrett <[email-masked]>
Date: Thu, 28 Aug 2003 11:43:38 +0200

>    (4) allows this use of NXDOMAIN to be deployed for four years,

(1) did not happen.
(2) was a mistake by one person, not by a company or the IETF.
(3) is a bug in bind 9.
(4) is a bug in bind 9.

> that NXDOMAIN in this situation is prohibited?

Since the premises to not hold, the conclusion makes no sense.

--apb (Alan Barrett)

---

From: Alan Barrett <[email-masked]>
Date: Thu, 28 Aug 2003 11:40:03 +0200

> ``required for interoperability'' means ``visible on the wire.'')

That wasn't an idiotic assertion.

The concept of interoperability is much broader than "interoperability
with known present-day implementations of today's specifications".  It
also includes interoperability with potential future implementations
of todays specifications, and interoperability with potential future
implementations of potential future updated specifications.

> Wrong. That would (1) violate RFC 2308

RFC 2308 appears to be silent on this issue.  A reasonable
interpretation of RFC 1034 would certainly permit the inference that
NXDOMAIN also applies to subdomains.

> and (2) fail to interoperate with existing servers.

Yes, but the existing servers for which interoperation would fail (those
that return NXDOMAIN for empty non-terminals) are out of compliance with
the specification in RFC 1034.

When there's a failure to interoperate, and one of he implementations is
clearly out of compliance with the spec, it's usually (but not always)
a good idea to change the non-compliant implementation to bring it into
line.  It is sometimes a good idea to change the specification, but that
hasn't been demonstrated in this case.

In this case, I think the right thing to do is: not change the
specification; fix the broken implementations (bind9 and tinydns);
somehow try to prevent similar misinterpretations of the specification
from arising in future.

--apb (Alan Barrett)

---

From: Robert Elz <[email-masked]>
Date: Thu, 28 Aug 2003 16:53:52 +0700

Date:        28 Aug 2003 04:20:06 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Robert Elz writes:
  | > The rules in 2119 apply to people who choose to use 2119
  | 
  | wcard-clarify-01: ``The key words ... are to be interpreted as
  | described in ... [RFC2119].''

Yes, that's fine - as I said, you're free to argue that a particular usage
of a word is in conflict with 2119, when 2119 is being used.   The working
group is free to decide to ignore your argument, 2119 is not a straight
jacket.

  | (I'm not going to bother responding to your idiotic assertion that
  | ``required for interoperability'' means ``visible on the wire.'')

If that was what I had said, you'd be right, that would be idiotic - but
it wasn't what I said - what I said was that the meaning of something which
is visible on the wire would clearly be needed for interoperability.

You make that point yourself, indirectly, in another message (see below).

But that isn't all of what "required for interoperability" means of
course, there's more to it than that.

  | Even if RFC 2119 didn't exist, having the IETF poke its nose into
  | private implementation issues would violate United States antitrust law.

This is not a private implementation issue, it is a question of what
bits on the wire actually mean.   NXDOMAIN means the name does not exist.
A name that does not exist clearly cannot have sub-domains, it would have
to exist for that to be true.   That's the definition of the error code.
It has nothing at all to do with how you choose to implement it, nor how
anyone else does.

  | > If a resolver chooses to apply NXDOMAIN to sub-domains,
  | > it is absolutely permitted to do so.
  | 
  | Wrong. That would (1) violate RFC 2308

It would do nothing of the kind.   2308 applies to caches, and what they
return to resolvers.

  | and (2) fail to interoperate with existing servers.

It would fail with some broken servers.   I don't care.   Those servers
should be fixed.

  | You're free to switch terminology---your competitors have ``caches''

I have no competitors, DNS code is one thing I have never been involved in
writing (the odd bug fix from time to time is about it).

  | while you have an ``apply-one-answer-to-another-query
  | mechanism''---but your AOATAQ mechanism is, in fact, a cache, and has to
  | obey the same rules as any other cache.

Not in the 2308 sense it isn't.   What 2308 says that can be done (it
doesn't actually say that anything in this are cannot be, as I recall it),
is that an NXDOMAIN response can be returned when a previous answer for
the same name + class returned NXDOMAIN.   If I am not returning NXDOMAIN,
but simply not doing any more queries, there's no way that 2308 can apply.

You're right, you can describe that as a cache - but it isn't the kind
of cache that 2308 applies to.   (Nor, for example, does 2308 apply to the
processor (fast access to RAM) cache which may remember an answer and give
it back later - the NXDOMAIN semantics we're discussing here aren't
relevant, but timers are - but no-one expects the processor cache to
understand DNS TTLs and invalidate itself if the DNS TTL times out.)

[email-masked] said in a different message:
  | Let me get this straight. After the BIND company
  |    (1) issues an RFC that clearly allows NXDOMAIN in this situation,
  |    (2) tells a new implementor that NXDOMAIN in this situation is fine,
  |    (3) publishes BIND 9, which uses NXDOMAIN in this situation, and
  |    (4) allows this use of NXDOMAIN to be deployed for four years,
  | you think it's perfectly reasonable for the BIND company to change its mind
  | and publish a new RFC saying---without a shred of justification--- that
  | NXDOMAIN in this situation is prohibited? 

Huh?   The BIND company (whatever that might be) does not get to make
IETF standards.   The IETF issued 2308, which does not clearly allow
NXDOMAIN in this situation (you yourself claimed, at most, that it implied
it as being possible - which is disputed anyway).

(2) and (3) have nothing to do with most of us here, certainly not me,
and I believe, not Alan Barrett, to whom this reply was addressed.   Nothing
Paul Vixie does or says in any way controls what I believe (neither he,
nor any organisation he's been associated with, ever, has ever had any
control over my actions).

(4) no-one did that I know of, this is a relatively unusual case, and I
suspect that most people simply never noticed it happening.

Then, the IETF is now publishing an RFC which says what the IETF has always
believed to be the state of affairs, whatever a small number of people may
have believed.

 | If the answer to my question in 1999 had been ``Don't use NXDOMAIN,''
 | I would have done the extra work to generate NODATA. But Vixie said
 | that NXDOMAIN was allowed (in fact, required). So I used NXDOMAIN. 

Yes, we know that, he made a mistake.   What's less believable is that
you could have seriously believed this.   But never mind.

Then this ...

  | Now, four years later, the BIND company is trying to force my users into a
  | completely unnecessary patch cycle. If the BIND company wants to screw BIND
  | users, I don't particularly care; but having the BIND company abuse the
  | standards process to punish _my_ users is completely unacceptable. 

ingnoring the "BIND company" invective, is what I referred to above.
If there was no interoperability issue here, you'd simply ignore this
completely (as you ignore other parts of the specification that you don't
agree with).

I have had enough of this absurd debate.   The DNS has *never* allowed
NXDOMAIN as a response to an empty non-terminal.   The name exists,
obviously, so claiming it does not would be absurd.

That some implementors (and I am not counting you in this group) managed
to confuse "name exists", with "RR attached to the name exists" is
unfortunate, but there's zero chance that those implementation bugs,
or your own deliberate choice, are going to change this part of the standard.

kre

---

From: Paul Vixie <[email-masked]>
Date: Thu, 28 Aug 2003 15:17:36 +0000

> (3) is a bug in bind 9.

which version/versions, specifically?  see below.

---

;; ANSWER SECTION:
version.bind.           0       CH      TXT     "9.3.0a0"

---

;; QUESTION SECTION:
;this.example.vix.com.          IN      A

;; AUTHORITY SECTION:
example.vix.com.        3600    IN      SOA     example.vix.com. root.vix.com. 2003082602 1800 900 604800 86400

---

#fh:i386# grep this example.vix.com 
test.a.is.this  A       127.0.0.5

---

i don't know why any of you is bothering to refute bernstein's assertions,
or even respond to him, or even read his tripe.  however, do consider the
likelihood of him defending my prior comments had he DISAGREED with them,
and also consider that whilest i did in fact misunderstand/misread RFC2308,
several other members of what bernstein laughably calls "the bind company",
notably the author of rfc2308 and a coauthor of the current wildcard draft,
have views remarkably different than the one bernstein quotes me as having.

can we have some serious discourse now?

---

From: [email-masked]
Date: Sat, 30 Aug 2003 00:54:34 -0500

> NXDOMAIN also applies to subdomains.

Is there a place in RFC 1034 you have in mind where the interpretation of
name error would suggest this?

In fact, I find that the opposite is true.  How can anybody infer from
reading

   Each node and leaf on the tree corresponds to a resource set (which
   may be empty).

in section 3.1, that in fact what it says is

   Each node and leaf on the tree corresponds to a resource set (which
   may be empty, but then the resource sets of all subnodes must be
   empty too).

I believe the author specifically wants to allow names that refer to
nothing (what else is the meaning of an empty resource set), and once
he established the concepts precisely in the beginning, he identifies a name
with the node and then the node with the associated resource set.  So
when he later writes about nonexistent names he means nonexistent
(empty) associated resource set.

So when you receive a "name error" when querying aol.org for
ns.aol.org, it seems to be a stretch to conclude that you also have to
give up on d.ns.aol.org.

Mate
 
---
Mate Wierdl | Dept. of Math. Sciences | University of Memphis

---

From: Edward Lewis <[email-masked]>
Date: Sat, 30 Aug 2003 10:21:20 -0400

This discussion is crossing the line of being on-topic for wild card, 
but the question raised is a reasonable one.  And the discussion does 
start in scope for the document, and when it strays, it strays into 
an area that does need to be discussed...

>name error would suggest this?

In 4.3.2, step c.  "If a match is impossible" you seek to apply wild 
card synthesis.  If you treat all names as existing (many with empty 
sets), you will *always* get an exact match as in step a.  There will 
never be a time to apply step c - hence the realization that 1034 
didn't really mean to say 'everything exists' as it does.

That's as far as the wcard-clarify needs to go - to make sure wild 
card synthesis actually happens.  Going into the name error issue 
now...

If you notice, if you don't ever enter step c, you don't return name 
error at all.  So, instead of treating all names as existing but some 
not having data means that you will only see negative answers fitting 
'no error/no data' instead of seeing name error when hitting a empty 
non-terminal.

>    may be empty, but then the resource sets of all subnodes must be

Recall that 4.3.2 contains the suggested may an authoritative server 
responds.  In this case, there's complete knowledge of the search 
space and the server just runs to the edge of it when it looks for 
data that's 'not there' - e.g., in step c.  If I'm looking for a 6 
label deep answer and nothing matches more than 3 of them - I 'know' 
that there's no data.  I don't see that there isn't a fourth and then 
infer there's no fifth and sixth.

The confusion in the discussion is that RFC 2308 talks about what 
happens at a cache (NCACHE).  The logic at a recursive server is 
quite different.  I've refrained on commenting on that because 
recursive servers don't do wild card synthesis.

>ns.aol.org, it seems to be a stretch to conclude that you also have to

If you ask for d.ns.aol.org. and the query hits a cache that sees 
that there's a name error when asking for ns.aol.org, then, well, I 
can understand why you'd assume there'd be no d.ns.aol.org worth 
asking for.  But it's a siren's call to optimize away the lookup.

A cache doesn't have perfect knowledge.  It could be that the name 
error came on a query a week ago and hasn't timed out yet - and in 
the meantime the deeper name added.  DNS isn't real time, but at 
least at the authoritative source I have current information - cache 
have never had the guarantee.

And once we get to discussing DNSSEC's authenticated denial of 
existence another complication will arise with wild card synthesized 
NXT's.  Because of the replacement of the owner name, relying on 
NXT's to supply information about what's in a zone won't be accurate. 
E.g., *.example.com NXT w.example.com will be used to synthesize a 
negative answer to x.example.com and show that there's nothing from 
x.example.com to w.example.com.  If you do the name math right, that 
would exclude example.com too.

The moral of the story is that caches ought to answer negatively only 
if they got a negative answer to the same query before (within the 
right time span).  They shouldn't assume a name error means there's 
nothing below (things change with time) and they have to narrowly 
interpret authenticated denial of existence messages (when they do 
flow).

By now we've veered far away from wild card synthesis and into the 
behaviors of caches...

PS - I was a bit confused by the paragraph about the author's 
intentions, because I'm not sure if you are referring to rfc 1034 or 
the clarification.  But, the need to define node as non-existent in 
the clarification draft is so that step c of 4.3.2 gets executed and 
thus synthesis done.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Robert Elz <[email-masked]>
Date: Sun, 31 Aug 2003 20:02:22 +0700

Date:        Sat, 30 Aug 2003 00:54:34 -0500
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | Is there a place in RFC 1034 you have in mind where the interpretation of
  | name error would suggest this?
  | 
  | In fact, I find that the opposite is true.

Actually, I think you might not, when you reconsider.

  | How can anybody infer from reading
  | 
  |    Each node and leaf on the tree corresponds to a resource set (which
  |    may be empty).
  | 
  | in section 3.1, that in fact what it says is
  | 
  |    Each node and leaf on the tree corresponds to a resource set (which
  |    may be empty, but then the resource sets of all subnodes must be
  |    empty too).

It doesn't, and no-one claims that.

  | I believe the author specifically wants to allow names that refer to
  | nothing (what else is the meaning of an empty resource set),

Yes, exactly.

  | and once he established the concepts precisely in the beginning,
  | he identifies a name with the node and then the node with the
  | associated resource set.  So when he later writes about nonexistent
  | names he means nonexistent (empty) associated resource set.

I'm not sure I can parse that last sentence, but I think I agree.
That is, I think you're saying, that if a name has an empty resource set
(or a non-empty one for that matter), it exists.   That I believe is the
intent of the sentence from 1034 you quoted.

  | So when you receive a "name error" when querying aol.org for
  | ns.aol.org, it seems to be a stretch to conclude that you also have to
  | give up on d.ns.aol.org.

What I think you're missing there, is the real point.   That is, if
d.ns.aol.org exists, then (obviously, as you can see it sitting there
in that name) ns.aol.org exists.   Consequently, you don't get a "name
error" (rcode == 3, which we mostly call NXDOMAIN) when you query ns.aol.com
(you cannot) regardless of what RR's exist at that node (including none).

Even Prof Bernstein agrees that this is what RFC1034/5 say is correct.
His argument has been that that was changed by RFC2308 (it wasn't, but
that's not relevant to your point).

kre

ps: from reading 1034/5, I believe that servers should really also support
empty terminal names (that is, names with no RRs, no sub-domains, but which
exist none the less).   I don't know of any servers that implement those.
Does anyone?   I'm not sure that it matters, as I doubt there is much in
the way of practical use for such things.   However, they seem to be clearly
allowed, so at the very least, those familiar with the DNSSEC algorithms
(particularly for proving non-existence) should probably make sure that
the algorithms work in the presence of emtpy terminal names.

---

From: Edward Lewis <[email-masked]>
Date: Sun, 31 Aug 2003 10:21:44 -0400

>exist none the less).   I don't know of any servers that implement those.

The only possible reasons for this might be that you want wild card 
synthesis to not apply to a particular name or you do not want to 
return a name error for a particular name.   (I.e., never step into 
'c' of 4.3.2.)

>the algorithms work in the presence of emtpy terminal names.

"Does anyone?"  No implementation I've ever seen does.

Unless we here from someone of the 1034 era, I doubt we could 
determine whether empty terminals were an intended consequence.  My 
reading, and why I originally suggested the rewording of existence, 
is that empty terminals were not an intended consequence.  And, even 
if they were, my gut is that they are as useful as IQUERY, also 
defined back then but since rescinded.

I can't think of a patented "it would be a really bad idea 
because..." to answer this.  I can see implementing it, and the 
configuring of empty terminals.  But it just doesn't seem natural.

The question for the wcard-clarify is then:

"Do we want to alter the existence to allow for empty terminals?"  If 
so, how to you distinguish (at a master server) between an existing 
and non-existing empty terminal?

PS - Since DNSSEC is lurking in the issue, way back when, the DNSSEC 
developers had an assumption that no name would own just an NXT RR. 
That would be violated by empty terminals.  Perhaps we need to 
discuss that issue.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Paul Vixie <[email-masked]>
Date: Sun, 31 Aug 2003 15:37:58 +0000

> the algorithms work in the presence of emtpy terminal names.

i don't agree.  1034/5 explains several ways a name can exist, and in each
case one can infer what data content or protocol event gives rise to that
existence.  no such existence is supported for empty terminals.

---

From: [email-masked]
Date: Mon, 01 Sep 2003 11:23:48 +1000

No.