Subject: I-D Action:draft-ietf-dnsext-rfc2672bis-dname-11.txt

From: [email-masked]
Date: Tue, 25 Mar 2008 07:00:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title           : Update to DNAME Redirection in the DNS
	Author(s)       : S. Rose, W. Wijngaards
	Filename        : draft-ietf-dnsext-rfc2672bis-dname-11.txt
	Pages           : 16
	Date            : 2008-03-25

The DNAME record provides redirection for a sub-tree of the domain
name tree in the DNS system.  That is, all names that end with a
particular suffix are redirected to another part of the DNS.  This is
an update to the original specification in RFC 2672, also aligning
RFC 3363 and RFC 4294 with this revision.Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-11.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 27 Mar 2008 12:44:11 -0400

>http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-11.txt

#                  Update to DNAME Redirection in the DNS
#                  draft-ietf-dnsext-rfc2672bis-dname-11
#
# 1.  Introduction
#
#    DNAME is a DNS Resource Record type.  DNAME provides redirection from
#    a part of the DNS name tree to another part of the DNS name tree.

Suggested change to the first sentence:

DNAME is a DNS Resource Record type defined in RFC 2672.
                                     ++++++++++++++++++++

#    Take for example, looking through a zone (see RFC 1034 [RFC1034],
#    section 4.3.2, step 3) for the domain name "foo.example.com" and a
#    DNAME resource record is found at "example.com" indicating that all
#    queries under "example.com" be directed to "example.net".  The lookup
#    process will return to step 1 with the new query name of
#    "foo.example.net".  Had the query name been "www.foo.example.com" the
#    new query name would be "www.foo.example.net".

I would place the example down further, after the next paragraph.  I find that
examples are good, but better left until after the definition.

#    The DNAME RR is similar to the CNAME RR in that it provides
#    redirection.  The CNAME RR only provides redirection for exactly one
#    name while the DNAME RR provides redirection for all names in a sub-
#    tree of the DNS name tree.

Because of the fights over what "similar" means, I'd suggest this:

The DNAME RR and the CNAME RR [RFC 1034] cause a lookup to (potentially)
return data corresponding to a domain name different from the queried
domain name.  The difference between the two resource records is that the
CNAME RR directs the lookup of data at its owner to another single name,
a DNAME RR directs lookups for data at descendents of its owner's name to
corresponding names under a different (single) node of the tree.

# 2.  The DNAME Resource Record
#
# 2.1.  Format
...
#    The DNAME RR causes type NS additional section processing.

That's not really a "Format" issue. (Belongs in section 3.)

# 2.2.  The DNAME Substitution
#
#    DNAMEs cause a name substitution to happen to query names.  This is
#    called the DNAME substitution.  The portion of the QNAME ending with
#    the root label that matches the owner name of the DNAME RR is
#    replaced with the contents of the DNAME RR's RDATA.  The owner name
#    of the DNAME is not itself redirected, only domain names below the
#    owner name are redirected.  Only whole labels are replaced.  A name
#    is considered below the owner name if it has more labels than the
#    owner name, and the labels of the owner name appear at the end of the
#    query name.  See the table of examples for common cases and corner
#    cases.

(It's darn hard to word this definition. Maybe we need to invent a 
term for the sequence of labels that end with the root.  One problem 
is trying to work in that it is not necessary to read a domain name r 
to l or l to r [accommodating scripts that are read left to right] 
but retaining that there is a root "on top" and we descend the tree 
to the desired location.)

When following RFC 1034, section 4.3.2's algorithm's third step, 
"start matching down, label by label, in the zone" a node is found to 
own a DNAME resource
record a DNAME substitution occurs.  The name being sought may be the original
query name or a name that is the result of a CNAME resource record being
followed or a previously encountered DNAME.  As is the case of finding a
CNAME resource record or NS resource record set, the processing of a DNAME
will happen prior to finding the desired domain name.

A DNAME substitution is performed by replacing the labels of the name being
sought matching the owner name of the DNAME resource record with those
labels with the string of labels in the RDATA field.  The matching labels
end with the root label in all cases.

# 2.3.  DNAME Apex not Redirected itself
#
#    The owner name of a DNAME is not redirected itself.  The reason for
#    the original decision was that one can have a DNAME at the zone apex
#    without problem.  Then use this DNAME at the zone apex to point
#    queries to the target zone.  There still is a need to have the
#    customary SOA and NS resource records at the zone apex.  This means
#    that DNAME does not mirror a zone completely, as it does not mirror
#    the zone apex.

Remove the "without problem" phrase.  And then strike the sentence after that.

#    Another reason for excluding the DNAME owner from the DNAME
#    substitution is that one can then query for the DNAME through RFC
#    1034 [RFC1034] caches.

That doesn't make much sense to me, but I can't think of a replacement or
a real reason to strike it.

# 2.4.  Names Next to and Below a DNAME Record
#
#    Other resource records MUST NOT exist at a domain name subordinate to
#    the owner of a DNAME RR.  To get the contents for names subordinate
#    to that owner, the DNAME redirection must be invoked and the
#    resulting target queried.  A server MAY refuse to load a zone that
#    has data at a domain name subordinate to a domain name owning a DNAME
#    RR.  If the server does load the zone, those names below the DNAME RR
#    will be occluded.  Also a server SHOULD refuse to load a zone
#    subordinate to the owner of a DNAME record in the ancestor zone.  See
#    Section 5.2 for further discussion related to dynamic update.

The term "occluded" needs definition (or a reference).

# 2.5.  Compression of the DNAME record.
#
#    The DNAME owner name can be compressed like any other owner name.
#    The DNAME RDATA target name MUST NOT be sent out in compressed form,
#    so that a DNAME RR can be treated as an unknown type.

[RFC 3597] - unknown types

#    Although the previous specification [RFC2672] talked about signaling
#    to allow compression of the target name, no such signaling is
#    explicitly specified.

previous DNAME specification
          +++++

What is meant by "no such signaling is *explicitly* specified"?  I don't
know if this means that this revision is saying there is no "such signalling"
or something else.

# 3.  Processing

Here is where the comment (under Formatting) about causing "additional"
processing should be put.

# 3.1.  Wildcards

I would have expected the first order of business would be to go over in
detail the changes to "the algorithm" in RFC 1034/4.3.2 before outlying
issues.  Even if you are subsuming the existing definitions - but I recall
that even the old changes (in RFC 2672) needed updating.

# 3.2.  CNAME synthesis
#
#    On the server side, the DNAME RR record is always included in the
#    answer section of a query, when one is encountered.  A CNAME RR

When preparing an response, a server upon performing a DNAME substitution
will in all cases include the DNAME RR used in the answer section.

Note - not "of a query" but "of a response."

#    record with TTL equal to the corresponding DNAME RR is synthesized

and included in the answer section

#    for old resolvers, specifically for the QNAME in the query.  DNSSEC

but I don't get "for the QNAME in the query."

#    [RFC4033], [RFC4034], [RFC4035] says that the synthesized CNAME does
#    not have to be signed.  The DNAME has an RRSIG and a validating
#    resolver can check the CNAME against the DNAME record and validate
#    the DNAME record.
#
...
#    The UD bit is part of the EDNS extended RCODE and Flags field.  It is
#    used to omit server processing, transmission and resolver processing
#    of unsigned synthesized CNAMEs.  Resolvers can set this in a query to

EDNS is RFC 2671

"unsigned?"  As opposed to negative numbers? ;)

#    request omission of the synthesized CNAMEs.  Servers copy the UD bit
#    to the response, and can omit synthesized CNAMEs from the answer.
#    Older resolvers do not set the UD bit, and older servers do not copy
#    the UD bit to the answer, and will not omit synthesized CNAMEs.
...
# 3.3.  Acceptance and Intermediate Storage
#
#    DNS caches can encounter data at names below the owner name of a
#    DNAME RR, due to a change at the authoritative server where data from
#    before and after the change resides in the cache.  This conflict
#    situation is a transitional phase, that ends when the old data times
#    out.  The cache can opt to store both old and new data and treat each
#    as if the other did not exist, or drop the old data, or drop the
#    longer domain name.  In any approach, consistency returns after the
#    older data TTL times out.

I would think that with the new "occluded" text, the option to drop the
longer name is out the window.  Come to think of it though, there is no
right answer for this situation.

# 3.4.  Server algorithm

This should be 3.1...

#    3.  Start matching down, label by label, in the zone.  The matching
#        process can terminate several ways:
...
# 5.  Other Issues with DNAME
#
#    There are several issues to be aware of about the use of DNAME.
#
# 5.1.  MX, NS and PTR Records Must Point to Target of DNAME

What about the replacement field in the NAPTR record or the domain name
in an SRV?  (Trying to think of other RR's that contain domain names.)
What about a URL in a NAPTR regExp field?  Or is the problem only
with records that have special processing for the additional section?

Also, this section title is a bit hard to digest.  "Point to" and "Target of"
are not precise terms.  Is this more accurately "RDATA-contained domain
names cannot be below DNAME owners?"  (I'm guessing.)  Or something that
that doesn't refer to "pointing" or "target."`

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

Never confuse activity with progress.  Activity pays more.

--
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: Kevin Darcy <[email-masked]>
Date: Thu, 27 Mar 2008 21:30:04 -0500

Edward Lewis wrote:
> term for the sequence of labels that end with the root. 
Is "suffix" too overloaded a term to use here? In this context I think 
it effectively denotes "a sequence of labels extending rootwards". If it 
is desired to emphasize that the label-sequence actually _terminates_ at 
the root, then a compound term could be used, such as "root-terminating 
suffix", "full suffix", "complete suffix" or some such.

- Kevin