Re: [dnsext] zone cut semantics

Jim Reid <jim@rfc1035.com> Mon, 21 February 2011 02:42 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 EA1C53A6F7F for <dnsext@core3.amsl.com>; Sun, 20 Feb 2011 18:42:45 -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 mzpi0ghD6mBl for <dnsext@core3.amsl.com>; Sun, 20 Feb 2011 18:42:45 -0800 (PST)
Received: from hutch.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) by core3.amsl.com (Postfix) with ESMTP id 083543A6F7D for <dnsext@ietf.org>; Sun, 20 Feb 2011 18:42:45 -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 9467B15420A1; Mon, 21 Feb 2011 02:43:23 +0000 (GMT)
Message-Id: <4AAEDEAF-AE3B-48D0-92AC-7C86538BF54E@rfc1035.com>
From: Jim Reid <jim@rfc1035.com>
To: Brandon Black <blblack@gmail.com>
In-Reply-To: <AANLkTi=uwMO-nwtru00F+gD8JmibRYx1b9VWThMSHhfv@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: Mon, 21 Feb 2011 02:43:22 +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> <EBAC7E2F-FE70-497E-9C6C-DE4D2180CF7F@rfc1035.com> <AANLkTi=uwMO-nwtru00F+gD8JmibRYx1b9VWThMSHhfv@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: Re: [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: Mon, 21 Feb 2011 02:42:46 -0000

On 21 Feb 2011, at 01:22, Brandon Black wrote:

> IMHO, this is where it's semantics.

The protocol specs say otherwise. Please read Section 6 of RFC2181. If  
you wish to continue an angels on pinhead debate about linguistic  
semantics of "authoritative" or what you mean by that, let's stop  
wasting each other's time and stop now.

> The root servers are authoritative for everything, that's why we  
> believe their delegation answers.

No they are not. The root servers are authoritative for the root  
zone*. Which largely holds pointers to where we can find authoritative  
data about other names in the DNS. The root zone cannot be  
authoritative for those pointers (delegations) because they live  
beneath the zone cuts for the TLDs.

I'm not sure what you mean by "believe delegation answers". No, please  
don't try to explain... But you seem to be wrong about that too. The  
root servers may well tell us there's a delegation for .brandon. But a  
resolving name server won't "believe" that until it gets an  
authoritative answer from one of the .brandon name servers, confirming  
the TLD's existence. And hopefully validates all of that with DNSSEC.

The word "authoritative" has a well defined meaning in the DNS  
protocol. You seem to want to use it in a different context. Which is  
fine: words can mean whatever you want them to mean. However please  
don't do that in this forum with technical terms which have carefully  
defined meanings when used for the DNS protocol. This list is for DNS  
protocol geeks after all.


*Well, OK, they also authoritatively serve root-servers.net.