Re: [dnsext] Autoconfiguration of variants

Doug Barton <> Wed, 09 March 2011 00:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B69243A67D2 for <>; Tue, 8 Mar 2011 16:17:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.557
X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8X4k6XIfjOtg for <>; Tue, 8 Mar 2011 16:17:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6EBD13A67AB for <>; 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 (HELO ? ( by with ESMTPAM; 9 Mar 2011 00:18:38 -0000
Message-ID: <>
Date: Tue, 08 Mar 2011 16:18:38 -0800
From: Doug Barton <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: George Barwood <>
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
Subject: Re: [dnsext] Autoconfiguration of variants
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

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.
> |
> (2) An application ( say a web server ) that is configured to handle
> 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.
> VARIANTS[-]big[-]

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.



	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.  :)