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.
- [dnsext] Failure to add glue MUST cause TC to be … Mark Andrews
- Re: [dnsext] Failure to add glue MUST cause TC to… Paul Vixie
- Re: [dnsext] Failure to add glue MUST cause TC to… bmanning
- Re: [dnsext] Failure to add glue MUST cause TC to… Tony Finch
- Re: [dnsext] Failure to add glue MUST cause TC to… George Barwood
- Re: [dnsext] Failure to add glue MUST cause TC to… Brandon Black
- Re: [dnsext] Failure to add glue MUST cause TC to… Mark Andrews
- [dnsext] zone cut semantics Jim Reid
- Re: [dnsext] Failure to add glue MUST cause TC to… George Barwood
- Re: [dnsext] Failure to add glue MUST cause TC to… Mark Andrews
- Re: [dnsext] Failure to add glue MUST cause TC to… Brandon Black
- Re: [dnsext] Failure to add glue MUST cause TC to… George Barwood
- Re: [dnsext] Failure to add glue MUST cause TC to… Mark Andrews
- Re: [dnsext] Failure to add glue MUST cause TC to… Mark Andrews
- Re: [dnsext] Failure to add glue MUST cause TC to… James Mitchell
- Re: [dnsext] Failure to add glue MUST cause TC to… Brandon Black
- Re: [dnsext] Failure to add glue MUST cause TC to… Masataka Ohta
- Re: [dnsext] zone cut semantics Brandon Black
- Re: [dnsext] Failure to add glue MUST cause TC to… Mark Andrews
- Re: [dnsext] zone cut semantics Jay Ashworth
- Re: [dnsext] zone cut semantics Jim Reid
- Re: [dnsext] zone cut semantics Brandon Black
- Re: [dnsext] zone cut semantics Jay Ashworth
- Re: [dnsext] zone cut semantics Joe Abley
- Re: [dnsext] zone cut semantics Olafur Gudmundsson
- Re: [dnsext] Failure to add glue MUST cause TC to… Florian Weimer
- Re: [dnsext] Failure to add glue MUST cause TC to… Tony Finch
- Re: [dnsext] Failure to add glue MUST cause TC to… Tony Finch
- Re: [dnsext] zone cut semantics W.C.A. Wijngaards
- Re: [dnsext] zone cut semantics Michael Graff
- Re: [dnsext] Failure to add glue MUST cause TC to… George Barwood
- Re: [dnsext] Failure to add glue MUST cause TC to… George Barwood
- Re: [dnsext] Failure to add glue MUST cause TC to… Mark Andrews
- Re: [dnsext] Failure to add glue MUST cause TC to… George Barwood
- Re: [dnsext] Failure to add glue MUST cause TC to… Joe Abley