Re: [dnsext] New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Tue, 23 August 2011 00:34 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
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 9C50221F8B28 for <dnsext@ietfa.amsl.com>; Mon, 22 Aug 2011 17:34:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.018
X-Spam-Level:
X-Spam-Status: No, score=-0.018 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
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 XLHLTBHZdnQz for <dnsext@ietfa.amsl.com>; Mon, 22 Aug 2011 17:34:49 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id D081521F8B2A for <dnsext@ietf.org>; Mon, 22 Aug 2011 17:34:48 -0700 (PDT)
Received: (qmail 86360 invoked from network); 23 Aug 2011 00:38:23 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 23 Aug 2011 00:38:23 -0000
Message-ID: <4E52F5A5.2080809@necom830.hpcl.titech.ac.jp>
Date: Tue, 23 Aug 2011 09:34:45 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Mark Andrews <marka@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> <1314015892.2779.45.camel@shane-desktop> <4E525476.4070001@necom830.hpcl.titech.ac.jp> <20110822194951.0C554130B8DB@drugs.dv.isc.org>
In-Reply-To: <20110822194951.0C554130B8DB@drugs.dv.isc.org>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
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: Tue, 23 Aug 2011 00:34:49 -0000

Mark Andrews wrote:

> No.  I think Shane means that they have been out of contact long
> enough that the AXFR style response is smaller than the IXFR style
> response and the upstream supplied a AXFR style response.

So, it's not two distribution servers but their clients, which
fail?

It's not a problem, as long as the distribution servers are
synchronized.

But, as Shane said "both distribution servers will need a full
AXFR when they restart", he seemingly assumes failures of
distribution servers, I'm afraid.

Anyway,

>> Even then, there is no point of IXFR-only because, with your example,
>> neither server can offer IXFR.
> 
> You are missing Shanes point,

What?

> which is that after the initial AXFR
> style response that the slaves that transferred from the DM that
> transfered first, and hence had a lower serial, will not be able
> to get a delta style response from the other DM.

Are you saying two distribution servers (never introduce new
terminology such as DM only to amplify the confusion) do not
have the same history of a zone?

How can it happen without severe operational errors?

Note that you don't assume failure of distribution servers.

> Shane isn't saying that it is a desirable solution.
> 
> The other solution is to prevent the axfr's out from the DM's until they
> both have the same serials available ixfr from.

I'm afraid both Shane and you have confused ideas on the configuration
of DNS servers, partially because of improper terminologies.

						Masataka Ohta