[dnsext] zone cut semantics

Jim Reid <jim@rfc1035.com> Sun, 20 February 2011 20:43 UTC

Return-Path: <jim@rfc1035.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 F076B3A6E02 for <dnsext@core3.amsl.com>; Sun, 20 Feb 2011 12:43:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Yf6MNErGMzNN for <dnsext@core3.amsl.com>; Sun, 20 Feb 2011 12:43:40 -0800 (PST)
Received: from hutch.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) by core3.amsl.com (Postfix) with ESMTP id 104163A6DDA for <dnsext@ietf.org>; Sun, 20 Feb 2011 12:43:40 -0800 (PST)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id D546315420A1; Sun, 20 Feb 2011 20:44:16 +0000 (GMT)
Message-Id: <EBAC7E2F-FE70-497E-9C6C-DE4D2180CF7F@rfc1035.com>
From: Jim Reid <jim@rfc1035.com>
To: Brandon Black <blblack@gmail.com>
In-Reply-To: <AANLkTimNujeo6KiJ4wqUU-b3qyjozVmDvR8M3XNsfmKx@mail.gmail.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sun, 20 Feb 2011 20:44:16 +0000
References: <20110219210716.72943A5602B@drugs.dv.isc.org> <11263.1298150425@nsa.vix.com> <20110220072916.GA3505@vacation.karoshi.com.> <30899A4A-833B-42EF-9850-AFEE8B8DBE02@dotat.at> <AANLkTimNujeo6KiJ4wqUU-b3qyjozVmDvR8M3XNsfmKx@mail.gmail.com>
X-Mailer: Apple Mail (2.936)
Cc: "bmanning@vacation.karoshi.com" <bmanning@vacation.karoshi.com>, "dnsext@ietf.org" <dnsext@ietf.org>
Subject: [dnsext] zone cut semantics
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: Sun, 20 Feb 2011 20:43:41 -0000

On 20 Feb 2011, at 20:14, Brandon Black wrote:

> Isn't this really a matter of semantics?

Yes: zone cut semantics, not language semantics.

> The parent zone is
> authoritative for everything beneath itself, even if it choses to use
> that power of authority to give a delegation response.  e.g. the .com
> servers are authoritative for www.example.com, but they choose to
> delegate that answer to the NS for example.com.

Nope. Query the .com name servers for the NS records for example.com.  
They correctly return a non-authoritative answer. It's only the name  
servers for example.com that are authoritative for example.com and  
will authoritatively answer that query. In other words, it's the child  
that's responsible for the zone's authoritative NS RRset, not the  
parent. Which is how things should be when you consider what  
delegation actually means: crossing an administrative boundary from  
one authority to another.

Please think again about what you posted. The inference of what you  
say is that the root servers are authoritative for everything. That's  
clearly not true.