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