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

[Alfred Hönes <[e-mail]>]

On Oct 21 2009, Chris Thomson wrote:

> On Oct 21 2009, Andrew Sullivan wrote:
>
>> Dear colleagues,
>>
>> On Wed, Oct 21, 2009 at 05:54:18PM +1100, Mark Andrews wrote:
>>>
>>> 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.
>>
>> 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.
>
> We really need Alfred Hönes to comment on this, as he was the one who
> 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
> 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">

Good clarification.  Agreed.

>  <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.

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.

>  </t><t>
>       These rules also allow DNAME records to be queried through RFC 1034
>       <xref target="RFC1034" /> compliant, DNAME-unaware caches.
>
> --
> Chris Thompson               University of Cambridge Computing Service,
> Email: [e-mail]    New Museums Site, Cambridge CB2 3QH,
> Phone: [phone]       United Kingdom.


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+