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

[Shane Kerr <[e-mail]>]

Wouter, 

On Mon, 2011-06-20 at 09:50 +0200, W.C.A. Wijngaards wrote:
> On 06/17/2011 08:05 PM, Brian Dickson wrote:
> > On Fri, Jun 17, 2011 at 11:41 AM, Edward Lewis <[e-mail]> wrote:
> >> I don't think there is an understanding of IXFR.  I'd suggest reading 1995
> >> again and checking it against your code.  Perhaps your code missed
> >> something.
> > 
> > Either a protocol change (non-standard, or standards-based) between
> > the client is needed,
> > or the client is forced to be very unfriendly, and abort the IXFR if
> > it doesn't see its own Serial
> > as the second RR of the IXFR. Closing the TCP socket is the only
> > mechanism it would have to do that.
> 
> What is wrong with closing the TCP socket?

There's nothing especially wrong with that, and IIRC we did consider
this option when discussing IXFR-only over beers several years ago.

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.

Granted this is probably only a few tens of MB at most, but I don't
think the changes on the slave side are much more complicated for
IXFR-only, and solve the problem.

--
Shane