Subject: Re: wcard-clarify violating RFC 2119, section 6

From: [email-masked]
Date: Tue, 2 Sep 2003 15:43:34 -0500

On Sat, Aug 30, 2003 at 10:21:20AM -0400, Edward Lewis wrote:
> 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...
> 
> At 0:54 -0500 8/30/03, [email-masked] wrote:
> >On Thu, Aug 28, 2003 at 11:40:03AM +0200, Alan Barrett wrote:
> >> 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.
> >
> >Is there a place in RFC 1034 you have in mind where the interpretation of
> >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.

I certainly never said anything about the "always existence" of names.
In fact, what I mean to emphasize is that the existence of _names_ is
not be confused with the existence of nodes(=resource sets).

Maybe it is easier to parse if I say this: the author of 1034 does not
distinguish (well, unfortunately, mixes) the pointer (domain name) and
the object (resource set or node) the pointer points to.  But I think
all rfc1034 really talks about is the (existence or non existence of
the) resource set.  Indeed, should we care about the existence of the
name a.b.c separately from the resource set it points to?

If the answer is that we just care about (the existence of) resource
sets, then of course you do not get stuck with case a. of algorithm
4.3.2 of rfc1034.

In example 1.3 of wcard-clarify, one can just simply say
"_telnet._tcp.host1.example does not exist" because the resource set
is empty, and the server would return NXDOMAIN.  Is it important that
the server, after wcard synthesis, "knows about the domain name
_telnet._tcp.host1.example" ?

I think the following rules do not contradict rfc1034:

1) empty resource set means domain does not exist

2) domain name not found in zonefile (even after wcard synthesis)
   means empty resource set (and hence, by 1), domain does not exist)

The above two rules also imply that if the domain name is found in the
zonefile but it points to an empty resource set, then the domain does
not exist.

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

--
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: Edward Lewis <[email-masked]>
Date: Wed, 3 Sep 2003 09:31:39 -0400

>not be confused with the existence of nodes(=resource sets).

I'm going to hold back on my discussion on this because I really 
don't have a lot of time to allocate.  But, to start, I think the 
problem here is that the names are the nodes, not the resource sets. 
The names are organized in the tree structure, not the data.  Perhaps 
that's the start of the confusion.

I.e., wild card synthesis doesn't care about QTYPE (unless it's 
CNAME), only about QNAME and the declared names.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Wed, 3 Sep 2003 10:05:18 -0500

On Sun, Aug 31, 2003 at 08:02:22PM +0700, Robert Elz wrote:
>   |    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.

Actually, my interpretation is the opposite: an empty resource set
means the domain does not exist.  This is because the resource set
should determine existence/nonexistence.

It does not matter whether the owner of the empty resource set is in
the zonefile or not (it was QNAME).  For example, wcard-clarify's
section 1.3 says _tcp.host1.example exists with no data---I'd say it
does not exist.  

Of course, it sounds silly to say the _name_ _tcp.host1.example does
not exist.  Names always exist, but what servers/clients (should) care
about is the resource set.  And if the resource set is empty, that is
a name error using rfc1034's terminology.

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

By what I said above, while _name_ ns.aol.org exists, it owns an empty
resource set, and hence name error should be returned.

> Even Prof Bernstein agrees that this is what RFC1034/5 say is correct.

I do not see this if I read rfc1034 with the understanding that in
many cases when it talks about (the existence of) a name it, in fact,
talks about the resource set owned by the name.

Mate
---

---

From: [email-masked]
Date: Thu, 04 Sep 2003 01:41:31 +1000

> should determine existence/nonexistence.

	The DNS is a tree.  The nodes of this tree can be empty but
	they do exist.

3.1. Name space specifications and terminology

The domain name space is a tree structure.  Each node and leaf on the  
tree corresponds to a resource set (which may be empty).  The domain   
system makes no distinctions between the uses of the interior nodes and
leaves, and this memo uses the term "node" to refer to both.

> section 1.3 says _tcp.host1.example exists with no data---I'd say it

	No. It exist.

> a name error using rfc1034's terminology.

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

---

From: [email-masked]
Date: Wed, 3 Sep 2003 13:32:05 -0500

> 	The DNS is a tree.  The nodes of this tree can be empty but

So, unlike Mr Lewis, you do identify the node with the resource set,
and not the name.  In any case, can you tell me why clients should
care to distingush between

1) name is in zonefile with empty resource set
2) name is not in zonefile

Except that in wcard-clarify, the desire to distinguish the two cases
results in a complicated and unclear definition of
existence/nonexistence.  Indeed, can you tell me when a domain exists
according to wcard-clarify?

I see (R3.1)

      A domain name is defined to exist if the domain name owns data
       and/or has a subdomain that exists.

This definition does not fit _tcp.host1.example of example 1.3 (of
wcard-clarify) since the resource set is empty (so there is no data to
be owned) and it does not have an existing subdomain.  You would then
think, _tcp.host1.example does not exist, since the denial of
existence is non-existence.

But in wcard-clarify there is R3.2, which says:

    R3.2 An authoritative server MUST treat a domain name that has neither
       a resource record set nor an existing subdomain as non-existent...

First, I do not understand why there would be a need for a separate
definition of nonexistence if the definition of existence was precise
enough to cover all cases.  In any case, notice that the above does
not cover _tcp.host1.example of example 1.3 either, since
_tcp.host1.example does have a resource record set, namely the empty
set.

wcard-clarify takes the position, in example 1.3, that
_tcp.host1.example exists---I do not see, though, how either of the
above definitions are used for this conclusion.

Why cannot we just define the existence of a domain by the resource
record set?

       A domain exists if and only if the RR set is nonempty.

---

---

From: Edward Lewis <[email-masked]>
Date: Wed, 3 Sep 2003 15:19:49 -0400

At 13:32 -0500 9/3/03, [email-masked] wrote:
>and not the name.

I'll leave that ("you do identify") to Mark Andrews to answer.

I think that there's a need for you to study 1034 closer.  It's not 
just my opinion that names exist or don't, and that existence of sets 
is a second tier issue.  It's the reason that there is a 'name error' 
defined but no 'set error.'  (Look at the RCODE values in 1035.) 
It's the reason synthesis is done on a name basis and not on a set 
basis.  (Why doesn't * MX fill in the MX's for all the hosts "in" the 
zone?)

>In any case, can you tell me why clients should

I've already answered this in 
http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01574.html, 
look for the word "folklore".

There's no reason why a client should really care - 'no data' is 'no 
data.'  But, well, it's a historic distinction.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: [email-masked]
Date: Thu, 04 Sep 2003 09:17:12 +1000

> care to distingush between

	An empty resouce set is just a name.  These only appear in the
	interior of a tree and never at the leaves. 

> according to wcard-clarify?

	It comes back to the basic premise that the DNS is a tree.
	All names exist between the root of the tree and the leaves.

	You also want nameservers from different vendors to produce
	consistant results based on the same zone contents.
	
> be owned) and it does not have an existing subdomain.

	In the example _tcp.host1.example has a subdomain that has
	a non-empty RRset.  That non-empty RRset is 

		_ssh._tcp.host1.example. SRV

	_ssh._tcp.host1.example is a subdomain of _tcp.host1.example,
	host1.example, example and ".".

	The set of all non-empty RRsets in a zone define all names
	the exist in a zone whether all those names have RRset at
	them or not.
	
>  You would then

	You fail to account for "nor an existing subdomain".  It has
	an existing subdomain (_ssh._tcp.host1.example).
 
>        A domain exists if and only if the RR set is nonempty.

	This is false.

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 03 Sep 2003 20:20:42 -0400

>         All names exist between the root of the tree and the leaves.

Not to be contrary, but I think the more _modern_ way to view it is that a
DNS name is just a concatenated sequence of labels which forms a unique index into
a DNS database. From that standpoint, the distinction between "terminal" and
"nonterminal" really loses its meaning and it seems rather silly and quaint for a
query of an empty "nonterminal" node to return anything different than a query of
an empty "terminal" node. Empty is empty. Period. Whatever negative-caching
optimizations are theoretically possible as a result of the seemingly-inconsistent
empty-terminal-vs-empty-nonterminal response differentiation seem to me to be
underutilized and not worth the confusion and the extra code and resources
required to interpret such response variations.

Obviously, the hierarchical structure of the DNS database is still important from
a zone-delegation/referral standpoint. But as a *database*structure*, the
hierarhical paradigm has long been superceded by relational and/or contextual
paradigms. Maybe it's time to let it go...

- Kevin

---

From: Robert Elz <[email-masked]>
Date: Thu, 04 Sep 2003 10:18:32 +0700

Date:        Wed, 3 Sep 2003 10:05:18 -0500
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | Of course, it sounds silly to say the _name_ _tcp.host1.example does
  | not exist.  Names always exist, but what servers/clients (should) care
  | about is the resource set.

Mark Andrews already replied to most of your message, but just on this
point - existence of itself is meaningless, what matters is existence
in a particular domain (in the generic sense, not the DNS meaning of
the term).

For that, in the DNS, if I control a particular zone, I get to decide
what names exist in that namespace - you can't make one appear by
querying it.

Whether or not I then choose to associate any resources with the name
or not is an entirely separate question.

  | And if the resource set is empty, that is
  | a name error using rfc1034's terminology.

No, it isn't - that's just an empty answer and no error, if the name
exists.

kre

---

From: [email-masked]
Date: Wed, 3 Sep 2003 22:32:36 -0500

> 	an existing subdomain (_ssh._tcp.host1.example).

My bad.  All seem consistent now (sorry for the long learning curve),
except rfc1034 does not explicitly outlaw a leaf with an empty RR set.
While wcard-clarify does that now explicitly in its definition of
existence, it also outlaws tinydns's present behavior:

$ dnsq a ns.csi.hu a.ns.csi.hu | grep nx
76 bytes, 1+0+1+0 records, response, authoritative, nxdomain

---

From: "D. J. Bernstein" <[email-masked]>
Date: 4 Sep 2003 01:17:49 -0000

Edward Lewis writes:
> It's the reason that there is a 'name error' defined but no 'set error.'

On the contrary. Caches apply NXDOMAIN to queries for any type under the
same name, while they apply NODATA only to the same type. Your ``no data
is no data'' comment fails to take cache effects into account.

The packet format was badly designed, so NODATA is much more difficult
to detect than NXDOMAIN, but this doesn't mean that NODATA is undefined;
it simply means that the definition is complicated. Go read RFC 2308, or
the BIND code, or cr.yp.to/djbdns/notes.html, or the dnscache code.

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

---

From: [email-masked]
Date: Thu, 04 Sep 2003 14:47:09 +1000

> the BIND code, or cr.yp.to/djbdns/notes.html, or the dnscache code.

	More that there was no RCODE for NODATA than the packet format
	was badly designed.  I keep thinking about introducing a NODATA
	rcode along with a client signaling that it can be understood
	via EDNS.

---

From: Sam Weiler <[email-masked]>
Date: Thu, 4 Sep 2003 05:53:12 -0400 (EDT)

> To the extent that wcard-clarify goes beyond issues
> visible on the wire, it's violating section 6 of RFC 2119.

	DNSSEC makes these issues visible on the wire, making these
	clarifications necessary.  Pre-DNSSEC, a unified understanding
	of wildcards was vastly less important -- so long as a zone
	behaved consistently, it didn't matter to clients how servers
	interpreted wildcards they found in zone files -- the clients
	never saw raw wildcards.

	DNSSEC, with its requirement for off-line signing, forces
	wildcard logic into the client -- even if the client doesn't
	do the actual synthesis, it has to be able to check it.  That
	forces a unified definition, at least for those zones using
	DNSSEC.

	1034's treatment of wilcards was, obviously, inadequate.
	These clarifications are vital to the DNSSEC specification
	effort.  DNSSECbis is incomplete without them.

-- Sam

---

From: Edward Lewis <[email-masked]>
Date: Thu, 4 Sep 2003 09:28:25 -0400

>is no data'' comment fails to take cache effects into account.

We're talking apples and oranges here.

There's no 'set error' value return code defined, that's the context 
of the comment, and that is traced back to the time when names were 
all we queried for.  You're right, there are set errors, but not as a 
return code value.  You're right that I am not talking about caches, 
wild cards are not synthesized there.

Do you feel that there should be a return code value defined for the 
condition in which a name/class matches but the desired set is 
absent?  (This is out of scope for wild card, I'm just asking.)

>the BIND code, or cr.yp.to/djbdns/notes.html, or the dnscache code.

The packet format could have been better, but it's not that bad.  DNS 
has managed to work for the past upteen years and has been a big part 
of the growth of the Internet.  You're right that there's room for 
improvement, especially when it comes to detecting when QNAME & 
QCLASS matched and QTYPE didn't.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 4 Sep 2003 18:17:19 -0000

Sam Weiler writes:
> wildcard logic into the client

I agree that the semantics of wildcards in DNSSEC are a protocol issue.
If wcard-clarify said ``The purpose of this document is to specify the
semantics of wildcards sent to DNSSEC clients'' and didn't swerve into
other issues, I wouldn't be complaining about it.

But wcard-clarify isn't limited to this. For example, it also outlaws
servers that support regular expressions.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 4 Sep 2003 15:24:39 -0400

>servers that support regular expressions.

Can you suggest new wording to prevent outlawing "that?"

By "that" I mean that I've been able to find any documentation (in 
the WG/mail list, draft, RFC) that describes how you would synthesize 
an answer from a regular expression.  I'm not against it, it's an 
intriguing idea.  It's just not been defined.

By specifying "here's a wcard domain name" and "you can't escape it 
away" the draft isn't outlawing any other form of synthesis.  By 
defining a wcard domain name label this makes it possible to transmit 
the synthesis via AXFR - which you pointed out.  The escape rule 
isn't meant to say you must have escapes, but if you do...do it this 
way.

(How would you transmit the synthesis rules from a master to secondary server?)

My motivation behind writing the document was nestled in the question 
of how many NXT's would have to be returned given that there was wild 
card synthesized answers for which to account.  In doing so, the 
concept of the closest encloser came up (as an outcome of the 
existence issue and 4.3.2).

I would imagine that if you had another synthesis mechanism, you 
still would need to decide when it will be invoked, that is, if you 
assume a zone would have some statically defined names augmented by 
the rules.  So, the same question would apply - how many NXT's.

I just had a thought - perhaps you are referring to the prohibition 
of "labels-*-this" which would match "labels-1-this" and so on. 
1034, in 4.3.3 does mention that names are of the form 
"*.<anydomain>", which I think rules out mid-label wild cards.  (That 
is also the basis od Simon's comment that double-wild cards aren't 
allowed per 1034.)

I'd imagine regular expression synthesis would mean you could have:

       [A-Z][^aeiou]\.*  MX mailhost
       [a-z][aeiou]\.*   MX spamhost

I can see how this would work, my questioning of providing this is 
that it's getting a bit heavy on functionality (in the sense that A6 
was) for such a basic core service as DNS.  Also, how does this fit 
into a zone transfer?

---

From: Rob Austein <[email-masked]>
Date: Thu, 04 Sep 2003 18:58:33 -0400

Summary: this is important work and should go forward, but there are
portions of it which could benefit from further work if the authors
have the time and the WG so wills it.

I think that the general intent of this doc is correct, and we badly
need something in this space.  The discussion of existance and so
forth matches my understanding of how this is supposed to work, and
the concept of "closest encloser" does indeed look very useful in
attempting to document how the DNSSEC NXT/NSEC stuff should work.

That said, some issues:

Section 6.4 needs work.  It's not at all obvious what action a name
server should take upon encountering a wildcard DNAME RR during the
lookup process: repeated use of the phrase "DNAME is a CNAME
generator" doesn't answer this question.  If the real answer is that
we haven't got a clue what to do here, the doc should say so, and
should state what one should do until we -do- acquire a clue.

Sections 6.1 and 6.2 are also a bit weird.  While the discussion of
synthesized zones in these sections is interesting, it strikes me as
either too much or too little: it's speculating about behavior that we
don't understand, but not in enough detail to help us understand said
behavior very well, and it seems to confound SOA RRs with a name
server's knowledge of the boundaries of the authoritative zones it has
loaded.  Finally, these sections don't ever come out and say what a
name server which -doesn't- implement zone synthesis should do with
these types; since all of section 6 is about "special processing",
it'd be good to describe what the processing rules for a normal
authoritative server are for each of the special types.

Last, with all due respect to the authors, and with the understanding
that Ed and I have long-standing friendly disagreements on many
stylistic issues, I found the document unnecessarily hard to read, and
suspect that a good flossing with a copy of Strunk and White would
make the document text a lot clearer.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 5 Sep 2003 02:01:20 -0000

Edward Lewis writes:
> How would you transmit the synthesis rules from a master to secondary 
> server?

The standard answer to ``How do you transfer something that AXFR doesn't
understand?'' is ``We replicate data with rsync, not AXFR.''

Are you aware that many modern servers can provide different answers to
different clients? (``Client differentiation'' in tinydns; ``views'' in
BIND 9.) Do you realize that the client-differentiation data

   * can't be transferred through AXFR,
   * can't be updated through DNSUPD, and
   * can't be secured with DNSSEC?

Do you conclude (1) that this variability has to be outlawed, or (2)
that AXFR, DNSUPD, and DNSSEC are behind the times?

> Can you suggest new wording to prevent outlawing "that?"

I just did: ``The purpose of this document is to specify the semantics
of wildcards sent to DNSSEC clients.'' Of course, you also have to
eliminate the portions of the document that stray outside this scope.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 4 Sep 2003 22:38:13 -0400

>understand?'' is ``We replicate data with rsync, not AXFR.''

Fair 'nuff.  What would help interoperability though is a 
specification of what's sent via rsync.  (What if someone uses a 
UltraDNS master and a PowerDNS slave?)

Note that I didn't use AXFR in my question.  That was on purpose - I 
didn't think you would transfer the rules in that format.  I'm 
curious what you do (or plan to) use to transfer the synthesis rules.

>Are you aware that many modern servers can provide different answers to
...
>that AXFR, DNSUPD, and DNSSEC are behind the times?

No problem with any of that functionality/variability.  Just so long 
as if interoperability is desired, the protocol for that is 
documented.  I realize you are using these as examples, but I'm 
trying to stick to the rules for answer synthesis.

(I really don't have the time to dedicate to try and work on regular 
expression synthesis.  So if it seems that I drop it at some point, 
it's not like I'm "playing" along.  I feel that there's nothing wrong 
with pursuing it, but it's beyond my needs hence my willingness to 
contribute time towards it.  I'm not opposed to it in principle.)

As far as (2), AXFR was designed for a simpler time.  DNSUPD is due 
for review sometime, and DNSSEC is once again being defined.  Maybe 
they are behind the times.  But still, none of them were designed for 
regular expression based synthesis.

>eliminate the portions of the document that stray outside this scope.

Well, I'd remove DNSSEC from that.  Do you have in mind specific 
portions of the document that stray beyond the scope?  (I know you've 
complained about the quote from 1034 that reappears in the draft, but 
it reappears only to give the context of another change.  BTW, is 
that perhaps the only place the document strays?)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Robert Elz <[email-masked]>
Date: Fri, 05 Sep 2003 12:02:30 +0700

Date:        5 Sep 2003 02:01:20 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | The standard answer to ``How do you transfer something that AXFR doesn't
  | understand?'' is ``We replicate data with rsync, not AXFR.''

But you're also on record (and I agree with this) as claimimg that the
IETF should never have standardised a local implementation detail (the
master file format), which in conjunction with the above, means that you
no longer have interoperable servers - only servers that have the same
implementation (since rsync just synchronises an array of anonymous bytes)
can possibly agree on what a zone actually contains.

We need either a standard format to transfer, or a standard transfer method.
1034/5 gave us both (so the standard transfer method could be used, or
some other method, and the data would have the same meaning).

  | Are you aware that many modern servers can provide different answers to
  | different clients?

  | Do you conclude (1) that this variability has to be outlawed,

Yes, it should - at least in the sense that it must be treated as a
non-standard extension, and that people doing that need to be aware of the
problems they are causing for themselves (including not being able to
just use any random two server implementations - which is one of the more
minor problems).

The doc needs to define wildcards as exchanged using AXFR, which is the
only currently viable method of getting data between two different server
implementations that can really be expected to work (there have been two many
local improvements added, and straight out implementation bugs, for
master file formatted file copy via another means to remain viable).

To do that, it needs to define the semantics of wildcards, so the receiving
server knows exactly what should be done with them - for which their
implications for dnssec seem to be one of the more important issues.

kre

---

From: Peter Koch <[email-masked]>
Date: Mon, 08 Sep 2003 00:08:36 +0200

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

I agree with the main direction of the document and support putting it onto
standards track. However, the current version 01 of this draft is not
ready for submission to the IESG.

> Another reason this clarification is needed is to answer questions
> regarding authenticated denial of existence, a service introduced in the
> DNS Security Extensions [RFC 2535].  Prior to the work leading up to this
> document, it had been feared that a large number of proof records (NXTs)
> might be needed in each reply because of the unknown number of potential
> wild card domains that were thought to be applicable.  One outcome of this
> fear is a now discontinued document solving a problem that is now known
> not to exist.  I.e., this clarification has the impact of defending against
> unwarranted protocol surgery.  It is not "yet another" effort to just
> rewrite the early specifications for the sake of purity.

Speaking of fears, I fear that the neutral reader in a year will be confused
by this paragraph. Just delete it.

>    - Implications of a wild card domain name owning any of the following
>      resource record sets: DNAME [RFC 2672], CNAME, NS, and SOA

s/sets/types/ in this case. In various other places this document uses
the term "resource record set" or "resource set". For the sake of consistency
(and brevity) that should just be "RRSet". This was defined by RFC 2181
which should be added to the normative reference list.

> The following queries would be synthesized from the wild card:
s/following queries/responses to the following queries/

>           QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
>                 because _tcp.host1.example. exists (without data)
>           QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN
>                 because host2.example. exists (without data)

Maybe I got the "closest encloser" wrong, but why is the reason different
in these two cases?

> RFC1034's wording is to be clarified by adding the following paragraph:

There may have bee precedents and it's clear to me what should be achieved,
but since noone is going to maintain the amended version of 1034, this
wording may be misleading (hey, we're *no* lawyers :-)

> NS RR set.  At the delegating server, the NS RR set is not authoritative,

There's no "the delegating server". s/At the delegating server/In the delegating
zone/;

> zone."  In this usage, a domain name is the root of a domain, not the entire
> domain.  The domain's root point is said to "exist in a zone" if the zone

Now, what's a domain? I'd rather use the term apex or something similar here.

> the authority, then a referral is given, possibly one indicating lameness.

You mean, the referral than turns out to be lame?

> Is it not a protocol error to have a NS RR owned by a wild card domian name,
> complimentary to the case of a SOA RR.  However, for this to work, an

Now, is it an error or is it none - as inthe case of SOA?

Minor nits to be sent to the author in private.

-Peter

---

From: Bill Manning <[email-masked]>
Date: Tue, 23 Sep 2003 15:23:24 -0700 (PDT)

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

What is the current status of this document?

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

-- 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 24 Sep 2003 09:58:44 +0200

On Tue, 23 Sep 2003 15:23:24 -0700 (PDT)

> What is the current status of this document?

WGLC Summary:
http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01756.html

Open Issues:
thread starting at:
http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01758.html

and thread starting at:
http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01757.html

The discussion on the issues has died a quiet death. Review of those
by the list would be aprreciated. 

The issues will need to be addressed by the editor. The editor (Ed
Lewis) needs to do this in spare time and he does not have much of
that lately. Volunteers to help with finishing this document please
contact Ed and the chairs. We would like to get progress on this
document.

-- Olaf
   DNSEXT Co-Chair