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

From: Pekka Savola <[email-masked]>
Date: Wed, 7 Apr 2004 12:49:18 +0300 (EEST)

I'm particularly interested in hearing what kind of opinions the WG 
has on this particular problem..

On Wed, 7 Apr 2004, Mark Andrews wrote:
> > Substantial (or not-so-editorial) comments:
> > 
> > 1. Section 1.1 (1.1 Representing IPv6 Addresses in DNS Records)
> > 
> >    In particular one should note that the use of A6 records, DNAME
> >    records in the reverse tree, or Bitlabels in the reverse tree is not
> >    recommended [2].
> > 
> > I think this is an overstatement about DNAME.  The text looks meaning
> > DNAME is not recommended *in any way* in the IPv6 reverse tree.  For
> > example, people would read this to mean it is discouraged to use DNAME
> > to manage both ip6.arpa and ip6.int zones as described in
> > http://www.isc.org/pubs/tn/isc-tn-2002-1.html

Yes.
 
> > But, in my understanding, the sense of the discussion in RFC3363 ([2])
> > is that DNAME in the reverse tree is deprecated for the reverse side
> > of the A6 usage.  That is, the usage for constructing multi-level,
> > hierarchal reverse trees, particularly with bitstring labels.

Chaining was indeed one important argument in the discussions.  I do 
not remember them in detail to be able to comment whether it was 
intentional to deprecate DNAME for all reverse usage or just with A6.  
IMHO, the document language:

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.  

[split by me]
                      Therefore, in moving RFC 2874 to experimental,
   the intent of this document is that use of DNAME RRs in the reverse
   tree be deprecated.

The first part *seems* indicate that at least when writing the 
document, there was no justified use for DNAME in the reverse tree.

However, this still does leave it open what's the case about
non-fragmented, non-A6 reverses (the scenario which Jinmei said).

And to that my feeling was that the implementation expense etc. of
DNAME is not really worth it in the non-fragmented scenario, and that
it might re-open problems we saw in A6 wrt. chaining.

> 	We should just reissue RFC3363 with *all* references to DNAME
> 	removed.  It continually causes problems.
[...]

First, I think there should be consensus that DNAME is a good thing, 
and it's OK to use it everywhere. :)

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

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

---

From: Jim Reid <[email-masked]>
Date: Wed, 07 Apr 2004 12:04:54 +0100

>>>>> "Masataka" == Masataka Ohta <[email-masked]> writes:

    Masataka> I think DNAME and bit labels MUST be obsoleted for
    Masataka> obvious reasons that they are useless and harmful.

I strongly disgaree with both your statement and the justification for
it. Please demonstrate how DNAME and bit labels are "useless and
harmful". DNAME has applications outside the reverse resolution of
IPv6 addresses: for instance in migrating old-domain-name to
new-domain-name. Bit labels are awful and very hard to use or
understand, but that's not an excuse to kill them. [DNSSEC is also
awful and hard to use or understand but nobody seems to want to kill
that.] IMO the status quo for DNAME and bit labels is just fine. IIRC
bit labels are now considered EXPERIMENTAL and so far a compelling
case hasn't been made to change that status.
.
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 20:23:19 +0900

Jim Reid wrote:

> [DNSSEC is also
> that.]

Huh?

It is also obviously useless and obviously harmful.

						Masataka Ohta

.

---

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

> has on this particular problem..

I think DNAME and bit labels MUST be obsoleted for obvious
reasons that they are useless and harmful.

						Masataka Ohta

.

---

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

Hi,

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.

I think this captures what Rob Austein clarified (as author RFC3354).

.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 19 Apr 2004 17:24:06 +0900

>>>>> On Fri, 16 Apr 2004 12:58:49 +0300 (EEST), 
>>>>> Pekka Savola <[email-masked]> said:

> Or do we have proposals for different kind of wording?  If so, please

Personally, I'm fine with this wording.  I think it reasonably
reflects the intention of RFC3363 (as Rob explained), and that's
enough for the dns-issues draft.  (Whether DNAME itself is a good or
bad thing or whether RFC3363 should be revised on this is a separate
issue from this draft, IMO).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html