[dnsext] Fwd: New Version Notification for draft-barton-clone-dns-labels-fun-profit-01
Doug Barton <dougb@dougbarton.us> Mon, 14 March 2011 07:53 UTC
Return-Path: <dougb@dougbarton.us>
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 0133C3A693D for <dnsext@core3.amsl.com>; Mon, 14 Mar 2011 00:53:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.582
X-Spam-Level:
X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 cWl8uDLMDu33 for <dnsext@core3.amsl.com>; Mon, 14 Mar 2011 00:53:04 -0700 (PDT)
Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by core3.amsl.com (Postfix) with ESMTP id DB17B3A68E9 for <dnsext@ietf.org>; Mon, 14 Mar 2011 00:53:03 -0700 (PDT)
Received: (qmail 20639 invoked by uid 399); 14 Mar 2011 07:54:23 -0000
Received: from router.ka9q.net (HELO ?192.168.2.9?) (dougb@dougbarton.us@75.60.237.91) by mail2.fluidhosting.com with ESMTPAM; 14 Mar 2011 07:54:23 -0000
X-Originating-IP: 75.60.237.91
X-Sender: dougb@dougbarton.us
Message-ID: <4D7DC9B0.1060202@dougbarton.us>
Date: Mon, 14 Mar 2011 00:54:24 -0700
From: Doug Barton <dougb@dougbarton.us>
Organization: http://SupersetSolutions.com/
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: dnsext@ietf.org
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [dnsext] Fwd: New Version Notification for draft-barton-clone-dns-labels-fun-profit-01
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: Mon, 14 Mar 2011 07:53:05 -0000
http://tools.ietf.org/html/draft-barton-clone-dns-labels-fun-profit I think this version greatly clarifies how CLONE can provide DNSSEC, including the addition of dynamic signing. Enjoy, Doug -------- Original Message -------- Subject: New Version Notification for draft-barton-clone-dns-labels-fun-profit-01 Date: Mon, 14 Mar 2011 00:45:11 -0700 (PDT) From: IETF I-D Submission Tool <idsubmission@ietf.org> To: dougb@dougbarton.us A new version of I-D, draft-barton-clone-dns-labels-fun-profit-01.txt has been successfully submitted by Douglas Barton and posted to the IETF repository. Filename: draft-barton-clone-dns-labels-fun-profit Revision: 01 Title: Cloning Domain Name System (DNS) Labels for Fun and Profit Creation_date: 2011-03-14 WG ID: Independent Submission Number_of_pages: 13 Abstract: This document describes a method for making one or more Domain Name System (DNS) labels behave in the DNS "as if" they were actually an entirely different label. E.g., the delegee for the example.org zone could define bar.example.org to be a CLONE of foo.example.org. This method is designed to meet the needs of those managing Internationalized Domain Name (IDN) zones that have been determined to be semantically similar, and therefore should be treated "as if" they were identical. This method can also be used more generally to handle situations where either CNAME or DNAME Resource Records are currently being used. A key design goal for the CLONE method is that all of the semantic benefits are available by updating only the authoritative servers for the zone. Domain managers who want to support DNSSEC for the CLONEd labels/zones may do so with dynamic signing of the CLONEs, or rely on users being behind a CLONE-Aware resolving name server. Foreword [RFC Editor, please remove this Section at publication time. Thanks.] This is my first draft, please be gentle. :) I'm definitely open to the possibility that there are better ways to accomplish the concepts presented herein. I'm sure that there are a non-zero number of errors in the formatting, references, etc. Also Sections 2 and 3 may be under-specified, unclear, or unworkable. So please don't be afraid to offer (constructive) criticism. TODO: Update/add/improve references? Add/improve examples? Revision History: 1. -00 Initial version 2. -01 Minor textual edits, add support for dynamic signing, clarify CLONE labels that are not zone cuts The IETF Secretariat.