Subject: RFC2672bis DNAME update document

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Mon, 12 Jun 2006 10:35:09 -0400

The chairs have recruited volunteers to take on this effort
They are:
	Matt Larson <[email-masked]>
	Wouter Wijngaards <[email-masked]>

Right now they are working on assembling a list off issues,
related to RFC2672 DNAME specification. If you have
issues/experiences with DNAME that you would like to see in the
initial list of issues, please send them a note, right now.

We need 5 people that speak up in response to this
note and between those people there is general consensus that this
document is a work item, If we do not consensus, we will ask the
editors to post this document as a personal submission first.
(We'd be sad if that would need to be the case.)

The editors will operate an public issue tracker for the document.

The process is a standard clarify process: Wouter and Matt are editors
reflecting the consensus of the working group.

The initial time line for this effort is to try to have the working
group finish this with this document by IETF 68 (March/2007).
At this point it is not clear if the resulting
document will be recycled at Proposed or be issued as a Draft standard.

	Olafur & Olaf 

--
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: Paul Vixie <[email-masked]>
Date: Mon, 12 Jun 2006 23:16:52 +0000

> 	The TTL of the synthesised CNAME is currently set at zero.
> 	There is no reason not to make the TTL of the CNAME match
> 	the TTL of the DNAME.  Doing so will reduce the load on
> 	the authoritative servers from non DNAME aware clients
> 	by allowing them to cache the CNAME name.

i agree.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 13 Jun 2006 09:21:08 +1000

We also need to refute this section of RFC 3363.

4.  DNAME in IPv6 Reverse Tree

   The issues for DNAME in the reverse mapping tree appears to be
   closely tied to the need to use fragmented A6 in the main tree: if
   one is necessary, so is the other, and if one isn't necessary, the
   other isn't either.  Therefore, in moving RFC 2874 to experimental,
   the intent of this document is that use of DNAME RRs in the reverse
   tree be deprecated.

	And this section of RFC 4294 which was supposed to have
	dropped all reference to DNAME.  I thought I had clobbered
	it but missed that it had not been removed when the next
	draft came out (months later).  See the thread starting:
	http://www1.ietf.org/mail-archive/web/ipv6/current/msg01689.html

   Those nodes are NOT RECOMMENDED to support the experimental A6 and
   DNAME Resource Records [RFC-3363].

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]