IETF Logo Mail Archive

Re: [dnsext] request to adopt draft-andrews-dnsext-expire-00.txt

Mark Andrews <Mark_Andrews@isc.org> Tue, 25 November 2008 22:59 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7A1328C1EC; Tue, 25 Nov 2008 14:59:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.384
X-Spam-Level:
X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 4Sp6b92OUjDn; Tue, 25 Nov 2008 14:59:45 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BFA863A687E; Tue, 25 Nov 2008 14:59:45 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1L56mo-000KP0-4o for namedroppers-data@psg.com; Tue, 25 Nov 2008 22:53:38 +0000
Received: from [2001:4f8:0:2::1c] (helo=mx.isc.org) by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <Mark_Andrews@isc.org>) id 1L56mi-000KOY-Cx for namedroppers@ops.ietf.org; Tue, 25 Nov 2008 22:53:35 +0000
Received: from farside.isc.org (farside.isc.org [IPv6:2001:4f8:3:bb::5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "farside.isc.org", Issuer "ISC CA" (verified OK)) by mx.isc.org (Postfix) with ESMTPS id C6853114021; Tue, 25 Nov 2008 22:53:12 +0000 (UTC) (envelope-from Mark_Andrews@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "drugs.dv.isc.org", Issuer "ISC CA" (not verified)) by farside.isc.org (Postfix) with ESMTP id F0514E60A3; Tue, 25 Nov 2008 22:53:11 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (8.14.3/8.14.3) with ESMTP id mAPMr5pc013297; Wed, 26 Nov 2008 09:53:07 +1100 (EST) (envelope-from marka@drugs.dv.isc.org)
Message-Id: <200811252253.mAPMr5pc013297@drugs.dv.isc.org>
To: Peter Koch <pk@DENIC.DE>
Cc: IETF DNSEXT WG <namedroppers@ops.ietf.org>
From: Mark Andrews <Mark_Andrews@isc.org>
Subject: Re: [dnsext] request to adopt draft-andrews-dnsext-expire-00.txt
In-reply-to: Your message of "Tue, 25 Nov 2008 18:28:01 BST." <20081125172801.GG8879@unknown.office.denic.de>
Date: Wed, 26 Nov 2008 09:53:05 +1100
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>

In message <20081125172801.GG8879@unknown.office.denic.de>, Peter Koch writes:
> On Thu, Nov 20, 2008 at 03:52:59AM +1100, Mark Andrews wrote:
> > 
> > 	As per the chairs' instructions, this is a request for
> > 	dnsext to adopt draft-andrews-dnsext-expire-00.txt as a wg
> > 	item.
> 
> this draft seems to assume that EXPIRE is a tool to deterministically bring
> a zone out of service, controlled by and to the benefit of the zone
> maintainer.  My reading of RFC 1034, section 4.3.5 is different: EXPIRE
> is just a relief for the slave, so it doesn't have to waste more resources
> on SOA checks.  I do not see how self-sustaining XFR-loops would hurt there.
> Actually, many zones use dangerously low EXPIRE values and accelerating
> expiration (independent of loops) might be counterproductive for them.

	The purpose of expire is to stop stale data being served.

	"If the secondary finds it impossible to perform a serial
	check for the EXPIRE interval, it must assume that its copy
	of the zone is obsolete an discard it."

	No where do I see any text which says that a slave will
	stop attempting to transfer the zone if it's old copy has
	expired.

	As for dangerously low EXPIRE values they are a problem with
	or without loops in the zone trasnfer graph.

> This suggests that a clarification of the meaning of the EXPIRE field is
> probably needed. If EXPIRE was a reliable zone removal tool, how would slave
> servers be expected to maintain state -- or would they be allowed to
> occasionally re-query?  What's the operational scenario in which zone
> removal would apply? Shouldn't this question be better addressed by a
> name server control protocol?

	It's not a zone removal tool.  It a stale data removal tool.
 
> That said, I do not believe adopting the draft is the best way forward, becau
> se
> it is too deep in solution space.  Seeking clarification of EXPIRE is a
> different work item and I'd support that.
> 
> -Peter
> 
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

v2.23.0 | Report a Bug | By Email