Subject: I-D ACTION:draft-ietf-dnsext-rfc2672bis-dname-07.txt

From: [email-masked]
Date: Tue, 18 Dec 2007 15:15:02 -0500

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-07.txt
	Pages		: 16
	Date		: 2007-12-18
	
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.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-dnsext-rfc2672bis-dname-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

---

From: Scott Rose <[email-masked]>
Date: Fri, 21 Dec 2007 08:07:48 -0500

The changes in this new version reflect the comments from Ed and Mark
from the last version(s), many of which were from the -05 version:

http://ops.ietf.org/lists/namedroppers/namedroppers.2007/msg00531.html

And

http://ops.ietf.org/lists/namedroppers/namedroppers.2007/msg00537.html

Please read and comment
Scott (& Wouter)

[email-masked] wrote:
> Warning: This message has had one or more attachments removed
> Warning: (not named).
> Warning: Please read the following for more information.
> 

-- 
----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
[email-masked]

http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
-----------------------------------------

--
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: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Fri, 21 Dec 2007 09:33:13 -0500

WG Last Call is planned for early January so now is a good time to take a
look and send comments to editors if any changes are needed before then.

         Olafur

---

From: Edward Lewis <[email-masked]>
Date: Mon, 31 Dec 2007 11:31:55 -0500

Regarding

# 2.3.  DNAME Apex not Redirected itself
...
#  This means that a DNAME RR is not allowed at the same domain name as
#  NS records unless there is also a SOA record present.  DNAME RRs are
#  not allowed at the parent side of a delegation point but are allowed
#  at a zone apex.

The first sentence makes no sense to me.  I would suggest omitting it 
as the valid point is made in the second sentence.  (That is - if you 
are a cache and happen to have all of a domain name's information 
stored you will always have an SOA where there is an NS.  From that 
perspective a restriction saying "it can't have NS unless there's an 
SOA" has got to be defined in the context of a zone file.)

# 2.4.  Names Next to and Below a DNAME Record
#
#   Other resource records MUST NOT exist below the owner of a DNAME RR.

MUST NOT exist *at a domain name* below
and maybe "s/below/subordinate/" as is in the succeeding sentence.

To disambiguate with records at the same name, some might confuse the 
concept of types at a name as having "higher/lower" position when we 
consider DNSSEC's canonical ordering of types within a domain name.

#3.2.  CNAME synthesis
...
#   It does not make sense for the authoritative server to follow the
#   chain of DNAMEs, CNAMEs and wildcards outside of the zone of the
#   query, as some resolver implementations will remove out-of-zone
#   information from the answer.

This wording bothers me.

What is the "zone of the query?"  A query does not have an intended 
zone, e.g., the same iterative query is sent to the root servers 
(barring anything better in a cache) as is sent to the TLD and so on, 
down to the server hosting the zone closest to the zone authoritative 
to the query name.  Is the intent that the zone picked in step 2 of 
RFC 1034, 4.3.2, the "zone of the query?"

Quoting from RFC 1034, chapter 4.3.2, verse 2:
@    2. Search the available zones for the zone which is the nearest
@       ancestor to QNAME.  If such a zone is found, go to step 3,
@       otherwise step 4.

I philosophically agree with "does not make sense for the 
authoritative server to follow" chains as I think that is one of the 
mistakes in RFC 1034.  However, that is what RFC 1034 "commands" 
later in 4.3.2:

Quoting from RFC 1034, chapter 4.3.2, verse 3:
@         a. If the whole of QNAME is matched, we have found the
@            node.
@
@            If the data at the node is a CNAME, and QTYPE doesn't
@            match CNAME, copy the CNAME RR into the answer section
@            of the response, change QNAME to the canonical name in
@            the CNAME RR, and go back to step 1.

Go "back to step 1" is the restart of the query within the server, 
meaning redo step 2 (choosing the zone).

If the intent is to edit those comments, this is a much bigger deal 
than advertised (=update to DNAME).

#3.3.  Acceptance and Intermediate Storage
#
#   DNS Caches MUST NOT allow data to be cached below the owner of a
#   DNAME RR, except CNAME records and their signatures.  CNAME records

All sorts of alarm bells began to ring on this one - "and their 
signatures" set them off.  The CNAMEs aren't signed in this case.

What about a situation in which data at a name is cached for a week 
and three days later the zone administrator puts in a DNAME above the 
name cached.  If the cache learns of the DNAME, does the cache have 
to purge the previously cached data?

Another thing bothers me that is not related to the text here and I 
couldn't find where it is mentioned.  Synthesizing the CNAME with a 
TTL of 0 is a mistake because that means unaware caches (those that 
can't handle DNAME) will not hold onto the CNAME.  Perhaps the TTL 
should be the same as the DNAME but DNAME aware caches ought to treat 
the CNAME as 0 - if they even ever see it.  (They'll see it from 
older responders that don't understand the UD bit.)

#5.2.  Dynamic Update and DNAME
#
#   Zones containing a DNAME RR MUST NOT accept a dynamic update message
#   that would add a record or delegation with a name existing under a
#   DNAME.
#
#   A server MUST return an error message with RCODE=REFUSED [RFC2136] in
#   response to a dynamic update message that would add a resource record
#   under a DNAME in the zone.

This section should state that it is permissible to delete a DNAME RR 
set from a name or modify one.  What about adding?  That's more 
complex because there may be existing names below the proposed owner 
of the DNAME.  Would it be like adding an NS RR?  Masking away the 
obscured names?  Or is the addition a flat-out error?  I think that 
needs to be discussed (meaning, I don't have a definite opinion 
myself).

#5.3.2.3.  Response With Synthesized CNAME
...
#   The answer shown above has the synthesized CNAME included.  However,
#   the CNAME has no signature, since the server does not sign online (it
#   is a slow operation and exposes the signing key).  So it cannot be

The parenthetical comment is true but wrong.  The CNAME isn't signed 
for other reasons, such as a cache synthesizing the record.  Such a 
cache doesn't have the key.  In addition, signing the CNAME does not 
expose the signing key, the presence of the key on the server makes 
it conceivable that the key would be exposed.  I'd recommend just 
removing the comment altogether as it isn't really needed here and 
the caveats that could be included would dwarf the rest of the 
paragraph.  Case in point, this comment is more than twice as long as 
what I'm commenting on.

Finally, if there is an update to this, change the copyright to 2008. 
;)  Been there, done that, got the bounce.

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

Think glocally.  Act confused.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 31 Dec 2007 12:11:27 -0500

<apologies="sick,brief">
On Mon, Dec 31, 2007 at 11:31:55AM -0500, Edward Lewis wrote:
> can't handle DNAME) will not hold onto the CNAME.  

Isn't that a good thing?
</apologies>

----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

---

From: Edward Lewis <[email-masked]>
Date: Mon, 31 Dec 2007 12:30:37 -0500

>>  can't handle DNAME) will not hold onto the CNAME.

I'll certainly agree that it is a toss up.  Holding the CNAME will 
lessen repeated queries, dropping it will mean that less, um, ersatz 
data is held in caches.

Given that the DNAME itself can be withdrawn at any time from the 
authoritative zone, thus once again proving the non-temporal nature 
of DNS, this day I'm siding with caching the CNAME.

(This is the same issue as caching bad DNSSEC validations.  Do you 
keep them to suppress an abuse of the system or drop them because 
they are false in the eyes of the would-be-holder?)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Paul Vixie <[email-masked]>
Date: Mon, 31 Dec 2007 17:52:21 +0000

> ... Holding the CNAME will lessen repeated queries, dropping it will mean
> that less, um, ersatz data is held in caches.

theoretically, yes.  but any authority server can tell you that the number
of repeated queries for cacheable information (both positive and negative)
is already so high that TTL=0 CNAME won't make any practical difference.

of course we should design for the ideal, so that if all stupid clients are
fixed, the number of repeated queries won't be artificially held high by a
TTL=0 CNAME design in the DNAME update.  (unless that's the only/best way.)

i just don't want the record to imply that there aren't repeated queries now.

---

From: Michael StJohns <[email-masked]>
Date: Mon, 31 Dec 2007 13:06:19 -0500

At 11:31 12/31/2007, Edward Lewis wrote:
>The first sentence makes no sense to me.  I would suggest omitting it as the valid point is made in the second sentence.  (That is - if you are a cache and happen to have all of a domain name's information stored you will always have an SOA where there is an NS.  From that perspective a restriction saying "it can't have NS unless there's an SOA" has got to be defined in the context of a zone file.)

Agreed.  AND... this really needs to be defined in terms of server and resolver behavior rather than what can and can't be in the zone file. People will screw up and bad things will happen.  How - exactly - does this record work in the presence of "bad data"?    E.g.  what happens at a cache if it gets both a DNAME and NS records for a specific name?  Does it keep the DNAME records and discard the NS records? Vice versa?  Crash in disgust?

In 2.4 - "refuse to load" should probably be "refuse to serve" data below a DNAME.

What does a recursive resolver do if it gets conflicting data (e.g. data below a DNAME followed later by a DNAME and vice versa?)

There are other places in the text which have this problem as well.

>To disambiguate with records at the same name, some might confuse the concept of types at a name as having "higher/lower" position when we consider DNSSEC's canonical ordering of types within a domain name.
>
>#3.2.  CNAME synthesis
>...
>What is the "zone of the query?"  A query does not have an intended zone, e.g., the same iterative query is sent to the root servers (barring anything better in a cache) as is sent to the TLD and so on, down to the server hosting the zone closest to the zone authoritative to the query name.  Is the intent that the zone picked in step 2 of RFC 1034, 4.3.2, the "zone of the query?"
>
>I philosophically agree with "does not make sense for the authoritative server to follow" chains as I think that is one of the mistakes in RFC 1034.  However, that is what RFC 1034 "commands" later in 4.3.2:
>
>Go "back to step 1" is the restart of the query within the server, meaning redo step 2 (choosing the zone).
>
>If the intent is to edit those comments, this is a much bigger deal than advertised (=update to DNAME).
>
>All sorts of alarm bells began to ring on this one - "and their signatures" set them off.  The CNAMEs aren't signed in this case.
>
>What about a situation in which data at a name is cached for a week and three days later the zone administrator puts in a DNAME above the name cached.  If the cache learns of the DNAME, does the cache have to purge the previously cached data?
>
>Another thing bothers me that is not related to the text here and I couldn't find where it is mentioned.  Synthesizing the CNAME with a TTL of 0 is a mistake because that means unaware caches (those that can't handle DNAME) will not hold onto the CNAME.  Perhaps the TTL should be the same as the DNAME but DNAME aware caches ought to treat the CNAME as 0 - if they even ever see it.  (They'll see it from older responders that don't understand the UD bit.)
>
>This section should state that it is permissible to delete a DNAME RR set from a name or modify one.  What about adding?  That's more complex because there may be existing names below the proposed owner of the DNAME.  Would it be like adding an NS RR?  Masking away the obscured names?  Or is the addition a flat-out error?  I think that needs to be discussed (meaning, I don't have a definite opinion myself).
>
>The parenthetical comment is true but wrong.  The CNAME isn't signed for other reasons, such as a cache synthesizing the record.  Such a cache doesn't have the key.  In addition, signing the CNAME does not expose the signing key, the presence of the key on the server makes it conceivable that the key would be exposed.  I'd recommend just removing the comment altogether as it isn't really needed here and the caveats that could be included would dwarf the rest of the paragraph.  Case in point, this comment is more than twice as long as what I'm commenting on.
>
>Finally, if there is an update to this, change the copyright to 2008. ;)  Been there, done that, got the bounce.
>
>--