Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Fri, 04 March 2011 01:02 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
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 642C23A684A for <dnsext@core3.amsl.com>; Thu, 3 Mar 2011 17:02:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.096
X-Spam-Level:
X-Spam-Status: No, score=-0.096 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
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 xnppzP36QRBS for <dnsext@core3.amsl.com>; Thu, 3 Mar 2011 17:02:44 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by core3.amsl.com (Postfix) with SMTP id 543333A683F for <dnsext@ietf.org>; Thu, 3 Mar 2011 17:02:43 -0800 (PST)
Received: (qmail 79501 invoked from network); 4 Mar 2011 01:18:27 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 4 Mar 2011 01:18:27 -0000
Message-ID: <4D703A35.9080207@necom830.hpcl.titech.ac.jp>
Date: Fri, 04 Mar 2011 10:02:45 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: dnsext@ietf.org
References: <20110227191542.6824.qmail@joyce.lan> <335963D7-3440-45E6-843C-38F419462792@cisco.com> <4D6C3FD3.7010801@ucd.ie> <302DAD77E927757D3DEA05DF@nimrod.local><alpine.LSU.2.00.1103031107460.14985@hermes-1.csi.cam.ac.uk> <20110303114148.A360FB98E2E@drugs.dv.isc.org> <alpine.LSU.2.00.1103031148130.14985@hermes-1.csi.cam.ac.uk>
In-Reply-To: <alpine.LSU.2.00.1103031148130.14985@hermes-1.csi.cam.ac.uk>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Subject: Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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>
X-List-Received-Date: Fri, 04 Mar 2011 01:02:45 -0000

Tony Finch wrote:

> Note that SMTP is able to use one transaction to send a message with
> multiple recipients at different domains hosted on the same server. So the
> server needs to be able to present a certificate authenticating all of the
> mail domains it hosts.

> Now perhaps this mess - both the protocol mess and the deployment mess -
> can be fixed by using the firmer foundations that DNSSEC provides, but
> that requires protocol development.

Just say "another level of indirection" or another CNAME.

By making CNAME domain names pointed by MXes different for each
mail domain name, and letting SMTP think servers with different
CNAME domain names are different servers even if they are
aliases of a single server, TLS should work with MX.

	mail0.example.com	MX 0 mail0.example.net
	mail1.example.com	MX 0 mail1.example.net
	mail0.example.net	CNAME mx.example.net
	mail1.example.net	CNAME mx.example.net

It's like differentiating name based virtual servers by different
CNAMEs pointed from different SVRs, as I pointed out a few weeks
ago.

A problem is that RFC1034 has a wrong example for reasoning
against recursive aliasing. But, it should be fixed. I'll post
an errata with a separate subject.

						Masataka Ohta