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

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

On 16 Oct 2009, at 19:14, Alfred HÎnes wrote:
> 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.
>

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

---

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

On Oct 16 2009, Alfred Hönes wrote:

>On Oct 16 2009, Chris Thompson wrote:
>
>> On Oct 16 2009, Alfred Hönes wrote:
>>
>>> 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.
>>
>> 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.
>
>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) :
>

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

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

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.

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