IETF Logo Mail Archive

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

Ondřej Surý <ondrej.sury@nic.cz> Thu, 18 August 2011 15:52 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 C49E621F8B33 for <dnsext@ietfa.amsl.com>; Thu, 18 Aug 2011 08:52:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, 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 5MzF9ykoGhpZ for <dnsext@ietfa.amsl.com>; Thu, 18 Aug 2011 08:52:47 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF2D21F8B29 for <dnsext@ietf.org>; Thu, 18 Aug 2011 08:52:42 -0700 (PDT)
Received: from [IPv6:2001:1488:ac14:1400:1d67:4023:e239:bd47] (unknown [IPv6:2001:1488:ac14:1400:1d67:4023:e239:bd47]) by mail.nic.cz (Postfix) with ESMTPSA id 82EC02A2C10; Thu, 18 Aug 2011 17:53:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1313682813; bh=aBcs8ZnCv/tqj5RG0Dhy9Vh1MDFU+NUrCtOAOv7xvp4=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QmpiLndcGSlYhl1aZo0znnMo5doO/Vcuhy58N1KHMn0j32metzWxXN7yDXi5uOEH/ LRnGHAdkapx1QmjRotnOacIPC+EOOyIBgrlKhb9NIyM57MEG5RQrdidrP8qQYhpGCH ozAD2YakzyXLu/MQ9JcfnkIMOTsedTBIWWvpQDfM=
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: <4E000B93.3030306@necom830.hpcl.titech.ac.jp>
Date: Thu, 18 Aug 2011 17:53:33 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8A34D894-4323-4948-811E-6568C838A503@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>
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: Thu, 18 Aug 2011 15:52:47 -0000

On 21. 6. 2011, at 5:10, Masataka Ohta wrote:
> Shane Kerr wrote:
> 
>> The reason this came up is that two operators (Ondrej and me) both
>> encountered the problem in the real world and it adversely affected
>> our operations.
> 
> 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.

So if I had a knob which would turn the AXFR fallback off I could easily
setup an infrastructure which will buzz me if the IXFR cannot be done because
something has happened on the master and I could f.e. allow to sync one slave
at the time (or few of them).  And there's a lot of stuff which can happen
on the master to forget the differences.

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 IXFR-only is not a mechanism which would be used by small DNS operators,
but it can make a difference for huge zone owners like the average DNSSEC
signed TLDs.

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
 -------------------------------------------

v2.23.0 | Report a Bug | By Email