[dnsext] draft-diao-aip-dns

Fred Baker <fred@cisco.com> Mon, 18 June 2012 20:17 UTC

Return-Path: <fred@cisco.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B168921F854A for <dnsext@ietfa.amsl.com>; Mon, 18 Jun 2012 13:17:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.156
X-Spam-Level:
X-Spam-Status: No, score=-108.156 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PabqL+vsasRd for <dnsext@ietfa.amsl.com>; Mon, 18 Jun 2012 13:17:35 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8F93421F8549 for <dnsext@ietf.org>; Mon, 18 Jun 2012 13:17:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=4228; q=dns/txt; s=iport; t=1340050655; x=1341260255; h=mime-version:subject:from:date:cc:message-id:to: content-transfer-encoding; bh=icZbRm09ZulVi0ly4KuBNqcommgtWvTDb5sGiDADtsc=; b=UzHVkx+iFIjtHqK7qA/WRs037Gf1l0v3H975feDNTwZNolPdQdSkOWc1 +aaEupsqurxTF4qOvhj1Lgklwd4yBMQnhVdUhbEjkKLkas/eLbPNaFdfi PF4sueY7Hz/ybMZhKaCaTTKEgbtrMSa508xTkz9nXW9TsmAydNFHJh0wS k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AskhAGiM30+rRDoI/2dsb2JhbABFtEKBLIEHgjEBJw8wgXOFb4F5mGaPE5Bbi1GFQWADiEKMYoVUiEOBZoMAgT8
X-IronPort-AV: E=Sophos;i="4.75,793,1330905600"; d="scan'208";a="49318129"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 18 Jun 2012 20:17:34 +0000
Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5IKHXAj028110; Mon, 18 Jun 2012 20:17:33 GMT
Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Mon, 18 Jun 2012 13:17:34 -0700
X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Mon, 18 Jun 2012 13:17:34 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker <fred@cisco.com>
Date: Mon, 18 Jun 2012 13:17:28 -0700
Message-Id: <C239EA2E-41E9-4719-A3C7-AE0B8A9A1FE9@cisco.com>
To: draft-diao-aip-dns@tools.ietf.org
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 18 Jun 2012 13:20:25 -0700
Cc: dnsext@ietf.org
Subject: [dnsext] draft-diao-aip-dns
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jun 2012 20:17:36 -0000

This is a resend, copying the right list.

I'm reading draft-diao-aip-dns, and wonder what the context is. Is this related to the BRICI proposal in WCIT, for support for a DNS root modeled on the International Calling Code structure of the telephone system?

My concern is for the possibility of disruption to Internet communications. If a country (or for that matter a business that simply decides to sell access to its own autonomous root) acts autonomously and unilaterally to add a TLD, other countries/services may or may not know about it, and the names may therefore not be usable in any context other than the country/service itself. If DNS resolution of names that are not from the country/service in question are forced to channel through the autonomous root, there are "interesting" questions of scale.


Comments on the paper itself:

The Introduction opens with the sentence

  Internet Domain Name System (DNS) distributes domain name and IP      
  address for the host on the Internet. DNS automatically translates    
  the domain name into IP address when user accesses Internet using     
  domain name. 

I would dispute that. The DNS enables a client to obtain a resource record from a name service; the resource record might be for an IPv4 or IPv6 address (A/AAAA), for the name of one or more mail servers (MX), an encryption/signature key, or a variety of other types of information.

In section 3.2, if I understand the document correctly, the document proposes to use recursive DNS access between AIPs. I have no problem with recursive translation; it is defined and works now. However, it would appear that this recursive translation happens between AIP DNS roots, as opposed to happening from a DNS server closer to the original request. I think that is likely to have serious scaling issues.

One general comment on sentence structure: in English, it is considered poor form to start a sentence with "And". For example

                                And any IP node's external domain     
  name is consist of its internal domain name and its AIP network       
  default domain name suffix.    

should read

                                  Any IP node's external domain     
  name consists of its internal domain name and its AIP network       
  default domain name suffix. 

While the specific point is a nit, I see it frequently in the paper.

I'm not sure I understand rule 3 in section 2.2. If, for example, I am in a Chinese AIP and want to access www.example.com, but I want to get to the one that would be accessible from Brazil, do I access "www.example.com", "www.example.com.ex", www.example.com.br.ex", or something else? Is there any reason to believe that the resource record for www.example.com within the AIP is the same as the one for the same name in some other AIP? I worry about that, as much as anything, because international business and communication depends on a common understanding of resource records; if a vendor in country A wants to make a product or service available to a potential customer in country B (or for that matter in all countries), it gives one URI/URL to all of them and they all have access to it. If there is significant confusion at this level, sending for example requests intended for Google to Baidu, it will have a significant and negative effect on international business and communications. That not only doesn't bode well for the Internet as an international communication vehicle, it portends poor economic results for the countries that deploy autonomous internets.


Last time China proposed this (October 2000), John Klensin and I flew to Beijing to discuss it with Professor Qian Hua-lin. He agreed that the economic importance of international trade far outweighed the value of having an autonomous naming system...

Could you comment on the proposal, explaining in more detail what you have in mind, and how (a) the service remains scalable, and (b) the service supports the international objectives of business interests that use it?