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

Alfred Hönes <ah@TR-Sys.de> Fri, 16 October 2009 17:16 UTC

Return-Path: <A.Hoenes@TR-Sys.de>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24BD53A68C1 for <dnsop@core3.amsl.com>; Fri, 16 Oct 2009 10:16:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.326
X-Spam-Level: **
X-Spam-Status: No, score=2.326 tagged_above=-999 required=5 tests=[AWL=1.075, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnCjlrjIZWPr for <dnsop@core3.amsl.com>; Fri, 16 Oct 2009 10:16:46 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 1A51F3A67B8 for <dnsop@ietf.org>; Fri, 16 Oct 2009 10:16:44 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA244753290; Fri, 16 Oct 2009 19:14:50 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id TAA01113; Fri, 16 Oct 2009 19:14:49 +0200 (MESZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <200910161714.TAA01113@TR-Sys.de>
To: cet1@cam.ac.uk
Date: Fri, 16 Oct 2009 19:14:48 +0200
In-Reply-To: <Prayer.1.3.2.0910161702100.21640@hermes-1.csi.cam.ac.uk> from Chris Thompson at Oct "16, " 2009 "05:02:10" pm
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 8bit
Cc: namedroppers@ops.ietf.org, dnsop@ietf.org
Subject: Re: [DNSOP] new draft about idn tld variants implementation
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Oct 2009 17:16:47 -0000

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

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
> others, certainly.)

True.

>
> A zone that *does* have a DNAME at the apex (and nothing else
> 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
> DNAME pulled up into that parent zone, *replacing* the
> delegation there. ...

This is just moot!

>               ... (I've got reverse zones I would love that
> to happen to, if only the parent zone administrators would
> co-operate...)

They are well advised to not do that!

>
> --
> Chris Thompson               University of Cambridge Computing Service,
> Email: cet1@ucs.cam.ac.uk    New Museums Site, Cambridge CB2 3QH,
> Phone: +44 1223 334715       United Kingdom.


Best regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| 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:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+