Subject: Re: wcard draft out there...

From: Robert Elz <[email-masked]>
Date: Tue, 19 Oct 2004 00:07:33 +0700

Date:        Mon, 18 Oct 2004 09:35:55 -0400
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <a06110401bd9975bf2a08@[192.35.166.53]>

  | I don't think there are any outstanding substantive questions.  The 
  | document was greatly reorganized, there are a lot of rough wording 
  | edges that'll need to be smoothed, if nothing else.

I see nothing in there that's wrong, but there are LOTS of little
things that need fixing (from typos to poor explanations).

I'll try to send a list tonight (if not, nothing from me before
the deadline), but just reading the thing makes most of them
jump out and hit you...

kre

--
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: Alex Bligh <[email-masked]>
Date: Mon, 18 Oct 2004 20:02:06 +0100

--On 18 October 2004 09:35 -0400 Edward Lewis <[email-masked]> wrote:

> I'd like to be able to refresh the draft by the deadline - if not just to
> update the editor contact info - so comments would be appreciated this
> week.

Comments included below as a diff - almost entirely typographical or
orthographical. I have added a couple of extra examples or explanations
when it wasn't immediately obvious to me which point the example was
making - and by dint of that you should check them!

Alex

--- wcard-clarify       Mon Oct 18 18:51:06 2004
+++ wcard-clarify-amb   Mon Oct 18 19:56:01 2004
@@ -1,3 +1,6 @@
+Inconsistent use of "RR's" and "RRs" throughout document
+
+
 DNSEXT Working Group                                            E. Lewis
 INTERNET DRAFT                                                   NeuStar
 Expiration Date: April 2005                                 October 2004
@@ -57,15 +60,15 @@
 1.1 Motivation

     Over time many implementations have diverged in different ways from
-    the original definition, or at least what had been intended.  Although
+    the original definition, or at least from what had been intended. 
Although
     there is clearly a need to clarify the original documents in light
     of this, the impetus for this document lay in the engineering of
     the DNS security extensions [RFC TBD].  With an unclear definition
-    of wildcards the design of authenticated denial became entangled.
+    of wildcards, the design of authenticated denial became entangled.

     Although this document is motivated by DNSSEC and the need to
     have a separate document passed for the sake of DNSSEC, other
-    motivations have risen.  The renewed understanding of wildcards gained
+    motivations have arisen.  The renewed understanding of wildcards gained
     is worthy of being documented.

 1.2 The Original Definition
@@ -95,15 +98,17 @@
     is clearly defined to be a resource record.  In the next sentence
     the term is shifted to be an adjective, the first step on the
     path to overloading the term.  Wildcard has also been used to
-    refer to domain names that begin with a "*".
+    refer to domain names whose first (i.e. left most or least
+    significant) label consists of a "*".

 1.3 The Clarification

-    The clarification effort can be divided into three sections.  One
-    is the use of new terminology to better describe wildcards.  Changes
-    to words in RFC 1034 that have resulted by discovering conflicting
-    concepts are presented.  Descriptions of special type records in the
-    context of being wildcards is discussed.
+    The clarification effort can be divided into three sections:
+    1. the use of new terminology to describe wildcards better;
+    2. changes to words in RFC 1034 that have resulted from discovering
+       conflicting concepts; and
+    3. descriptions of special type records in the context of being
+       wildcards is.

 1.3.1 New Terms

@@ -137,14 +142,21 @@
     1034.  A summary of the changes appear next and will be fully
     covered in later sections.

+    Note that labels other than the Asterisk Label which contain
+    asterisks have no special significance or terminology in this
+    document; thus the fact that a domain names starts with an
+    asterisk is also of no special significance (and has no special
+    terminology) unless its first label is the Asterisk Label, i.e.
+    "*foo.example.com" has no special significance).
+
 1.3.2 Changed Text

     The definition of "existence" is changed, superficially, to exclude
     empty domains that have no subdomains with resource records.  This
-    change will not be apparent to implementations, it is needed to
+    change will not be apparent to implementations; it is needed to
     make descriptions more concise.

-    In RFC 1034, there is text that seems to bar having two Asterisk
+    In RFC 1034, there is text that seems to prohibit having two Asterisk
     Labels in a Wild Card Domain Name.  There is no further discussion,
     no prescribed error handling, nor enforcement described.  In this
     document, the use of such names will be discouraged, but 
implementations
@@ -159,13 +171,13 @@

     This clarification will describe in some detail the semantics of
     wildcard CNAME RRs, wildcard NS RRs, wildcard SOA RR's,
-    wildcard DNAME RRs [RFC wxyz], and empty, non-terminal wildcards.
+    wildcard DNAME RRs [RFC wxyz], and empty non-terminal wildcards.
     Understanding these types in the context of wildcards has been
     clouded because these types incur special processing if they
     are the result of an exact match.

     By the definition in RFC 1034, there can be no empty, non-terminal
-    "wildcards", but in the algorithm, it is possible that an empty
+    "wildcards". However, in the algorithm, it is possible that an empty
     non-terminal is sought as the potential owner of a "wildcard."  This
     is one example of why the ordering of the discussion in RFC 1034 is
     confusing.
@@ -191,10 +203,10 @@

     Tackling the latter first, there are two objectives in defining a
     means to identify a resource record set as a source of synthesis.
-    First is the desire to maintain all DNS data in a consistent manner.
-    Avoiding the need for implementations to have many internal data
-    structures is a good thing.  Not that this means limiting quantity,
-    but rather types of data.  The second objective impacts 
interoperability,
+    First, the desire to maintain all DNS data in a consistent manner:
+    avoiding the need for implementations to have many internal data
+    structures is a good thing, i.e. limiting the number of types of
+    data (as opposed to quantity of data). The second objective impacts 
interoperability,
     that is a master server of one implementation has to be able to
     send the synthesis instructions to the slaves.  Although there are
     alternatives to the use of zone transfers via port 53, a truly
@@ -213,7 +225,8 @@

 2.1.1 Wild Card Domain Name and Asterisk Label

-    A "Wild Card Domain Name" is defined by having its initial label be:
+    A "Wild Card Domain Name" is defined by having its initial
+    (i.e. left-most, or least significant) label being:

          0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)

@@ -224,7 +237,7 @@
     character encoding.

     A descriptive name of a label equaling that value is an "Asterisk
-    Label."
+    Label.".

     RFC 1034's definition of wildcard would be "a resource record owned
     by a Wild Card Domain Name."  This is mentioned to help maintain some
@@ -235,6 +248,9 @@

 2.1.2 Variations on Wild Card Domain Names

+    Labels other than the Asterisk Label which contain the
+    ASCII representation of the asterisk (0x2a) have no significance
+    for the purposes of this document.
     RFC 1034 and RFC 1035 do not explicitly mention the case in which a
     domain name might be something like "the*.example.com."  The
     interpretation is that this domain name in a zone would only match
@@ -248,13 +264,22 @@
     [Ed note: the above paragraph reads too strong.  The intent ought to
     be that such names do not fall under the rules of wildcards.  The
     intent is not to bar any future attempts to define other forms of
-    synthesis - nor is the intent to encourage them.]
-
-    The interpretation of a wild card domain specification which is not a
-    leaf domain is not clearly defined in RFC 1034.  E.g., sub.*.example.,
+    synthesis - nor is the intent to encourage them.
+    AB - I thought it's OK but perhaps the addition of the first
+    sentence suggested puts it into context - i.e. nothing to do with us]
+
+    The interpretation of a domain name containing an Asterisk Label 
otherwise
+    than as a  leaf domain is not clearly defined in RFC 1034.
+    [AB - you have defined Wild card domain name to be the case where it 
*is*
+    a leaf so previously this was a contradiction in terms]
+    E.g., sub.*.example.com.,
     is not discussed, not barred.  In wanting to minimize changes from
     the original specification, such names are permitted.  Although
-    "sub.*.example." is not a Wild Card Domain Name, "*.example." is.
+    "sub.*.example.com." is not a Wild Card Domain Name, "*.example.com." 
is,
+    as are "*.sub.*.example.com.", and "*.*.example.com." (though for
+    the latter two cases see 2.1.3 below).
+    [AB - Right? Per your definition above, they are still Wild Card Domain
+    Names notwithstanding 2.1.3].

     RRSets used to synthesize records can be owned by a Wild Card Domain
     Name that has subdomains.
@@ -287,6 +312,11 @@
     (See the upcoming sections on empty non-terminals.)  In this case,
     the lookup will terminate as would any empty non-terminal match.

+    Similarly, both server and resolver implementations ought to accept 
domain names with
+    Asterisk Labels in positions other than the left most (least 
significant)
+    label though they should not attribute any special meaning to such
+    labels.
+
 2.2 Existence Rules

     The notion that a domain name 'exists' arises numerous times in
@@ -345,7 +375,7 @@
                            |             |
                          _ssh          _ssh

-    The following queries would be synthesized from the wild card:
+    The following queries would be synthesized from one of the wild cards:

          QNAME=host3.example. QTYPE=MX, QCLASS=IN
               the answer will be a "host3.example. IN MX ..."
@@ -360,7 +390,7 @@
               the answer will be "foo.bar.example. IN TXT ..."
               because bar.example. does not exist, but the wildcard does.

-    The following queries would not be synthesized from the wild card:
+    The following queries would not be synthesized from either wild card:

          QNAME=host1.example., QTYPE=MX, QCLASS=IN
               because host1.example. exists
@@ -385,7 +415,7 @@
 2.2.2 Empty Non-terminals

     Empty non-terminals are domain names that own no resource records but
-    have subdomains which do.  This is defined in section 3.1 of RFC 1034:
+    have subdomains that do.  This is defined in section 3.1 of RFC 1034:

 #    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
@@ -449,7 +479,7 @@

     When a Wild Card Domain Name appears in a message's query section,
     no special processing occurs.  Asterisk Labels in such a context
-    only Label Matches other Asterisk Labels in the existing zone tree
+    only Label Matche other Asterisk Labels in the existing zone tree
     when the 4.3.2 algorithm is being followed.

     When a Wild Card Domain Name appears in the resource data of a
@@ -468,7 +498,7 @@

     There is a documentation issue deserving some explanation.  The
     algorithm in RFC 1034, section 4.3.2. is not intended to be pseudo
-    code, i.e., it's steps are not intended to be followed in strict
+    code, i.e., its steps are not intended to be followed in strict
     order.  The "algorithm" is a suggestion.  As such, in step 3, parts
     a, b, and c, do not have to be implemented in that order.

@@ -496,40 +526,41 @@
     There are two reasons to repeat this.  One is that this means all
     of step 3 is done within the context of a zone, which will constrain
     the discussion.  The other is the though behind synthesizing entire
-    zones and the use of Wild Card Domain Names to do so.
+    zones and the use of Wild Card Domain Names to do so. [This sentence
+    makes no sense - I think there's a word missing - AB]

 3.2 Step 3

-    Step 3 is dominated by three parts, labelled a, b, and c.  But the
+    Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'.  But 
the
     beginning of the Step is important and needs explanation.

 #   3. Start matching down, label by label, in the zone.  The
 #      matching process can terminate several ways:

-    The word matching in this care refers to Label Matching.  The concept
+    The word matching in this case refers to Label Matching.  The concept
     is based in the view of the zone as the tree of existing names.  The
     Query Name is considered to be an ordered sequence of labels - as
     if the name were a path from the root to the owner of the desired
     data.

     The process of Label Matching ends in one of three choices, the parts
-    a, b, and c.  Once one of the parts is chosen, the other parts are
+    'a', 'b', and 'c'.  Once one of the parts is chosen, the other parts 
are
     not considered.  (E.g., do not execute part c and then change the
-    execution path to finish in part b.)  The process of Label Matching
-    is also done independent of the Query Type.
+    execution path to finish in part 'b'.)  The process of Label Matching
+    is also done independently of the Query Type.

-    Parts a and b are not an issue for this clarification as they do not
-    relate to record synthesis.  Part a generally covers a situation in
+    Parts 'a' and 'b' are not an issue for this clarification as they do 
not
+    relate to record synthesis.  Part 'a' generally covers a situation in
     which all of the labels in the search (query) name have been matched
-    down the tree, e.g., the sought name exists as an exact Label Match.
-    Part b generally covers a situation in which any label in the sought
-    name Label Matches a tree label and the tree label has a NS RRSet.
+    down the tree, e.g., the name being sought exists as an exact Label 
Match.
+    Part 'b' generally covers a situation in which any label in the name 
being
+    sought Label Matches a tree label, and the tree label has a NS RRSet.

 3.3 Part 'c'

     The context of part 'c' is that the process of Label Matching the
-    labels in the sought name has resulted in a situation in which there
-    is nothing corresponding in the tree.  It is as if the lookup has
+    labels in the name being sought has resulted in a situation in which 
there
+    is no corresponding entry in the tree.  It is as if the lookup has
     "fallen off the tree."

 #         c. If at some label, a match is impossible (i.e., the
@@ -546,34 +577,36 @@
     The "Closest Encloser" is the node in the zone's tree of existing
     domain names that is has the most matching labels with the sought
     name.  Each match is a "Label Match" and the order of the labels
-    is also the same.  The Closest Encloser is an existing name in the
-    zone, it may be an empty non-terminal, it may even be a Wild Card
+    is also the same.  The Closest Encloser is by definition an existing 
name in the
+    zone. It may be an empty non-terminal. It may even be a Wild Card
     Domain Name itself.  In no circumstances is the Closest Encloser
-    the used to synthesize records though.
+    used to synthesize records though.

     A "Source of Synthesis" is defined in the context of a lookup
     process as the Wild Card Domain Name immediately descending from
-    the Closest Encloser provided the Wild Card Domain Name exists.
+    the Closest Encloser, provided the Wild Card Domain Name exists.
+    If the Wild Card Domain Name does not exist, there is no
+    Source of Synthesis. [AB: Correct?]
     A Source of Synthesis does not guarantee having a RRSet to use
-    for synthesis, a Source of Synthesis may even be an empty
+    for synthesis; a Source of Synthesis may even be an empty
     non-terminal.

     If a Source of Synthesis exists, it will be the Wild Card Domain Name
     that is identified by an Asterisk Label below the Closest Encloser.
     E.g., "<Asterisk Label>.<Closest Encloser> or "*.<Closest Encloser>."
     If the Source of Synthesis does not exist (not on the domain tree),
-    there will be no wildcard synthesis
+    there will be no wildcard synthesis.

     The important concept is that for any given lookup process, there
     is at most one place at which wildcard synthetic records can be
     obtained.  If the Source of Synthesis does not exist, the lookup
-    terminates, the lookup does not look for other wildcard records.
+    terminates; the lookup does not look for other wildcard records.

     Other terms have been coined on the mailing list in the past.  E.g.,
     it has been said that existing names block the application of
     wildcard records.  This is still an appropriate viewpoint, but
     replacing this notion with the Closest Encloser and Source of
-    Synthesis the depiction of the wildcard process is clearer.
+    Synthesis terminology depicts the wildcard process more clearly.

 3.3.2 Closest Encloser and Source of Synthesis Examples

@@ -593,6 +626,7 @@
     The fact that a closest encloser will be the only superdomain that
     can have a candidate wild card will have an impact when it comes to
     designing pre-calculated authenticated denial of existence proofs.
+    [Insert Reference to DNSSEC-bis]

 3.3.3 Non-existent Source of Synthesis
@@ -613,7 +647,7 @@

 3.3.4 Type Matching

-     RFC 1034 concludes part c with this:
+     RFC 1034 concludes part 'c' with this:

 #            If the "*" label does exist, match RRs at that node
 #            against QTYPE.  If any match, copy them into the answer
@@ -623,15 +657,15 @@

     This final paragraph covers the role of the QTYPE in the lookup 
process.

-    Based on implementation feedback and similarities between step a and
-    step c a change to this passage a change has been made.
+    Based on implementation feedback and similarities between step 'a' and
+    step 'c', a change to this passage a change has been made.

     The change is to add the following text:

              If the data at the source of synthesis is a CNAME, and
              QTYPE doesn't match CNAME, copy the CNAME RR into the
              answer section of the response changing the owner name
-             to the QNAME, change QNAME to the  canonical name in the
+             to the QNAME, change QNAME to the canonical name in the
              CNAME RR, and go back to step 1.

     This is essentially the same text in step a covering the processing of
@@ -663,10 +697,13 @@
     Domain Name is if the QNAME is in a domain below the zone's name.

     E.g., if *.example. has an SOA record, then only a query like
-    QNAME=*.example., QTYPE=A, QCLASS=IN would see it.  As another
+    QNAME=*.example., QTYPE=A, QCLASS=IN would see it. 
QNAME=*.example.com, QTYPE=SOA, QLASS=IN
+    would also see the SOA record, but QNAME=foo.example.com, QTYPE=SOA, 
QCLASS=IN
+    would not. As another
     example, a QNAME of www.*.example. would also result in passing
     through the zone.

+
 4.2. NS RR's at a Wild Card Domain Name

@@ -697,6 +734,9 @@
     to consider the name delegated away.  I.e., the server is not
     synthesizing a record (the NS RRSet) that means the server does not
     have the right to synthesize.
+
+    [I think it would be useful to comment that thus NS RR's are
+    unlikely to work as expected, which is (I think) the case - AB]

 4.3. CNAME RR's at a Wild Card Domain Name

---

From: Robert Elz <[email-masked]>
Date: Tue, 19 Oct 2004 04:56:47 +0700

[ Moderators note: Post was moderated, either because it was posted by 
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subsrcibers. Please fix your 
   subscription addresses. ]

OK, here are some comments interspersed with the text (with many
parts deleted where there's nothing to say)

  | 1.2 The Original Definition

  |     This document is intended to not make changes.  To reinforce

Actually, it is intended to make one change (CNAME) - you really shouldn't
say that there will be none, and then make one anyway.

  |     This passage appears after the algorithm in which they are used is
  |     presented.  The terminology is not consistent, the word "wildcard"
  |     is clearly defined to be a resource record.  In the next sentence
  |     the term is shifted to be an adjective, the first step on the

That's going way overboard in looking for something to worry about.
Just delete the bit that relates to adjectives as an attempt to show
that there are problems in 1034 (there really aren't many, 1034 isn't
bad in this area, it just isn't obvious).

  |     Label Match - two labels are equivalent if the label type and label
  |     length are the same bit sequence and if the name is the label is
  |     equivalent bit wise after down casing all of the ASCII characters.
  |     [Ed note: do we still call them ASCII?]

Yes, we do, but "down casing" isn't he right way to describe how
names are matches, it is just a case-independent comparison, just as
the DNS RFCs describe it, in this doc there's no need to add confusion
by describing things in a different way.

  |     In RFC 1034, there is text that seems to bar having two Asterisk
  |     Labels in a Wild Card Domain Name.  There is no further discussion,
  |     no prescribed error handling, nor enforcement described.  In this
  |     document, the use of such names will be discouraged, but implementations
  |     will have to account for the possibility of such a name's use.

What you mean to say here is that they are to be allowed.   Just say it,
there's no need to side-step around it by telling implementations
that they have to allow for it, without actually saying that it is OK.

  | 1.3.3 Considerations with Special Types

  |     This clarification will describe in some detail the semantics of
  |     wildcard CNAME RRs, wildcard NS RRs, wildcard SOA RR's,
  |     wildcard DNAME RRs [RFC wxyz], and empty, non-terminal wildcards.

It would probably be a good idea to also describe the semantics for a
representative "normal" (ie: easy) RR type (say MX, or A) just so
the normal case doesn't need to be inferred from what's done with the
odd ones.

  |     By the definition in RFC 1034, there can be no empty, non-terminal
  |     "wildcards",

I'm not sure I agree with that.    I think you're reading the description
in 1034 as if it was considering the text input format, rather than the
domain tree, but I don't think it is.

  | 2 "Wildcard"

[...]

  |     Avoiding the need for implementations to have many internal data
  |     structures is a good thing.

Huh?   What's that supposed to be about.   There's no foundation I can
find for referring to these data structures.

  |     Not that this means limiting quantity, but rather types of data.

I have no idea what that is trying to say either.

  | 2.1.1 Wild Card Domain Name and Asterisk Label

  |     A "Wild Card Domain Name" is defined by having its initial label be:

(in the format used in DNS packets)

  |          0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)

  |     RFC 1034's definition of wildcard would be "a resource record owned
  |     by a Wild Card Domain Name."  This is mentioned to help maintain some
  |     orientation between this clarification and RFC 1034.  Keep in mind,
  |     that in "Clarifications to the DNS Specification" [RFC 2181] the name

need a ref (in ref's section) for 2181 if you're going to mention it.

  | 2.1.2 Variations on Wild Card Domain Names

  |     RFC 1034 and RFC 1035 do not explicitly mention the case in which a
  |     domain name might be something like "the*.example.com."  The
  |     interpretation is that this domain name in a zone would only match
  |     queries for "the*.example.com" and not have any other role.  An
  |     asterisk ('*') occurring other than as the sole character in
  |     a label is simply a character forming part of the label and has no
  |     special meaning.   This is not an Asterisk Label, simply a label
  |     an asterisk in it.  The same is true for "**.example.com." and
  |     "*the.example.com."

  |     [Ed note: the above paragraph reads too strong.

No it doesn't, that one is fine as it is.

  |     The intent ought to
  |     be that such names do not fall under the rules of wildcards.  The
  |     intent is not to bar any future attempts to define other forms of
  |     synthesis - nor is the intent to encourage them.]

First, nothing we do can "bar any future standards" from anything, there's
no point worrying about that.   Just be very clear (which the above is)
what the current state of the world is, and allow the future look after itself.
(It would perhaps be different if there was already an extension planned,
or commonly used or something, but there isn't.)

  |     The interpretation of a wild card domain specification which is not a
  |     leaf domain is not clearly defined in RFC 1034.

Actually, it is.   It just isn't explicit.   No-where does it say anything
about sub-domains of wildcards.   The reason is that they're simply not
relevant to anything.   There shouldn't have ever been any need to say
anything about them at all.   The only reason we need to cover this now
is that people have started to (very badly) misunderstand the way wildcards
work, and because of that to imagine semantics for such things which don't
exist.

  | 2.1.3 Non-terminal Wild Card Domain Names

[...]

  |     The recommendation is that implementations ought to anticipate the
  |     appearance of such names but generally discourage their use in
  |     operations.

It isn't really applications, but DNS operators - the people who decide
what names to stick in zone files, where this should be discouraged.

  |     No standards statement, such as "MAY NOT" or "SHOULD NOT"
  |     is made here.

You probably should use MUST NOT rather than MAY NOT here, MAY NOT is
a useless specification (it turns out to mean exactly the same as MAY,
though with perhaps a slightly different slant).

  |     The interpretation of this is, when seeking a Wild Card Domain Name
  |     for the purposes of record synthesis, an implementation ought not to
  |     check the domain name for subdomains.

Rather than tell implementations what to do, just say what is required.
Here, after the second ',', "the existence (or not) of sub-domains of the
Wild Card Domain Name is irrelevant."

  | 2.2 Existence Rules

  |     The notion that a domain name 'exists' arises numerous times in
  |     discussions about the wildcard concept.

Really?   In the dnssec context perhaps, but not just wildcard discussions
did it?

  |     RFC 1034 raises the issue
  |     of existence in a number of places, usually in reference to
  |     non-existence and in reference to processing involving wildcards.
  |     RFC 1034 contains algorithms that describe how domain names impact
  |     the preparation of an answer and does define wildcards as a means of
  |     synthesizing answers.  Because of this a discussion on wildcards
  |     needs to cover a definition of existence.

I'm not sure I agree, but it seems that people want it, so whatever...

  |     To help clarify the topic of wild cards, a positive definition of
  |     existence is needed.  Complicating matters, though, is the
  |     realization that existence is relative.  To an authoritative server,
  |     a domain name exists if the domain name plays a role following the
  |     algorithms of preparing a response.  To a resolver, a domain name
  |     exists if there is any data available corresponding to the name.

Really: if it doesn't get an error from an attempt to resolve the
name.   The resolver usually has no clue whether "any data" is available
or not, just the particular data type it asked about.   To an application,
names "exist" (in some sense, not really relevant here) if the particular
data they need to operate exists for the name, but that's not really true
for resolvers (and certainly wouldn't be for dnssec aware resolvers).

  |     For the purposes of this document, the point of view of an
  |     authoritative server is more interesting.

What does it matter what is "interesting".   What matters is what is
necessary to define in order for it to be able to be used in this doc.
Just define the term and use it, please try and avoid being "chatty".

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

But _tcp.host2.example. exists as well, what's the difference between
this example and the previous (host1) example??

[Aside: you don't really need the $ORIGIN in the zone file segment, there
are no unqualified domain names present, so what the origin is doesn't
really matter.]

You could possibly further clarity "exist" here by noting that to
"exist" the domain name must appear somewhere in a textual representation
of a domain name.

If you want to get into the real weird cases, one to worry about is whether
or not a PTR record RDATA can ever cause a name to "exist".   While the most
reasonable answer is probably "no, of course not", it isn't really necessarily
quite that clear.

  | 2.2.3 Yet Another Definition of Existence

  |     RFC1034's wording is clarified by the following paragraph:

  |          A node is considered to have an impact on the algorithms of
  |          4.3.2 if it is a leaf node with any resource sets or an interior
  |          node (with or without a resource set) that has a subdomain that
  |          is a leaf node with a resource set.  A QNAME and QCLASS matching
  |          an existing node never results in a response code of
  |          authoritative name error (RCODE==3).

What's a "resource set"?  Please be consistent in the terminology, you
mean a "resource record set" (or RRset if you want to save bytes).

  |     Summarizing the discussion on existence in non-RFC1034 words:

  |         An authoritative server is to treat a domain name as existing
  |         during the execution of the algorithms in RFC 1034 when the
  |         domain name conforms to the following definition.  A domain name
  |         is defined to exist if the domain name owns data or has a
  |         subdomain that exists, or both.

I'm not sure this is quite clear enough - that is, a synthesised domain
from a wildcard "owns data" (in some sense anyway) (assuming the appropriate
record type exists at the wildcard). 

  | 2.3 When does a Wild Card Domain Name not own a wildcard (record)

  |     When a Wild Card Domain Name appears in a message's query section,
  |     no special processing occurs.  Asterisk Labels in such a context
  |     only Label Matches other Asterisk Labels in the existing zone tree
  |     when the 4.3.2 algorithm is being followed.

I have no idea what that sentence says.  Maybe "Label Matches" is just
meant to be "match" ??

Assuming it is, it might be worth pointing out that a '*' in a QNAME
can never generate synthesised domain names, as if there's a wildcard
that could ever apply to it, it always matches explicitly instead
(makes no difference to the answer generated, just semantics, but
it is something that needs to be understood.)

  |     There is a documentation issue deserving some explanation.  The
  |     algorithm in RFC 1034, section 4.3.2. is not intended to be pseudo
  |     code, i.e., it's steps are not intended to be followed in strict
  |     order.  The "algorithm" is a suggestion.  As such, in step 3, parts
  |     a, b, and c, do not have to be implemented in that order.

It really doesn't matter - implementations never need to follow the exact
order of pseudo-code, even if that is what it is - all that's required is
to have the same effect.   Since 'a' 'b' and 'c' are mutually exclusive,
it can't possibly make a difference what order they're implemented, nor
whether 4.3.2 is pseudo-code or not.   There's no need to make an issue
of this.

  |     Another issue needing explanation is that RFC 1034 is a full
  |     standard.  There is another RFC, RFC 2672, which makes, or proposes
  |     an adjustment to RFC 1034's section 4.3.2 for the sake of the DNAME
  |     RR.  RFC 2672 is a proposed standard.  The dilemma in writing these
  |     clarifications is knowing which document is the one being clarified.
  |     Fortunately, the difference between RFC 1034 and RFC 2672 is not
  |     significant with respect to wild card synthesis, so this document
  |     will continue to state that it is clarifying RFC 1034.  If RFC 2672
  |     progresses along the standards track, it will need to refer to
  |     modifying RFC 1034's algorithm as amended here.

Then, if 2672 progresses, it would be DS, most likely while this doc
remains PS, so why should it not do exactly the same as you're doing,
and simply ignore the "lower status" doc?

Avoid that issue, just delete all the text about the various status of
RFCs.   If nothing in 2672 is adversely affected by anything that's here,
which is what I'd expect, as I doubt 2672 is attempting to mis-use wildcards,
then there's no issue at all, and we just clarify both together.   On the
other hand, if we're changing something that 2672 is assuming, then we need
to be explicit about what the result is to be - otherwise we end up with
two PS docs that are conflicting with each other, and with the later one
not being clear what this really all means (obviously the earlier one cannot
be).

  |     In this step, the most appropriate zone for the response is chosen.
  |     There are two reasons to repeat this.  One is that this means all
  |     of step 3 is done within the context of a zone, which will constrain
  |     the discussion.  The other is the though behind synthesizing entire
  |     zones and the use of Wild Card Domain Names to do so.

What's a "though" ?   "thought"?   Still doesn't really make sense.
Maybe "attempt to" (in place of "though behind")? 
Do we really even want to mention this?

  |     The word matching in this care refers to Label Matching.

Here you need to make it very clear that the only "matching" that happens
is string equality (case independent) - there's absolutely no "pattern
matching" being done.   My impression is that this the the biggest source
of misunderstanding - people see "match", they leap to "pattern match"
and then "*" means "match anything".

  |     The concept
  |     is based in the view of the zone as the tree of existing names.  The
  |     Query Name is considered to be an ordered sequence of labels - as
  |     if the name were a path from the root to the owner of the desired
  |     data.

"as if" ??   Isn't that exactly what it is?

  |     The process of Label Matching ends in one of three choices, the parts
  |     a, b, and c.

"always ends in exactly one of"

  | #         c. If at some label, a match is impossible (i.e., the
  | #            corresponding label does not exist), look to see if a
  | #            the "*" label exists.

It may be worth explaining here, very explicitly, that the '*' does
not "match" anything in the QNAME - quite the contrary, we're here
precisely because nothing matches ("a match is impossible"), and yet
(assuming the '*' does exist) the '*' label is there.

  |     To help describe the process of looking "to see is a the [sic]
  |     label exists" a term has been coined to describe the last label
  |     matched.  The term is "Closest Encloser."

You put in "[sic]" but then added a typo "is" rather than "if" making the
[sic] incorrect...

  | 3.3.1 Closest Encloser and the Source of Synthesis

  |     The "Closest Encloser" is the node in the zone's tree of existing
  |     domain names that is has the most matching labels with the sought
  |     name.

Just use QNAME rather than "sought name" - if necessary, somewhere, say
what "QNAME" means.    And not "most matching labels", then if the
QNAME were "a.b.c.d.e.f.g." and the "g." zone contains "a.b.c.d.e.g."
then there could be considered to be 5 matching labels in the zone
(not counting the 'g').   In reality, there are none, as there's no
'f' there - what we want is the most consecutive trailing matching labels.

  |     A "Source of Synthesis" is defined in the context of a lookup
  |     process as the Wild Card Domain Name immediately descending from
  |     the Closest Encloser provided the Wild Card Domain Name exists.

s/the Wild/that Wild/

  |     If a Source of Synthesis exists, it will be the Wild Card Domain Name
  |     that is identified by an Asterisk Label below the Closest Encloser.

s/below the/as a sub-domain of/

Stick to DNS terminology.

  |     E.g., "<Asterisk Label>.<Closest Encloser> or "*.<Closest Encloser>."

Surely "ie" not "eg" - this isn't an example, this is *it*.

  |     If the Source of Synthesis does not exist (not on the domain tree),
  |     there will be no wildcard synthesis

(missing '.' at the end of that sentence).   "on the domain tree" ?
I guess that's OK, but "in" is more common isn't it?    You may want
to say something like "Other Wild Card Domain Names are irrelevant
and can never play any part in synthesis, regardless of where they
appear in the DNS tree."

  |     The important concept is that for any given lookup process, there
  |     is at most one place at which wildcard synthetic records can be
  |     obtained.  If the Source of Synthesis does not exist, the lookup
  |     terminates, the lookup does not look for other wildcard records.

This is a slightly milder form of what I'd say.

  |     Other terms have been coined on the mailing list in the past.  E.g.,
  |     it has been said that existing names block the application of
  |     wildcard records.  This is still an appropriate viewpoint, but
  |     replacing this notion with the Closest Encloser and Source of
  |     Synthesis the depiction of the wildcard process is clearer.

Delete that paragraph, there's no useful information there.

  | 3.3.2 Closest Encloser and Source of Synthesis Examples

  |     To illustrate, using the example zone in section 2.2.1 of this document,
  |     the following chart shows QNAMEs and the closest enclosers.

  |      QNAME                        Closest Encloser     Source of Synthesis
  |      host3.example.               example.             *.example.
  |      _telnet._tcp.host1.example.  _tcp.host1.example.  no source
  |      _telnet._tcp.host2.example.  host2.example.       no source

				      _tcp.host2.example.

  |      _telnet._tcp.host3.example.  example.             *.example.
  |      _chat._udp.host3.example.    example.             *.example.

  |     The fact that a closest encloser will be the only superdomain that
  |     can have a candidate wild card will have an impact when it comes to
  |     designing pre-calculated authenticated denial of existence proofs.

Do we need to include that?   We're not designing denial of existence
proofs here, are we?   Stick to the topic, don't wander.

  | 3.3.4 Type Matching

  |      RFC 1034 concludes part c with this:

  | 4.1. SOA RR's at a Wild Card Domain Name

  |     A Wild Card Domain Name owning an SOA RRSet means that the domain
  |     is at the root of the zone (apex).  The domain can not be a Source of
  |     Synthesis because that is, but definition, a descendent node (of

s/but/by/

  |     the Closest Encloser) and a zone apex is at the top of the zone.

  |     Although a Wild Card Domain Name can not be a Source of Synthesis,

"for SOA records"  and I'd use "never" instead of "not" to make it
clearer that it is simply impossible, rather than an imposed restriction.

  |     there is no reason to forbid the ownership of an SOA RRSet.  This
  |     means that zones with names like "*.<Parent Zone>.", and even
  |     "*.<Parent Sublabels>.<Parent Zone>."

That last sentence looks incomplete.   Means what?

  |     Step 2 (section 3.1) does not provide a means to specify a means to
  |     synthesize a zone.

too many "means", make the second "method"

  |     Therefore, according to the rules there, the
  |     only way in which a zone that has a name which is a Wild Card
  |     Domain Name is if the QNAME is in a domain below the zone's name.

I suspect that sentence means something, but I don't know what.

But how can the name of a zone possibly depend upon what happens to be
in some particular query?   The zone exists (and is named) first,
queries come later.

  |     E.g., if *.example. has an SOA record, then only a query like
  |     QNAME=*.example., QTYPE=A, QCLASS=IN would see it.

But it wouldn't - or not directly - a QTYPE=A isn't going
to result in a SOA being returned.   (And yes, I know it gets added
to the auth section to provide cache info, but I don't think we
should descend there).   Just make the QTYPE be SOA, it already
says "like" so it isn't saying that's the only way to ever get
the SOA record back anywhere, but it is the only way to get it as
the answer.

  |     As another
  |     example, a QNAME of www.*.example. would also result in passing
  |     through the zone.

"passing through"?   Is this relevant?   We'd have to define what that
actually means (this is supposed to be clarifications, not confusifications).

  | 4.2. NS RR's at a Wild Card Domain Name

  |     The semantics of a Wild Card Domain Name ownership of a NS RRSet
  |     has been unclear.

s/has/have/

And "unclear" isn't really correct/   They are clear.  What they've been
is misunderstood.

  |	Looking through RFC 1034,

Who's looking?   Why is that phrase needed?

  |     the recommendation
  |     is to have the NS RRSet act the same a any non-special type, e.g.,
  |     like an A RR.

What recommendation?   From 1034, a new one here, or ??

Why do we need a recommendation anyway, can't be just be excplicit and
concise, and state the fact:
	An NS RRSet acts the same as any other type.

  |     In any other case, the Wild Card Domain Name owned NS RRSet would
  |     be the only RRSet (prior to changes instituted by DNSSEC) at the
  |     node by DNS rules.

You probably need to refer to just what DNS rules they are.

  |     Note that there is no synthesis of records in the authority section
  |     because part 'b' does not account for synthesis.

Rather than "does not account for synthesis", "applies only when there is
a name match, no records are synthesised"

  |     If the QNAME is not the same as the Wild Card Domain Name nor a
  |     subdomain of it, then part 'c' of Step 3 has been triggered.  Once
  |     part 'c' is entered, there is no reverting to part 'b' - i.e.,
  |     once an NS RRSet is synthesized it does not mean that the server has
  |     to consider the name delegated away.  I.e., the server is not
  |     synthesizing a record (the NS RRSet) that means the server does not
  |     have the right to synthesize.

I can't interpret the final sentence.   Here you might want to quite more
of 'c', including in particular, the "goto 6", with a note that that means
that the whole process is effectively over.

  | 4.4. DNAME RR's at a Wild Card Domain Name

  |     The specification of the DNAME RR, which is at the proposed level of
  |     standardization, is not as mature as the full standard in RFC 1034.

Drop that.

  |     Because of this, or the reason for this is, there appears to be a
  |     a number of issues with that definition and it's rewrite of the algorithm
  |     in 4.3.2.

If there are issues, we should be fixing them.   What are these issues?
Don't beat about the bush - be clear.

  |     For the time being, when it comes to wild card processing

Why "for the time being" - when does that time end?   6 months?
If another draft later wants to change things, then that's fine.
But until then, we just say what we want to be  the state of the world.

  | 4.5 Empty Non-terminal Wild Card Domain Name

  |     If a Source of Synthesis is an empty non-terminal, then the response
  |     will be one of no error in the return code and no RRSet in the answer
  |     section.

It might be worth pointing out here that this is just a not-very-interesting
case of there being no RRs that are of the QTYPE requested - it really
doesn't matter that there are also no other RRs at the node, or lots
of other RRs - everything is the same.   No RRs match QTYPE -> empty answer.

  | 5. Security Considerations

  |     This document is refining the specifications to make it more likely
  |     that security can be added to DNS.  No functional additions are being
  |     made, just refining what is considered proper to allow the DNS,
  |     security of the DNS, and extending the DNS to be more predictable.

There is a "functional addition" - wildcard CNAME.   Don't misprepresent.

  | 6. References

Probably need BCP78 & BCP79 - they're referred to in the IP noise.

Do need 2181.

  | 7. Others Contributing to This Document

  |     Others who have been editors of this document: Bob Halley and Robert Elz.

I wasn't there long enough to count, just delete me.

kre

ps: I have seen Alex's comments - I don't think there's a need to go
overboard adding "(i.e. left most or least significant)" everywhere
the text talks about the leftmost domain name.   Once perhaps, but
I think that's there already.

And ...

is simply wrong.

*.*.example.com. actually contains 2 different Wild Card Domain Names.
(Recall that for any domain name that exists, all of its parents must
also exist, and are all domain names themselves).