Re: [dnsext] Autoconfiguration of variants

Doug Barton <dougb@dougbarton.us> Wed, 09 March 2011 00:17 UTC

Return-Path: <dougb@dougbarton.us>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B69243A67D2 for <dnsext@core3.amsl.com>; Tue, 8 Mar 2011 16:17:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.557
X-Spam-Level:
X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 8X4k6XIfjOtg for <dnsext@core3.amsl.com>; Tue, 8 Mar 2011 16:17:28 -0800 (PST)
Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id 6EBD13A67AB for <dnsext@ietf.org>; Tue, 8 Mar 2011 16:17:27 -0800 (PST)
Received: (qmail 25478 invoked by uid 399); 9 Mar 2011 00:18:38 -0000
Received: from router.ka9q.net (HELO ?192.168.2.9?) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 9 Mar 2011 00:18:38 -0000
X-Originating-IP: 75.60.237.91
X-Sender: dougb@dougbarton.us
Message-ID: <4D76C75E.40503@dougbarton.us>
Date: Tue, 08 Mar 2011 16:18:38 -0800
From: Doug Barton <dougb@dougbarton.us>
Organization: http://SupersetSolutions.com/
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: George Barwood <george.barwood@blueyonder.co.uk>
References: <8E708CF867F54D02825E0E66A9861EB8@local>
In-Reply-To: <8E708CF867F54D02825E0E66A9861EB8@local>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dnsext@ietf.org
Subject: Re: [dnsext] Autoconfiguration of variants
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 09 Mar 2011 00:17:29 -0000

On 3/8/2011 2:58 PM, George Barwood wrote:
> I have not yet properly understood the CLONE draft, for which I
> apologise, but it seems to suffer from some technical issues.

Questions and/or suggestions for clarification are welcome of course. I
tried to keep the explanation of the concept simple, but strike a
balance on explaining the protocol elements with sufficient detail to
make my meaning clear. I'm certain that improvement is possible in both
areas.

OTOH, I think one of the nice thing about the CLONE approach is that it 
*is* simple. Either in the sense that it is too simple-minded to work, 
or so simply elegant that it is confounding. :)

> How about this approach:
>
> (1) A new RRTYPE that defines the aliases for a given domain.
>
> www.mybigbank.com. VARIANTS www.my-big-bank.com. |
> www.my-bigbank.com. | www.mybig-bank.com.
>
> (2) An application ( say a web server ) that is configured to handle
> www.mybigbank.com will on initialisation check the DNS for variants,
> and if they are defined, will automatically configure them.

So far you have not described anything that cannot be accomplished with 
the CLONES RR I'm proposing.

> (3) Authoritative DNS servers when they see a VARIANTS record will
> auto-configure the appropriate copy zones. For DNSSEC this needs to
> be handled during zone signing.

This sounds sort of like Paul's SHADOW idea. I have expressed 2 
reservations about this concept in the past. First I would prefer that 
we not limit a possible solution to the zone level. Second, how do you 
handle DNSKEYs for the variant zones?

> (4) Possibly for concise expression, instead of a simple list of
> domain names, some limited pattern matching might be allowed in the
> RDATA of the VARIANTS record, e.g.
>
> www.mybigbank.com. VARIANTS www.my[-]big[-]bank.com.

Potentially dangerous, but interesting. :)

> (5) Resolvers do not need updating.

I think your idea is interesting, but perhaps we would both benefit from 
a more thorough critique of the CLONE idea. I think we're both talking 
about similar things.


Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/