Re: [dnsext] the same in old days, was making names the same NEED protocol changes?

Alex Bligh <alex@alex.org.uk> Sun, 27 February 2011 19:55 UTC

Return-Path: <dnsext-bounces@ietf.org>
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98A343A6A28; Sun, 27 Feb 2011 11:55:14 -0800 (PST)
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 7BBD23A6A28 for <dnsext@core3.amsl.com>; Sun, 27 Feb 2011 11:55:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level:
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 HSADvafyNgik for <dnsext@core3.amsl.com>; Sun, 27 Feb 2011 11:55:12 -0800 (PST)
Received: from mail.avalus.com (mail.avalus.com [89.16.176.221]) by core3.amsl.com (Postfix) with ESMTP id A89AC3A67C1 for <dnsext@ietf.org>; Sun, 27 Feb 2011 11:55:12 -0800 (PST)
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 1FA12C56062; Sun, 27 Feb 2011 19:56:09 +0000 (GMT)
Date: Sun, 27 Feb 2011 19:56:09 +0000
From: Alex Bligh <alex@alex.org.uk>
To: "John R. Levine" <johnl@iecc.com>
Message-ID: <AF3A2DE418832E7A91CD07A5@Ximines.local>
In-Reply-To: <alpine.BSF.2.00.1102271336340.6604@joyce.lan>
References: <20110227182720.6537.qmail@joyce.lan> <552AB7D12FAB50296E795CF5@Ximines.local> <alpine.BSF.2.00.1102271336340.6604@joyce.lan>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Disposition: inline
Cc: dnsext@ietf.org
Subject: Re: [dnsext] the same in old days, was making names the same NEED protocol changes?
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Alex Bligh <alex@alex.org.uk>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

--On 27 February 2011 13:37:17 -0500 "John R. Levine" <johnl@iecc.com> 
wrote:

>>> The primary shortcoming I see is a security issue: anyone can set a
>>> BNAME to make a random name equivalent to one of mine.
>
>> How does this differ from DNAME?
>
> Not in any important way I can see.  But I'm not aware of any application
> servers that autoconfigure based on DNAME, either.

I think I'm being thick here. Doesn't the BNAME reference go the
wrong way to autoconfigure a server based on it in a manner where
there can be a security problem as a result? IE Mallory's BNAME
record tells you which zone Mallory's zone is equivalent to.
Mallory's BNAME record does not tell you which other zones
(incl. Mallory's) are equivalent to yours. What would make
your server query Mallory's BNAME record at config time anyway?

-- 
Alex Bligh
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext