[dnsext] errata on RFC1034 for recursive aliasing and name based diffrentiation

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Fri, 04 March 2011 03:15 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 EA7463A6918 for <dnsext@core3.amsl.com>; Thu, 3 Mar 2011 19:15:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.095
X-Spam-Level:
X-Spam-Status: No, score=-0.095 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, NORMAL_HTTP_TO_IP=0.001]
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 8FnyPEg-jo8L for <dnsext@core3.amsl.com>; Thu, 3 Mar 2011 19:15:01 -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 826A73A6916 for <dnsext@ietf.org>; Thu, 3 Mar 2011 19:15:00 -0800 (PST)
Received: (qmail 81300 invoked from network); 4 Mar 2011 03:30:39 -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 03:30:39 -0000
Message-ID: <4D705952.6000409@necom830.hpcl.titech.ac.jp>
Date: Fri, 04 Mar 2011 12:15:30 +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> <4D703A35.9080207@necom830.hpcl.titech.ac.jp>
In-Reply-To: <4D703A35.9080207@necom830.hpcl.titech.ac.jp>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Subject: [dnsext] errata on RFC1034 for recursive aliasing and name based diffrentiation
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 03:15:03 -0000

While RFC1034 says:

   Domain names in RRs which point at another name should
   always point at the primary name and not the alias.
   This avoids extra indirections in accessing information.
   For example, the address to name RR for the above host
   should be:

       52.0.0.10.IN-ADDR.ARPA  IN      PTR     C.ISI.EDU

   rather than pointing at USC-ISIC.ARPA.  Of course, by
   the robustness principle, domain software should not
   fail when presented with CNAME chains or loops; CNAME
   chains should be followed and CNAME loops signalled as
   an error.

"avoids extra indirections" is not a strong requirement
and virtually allowed with the wording of while "CNAME
loops signalled as an error" is a strong requirement.

Thus, while CNAME (and BNAME) chains should be discouraged,
it should be explicitly allowed to use CNAME as a target of
PTR, MX, SVR and so on which does not cause recursion loops,
which is useful for name based differentiation of a service
on a single host.

CNAME as a target of NS should also be discouraged, because
it may cause recursion loop to be resolved by glue, which
requires unnecessarily complex operations.


					Masataka Ohta