Re: [dnsext] draft-yao-dnsext-identical-resolution-02 comment

Andrew Sullivan <> Mon, 14 February 2011 16:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 81B803A6D5C for <>; Mon, 14 Feb 2011 08:37:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BuN5gTAf5Mrg for <>; Mon, 14 Feb 2011 08:37:23 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8DD553A6D4C for <>; Mon, 14 Feb 2011 08:37:23 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 47ED91ECB41D for <>; Mon, 14 Feb 2011 16:37:45 +0000 (UTC)
Date: Mon, 14 Feb 2011 11:37:43 -0500
From: Andrew Sullivan <>
Message-ID: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [dnsext] draft-yao-dnsext-identical-resolution-02 comment
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: Mon, 14 Feb 2011 16:37:24 -0000

On Mon, Feb 14, 2011 at 05:05:02PM +0200, Vaggelis Segredakis wrote:

> I can understand that a number of issues would need to be sorted before such
> a solution could be used. However I believe that there is a need for it.

Speaking only for myself, this is the crux of the issue.  What you're
saying is that the technology is needed, but the objection that some
have raised is that such a technology won't really work except in the
most trivial cases.  Since the trivial cases could just as easily be
solved with DNAME + other records at the apex, it's hard to justify
making a big change to the protocol.

Now, if the suggestion is that the parent _needs to_ enforce policies
in the tree underneath the parent, then we have a different argument,
because DNAME on the parent side won't really work for this purpose.

Speaking as co-chair but without having run this text past Olafur: in
respect of having a meeting, the issue is that we've already talked
about this topic a lot in meetings.  We discussed it at length in
Anaheim, had a special session about it in Maastricht, devoted meeting
time to in Beijing, and even had an interim teleconference.  But in
between those events very little discussion on the topic seems to have
happened.  Moreover, when we do have discussion it tends to focus on
existing proposals: "Do BNAME", for instance.  But the problem we have
is that we cannot tell whether BNAME (or any other proposal) actually
addresses the particular problems people have.  So either we get a
clear and broadly agreed-upon statement of the problem we are trying
to solve, or we don't solve the problem (because if we can't say what
it is, I think that means we don't know).



Andrew Sullivan
Shinkuro, Inc.