Subject: Re: [DNSOP] new draft about idn tld variants implementation

From: Alfred Hönes <[email-masked]>
Date: Fri, 16 Oct 2009 16:48:53 +0200 (MESZ)

Another point:

The draft is speaking abut "DNAME _in_ the root".

According to my surficial knowledge, DNAME RRs 'live'
at the _apex_ of the zone that shall be redirected, not
at the delegation point -- or did I miss something?
Within each zone, there may be at most one DNAME RR,
and if so, it must be at the apex of the zone.

So if you have a variant TLD, this variant would need to be
delegated from the root zone (via NS RRs as usual) anyway, and
the owner / DNS operator of the delegated variant TLD (ICANN
should perhaps ensure that's the same one as for the 'original'
TLD!) simply publishes a tiny zone with the DNAME RR.
>From the point of view of the root zone, there's no difference
in the 'look and feel' of an 'original' TLD and a variant TLD.
Most likely however, the name servers for the variants would
be the same as for the basic TLD.

But the owner / DNS operator of the 'original' TLD and its
variants is entirely free to manage the equivalence of these
domains in any feasable way, one of it being DNAME; however,
if they have server software that can perform the aliasing
'on the fly' from a database, they could use that.
It is a contractual matter between ICANN and the TLD owner
to ensure that the equivalence is maintained under all
circumstances, not a DNS protocol issue.

Or is it the intent to have the variant TLS zones all be
served by the root servers as well, to which you oppose ?
I've not heard about such proposal, but admittedly I did
not care much about such questions in the past.

If ICANN would decide to have the DNAME-based variant TLD zones
(those tiny zones with only the SOA, the DNAME, and maybe a few
other RRs) be served within the root server organization, they
would not necessarily have to do that with the original root
servers; they also could deploy additional servers for this
purpose and delegate the variant TLDs to these servers.
Even if the variant zones were to be served by the original
root servers, there would have to be delegations (to the same
servers) via NS RRs, insn't it?

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: Fri, 16 Oct 2009 16:43:48 +0100

> and if so, it must be at the apex of the zone.

	I'm strongly inclined to respect the instinct behind this
	reaction from Alfred, but ...

	My (far more!) superficial knowledge is at variance with his.

	The reverse DNS for my domestic IPv6 /48 is actually
	pseudo-delegated using a DNAME record in the 'parent' zone.

	The idea of using DNAME only at the apex makes sense, and
	may well be what will emerge as best practice, but I don't
	believe it's yet in any rule book.

	Best regards,

	/Niall

---

From: Chris Thompson <[email-masked]>
Date: 16 Oct 2009 17:02:10 +0100

>and if so, it must be at the apex of the zone.

That's just wrong. DNAMEs can occur anywhere within a zone
(including at the apex, but not restricted to it), and there
can be as many as you like within a zone, subject only to the
constraint that no RR has a name subordinate to that of a DNAME.
(So *if* you have one at the apex, *then* you can't have any
others, certainly.)

A zone that *does* have a DNAME at the apex (and nothing else
but SOA and NS records) is positively crying out to have the
DNAME pulled up into that parent zone, *replacing* the
delegation there. (I've got reverse zones I would love that
to happen to, if only the parent zone administrators would
co-operate...)

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

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 16 Oct 2009 19:14:48 +0200 (MESZ)

> constraint that no RR has a name subordinate to that of a DNAME.

I don't think so.

Here's a full section from  draft-ietf-dnsext-rfc2672bis-dname-17
(expected to be shipped to the IESG soon) :

2.3.  DNAME Apex not Redirected itself

   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.  The
   domain name that owns a DNAME record is allowed to have other
   resource record types at that domain name, except DNAMEs, CNAMEs or
   other types that have restrictions on what they can co-exist with.
|> DNAME RRs are not allowed at the parent side of a delegation point
|> but are allowed at a zone apex.

   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.

   These rules also allow DNAME records to be queried through RFC 1034
   [RFC1034] compliant, DNAME-unaware caches.

That's been uncontroversial consensus in DNSEXT, with full support
of DNS implementers, IIRC.
The last paragraph is at the heart of the matter,
and it should mitigate the concerns in the tld-variant draft!

> (So *if* you have one at the apex, *then* you can't have any

True.

> but SOA and NS records) ...

... or TXT or whatever you like or need -- don't forget DNSSEC RRs!

>                     ... is positively crying out to have the
> delegation there. ...

This is just moot!

>               ... (I've got reverse zones I would love that

They are well advised to not do that!

Best regards,
  Alfred.

--

---

From: Chris Thompson <[email-masked]>
Date: 16 Oct 2009 19:15:23 +0100

>2.3.  DNAME Apex not Redirected itself

The term "DNAME Apex" occurs nowhere else in the document, and is
perhaps rather unfortunate. I've always assumed it was meant to be
the same as "DNAME owner name" as in the text below, and certainly
not equivalent to "zone apex".

>|> but are allowed at a zone apex.

"Allowed at a zone apex" != "Must be at the zone apex".

(And of course lifting a DNAME into the parent zone must *replace* the
delegation, not co-exist with it.)

>   [RFC1034] compliant, DNAME-unaware caches.

Not allowing DNAMEs except at the zone apex would be grossly incompatible
with RFC 2672 itself (see the example in section 5.2) and with deployed
code. I cannot imagine it was the intent of the draft to make such a
change without a highly explicit statement to that effect. (Nor do I
see any reason to make such a change.)

I guess this had better be continued on namedroppers rather than dnsop.

---

From: joao damas <[email-masked]>
Date: Sat, 17 Oct 2009 11:21:56 +0200

> |> but are allowed at a zone apex.

What this says is that if you use a DNAME at the parent it must  
replace the delegation. It does not say that the DNAME can't be in the  
parent.

The real issue that needs attention here is an operational one: the  
extra load at the root servers derived from the need to do CNAME  
synthesis for a percentage of the queries. This has a provisioning  
side which would be good to quantify and an implementation efficiency  
side, which could be addressed by ICANN throwing money at implementers  
to optimise that part if DNAME is the choice for IDN variant  
implementation at the root.

Joao