Subject: Re: DNAME and non-fragmented, non-A6 reverses [Re: [dnsop] WG Last Call: draft-ietf-dnsop-ipv6-dns-issues-04.txt]

From: Masataka Ohta <[email-masked]>
Date: Wed, 07 Apr 2004 20:38:59 +0900

Mark Andrews wrote:

> 	DNAME does NOTHING more that allow the server to synthesis
> 	CNAMEs.

Mass CNAME synthesis can, and thus MUST, be performed purely
locally within a server as a minor zone file syntax change
without any protocol changes.

>       When you also call for CNAMEs to be removed I will
> 	believe you are being honest in wanting DNAMEs to be removed.

See above.

						Masataka Ohta

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 07 Apr 2004 21:32:46 +0900

> 	Well when you have a server that can load 18446744073709551616
> 	CNAME records require to replace 1 DNAME record at the /64
> 	level please let me know.

A sane implementers simply load 1 instance of specific syntax
as a directive to synthesis 18446744073709551616 or more possible
CNAME records.

During the transition period to obsolete DNAME, implementers
are encouraged let DNS servers interprete "DNAME" as such a
directive.

						Masataka Ohta

.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 12 Apr 2004 07:03:50 +0900

Mark Andrews;

> 	Please describe how to transfer this directive between
> 	servers for the zone?  Then please demonstrate that it is
> 	more effective that DNAME and demonstrate how to support
> 	DNSSEC validation of the syntesised records without the use
> 	of a online key.  You are free to add protocol support to
> 	DNSSEC to achieve the later.

I forgot the details of DNAME. Sorry.

Mass CNAME synthesis can, and thus MUST, be performed purely
locally (both at the dereference and reffered locations)
within servers as a minor configuration file syntax functionality
without any protocol changes.

That is, use NS for mass redirection and use included files
with zone relative notations.

						Masataka Ohta

.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 16 Apr 2004 16:46:46 +0300 (EEST)

On Fri, 16 Apr 2004, Mark Andrews wrote:
> > There haven't been as many replies as I'd have hoped for, but I think 
> > there is slight preference towards rewording to not say much of 
> > anything about DNAME, along the lines of:
> > 
> >         <t>In particular one should note that the use of A6 records in
> > the forward tree or Bitlabels in the reverse tree is not recommended
> > <xref target="RFC3363"/>.  Using DNAME records is not recommended in
> > the reverse tree in conjunction with A6 records; the document did not
> > mean to take a stance on any other use of DNAME records <xref 
> > target="RFC3364"/>.</t>
> > 
> > Or do we have proposals for different kind of wording?  If so, please
> > send it ASAP.
> 
> 	
> 	Lets be consistant w/ draft-ietf-ipv6-node-requirements-08.txt.
> 	All references to DNAME were removed in the last draft there.
> 
> 	See Section 5.2
> 
>    Those nodes are NOT RECOMMENDED to support the experimental A6 and
>    DNAME Resource Records [RFC-3363].

I'm fine with saying DNAME support is not recommended.  But did I 
misunderstand you -- as this appears to exactly the opposite to what 
you've said in the past?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

.

---

From: Pekka Savola <[email-masked]>
Date: Sun, 18 Apr 2004 11:35:54 +0300 (EEST)

On Sun, 18 Apr 2004, Mark Andrews wrote:
> 	The use of DNAME has always been *independent* of whether
> 	A6/AAAA or nibble/Bitlabels are in use.  The choice to use
> 	DNAME is driven by neither of these.  It will be driven by
> 	the need to shift a heirachy of zones without having to
> 	redelegate the entire heirachy.

I think the current text:

   In particular one should note that the use of A6 records in the
   forward tree or Bitlabels in the reverse tree is not recommended [2].
   Using DNAME records is not recommended in the reverse tree in
   conjunction with A6 records; the document did not mean to take a 
   stance on any other use of DNAME records [5].

is good, because it clarifies the intent.  Removing it would be worse.
Do you agree?

.

---

From: Pekka Savola <[email-masked]>
Date: Sun, 18 Apr 2004 13:44:08 +0300 (EEST)

On Sun, 18 Apr 2004, Mark Andrews wrote:
> 	No.  You are doing the same thing RFC 3363 did.  You are
> 	placing a restriction on DNAME that SHOULD NOT BE THERE.
> 	There is no reason to place any restriction on DNAME.

Read it again; it says:

 Using DNAME records is not recommended in the reverse tree in
    conjunction with A6 records; 

(this is what RFC3363 meant to say about DNAME's, I was told)

                            the document did not mean to take a
    stance on any other use of DNAME records [5].

(clarifies that RFC3363 didn't mean to restrict DNAME's in any other
way.)

Based on this, I do not think there is consensus to change this 
at all.

.