[dnsext] Use case for IXFR-only, was Re: Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02

Shane Kerr <shane@isc.org> Mon, 20 June 2011 12:11 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 32B2311E815F for <dnsext@ietfa.amsl.com>; Mon, 20 Jun 2011 05:11:13 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1yGNMoRJO9N for <dnsext@ietfa.amsl.com>; Mon, 20 Jun 2011 05:11:12 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 498C411E815C for <dnsext@ietf.org>; Mon, 20 Jun 2011 05:11:12 -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.pao1.isc.org (Postfix) with ESMTPS id 1DB4FC9428; Mon, 20 Jun 2011 12:11:07 +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 7BFC9216C83; Mon, 20 Jun 2011 12:11:05 +0000 (UTC) (envelope-from shane@isc.org)
From: Shane Kerr <shane@isc.org>
To: Edward Lewis <Ed.Lewis@neustar.biz>
In-Reply-To: <a06240807ca2117b8a0eb@[10.31.201.23]>
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]> <4DFB6173.5080802@nic.cz> <a06240807ca2117b8a0eb@[10.31.201.23]>
Content-Type: text/plain; charset="UTF-8"
Organization: ISC
Date: Mon, 20 Jun 2011 14:11:01 +0200
Message-ID: <1308571861.2742.34.camel@shane-desktop>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14)
Content-Transfer-Encoding: 8bit
Cc: dnsext@ietf.org
Subject: [dnsext] Use case for IXFR-only, was Re: Fwd: 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, 20 Jun 2011 12:11:13 -0000

Ed,

On Fri, 2011-06-17 at 10:50 -0400, Edward Lewis wrote:
> At 16:15 +0200 6/17/11, OndÞej Sur˜ wrote:
> 
> >But the fact is that you get a full zone.
> >
> >Also the new draft says:
> >
> >    In case of fallback to AXFR, the answer contains the same RRs (and is
> >    subject to the same ordering rules) as specified in Sections 2.2
> >    through 3 of RFC 5936, with the single difference being the echoed
> >    QCODE (i.e., IXFR) in the Question section.
> >
> >The fact is that the it's the behaviour which is "AXFR" (that is what we
> >talk about), but the QCODE/RCODE is not "AXFR", but IXFR.
> 
> My impression is that the issue surrounding 
> IXFR-only is about load on processing and network 
> latency.  I fail to see that the problem is that 
> you get all of the zone at once. The problem is 
> that you have to do a lot of work to get all of 
> the records of an large zone when all you really 
> need is a just a small increment.

Yes, the problem is CPU, memory, network bandwidth, and latency.

If you have multiple masters, and one is missing a particular version of
a zone for whatever reason (for example if the server needs to be
restarted and has a long fsck), then if your slave is unlucky and sends
IXFR to that master, then it will get the entire version of the zone,
even if other masters can happily supply just the differences in the
zone. If your zone is large or your connections are slow, this can be a
problem.

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.

IXFR-only specifies that you do not want the behavior to fall back to an
AXFR-style transfer, to avoid this issue. That's all.

In my mind, it turns IXFR into "Do What I Said" instead of "Do What You
Think Might Be Helpful". :)

--
Shane