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 | +------------------------+--------------------------------------------+
- [DNSOP] new draft about idn tld variants implemen… Yao Jiankang
- Re: [DNSOP] new draft about idn tld variants impl… Ray.Bellis
- Re: [DNSOP] new draft about idn tld variants impl… Andrew Sullivan
- Re: [DNSOP] new draft about idn tld variants impl… Mark Andrews
- Re: [DNSOP] new draft about idn tld variants impl… YAO Jiankang
- Re: [DNSOP] new draft about idn tld variants impl… Sebastian Castro
- Re: [DNSOP] new draft about idn tld variants impl… Mark Andrews
- Re: [DNSOP] new draft about idn tld variants impl… Alfred Hönes
- Re: [DNSOP] new draft about idn tld variants impl… Niall O'Reilly
- Re: [DNSOP] new draft about idn tld variants impl… Chris Thompson
- Re: [DNSOP] new draft about idn tld variants impl… Andrew Sullivan
- Re: [DNSOP] new draft about idn tld variants impl… Alfred Hönes
- Re: [DNSOP] new draft about idn tld variants impl… Chris Thompson
- Re: [DNSOP] new draft about idn tld variants impl… joao damas
- Re: [DNSOP] new draft about idn tld variants impl… YAO Jiankang
- Re: [DNSOP] new draft about idn tld variants impl… Paul Hoffman
- Re: [DNSOP] new draft about idn tld variants impl… YAO Jiankang