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

Alex Bligh <alex@alex.org.uk> Mon, 13 September 2010 16:52 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 5C51F3A6A11; Mon, 13 Sep 2010 09:52:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.332
X-Spam-Level:
X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, J_CHICKENPOX_55=0.6]
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 SPpk8Po83jwZ; Mon, 13 Sep 2010 09:52:13 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 56A373A6A0C; Mon, 13 Sep 2010 09:52:13 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1OvCED-000Mac-1g for namedroppers-data0@psg.com; Mon, 13 Sep 2010 16:50:01 +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 1OvCEA-000Ma6-5q for namedroppers@ops.ietf.org; Mon, 13 Sep 2010 16:49:58 +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 A5A03C5691B; Mon, 13 Sep 2010 17:49:56 +0100 (BST)
Date: Mon, 13 Sep 2010 17:49:56 +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: <1B0679E8FE7160C3E91E246B@Ximines.local>
In-Reply-To: <4C8E530F.1050009@ucd.ie>
References: <C0F55485EA77FDF78E9B0398@Ximines.local> <4C8E266D.3070702@ucd.ie> <952FA12530B5693E36B03554@Ximines.local> <4C8E399F.8090300@ucd.ie> <C1D6C4E4CDAB83BE68BE10B0@Ximines.local> <4C8E4B65.5030402@ucd.ie> <9C2DE15E0F640A9D041DD421@Ximines.local> <4C8E530F.1050009@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:36:31 +0100 Niall O'Reilly <Niall.oReilly@ucd.ie> 
wrote:

> On 13/09/10 17:20, Alex Bligh wrote:
>> So you mean:
>>
>> $ORIGIN c1.d1.
>>      b2    IN DNAME b1.c1.d1.
>>      b1    IN NS ns.example.com.
>
> 	That's what I had in mind, with a bunch of MX, SRV, and
> 	whatever else belonging to b1.c1.d1. as well, and needing
> 	to be projected (mirrored, shadowed, ...) onto b2.c1.d1.

Right, and the coexistence of those other records is the problem, yes?
If so, I wrote:
> 1. Apparent pseudo-regulatory requirement to ensure TLDs operate with
> recursive sameness. This is making TLD1 == TLD2.
...
> Problem 1 can, it seems to me, be solved by DNAME. DNAME only doesn't
> do the job when there is a record at the apex, because DNAME+CNAME
> can't coexist. Few if any TLDs have records at their apexes.

By assumption (last sentence) there are no records that need to
be at b2.

IE I am assuming problem 1 (need for recursive sameness beyond
that which provisioning could give us) only applies in circumstances
where coexisting records do not exist. So far the only use
people who have said "provisioning doesn't work for this" are
TLDs.

-- 
Alex Bligh