Re: [dnsext] zone cut semantics
Brandon Black <blblack@gmail.com> Mon, 21 February 2011 01:21 UTC
Return-Path: <blblack@gmail.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 7030E3A6D4D for <dnsext@core3.amsl.com>; Sun, 20 Feb 2011 17:21:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 0gR-5kWiujCU for <dnsext@core3.amsl.com>; Sun, 20 Feb 2011 17:21:31 -0800 (PST)
Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by core3.amsl.com (Postfix) with ESMTP id D82843A6CC3 for <dnsext@ietf.org>; Sun, 20 Feb 2011 17:21:30 -0800 (PST)
Received: by gwj23 with SMTP id 23so1178264gwj.15 for <dnsext@ietf.org>; Sun, 20 Feb 2011 17:22:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Q3GeOVm0Hbz1RieHYZ7zanmdGFHiOGUpbH7bNO6cgKE=; b=HshDj42R64aXSdT2/1fNJx2DZoxjs6EKq3NC03a4g2CbKZigK9jXFSKCLb/CAArRq/ b+ccLXy4qX4vl61nM0OcGCgiU9N9+roHVQGKth1IkZaEd9T2UGhV3rKVTO4wYxcXKeyw Yd/idTx1DjbpcfbCAH5Gk2UPQlYoShOjjVz3I=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KvV5bcs+rbytu8YT8he0lbHvLXb87rRs7CJ1tlaQXzI0+lf1oaYy3MXXewXPZWTBpm qUFN08dQ4psZV9j8ddKaYF19S/xBY5HZk02dzGGxmgvBBm2G1w0uAMaKJVkl0ZzAvZGw crdzGf59W1Ul3B31l/nyl+RB5dg5Kc+6oubwc=
MIME-Version: 1.0
Received: by 10.100.95.14 with SMTP id s14mr376608anb.29.1298251329555; Sun, 20 Feb 2011 17:22:09 -0800 (PST)
Received: by 10.101.68.7 with HTTP; Sun, 20 Feb 2011 17:22:09 -0800 (PST)
In-Reply-To: <EBAC7E2F-FE70-497E-9C6C-DE4D2180CF7F@rfc1035.com>
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>
Date: Sun, 20 Feb 2011 19:22:09 -0600
Message-ID: <AANLkTi=uwMO-nwtru00F+gD8JmibRYx1b9VWThMSHhfv@mail.gmail.com>
From: Brandon Black <blblack@gmail.com>
To: Jim Reid <jim@rfc1035.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 01:21:32 -0000
On Sun, Feb 20, 2011 at 2:44 PM, Jim Reid <jim@rfc1035.com> wrote: > 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. IMHO, this is where it's semantics. The root servers are authoritative for everything, that's why we believe their delegation answers. The AA-bit is just part of how the protocol signals delegation of authority. Yes, the child is responsible for its own NS records while the parent delegates, but the parent can take away the delegation at any time and serve the child's zone data directly. This does come into play in the glue issues. You can trust glue data which falls within the delegating (parent) zone , but you can't necessarily trust other glue records that might come in a response. This is much like a corporate hierarchy model: the CEO is authoritative for everything, but delegates decisions throughout a hierarchy of lower level managers. The fact that Joe the VP of Sales is responsible for all Sales decisions doesn't take away the CEO's authority over everything the company does.
- [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