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

Ondřej Surý <ondrej.sury@nic.cz> Fri, 19 August 2011 07:28 UTC

Return-Path: <ondrej.sury@nic.cz>
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 6D80721F86B6 for <dnsext@ietfa.amsl.com>; Fri, 19 Aug 2011 00:28:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.025
X-Spam-Level:
X-Spam-Status: No, score=-1.025 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3]
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 wiP6LLdeDOXz for <dnsext@ietfa.amsl.com>; Fri, 19 Aug 2011 00:28:22 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3436421F86AC for <dnsext@ietf.org>; Fri, 19 Aug 2011 00:28:22 -0700 (PDT)
Received: from [IPv6:2001:1488:ac14:1400:d03d:a0:8f9b:2ed1] (unknown [IPv6:2001:1488:ac14:1400:d03d:a0:8f9b:2ed1]) by mail.nic.cz (Postfix) with ESMTPSA id AA1542A2CC3; Fri, 19 Aug 2011 09:28:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1313738936; bh=rwGOtJO7Vzk/px0TbY78vW16M8GOPt4+mGXksU+9Y6Y=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=J189nFUD3hx6At2aC8xEbBtFN5b3e4xtViGd8Cqw0mXZ12M/v+gnx0pVrGnUaYmbS OPh3gCx6FNI0/OjfJzR2WDnQYaYijhK7oDPsPzgYgjB52gy4mhBs5P91DgymSo/Qr6 4Y03sGHRCk/Z+oVa2lrZyxw+1Yu/IDhDBAnRvIKc=
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset="utf-8"
From: Ondřej Surý <ondrej.sury@nic.cz>
In-Reply-To: <4E4D7E7E.1070700@necom830.hpcl.titech.ac.jp>
Date: Fri, 19 Aug 2011 09:28:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <80B25AE0-4DB6-4DBB-866B-4DB8F59D6DA0@nic.cz>
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>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
X-Mailer: Apple Mail (2.1244.3)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
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: Fri, 19 Aug 2011 07:28:35 -0000

On 18. 8. 2011, at 23:05, Masataka Ohta wrote:

> Ondej Sur wrote:
> 
>>> Are your examples essentially different from Brian Dickson's?
> 
>> Much simpler.  The DNSSEC signed zone is huge and with anycasts scattered
>> around the world downloading the zone from hidden master(s) I just don't
>> want the AXFR happen if it can be prevented.
> 
> You fail to explain why the AXFR happens.
>> And there's a lot of stuff which can happen
>> on the master to forget the differences.
> 
> I can see none.

From an operational experience, I see a lot.  You can run out of memory,
out of disk space, on disk journal can get corrupt (yes this happens),
DNS software can (and will) have other bugs, people can make mistakes.
Yes, all of this happens in the real world.

>> The problem is that the 500MB zone * number of anycast slaves (25ish) is
>> 10 GB of data to transfer.  Sure, I can just buy a really fat pipe, but
>> I am no friend of "throw more money" there solutions when we can have
>> simple protocol solution.
> 
> The simplest solution is not to forget the differences.


From the pure theoretical view point, yes.  From the operational view,
I cannot agree with you.  You seem to operate on the grounds that
the run environment is perfect, the software is bug free, the people
don't make mistakes.  The operational experience don't concur with
that view.

Simply put, I see this as an design flaw in the original IXFR.
The decision on whether to do an AXFR-style IXFR or not should
be the decision of the slave (the client) and not the master server.
It should not be the decision of the server whether to send a few
megabytes of differences (IXFR) or hundreds of megabytes (AXFR-style).

The IXFR-only is a simple solution to remedy this problem.  It is
backwards compatible with existing servers and clients, nobody is
forced to use it, yet you are strongly opposed claiming that it's
not needed.  Even though at least mine and Shane's experience with
the operations of big-to-huge zones differ.

O.
--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:ondrej.sury@nic.cz    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------