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/
- [dnsext] Autoconfiguration of variants George Barwood
- Re: [dnsext] Autoconfiguration of variants Doug Barton