Subject: [dnsext] Re: DNAME-bis issues (was: [DNSOP] new draft about idn tld variant implementation)

From: Chris Thompson <[email-masked]>
Date: 19 Oct 2009 19:36:22 +0100

[I sent this response to Andrew's posting to namedroppers on Friday,
but it seems to have been lost completely in this weekend's troubles
with the mailing list. Ah well, it gives me a chance to correct and
expand it a bit this time ...]

On Oct 16 2009, Andrew Sullivan wrote:

>As near as I can tell, the problem is that the current draft makes an
>explicit claim that DNAME is not allowed on the parent side of zone
>cuts, and there is reason to believe that existing implentations have
>no trouble with child-side DNAMEs, so this would be a protocol change.

No-one (I hope) is claiming that a DNAME can exist on the parent side
of a cut, in the sense of coexisting with delegation (i.e. non-apex)
NS records.

This came up while discussing draft-yao-dnsop-idntld-implementation-00.txt.
There are two proposals being compared:

  ; In the root zone
  xn--314159. NS ...some nameserver...
              NS ...other nameservers...
  xn--217182. NS ...some nameserver...
              NS ...other namesevers...

versus

  ; In the root zone
  xn--314159. NS ...some nameserver...
              NS ...other namesevers...
  xn--217182. DNAME xn--314159.

Alfred said essentially (I hope I am not misrepresenting him) "You can't
use the second variant, because DNAMEs have to be at the zone apex. You
have to delegate and then put the DNAME at the apex of the child zone."

My claim is that is not the intention of the draft, or (as the lawyers say)
in the alternative that it is, it's grossly incompatible with RFC 2672.
with deployed code, and with existing DNAME records.

But if I am right in thinking that was not the intention of the draft,
then the fact that it could be misinterpreted that way is fairly serious.
I can certainly see that section 2.3 taken in isolation could be confusing.
I would suggest replacing "DNAME Apex" by "DNAME Owner Name" in the section
title, and the second paragraph by

   If a DNAME record is present at the zone apex, there is still is a need
   to have the customary SOA and NS resource records there as well. This
   means that a DNAME cannot be used to mirror a zone completely, as it
   does not mirror the zone apex.

Should I declare an interest? We use DNAMEs in parts of our reverse lookup
tree, and some of them are very definitely not at a zone apex.

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 20 Oct 2009 01:44:44 +0000

> Date: 19 Oct 2009 19:36:22 +0100
> From: Chris Thompson <[email-masked]>
> ...

+1.

> then the fact that it could be misinterpreted that way is fairly serious.

+1.

---

From: "Health" <[email-masked]>
Date: Wed, 21 Oct 2009 14:12:28 +0800

----- Original Message ----- 
From: "Chris Thompson" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, October 20, 2009 2:36 AM
Subject: [dnsext] Re: DNAME-bis issues (was: [DNSOP] new draft about idn tld variant implementation)

>  xn--217182. DNAME xn--314159.

do you mean that the following records can work or not in the root server?

>  xn--217182. DNAME xn--314159.

I has a little confused by the following comments.

Could you help me to clarify it?

Thanks a lot.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 21 Oct 2009 17:54:18 +1100

DNAME's placement is the same as any ordinary resource record (e.g.
MX, TXT).  There is nothing special about where DNAME can or can't
be used.

This is perfectly legal.

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

---

From: Paul Vixie <[email-masked]>
Date: Wed, 21 Oct 2009 11:33:37 +0000

> From: Mark Andrews <[email-masked]>
> Date: Wed, 21 Oct 2009 17:54:18 +1100
> 
> DNAME's placement is the same as any ordinary resource record (e.g.  MX,
> TXT).  There is nothing special about where DNAME can or can't be used.

+1.

> xn--217182. DNAME xn--314159.

legal, but unlikely.  rather, we'd see:

	XX.         NS ...some nameserver...
	            NS ...other namesevers...
	xn--217182. DNAME xn--314159.XX.

or:

	XX.         NS ...some nameserver...
	            NS ...other namesevers...
	xn--217182. DNAME XX.

that is, the existing NS would continue to be associated with an existing
CCTLD, and the DNAME will point to that or to some subdomain under that.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 21 Oct 2009 09:37:36 -0400

Dear colleagues,

> MX, TXT).  There is nothing special about where DNAME can or can't

While that is true, quite plainly the current dname-bis draft doesn't
leave everyone with that impression.  We need proposed text to make
the intent clearer.  Can someone please propose it?  Given the
emergence of this issue, the document is clearly not ready for
advancement, and it needs to be fixed before we send it on.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Chris Thompson <[email-masked]>
Date: 21 Oct 2009 16:30:35 +0100

>advancement, and it needs to be fixed before we send it on.

We really need Alfred Hönes to comment on this, as he was the one who
acquired the wrong impression. My feeling is that the confusion is
confined to section 2.3, and I would now suggest the following:

--- draft-ietf-dnsext-rfc2672bis-dname-17.xml	Wed Oct 21 16:17:14 2009
+++ draft-ietf-dnsext-rfc2672bis-dname-17a.xml	Wed Oct 21 16:19:51 2009
@@ -214,7 +214,7 @@
 	for the YXDOMAIN (value 6) RCODE.
 	</t>
 </section>
-<section title="DNAME Apex not Redirected itself">
+<section title="DNAME Owner Name not Redirected itself">
 <t>
 	Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its
 	owner name; the owner name of a DNAME is not redirected itself.
@@ -224,9 +224,10 @@
 	DNAME RRs are not allowed at the parent side of a delegation point 
 	but are allowed at a zone apex.
 </t><t>
-	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.
+	If a DNAME record is present at the zone apex, there is still a need
+	to have the customary SOA and NS resource records there as well. Such
+	a DNAME cannot be used to mirror a zone completely, as it does not
+	mirror the zone apex.
 </t><t>
 	These rules also allow DNAME records to be queried through RFC 1034
 	<xref target="RFC1034" /> compliant, DNAME-unaware caches.

---

From: Alfred Hönes <[email-masked]>
Date: Wed, 21 Oct 2009 21:57:42 +0200 (MESZ)

On Oct 21 2009, Chris Thomson wrote:

> acquired the wrong impression.  ...

I'll try, also elaborating on thoughts only exchanged off-list
so far (last week).

First my apologies for not being able to return to this discussion
earlier.  And maybe I was a bit overshooting in the first instance,
too much focussed on the aspects I try to clarify below.

Let me first discuss the more generic questions underlying the
'variant' domain (TLD or other) draft and discussion.

The basic topic where we started from last week is a delegation.
With regard to the root zone (and any other "registry-like" zone),
"owner" and "delegation" are not only technical terms related to DNS
database and protocol details, but also are contractual and legal
terms, and so a lot of care needs to be taken in using these terms.

This has repercussions to the protocol and database layer; for
instance, in a DNSSEC signed zone the owner of the zone will sign
the records there, and will be kept accountable for their content.

For brevity, I'll designate the discussed "DNAME at the root" as an
instance of a "pseudo-delegation" below (vs. "normal" delegation).

For a "normal" delegation, the NS RRset in the delegating zone
indeed is owned (in the legal sense!) by the parent zone owner;
it is subject to the contractual relationship between the owner
of the parent zone and the owner of the delegated zone.  The
NS RRset at the zone cut is handed over to the parent zone in
a technical, contractual and legal sense.  (Note that the owner
of a zone is free to publish a different NS RRset for the zone
at the apex of the zone itself than what he has handed over to
the parent -- but he should strongly consider the consequences.)
Hence, consistently DNSSEC signs the delegation NS RRs in the
parent zone and thereby documents the legal ownership as well.
Consequently, any other RRs for the delegated zone, if copied
into the parent zone are not signed under DNSSEC there --
independent of their use as "glue" RRs in the narrow sense
(address RRs for the name servers specified in the delegating
NS RRs) or not.

Since with DNAME queries for the owner name (technical!) of a
DNAME RR will be answered from the zone where that DNAME RR is
located, any other RRs with the same owner (technically!) name
must be co-located in the same zone and hence fall technically
under the authority (legally) of the owner (in legal terms) of
the parent zone.  This is entirely consistent with DNSSEC signing
authority for all RRsets at the owner name (technically) of the
DNAME RR being with the owner (legally and technically) of the
'hosting' zone of the DNAME RR.

Many owners (legally) of TLDs and other "registry-like" zones
place various RRs not directly related to the delegation (in
the technical sense) at the zone apex for the delegated zone.
For instance, I've seen TXT and NAPTR RRs recently there,
but other RR types might be likely too.

In the case of a 'pseudo-delegation' with DNAME in the parent
zone these RRsets all would need to be stored in the latter,
for instance in the root zone.  Without DNSSEC, doing so and
maintaining these RRs might be regarded as an O&M issue that
could be organized on a contractual base, overriding to some
extent the basic legal split of responsibility.  But with a
DNSSEC signed parent zone, the sibling RRsets of the DNAME
would become subject of the parent zone signing policy and
practice; I seriously doubt that this would be practical;
furthermore, it is likely that the DNSSEC signature over such
RRsets would be taken under some legislation as a strong sign
of ownership and hence accountability of the parent zone owner
for the content of these RRsets.  This seems to be in perfect
accordance with the DNSSEC trust model.

Even more, the user of an 'alias' domain name will want to gain
full legal authority of this name and consequently also will be
held accountable for it; delegating registration-like domains
will most likely not want to become accountable for these names.
For a 'normal' delegation, there's a visible 'proof' of ownership
for the delegation by the SOA RR at the apex of the delegated zone,
which might legally serve as a strong indication of ownership of
the delegation -- there's a pointer to "layer 8 and above" in the
SOA in the form of the RNAME element in the SOA RDATA.
A DNAME RR however does not carry such link to higher layers.
Therefore, 'pseudo-delegations' via DNAME will most likely not be
regarded as delegations of ownership, authority and accountability
in the legal sense.

All these complications do not arise if the owner (technically) of
a DNAME RR is owned (legally) by the same administrative entity as
the TARGET domain of the DNAME.

Thus, it look like to avoid administrative, operational, and legal
issues with DNAME, it seems to be evident that 'pseudo-delegations'
are inappropriate for cases where the semantics of a true delegation
(in the legal sense) is inherent and/or intended.  This is obviously
not the case in certain company-internal structured zones, where
the ownership and authority for both domains related to a DNAME are
within a single administrative domain, and most likely equally
in many regions of the reverse DNS trees.

So the terse rule of thumb might be:  'normal' delegations are for
cases where the semantics of a (plain English etc.) delegation is
expected, 'pseudo-delegations' can be used where the semantics of
a "hint" or "shortcut" prevails.

Back from the 'variant' domain arguments to the protocol specification
undergoing revision (I-D.dnsext-rfc2782bis-dname):

>                            ... My feeling is that the confusion is

Good clarification.  Agreed.

>       owner name; the owner name of a DNAME is not redirected itself.

Good.  Maybe even better (arrow lines tagging proposed changes):
                                        v
> +     If a DNAME record is present at a zone apex, there is still a need
> +     to have the customary SOA and NS, and perhaps other resource records
                                        ^^^^^^^^^^^^^^^^^^^
> +     there as well. Such a DNAME cannot be used to mirror a zone
> +     completely, as it does not mirror the zone apex.

>       <xref target="RFC1034" /> compliant, DNAME-unaware caches.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 22 Oct 2009 12:03:31 +0100

> +++ draft-ietf-dnsext-rfc2672bis-dname-17a.xml    Wed Oct 21 16:19:51 2009

	+1

	+1,

	but I think the sentence before the Chris's proposed update
	is also a possible source of confusion.  I'm thinking of what
	text to send.

--	
Niall O'Reilly
University College Dublin IT Services

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 22 Oct 2009 12:36:44 +0100

>     is also a possible source of confusion.  I'm thinking of what

	The phrase, "parent side of a delegation point" seems to have
	been introduced without definition, even though the established
	term, "zone cut" seems equivalent.

	I suggest replacing

DNAME RRs are not allowed at the parent side of a delegation
point but are allowed at a zone apex.

	by

A DNAME RR is not allowed in conjunction with an NS record except
at the apex of a zone.

	or else

A DNAME RR may not have the same owner name as an NS record except
at the apex of a zone.

	IHTH

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 22 Oct 2009 16:50:57 -0400

Dear colleagues,

> 'variant' domain (TLD or other) draft and discussion.

[. . .]

> undergoing revision (I-D.dnsext-rfc2782bis-dname):

I'd like to keep these two topics distinct, please.  The legal and
political (in the broad sense, like "policy") ramifications of using
DNAME are not really on-topic for DNSEXT, so let's try to separate the
two discussions.

Thanks,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.