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.