Re: [dnsext] New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02
Shane Kerr <shane@isc.org> Mon, 22 August 2011 12:23 UTC
Return-Path: <shane@isc.org>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DC021F8B42 for <dnsext@ietfa.amsl.com>; Mon, 22 Aug 2011 05:23:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+vx6dCuSVAd for <dnsext@ietfa.amsl.com>; Mon, 22 Aug 2011 05:23:56 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 5B40321F8B40 for <dnsext@ietf.org>; Mon, 22 Aug 2011 05:23:56 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id C81EC5F984C for <dnsext@ietf.org>; Mon, 22 Aug 2011 12:24:54 +0000 (UTC) (envelope-from shane@isc.org)
Received: from [IPv6:2001:610:719:1:beae:c5ff:fe43:aa00] (unknown [IPv6:2001:610:719:1:beae:c5ff:fe43:aa00]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id DA092216C22; Mon, 22 Aug 2011 12:24:51 +0000 (UTC) (envelope-from shane@isc.org)
From: Shane Kerr <shane@isc.org>
To: Mark Andrews <marka@isc.org>
Date: Mon, 22 Aug 2011 14:24:48 +0200
In-Reply-To: <20110821194704.2793E1303C8E@drugs.dv.isc.org>
References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <a06240803ca1fd7525c50@10.31.201.23> <BANLkTinjRDHyKH-tLEoejodXb2+7qQLO7w@mail.gmail.com> <a06240801ca2102b8b4f2@10.31.201.23> <BANLkTikoVVaXF2_LJ3KHm6P7oFpfC+n2tw@mail.gmail.com> <a06240801ca21246f76de@10.31.201.23> <BANLkTinVfuL0WEYwaycTaAnWDS9vYF5NjQ@mail.gmail.com> <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp> <BANLkTimhLJfsmMe3AE34yLrOQ+zyZPBdgQ@mail.gmail.com> <4E000B93.3030306@necom830.hpcl.titech.ac.jp> <8A34D894-4323-4948-811E-6568C838A503@nic.cz> <4E4D7E7E.1070700@necom830.hpcl.titech.ac.jp> <80B25AE0-4DB6-4DBB-866B-4DB8F59D6DA0@nic.cz> <20110821194704.2793E1303C8E@drugs.dv.isc.org>
Organization: ISC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.0.2 (3.0.2-3.fc15)
Content-Transfer-Encoding: 7bit
Message-ID: <1314015892.2779.45.camel@shane-desktop>
Mime-Version: 1.0
Cc: dnsext@ietf.org
Subject: Re: [dnsext] New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 22 Aug 2011 12:23:57 -0000
Mark, On Mon, 2011-08-22 at 05:47 +1000, Mark Andrews wrote: > Or one could say the it is a design flaw in how the TLD operators > generate the deltas. Compression of delta is optional and the > consequences of doing so were well documented. The TLD operators > wrote software that only compressed deltas then configured the > servers exactly as they were warned not to do if they compressed > deltas. There are other circumstance which can result in unwanted full zone transfer. Consider an environment where one has 2 distribution servers at a node, which act as slaves to off-site server. These distribution servers act as masters to any number of local slaves on site. If the node suffers a power failure, then it is quite possible that both distribution servers will need a full AXFR when they restart. If zone updates are frequent, there is a good chance that they will not have the exact same starting serial. All of the local slaves will need to do a full zone transfer when they start or soon after, getting the data from the first distribution server to complete the AXFR. At the first zone update, then on average half of them will need to get the entire zone contents again, because they will try a distribution master that does not have the same starting serial. For small zones this is not a big problem, but for large zones this can result in several minutes of delay before zones get updated - at a difficult time operationally. ("Yes, the node is up - it'll be a few more minutes before we can put it back online...") One solution is to have a single distribution server. However, this introduces a single point of failure into the design. It may also be possible to use some sort of high-availability setup to avoid this problem. A better solution would be for something like IXFR-only. There are probably other failure scenarios. My point is that there are cases other than compressed deltas that would benefit from IXFR-only. Forced fallback to full zone transfer is not a crucial operational problem or it would have been solved already. But it is a problem - or as Ondrej calls it a design flaw - and not too difficult to fix. -- Shane
- [dnsext] Fwd: New Version Notification for draft-… Ondřej Surý
- Re: [dnsext] Fwd: New Version Notification for dr… Ondřej Surý
- Re: [dnsext] Fwd: New Version Notification for dr… Edward Lewis
- Re: [dnsext] Fwd: New Version Notification for dr… Brian Dickson
- Re: [dnsext] Fwd: New Version Notification for dr… Mark Andrews
- Re: [dnsext] Fwd: New Version Notification for dr… Masataka Ohta
- Re: [dnsext] Fwd: New Version Notification for dr… Mark Andrews
- Re: [dnsext] Fwd: New Version Notification for dr… Masataka Ohta
- Re: [dnsext] Fwd: New Version Notification for dr… Edward Lewis
- Re: [dnsext] Fwd: New Version Notification for dr… Edward Lewis
- Re: [dnsext] Fwd: New Version Notification for dr… Ondřej Surý
- Re: [dnsext] Fwd: New Version Notification for dr… Edward Lewis
- Re: [dnsext] Fwd: New Version Notification for dr… Brian Dickson
- Re: [dnsext] Fwd: New Version Notification for dr… Edward Lewis
- Re: [dnsext] Fwd: New Version Notification for dr… Brian Dickson
- Re: [dnsext] Fwd: New Version Notification for dr… Masataka Ohta
- Re: [dnsext] Fwd: New Version Notification for dr… Brian Dickson
- Re: [dnsext] Fwd: New Version Notification for dr… W.C.A. Wijngaards
- [dnsext] Use case for IXFR-only, was Re: Fwd: New… Shane Kerr
- [dnsext] Slamming the TCP door, was Re: Fwd: New … Shane Kerr
- Re: [dnsext] Use case for IXFR-only, was Re: Fwd:… Edward Lewis
- Re: [dnsext] Slamming the TCP door, was Re: Fwd: … Edward Lewis
- Re: [dnsext] Slamming the TCP door, was Re: Fwd: … Mark Andrews
- Re: [dnsext] Use case for IXFR-only, was Re: Fwd:… Mark Andrews
- Re: [dnsext] Slamming the TCP door, was Re: Fwd: … Edward Lewis
- Re: [dnsext] Slamming the TCP door, was Re: Fwd: … W.C.A. Wijngaards
- Re: [dnsext] Slamming the TCP door, was Re: Fwd: … Josh Littlefield
- Re: [dnsext] Slamming the TCP door, was Re: Fwd: … Josh Littlefield
- Re: [dnsext] Slamming the TCP door, was Re: Fwd: … Paul Vixie
- Re: [dnsext] Slamming the TCP door, was Re: Fwd: … Edward Lewis
- Re: [dnsext] Fwd: New Version Notification for dr… Masataka Ohta
- Re: [dnsext] Slamming the TCP door, was Re: Fwd: … Masataka Ohta
- Re: [dnsext] Slamming the TCP door, was Re: Fwd: … Florian Weimer
- Re: [dnsext] Fwd: New Version Notification for dr… Edward Lewis
- Re: [dnsext] Fwd: New Version Notification for dr… Masataka Ohta
- Re: [dnsext] Fwd: New Version Notification for dr… Edward Lewis
- Re: [dnsext] Fwd: New Version Notification for dr… Masataka Ohta
- Re: [dnsext] Fwd: New Version Notification for dr… Edward Lewis
- Re: [dnsext] Fwd: New Version Notification for dr… Masataka Ohta
- Re: [dnsext] New Version Notification for draft-a… Ondřej Surý
- Re: [dnsext] New Version Notification for draft-a… Masataka Ohta
- Re: [dnsext] New Version Notification for draft-a… Ondřej Surý
- Re: [dnsext] New Version Notification for draft-a… Masataka Ohta
- Re: [dnsext] New Version Notification for draft-a… Ondřej Surý
- Re: [dnsext] New Version Notification for draft-a… Masataka Ohta
- Re: [dnsext] New Version Notification for draft-a… Mark Andrews
- Re: [dnsext] New Version Notification for draft-a… Masataka Ohta
- Re: [dnsext] New Version Notification for draft-a… Shane Kerr
- Re: [dnsext] New Version Notification for draft-a… Masataka Ohta
- Re: [dnsext] New Version Notification for draft-a… Mark Andrews
- Re: [dnsext] New Version Notification for draft-a… Masataka Ohta