[dnsext] common resources from multiple names, sustaining performance and identifying primary names
Douglas Otis <dotis@mail-abuse.org> Wed, 15 September 2010 01:44 UTC
Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 877253A6846; Tue, 14 Sep 2010 18:44:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.297
X-Spam-Level:
X-Spam-Status: No, score=-106.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 MWV-k2xW01lM; Tue, 14 Sep 2010 18:44:28 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id CBB933A67E5; Tue, 14 Sep 2010 18:44:27 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1OvgvP-000LHZ-HI for namedroppers-data0@psg.com; Wed, 15 Sep 2010 01:36:39 +0000
Received: from harry.mail-abuse.org ([168.61.5.27]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from <dotis@mail-abuse.org>) id 1OvgvM-000LHG-Tg for namedroppers@ops.ietf.org; Wed, 15 Sep 2010 01:36:36 +0000
Received: from US-DOUGLASO-MB.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id AA5B0A94650 for <namedroppers@ops.ietf.org>; Wed, 15 Sep 2010 01:36:34 +0000 (UTC)
Message-ID: <4C902324.1020005@mail-abuse.org>
Date: Tue, 14 Sep 2010 18:36:36 -0700
From: Douglas Otis <dotis@mail-abuse.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3
MIME-Version: 1.0
To: IETF DNSEXT WG <namedroppers@ops.ietf.org>
Subject: [dnsext] common resources from multiple names, sustaining performance and identifying primary names
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>
While aliasing a name is how common resources seen from multiple names are normally handled, CNAME and the seldom used DNAME are not very suitable for renaming large portions of the name/resource tree. Resolvers that don't understand DNAME, and those that don't understand a new aliasing paradigm will then need each node replaced with synthesized CNAME records having 0 TTLs. It seems this approach on a large scale is likely to result in a significant performance reduction. Synchronizing (amber/shadow) zones could be something that virtualized name servers might accomplish, when given the necessary meta-information. While zone synchronization avoids the problematic performance issues that might be caused by new and pervasive aliasing, multiple zones will leave applications unable to identify which name is to be considered primary. Name consolidation onto a primary name and message path has the added benefit of obtaining higher cache hit rates and perhaps needing fewer certificates. When aliasing is used, a different answer-name from that of the query-name indicates the answer-name is the primary domain. There does not seem to be an analogue that might be used to discover which domain should be considered primary when amber/shadow zones are being used, nor does it seem possible to re-purpose the various xName aliasing resources. It should be possible for the zone cloning processes to include a primary domain resource that points to mirror points within the Amber zone. The amber zone could capture the mirror points as hash labels or resources holding signatures confirmed by the primary domain public key. The hash label technique, if eventually handled by the protocol, might be used to consolidate a large collection of resources as well. The definition of a primary name when using Amber/Shadow zones would need to be done using some type of meta language. This meta language would likely replace a BNAME construct (a DNAME that aliases itself.) While BNAMES would increase DNS agility when coping with a convoluted name space, it seems that this feature should not be the primary method used for introducing TLD and SLD domains when common resources are to be obtained from these domains. -Doug
- [dnsext] common resources from multiple names, su… Douglas Otis
- Re: [dnsext] common resources from multiple names… Mark Andrews