Re: [dnsext] zone cut semantics
Brandon Black <blblack@gmail.com> Mon, 21 February 2011 03:59 UTC
Return-Path: <dnsext-bounces@ietf.org>
X-Original-To: namedroppers-archive-gleetwall6@lists.ietf.org
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 576743A6D99; Sun, 20 Feb 2011 19:59:46 -0800 (PST)
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 ECDC93A6D99 for <dnsext@core3.amsl.com>; Sun, 20 Feb 2011 19:59:44 -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 YjXWJvu+OhJB for <dnsext@core3.amsl.com>; Sun, 20 Feb 2011 19:59:44 -0800 (PST)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id D9FD53A6D52 for <dnsext@ietf.org>; Sun, 20 Feb 2011 19:59:43 -0800 (PST)
Received: by yie19 with SMTP id 19so2612011yie.31 for <dnsext@ietf.org>; Sun, 20 Feb 2011 20:00:24 -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; bh=Ueh8KsnvOTTVArwT6Vk0T4Tv50sOEu9OZcUw/yqL/oU=; b=Rtmz4ihMpkho/9UywNH/CQHhS3oYNM3IDlEbO20ZgjBYW6PbYdFc9PQXMIqFBrmLD5 +8fYI1ecDNflM3GUP+HZgnmYeR93ss6CgFiqZV8y62FV6IsGTZjkLnt16Aj8IkO8vrRB 0vPHGsAMZODKvLEos6Oc8WpXrc24dcBaqFrj4=
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; b=OzaumBPrc2NBMI3nGIFGC6hWydPMOsojH9/6h3RSAiHn8m3lGrHv7nbFFHUpWoeXWU ThpmvGMH3/Aq4IxJ4fNRZmAWhGdDmQDTlQU01sP2Zo9+rAram39U+DbSzEwTIOXFoHMM FW7BA9IRR9RH/Ci5RjoBT9l4w0CviXoHcOjqg=
MIME-Version: 1.0
Received: by 10.100.3.12 with SMTP id 12mr411381anc.233.1298260823958; Sun, 20 Feb 2011 20:00:23 -0800 (PST)
Received: by 10.101.68.7 with HTTP; Sun, 20 Feb 2011 20:00:23 -0800 (PST)
In-Reply-To: <4AAEDEAF-AE3B-48D0-92AC-7C86538BF54E@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> <AANLkTi=uwMO-nwtru00F+gD8JmibRYx1b9VWThMSHhfv@mail.gmail.com> <4AAEDEAF-AE3B-48D0-92AC-7C86538BF54E@rfc1035.com>
Date: Sun, 20 Feb 2011 22:00:23 -0600
Message-ID: <AANLkTinWyUEi8prNUcrdEMZVCEpYa_tDRNKAQWcykRoL@mail.gmail.com>
From: Brandon Black <blblack@gmail.com>
To: Jim Reid <jim@rfc1035.com>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org
On Sun, Feb 20, 2011 at 8:43 PM, Jim Reid <jim@rfc1035.com> wrote: >> 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. Fine, I won't use the word Authoritative in way that doesn't conform to the specifications, that's fair. The only way the resolver knows to believe the answer from the .brandon name servers is based on glue it believed from the root server. One way or another, you cannot avoid the fact that the root servers control .brandon's resolution, directly or indirectly. The root servers make a poor example though, because they're universal. Let's look at example.com. vs example.org. again, assuming the root delegates com. and org. to different sets of nameservers. If the org. nameservers answer www.example.org. with: example.org. NS ns1.example.com. ns1.example.com. A 192.0.2.1 I thought it was part of avoiding cache poisoning, etc, that org. nameservers are not to be believed for glue outside of its authority, and that the resolver should query ns1.example.com. separately. Or is it the view of the RFCs that ns1.example.com. is basically functionally a "temporary" name that ties those two response RRs together just to be used once to contact 192.0.2.1 for this one delegation and never cached, and that this doesn't need to be independently verified through the com. servers? I was under the impression this is why it matters whether example.org.'s nameserver glue is or isn't within org., and hence my whole point about why this matters for glue. An un-snarky correction on this would be appreciated :P _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext
- Re: [dnsext] Failure to add glue MUST cause TC to… Tony Finch
- [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… 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 Michael Graff
- 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 Joe Abley
- 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