Subject: Working Group Last Call: draft-ietf-dnsext-wcard-clarify-07

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 1 Jun 2005 16:29:17 +0200

Dear Colleagues,

This is the second WGLC for the "Wildcard clarification document"

                       The Role of Wildcards
                    in the Domain Name System
              draft-ietf-dnsext-wcard-clarify-07.txt

Abstract:

    This is an update to the wildcard definition of RFC 1034.  The
    interaction with wildcards and CNAME is changed, an error
    condition removed, and the words defining some concepts central
    to wildcards are changed.  The overall goal is not to change
    wildcards, but to refine the definition of RFC 1034.

The first WGLC of this document was in September 2003 [1] and raised
the issue of wildcard synthesis. That last call concluded [2] with
overall consensus of the working-group is that clarification of
wildcard behavior is necessary and that the document is to proceed on
the standard track.

A number of open issues were identified at that time and while
clarifying these new issues came up.  The main topics were the
handling of NS, SOA, CNAME and DNAME types owned by a "*-labels".

Hereby we start a last call that will end Sunday June 19. 

Please review the document. Please state you reviewed the document
with your objections and support. Send your statement to the
mailing list or to both chairs directly.

Statements that the documents has been thoroughly reviewed by working
group members do help in writing a summary for the IESG and to further
shepherd the document.

If no support or objections have been received the default action will
be to forward this document to the IESG with a request to publish on
the standards track. 

--Olaf & Olafur
  DNSEXT Chairs

[1] http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01558.html
[2] http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01756.html

--
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: Samuel Weiler <[email-masked]>
Date: Wed, 15 Jun 2005 11:12:21 -0400 (EDT)

I'm glad I finally overcame my apprehensions about tackling this
document.

This doc is important, and I have very few issues with its technical
content, but I think it needs some better intro/summary text in order
to be read by the people who need it and perhaps a more uniform
discussion of what does and doesn't work in order to be more useful
for reference.  In particular, the first couple of pages need a
summary of the main things we expect implementers to miss, and we need
a roadmap to the doc.  That roadmap might suggest reading sections 3
and 4 first, then going back to the painful details in section 2.

To me, the most useful parts were 1.3, 2.2.1, and section 4.  Section
3 was a mixed bag.  I'd really like to see 3 and 4 tightened up, and
the items in 4 made more uniform and unambiguous.  You may even want
to reorder the doc, pulling the above-listed sections higher up and
pushing details down.

Here are some specific suggestions, starting from the back of the doc
(since I found it to be the most valuable).  Minor textual stuff has
been sent to Ed privately.  I do think these issues are worth delaying
the doc for.  I'm also worried that we haven't given enough
consideration to sections 4.6 and 4.7 (wildcard DS and NSEC RRs).

4.3 (CNAME)

Go ahead and put details here -- make all of these subparts of 4 tell
the reader the same things: whether it makes sense to publish such
RR's, whether they cause synthesis, and whether something weird
happens.  Go ahead and say them here, even if another section goes
into greater detail.

-----------

4.4  (DNAME)

Although verbose, this section is extremely clear -- it says what not
to do, tells you why, and keeps repeating the mantra that this idea is
stupid.  I really like it.

----

4.5  (SRV)

This is not clear to me.  Can we just say "this SRV record, since ...,
does not cause anything to be synthesized"?  Again, say "you can
publish it, but it won't do what you're thinking".  Possibly write
about what would happen to *_tcp_.example., which might actually be
useful.

----

4.6  (DS)

Meaningless and harmless, yes, but does it synthesize things?
Generally, I would think so.  But it's worth pointing out that a DS
should normally only appear at a parent side zone cut, and refer back
to the NS discussion.

-------

4.7  (NSEC)

This is more the kind of description I was looking for, but I'm not
sure it's correct.  Does "query exactly matches the record" mean that
QTYPE matches?  If so, say that.

And I'm not sure about the non-dangerous bit, either.  This needs a
little more thought.

-----

4.9  (empty non-terminals)

Add an example?  I don't follow this on a first read.

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

3.3.3

I got lost here, too -- I really want (I know I'm dreaming) something
as simple as "wildcard CNAMEs work".  Sadly, even 4.3 doesn't just
come out and say something brief and understandable.  I want something
brief and understandable.  For instance, for SOA's "yes, you can have
a wildcard domain name owning an SOA, but it can't be used as a source
of synthesis (or, even better, it doesn't lead to synthesis)"

-------

3.3.1

I didn't follow this section on this reading (much like 1.2) -- maybe
I'll be able to say more next time.  In general, though, Section 3
needs to do the same thing I'm suggesting for section 4 and the doc
as a whole -- it needs an intro/summary in very plain language.
Precise is good, too, but add a summary in plainer language.

------

Section 2.3

I'm wondering if there should be other cases included here, too.
(Dynamic update messages, etc.)

-----

Section 2.1.3

  "A wild card domain name can have subdomains."  this is also unclear
to the casual reader -- can you have a zone cut at a wildcard label or
not?  Clarify here, referring to the relevant section (4.2) later.

------

Section 1.2 is where I started getting lost in the details.  I suggest
moving it somewhere else or even removing it.  If it moves to section
2, add a warning at the end of section 1 and tell folks about the good
things come in the later sections.  In any case, move it below the
definition of the #-convention.

Speaking of the #-convention, I think it's ugly.  Perhaps ask the RFC
Editor now if they have a preference for what to use?

----

Section 1

As before, can we put a few gotchas here and some other reasons to
read the whole thing?  Maybe pulling the list from 1.3 higher up and
adding a couple of examples?

---

From: Edward Lewis <[email-masked]>
Date: Wed, 15 Jun 2005 11:52:09 -0400

>I'm glad I finally overcame my apprehensions about tackling this

I wish I could overcome my apprehensions about the document as well.

>and 4 first, then going back to the painful details in section 2.

I find it difficult to provide "a summary of" what "we expect 
implementers to miss" especially as this is a supplemental document 
and not introducing a new idea.

>to reorder the doc, pulling the above-listed sections higher up and

1.3 is a roadmap, 2.2.1 are examples, and I consider (as editor) 
section 4 to be the least important part of the document.  The 
document is about the commentary on RFC 1034 - in the spirit of 
clarifying it - so section 3 is the heart of the effort.  Section 4 
is "how the rubber meets the road" so to speak.

>consideration to sections 4.6 and 4.7 (wildcard DS and NSEC RRs).

Now's the time to consider them (DS and NSEC).

Keep in mind that this is not meant to be a tutorial on wild cards 
for the benefit of implementers nor for the benefit of operators. 
The goal of the document is to fill in gaps in the description of RFC 
1034.  The goal of IETF documents is to be clear enough that diverse 
sets of readers can arrive at interoperable understandings. 
Interoperable understandings does not mean "do it the same way."

This document has already been in the making for sometime.  Please 
make comments now that are complete.  I want to move on from editing 
this, there are other things to do.  There's something to be said for 
"if it were really important, it would have come up in time."

I'm not going to address the remainder of the comment.  I invite 
other members of the WG to do so - I'm just editing.

I will add this - the style of the document is to dive into details 
of the "science" and then back out to the impacts on records.  This 
is not the only style for a technical document.  If I were writing 
this as a "marketing the idea" I would put the features and 
conclusions first, followed by successive detail justifying the 
previous point.  But that isn't the purpose of the document, the 
purpose is to bolster RFC 1034.

As far as uneven detail, yes, the document has that, but this is not 
a standalone document.  The lack of clarity evident in the original 
varies, this document is filling in.   The document is not a great 
literary work - partly because it has taken so long to get to where 
it is.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

---

From: Peter Koch <[email-masked]>
Date: Sun, 19 Jun 2005 23:35:47 +0200

> mailing list or to both chairs directly.

The document is well written and clear in its intent. The points raised below
do not criticise the general direction but should be dealt with before the
draft is sent to the IESG.

The comments affect some wording issues, one request for declaration of
the scope of the draft (start of section 3). and the "* NS" and "* DS"
subsections.

> DNSEXT Working Group                                          E. Lewis
> INTERNET DRAFT                                                 NeuStar
> Expiration Date: November 16, 2005                        May 16, 2005

The list of to be updated RFCs (1034, SRV, DNAME, DNSSEC) is missing.

> 1 Introduction

>     In addition, consideration has been given to minimize any
>     backwards compatibility with implementations that have complied
>     with RFC 1034's definition.

That might be a "maximize"?

> 1.1 Motivation

>     Many DNS implementations have diverged with respect to wildcards
>     in different ways from the original definition, or at from least

"from at least"?

>     This document is intended to limit changes,  only those based on
>     implementation experience, and to remain as close to the original

missing verb?

> 1.3.2 Changed Text

>     Only the latter change represents an impact to implementations.
>     The definition of existence is not a protocol impact.  The change
>     to the restriction on names is unlikely to have an impact, as
>     there was no discussion of how to enforce the restriction.

Not sure what "there" references to. Is it the discussion of this spec or
is it the old spec itself?

> 2.1.2 Asterisks and Other Characters
> 
>     No label values other than that in section 2.1.1 are asterisk
>     labels, hence names beginning with other labels are never wild
>     card domain names.  Labels such as 'the*' and '**' are not
>     asterisk labels, they do not start wild card domain names.

'so' after the last comma makes this easier to read.

>     NXDOMAIN is introduced in RFC 2308, section 2.1 says "In this

No objection, but 'NXDOMAIN' resulted in an IESG DISCUSS for another draft
recently.

> 2.2.1 An Example

>     The following queries would be synthesized from one of the

s/queries/responses/, occurs twice

>         QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
>              because *.example. exists

This I really like; may we add a sentence below the examles like
"Note that the second example above illustrates that the wildcard never
matches all names below the closest encloser. Any descendants of the wildcard
domain name are shadowed by the wildcard itself."?

> 2.2.3 Yet Another Definition of Existence

>     The domain name space is a tree structure.  Nodes in the tree
>     either own at least one RRSet and/or have descendants that
>     collectively own at least on RRSet.  A node may have no RRSets
>     if it has descendents that do, this node is a empty non-terminal.
s/ a / an /

>     A node may have its own RRSets and have descendants with RRSets
s/$/,/

>     including the NS RR set.  At the delegating server, the NS RR

Purist again. Servers don't delegate. change to
"At the delegating zone's servers" or "In the delegating zone"

> 2.3 When does a Wild Card Domain Name is not Special

s/does //

>     When a wild card domain name appears in a message's query section,
>     no special processing occurs.  An asterisk label in a query name
>     only (label) matches an asterisk label in the existing zone tree
>     when the 4.3.2 algorithm is being followed.

Should "(label)" be deleted?

> 3. Impact of a Wild Card Domain Name On a Response

>     The algorithm in RFC 1034, section 4.3.2. is not intended to be
>     pseudo 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.

This is a clarification that has not been made in any RFC before. While
I agree with the intent (it's not that bad, alphabetical order is fine,
although some rollback is needed), this statement has side effects beyond
the definition and application of wildcards. That's fine, but it's more
than the introduction declares, so that should be changed.

> 3.2 Step 3

>     The process of label matching a query name ends in exactly one of
>     three choices, the parts 'a', 'b', and 'c'.  Either the name is
>     found, the name is below a cut point, or the name is not found.
> 
>     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 (QTYPE).
> 
>     Parts 'a' and 'b' are not an issue for this clarification as they
>     do not relate to record synthesis.  Part 'a' is an exact match
>     that results in an answer, part 'b' is a referral.  It is
>     possible, from the description given, that a query might fit
>     into both part a and part b, this is not within the scope of
>     this document.

The first and the third paragraph above seem to collide. While the first
promises a clear decision, the last says it might be 'a' and 'b'. IMHO
the promise is wrong since a name may be matched and still be below the
zone cut ("cut point" is yet undefined).

> 3.3.3 Type Matching
> 
>      RFC 1034 concludes part 'c' with this:
> 
> #            If the "*" label does not exist, check whether the name
> #            we are looking for is the original QNAME in the query
> #            or a name we have followed due to a CNAME.  If the name
> #            is original, set an authoritative name error in the
> #            response and exit.  Otherwise just exit.
> #
> #            If the "*" label does exist, match RRs at that node
> #            against QTYPE.  If any match, copy them into the answer
> #            section, but set the owner of the RR to be QNAME, and
> #            not the node with the "*" label.  Go to step 6.
> 
>     The 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 has been made.
> 
>     The change is to add the following text to step 'c':
> 
>              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
>              CNAME RR, and go back to step 1.

Strictly speaking, if we just add this to step 'c', it's a noop since the
paragraphs above cover '* exists' and '* doesn't exist'. Avoiding the
logic we applied to step 3 as a whole (choose the order that best fits)
seems sensible, so the text has to be inserted before "Go to step 6" in the
second paragraph.

> 4.2 NS RRSet at a Wild Card Domain Name

>     After some lengthy discussions, there has been no clear "best
>     answer" on how to document the semantics of such a situation.

When the chairs asked for comments on this approach I responded that we
lost part of the discussion with this text. Giving no "best answer" is OK,
but we could more explicitly list the answers we don't give.

>     Combining these observations with thought that a wild card
>     domain name owning an NS record is an operationally uninteresting
>     scenario, i.e., it won't happen in the normal course of events,
>     accomodating this situation in the specification would also be
>     categorized as "needless complication." Further, expending more
>     effort on this topic has proven to be an exercise in diminishing
>     returns.

Just for the record these are wildcard NS RRSets found in the "wild":

	*.AC.  *.IO.  *.MP.  *.SH.  *.TM.

> 4.4 DNAME RRSet at a Wild Card Domain Name
> 
>     Ownership of a DNAME RRSet by a wild card domain name
>     represents a threat to the coherency of the DNS and is to be
>     avoided or outright rejected.  Such a DNAME RRSet represents
>     non-deterministic synthesis of rules fed to different caches.
>     As caches are fed the different rules (in an unpredictable
>     manner) the caches will cease to be coherent.  ("As caches
>     are fed" refers to the storage in a cache of records obtained
>     in responses by recursive or iterative servers.)

s/iterative/non-recursive/ There are "iterative resolvers", but those are the
ones actually offering "recursive service".

>     For example, assume one cache, responding to a recursive request,
>     obtains the record "a.b.example. DNAME foo.bar.tld." and another
>     cache obtains "b.example. DNAME foo.bar.tld.", both generated
>     from the record "*.example. DNAME foo.bar.tld." by an
>     authoritative server.

Ceterum censeo RFC 2606 should have reserved mor distinct example TLDs.
Not sure what to do here.

>     The DNAME specification is not clear on whether DNAME records
>     in a cache are used to rewrite queries.  In some interpretations,
>     the rewrite occurs, in some, it is not.  Allowing for the

s/ is / does /

> 4.5 SRV RRSet at a Wild Card Domain Name

>     *.example is a wild card domain name and although it it the Name
>     of the SRV RR, it is not the owner (domain name).  The owner
>     domain name is "_foo._udp.*.example." which is not a wild card
>     domain name.

"owner domain name" is new lingo, "owner name" has been more common.
Rephrased:

    *.example is a wild card domain name and although it is the Name
    of the SRV RR, it is not its owner (name).  The owner
    name is "_foo._udp.*.example." which is not a wild card
    domain name.

> 4.6 DS RRSet at a Wild Card Domain Name
> 
>     A DS RRSet owned by a wild card domain name is meaningless and
>     harmless.

Does meaningless mean it cannot be a source of synthesis? What about the
"*" subdomain, could it be secured by the "*" DS RR? This will have
implications for the interpretation of "* NS", won't it?

-Peter

---

From: Edward Lewis <[email-masked]>
Date: Mon, 20 Jun 2005 15:59:38 -0400

I'll address only the points that beg, umm, clarification.

At 23:35 +0200 6/19/05, Peter Koch wrote:
>  Quotes from the draft:

I'll have to see if I defined "label match" to try and clear up what is
meant when "matching label by label".  This might be something that has
time pass it by.

>than the introduction declares, so that should be changed.

Interesting call.  That statement has been made by Rob Austein a few 
times.  That's where I got it from and have used it in other threads.

>zone cut ("cut point" is yet undefined).

For example, a query for type=DS or NSEC for delegation point could 
arguably be in a or b, but still only one of 'a' or 'b' or even 'c' 
will hold.

Maybe (I'll) just drop the last sentence.

>>  3.3.3 Type Matching
...
>seems sensible, so the text has to be inserted before "Go to step 6" in the

Okay, okay.

>but we could more explicitly list the answers we don't give.

It's hard to do that because part of the reason for not giving a 
"good" answer is that so some a "good answer" is a "bad answer" to 
others, if you follow my meaning.  Hmmm.

>	*.AC.  *.IO.  *.MP.  *.SH.  *.TM.

Well, the IETF doesn't do enforcement...;)

>Not sure what to do here.

I suppose I could just switch tld to example.net.

Cognito ergo cerveza.  (I think therefore I drink.)  I have to admit 
I had to figure out what Ceterum censeo meant. ;)

>implications for the interpretation of "* NS", won't it?

Meaningless - if I did synthesize a DS RRSet, there isn't a reliable 
NS RRSet to correspond to it (therefore no DNSKEY RRSet) to make it 
worthwhile.  I admit to running out of steam when I wrote that part, 
but a DS RRSet without a corresponding DNSKEY RRSet is pretty 
meaningless in the larger scheme of the world.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Alex Bligh <[email-masked]>
Date: Mon, 20 Jun 2005 21:57:26 +0100

> times.  That's where I got it from and have used it in other threads.

The question here is whether such statements mean:
a) that the algorithm presented is merely an example of a mechanism for
   reliably obtaining the correct result, and that an implementation need
   not necessarily duplicate the pseudocode exactly; any implementation
   is acceptable provided it produces the results required by the RFCs,
   and (as the pseudocode is compliant in this respect) as the pseudocode.
   However, code which produces differing output for any one input set
   is not compliant; OR
b) that the algorithm presented is merely an example of a mechanism for
   implementing the RFCs, and that it includes design choices beyond those
   specified by the RFCs. Thus whilst producing an implementation which
   duplicates the pseudocode exactly will result in compliance, it would
   equally be possible to produce another interpretation, which might
   give different output in a subset of input cases, which would be
   equally compliant, because the RFC's leave some choices as to behaviour
   to the implementer, who might not choose the same implementation as
   the pseudocode.

If (a) is the case, then this is indeed merely a clarification, in that
it is saying that RFC's define protocols, not implementation, and (in
essence), the algorithm is there to show how the protocol should respond.
For instance, an algorithm which used a hash cache of the query tuple
would be a valid implementation, in that it would always produce the
same results as the algorithm.

If (b) is the case, that's a bit surprising, and more than a clarification.
It's also possibly rather unhelpful, as the next question is "well, what
assumptions does the algorithm presented make that need not be made for
conformance with the mandatory terms of the RFC". In that respect, it's
the opposite of a clarification, because it introduces doubt (obviously
not Ed's fault!).

I have always thought the statement (made not only by Rob, but also others)
meant (a) above - IE "it doesn't matter how you do it, just so long as
it produces the same results, because we are in the business of defining
protocols not implications". To which I say "well duh", but I suppose
it needs stating. If I'm right, the text in -clarify should probably
have appended "provided that same result is produced" after "in that order".

Alex

---

From: Edward Lewis <[email-masked]>
Date: Tue, 21 Jun 2005 11:31:27 -0400

>have appended "provided that same result is produced" after "in that order".

I think it's a also.  So the extra words are probably a good idea. 
("Probably" because I'm reacting to the email and not looking at the 
draft right now. ;))

---

From: Peter Koch <[email-masked]>
Date: Wed, 22 Jun 2005 17:43:58 +0200

Edward Lewis <[email-masked]>

> I'll have to see if I defined "label match" to try and clear up what is

turns out to have been a parsing problem on my side, but the clarification
might also assist others.

> times.  That's where I got it from and have used it in other threads.

Violent agreement here, the clarification itself is fine. It just influences
more than wildcards, but also e.g. whether the NS RRs for a delegated zone
will end up in the answer or authority section when asking the parent's
servers).

> arguably be in a or b, but still only one of 'a' or 'b' or even 'c' 

OK, so there's a degree of freedom to choose between 'a' and 'b'.

	It is possible, from the description given, that a query might fit
	equally well into both part a and part b. Directing the final
	decision is not within the scope of this document.

> Maybe (I'll) just drop the last sentence.

Your clarification helped and I think it's useful to explicitly state that
an implementation may decide (or may have to consult other documents for
a guided decision) here.

> Well, the IETF doesn't do enforcement...;)

Not advocating in that direction, nor defending the setup. Just a heads up
in response to "this is a corner case of no practical relevance".

> meaningless in the larger scheme of the world.

Agreed, but that assumes that "* NS" doesn't even work literally, i.e. for
the "*" subdomain without being a source of synthesis.

-Peter

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 28 Jun 2005 09:14:37 +0200

The last call has been completed and there is as far as I can tell one
issue that is non-editorial and needs some addressing.

The issue starts with Peter's message and relates to this comment.

There is an active thread on this issue that deserves your attention.

Once this issue and the editorial issues are addressed satisfactory we
will allow the last sets of diffs to be reviewed ( on the diffs only )
for about 1-2 weeks and then send off the document to the IESG.

At that time I will also CC the working group on the form that is send
to the sheparding AD.

-- Olaf Kolkman
   DNSEXT Co-Chair