IETF Logo Mail Archive

Re: [dnsext] Slamming the TCP door, was Re: Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02

Florian Weimer <fweimer@bfk.de> Tue, 21 June 2011 11:48 UTC

Return-Path: <fweimer@bfk.de>
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 3168311E808D for <dnsext@ietfa.amsl.com>; Tue, 21 Jun 2011 04:48:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.784
X-Spam-Level:
X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 ui4MECUVDXtE for <dnsext@ietfa.amsl.com>; Tue, 21 Jun 2011 04:48:58 -0700 (PDT)
Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3962311E80D4 for <dnsext@ietf.org>; Tue, 21 Jun 2011 04:48:58 -0700 (PDT)
Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1QYzRr-0004EM-Qw; Tue, 21 Jun 2011 11:48:51 +0000
Received: by bfk.de with local id 1QYzRr-0000ZA-HS; Tue, 21 Jun 2011 11:48:51 +0000
From: Florian Weimer <fweimer@bfk.de>
To: Shane Kerr <shane@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> <4DFEFBDE.4030303@nlnetlabs.nl> <1308572047.2742.37.camel@shane-desktop>
Date: Tue, 21 Jun 2011 11:48:51 +0000
In-Reply-To: <1308572047.2742.37.camel@shane-desktop> (Shane Kerr's message of "Mon, 20 Jun 2011 14:14:07 +0200")
Message-ID: <82mxhb5rrw.fsf@mid.bfk.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: dnsext@ietf.org
Subject: Re: [dnsext] Slamming the TCP door, 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: Tue, 21 Jun 2011 11:48:59 -0000

* Shane Kerr:

> While you will not get the entire zone, you'll likely still get a lot of
> extra data. Your operating system will be happily filling its TCP buffer
> until your application notices that it is getting a AXFR-style transfer
> and then closes the connection.

Is it possible to reach that conclusion early during the connection?
Would the window be fully opened at that point?

Anyway, if you close a socket while there is pending data to read,
modern TCP implementations are expected to abort the connection.  So all
that data will be discarded, and the sender can be notified before the
data currently in flight is acknowledged.

-- 
Florian Weimer                <fweimer@bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

v2.23.0 | Report a Bug | By Email