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

John Levine <johnl@iecc.com> Sat, 05 March 2011 19:19 UTC

Return-Path: <johnl@iecc.com>
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 C8DDA3A687E for <dnsext@core3.amsl.com>; Sat, 5 Mar 2011 11:19:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.755
X-Spam-Level:
X-Spam-Status: No, score=-110.755 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
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 2+8ndWbFkpgH for <dnsext@core3.amsl.com>; Sat, 5 Mar 2011 11:19:16 -0800 (PST)
Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id D99DB3A67B1 for <dnsext@ietf.org>; Sat, 5 Mar 2011 11:19:15 -0800 (PST)
Received: (qmail 19264 invoked from network); 5 Mar 2011 19:20:25 -0000
Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 5 Mar 2011 19:20:25 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:vbr-info; s=429a.4d728cf9.k1103; i=johnl@user.iecc.com; bh=s7Ak1UmJ4NklAdT2D9+i3ZnCdMR1t6KwQs/g9YpSiTE=; b=pHWogmNdQJKvMzTUmrlQuM0S4v0c5zFACTSAq+DGJo5Q8UoM+zaEMA4Sm5vtnKv6ccN765gDxiWbebnwxsDE8U55qC3bfF3nwEqV5mmU4mPZcCulZdi0NHXxb3LsGlGSwdeZq2Fq9W5NBGidsPeDRB/3j7nPTEowx/RmUc0avT8=
VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org
Date: Sat, 05 Mar 2011 19:20:25 -0000
Message-ID: <20110305192025.17049.qmail@joyce.lan>
From: John Levine <johnl@iecc.com>
To: dnsext@ietf.org
In-Reply-To: <AANLkTikBfdxasG2uUYJTveMiOtLZg4zUQYjfEL5swmgY@mail.gmail.com>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 7bit
Subject: Re: [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: Sat, 05 Mar 2011 19:19:17 -0000

>Instead of having a CNAME:
>
>alias.example.com   CNAME  real.example.com.
>real.example.com    TXT "This is real data, maintained in a single location."

>have a *zone cut*

You don't have to do anything that complicated.  Just copy the records
from the target to the address of the CNAME.

>       zone alias.example.com { master; file="czone-data.example.com";};
>       zone real.example.com { master; file="czone-data.example.com";};

And keep in mind that not every DNS server uses BIND format control
statements or zone files.

In any event, this is not a new idea.  We all know that in principle,
anything you can do with B/C/DNAME you could do with sufficiently
disciplined server management.

This confirms my impression that if we're going to do any of this
stuff, it's only useful as part of a system where applications can use
the info in the DNS to auto-provision and make names equivalent at the
application level.

R's,
John