[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