Re: [dnsext] Failure to add glue MUST cause TC to be set.

bmanning@vacation.karoshi.com Sun, 20 February 2011 07:29 UTC

Return-Path: <bmanning@karoshi.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 7C3393A6CB6 for <dnsext@core3.amsl.com>; Sat, 19 Feb 2011 23:29:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 cNcb-0ynxFJu for <dnsext@core3.amsl.com>; Sat, 19 Feb 2011 23:29:51 -0800 (PST)
Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 80A323A6CD1 for <dnsext@ietf.org>; Sat, 19 Feb 2011 23:29:46 -0800 (PST)
Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p1K7TV7s003517; Sun, 20 Feb 2011 07:29:48 GMT
Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p1K7TLsv003516; Sun, 20 Feb 2011 07:29:21 GMT
Date: Sun, 20 Feb 2011 07:29:16 +0000
From: bmanning@vacation.karoshi.com
To: Paul Vixie <vixie@isc.org>
Message-ID: <20110220072916.GA3505@vacation.karoshi.com.>
References: <20110219210716.72943A5602B@drugs.dv.isc.org> <11263.1298150425@nsa.vix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <11263.1298150425@nsa.vix.com>
User-Agent: Mutt/1.4.1i
Cc: dnsext@ietf.org
Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set.
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: Sun, 20 Feb 2011 07:29:52 -0000

doesn't that cause some tension - two zones being authoritative for the
same data?  and i'm not fully convinced that stripping out recursion is
a n'cessy evil.

--bill


On Sat, Feb 19, 2011 at 09:20:25PM +0000, Paul Vixie wrote:
> we also need to require that the parent zone contain the addresses of
> child glue, since otherwise the parent authority must also be recursive
> which is something i think we're trying to move away from.
> 
> re:
> 
> > We need to make it clear that adding address records here (RFC 1034,
> > Section 4.3.2, step 3b) is not optional unlike step 6 where they are
> > optional.
> > 
> >          b. If a match would take us out of the authoritative data,
> >             we have a referral.  This happens when we encounter a
> >             node with NS RRs marking cuts along the bottom of a
> >             zone.
> > 
> >             Copy the NS RRs for the subzone into the authority
> >             section of the reply.  Put whatever addresses are
> >             available into the additional section, using glue RRs
> >             if the addresses are not available from authoritative
> >             data or the cache.  Go to step 4.
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext