IETF Logo Mail Archive

Re: [dnsext] Name equivalence: Another no protocol change solution

Alex Bligh <alex@alex.org.uk> Mon, 13 September 2010 16:23 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 380F13A6A0A; Mon, 13 Sep 2010 09:23:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.615
X-Spam-Level:
X-Spam-Status: No, score=-1.615 tagged_above=-999 required=5 tests=[AWL=0.984, 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 G3zAM6FdRNsv; Mon, 13 Sep 2010 09:23:14 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E3BE13A69F5; Mon, 13 Sep 2010 09:23:13 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1OvBlQ-000Jfx-C0 for namedroppers-data0@psg.com; Mon, 13 Sep 2010 16:20:16 +0000
Received: from mail.avalus.com ([89.16.176.221]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <alex@alex.org.uk>) id 1OvBlN-000Jff-AZ for namedroppers@ops.ietf.org; Mon, 13 Sep 2010 16:20:13 +0000
Received: from [192.168.100.15] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id CD882C56964; Mon, 13 Sep 2010 17:20:11 +0100 (BST)
Date: Mon, 13 Sep 2010 17:20:11 +0100
From: Alex Bligh <alex@alex.org.uk>
Reply-To: Alex Bligh <alex@alex.org.uk>
To: Niall O'Reilly <Niall.oReilly@ucd.ie>
cc: namedroppers@ops.ietf.org, Alex Bligh <alex@alex.org.uk>
Subject: Re: [dnsext] Name equivalence: Another no protocol change solution
Message-ID: <9C2DE15E0F640A9D041DD421@Ximines.local>
In-Reply-To: <4C8E4B65.5030402@ucd.ie>
References: <C0F55485EA77FDF78E9B0398@Ximines.local> <4C8E266D.3070702@ucd.ie> <952FA12530B5693E36B03554@Ximines.local> <4C8E399F.8090300@ucd.ie> <C1D6C4E4CDAB83BE68BE10B0@Ximines.local> <4C8E4B65.5030402@ucd.ie>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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/>

--On 13 September 2010 17:03:49 +0100 Niall O'Reilly <Niall.oReilly@ucd.ie> 
wrote:

>>>> If we are talking about label multiplicity, i.e.
>>>>      a1.b1.c1.d1
>>>> and
>>>>      an.bn.cn.dn
>>>> are equivalent for all values of n, thus creating an O(n^k)
>>>> problem, then DNAME solves this to the extent it is used.
>>>
>>>     Unless a subsidiary zone apex (for example, 'c' above
>>>     might be delegated from 'b') needs data other than
>>>     a DNAME.
>>
>> I must be missing something. How can c be delegated from b?
>
> 	D'oh!
> 	You're not.  I'm sorry.  I meant b from c.
>

OK, that is less confusing!

So you mean:

$ORIGIN c1.d1.
	b2	IN DNAME b1.c1.d1.
	b1	IN NS ns.example.com.

or do you mean glue records with the DNAMEd zone:	
	b2	IN DNAME b1.c1.d1.
	b1	IN NS ns.b2.c1.d1.
	ns.b2.c1.d1.	IN	A	192.0.2.2

If the latter, the answer is, I think "don't do that!".

-- 
Alex Bligh

v2.23.0 | Report a Bug | By Email