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

Mark Andrews <marka@isc.org> Fri, 16 October 2009 05:32 UTC

Return-Path: <marka@isc.org>
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 D70BA3A67F3 for <dnsop@core3.amsl.com>; Thu, 15 Oct 2009 22:32:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 MRl7N2FkPYWQ for <dnsop@core3.amsl.com>; Thu, 15 Oct 2009 22:32:46 -0700 (PDT)
Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) by core3.amsl.com (Postfix) with ESMTP id C82893A6782 for <dnsop@ietf.org>; Thu, 15 Oct 2009 22:32:45 -0700 (PDT)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id D438EE6059; Fri, 16 Oct 2009 05:32:46 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id n9G5WgS0036223; Fri, 16 Oct 2009 16:32:42 +1100 (EST) (envelope-from marka@drugs.dv.isc.org)
Message-Id: <200910160532.n9G5WgS0036223@drugs.dv.isc.org>
To: Sebastian Castro <sebastian@nzrs.net.nz>
From: Mark Andrews <marka@isc.org>
References: <004a01ca4d9a$9b866920$63c0ab73@YaoJK> <20091015204405.GJ6184@shinkuro.com> <4AD7FC8E.40202@nzrs.net.nz>
In-reply-to: Your message of "Fri, 16 Oct 2009 17:54:38 +1300." <4AD7FC8E.40202@nzrs.net.nz>
Date: Fri, 16 Oct 2009 16:32:42 +1100
Sender: marka@isc.org
Cc: 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 05:32:46 -0000

In message <4AD7FC8E.40202@nzrs.net.nz>, Sebastian Castro writes:
> Andrew Sullivan wrote:
> > Dear colleagues,
> 
> Dear colleagues,
> 
> my reply to Andrew inline (I don't cover all points tho)
> 
> > 
> > 
> > (3) is not, so far, an argument we have been hearing from the root
> > nameserver operators.  But in any case, this is a load and
> > provisioning issue, and is not an argument that can properly be made
> > about whether a given technology as such should be selected for a
> > given purpose.  It is rather a consideration that needs to be taken
> > into account when someone makes a decision to support variant labels.
> > It is an important operational consideration, and operational
> > constraints have to be taken into account when making deployment
> > decisions.  That's an issue to be debated in the root server
> > operators' fora, or at ICANN, but not here I think.
> 
> I think it's a valid concern about the load at the root servers and
> agree it doesn't correspond here to discuss it. If ICANN/root_operators
> decide to implemente the IDN TLD variants by using DNAME, every query
> for a name under the variant will go to the roots.

No they won't, only non-DNAME aware resolvers will go back to the
roots.  DNAME aware resolvers will perform the synthesis locally
using the cached DNAME.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org