Interoperability with QIP

[Paul A Vixie]

tom, you wrote:

> QIP is a DNS server that has pre-standard support for IXFR (they don't
> claim that it will talk to anything but another QIP servers until the
> standard is final and they update the software).

RFC 1995 was published in 1996 and is Standards track!

> No problem... BIND users can just disable IXFR for zone transfers to
> QIP servers.

How?  There's no 'allow-ixfr' ACL, and the 'support-ixfr' server
option only applies to zone transfers that we initiate when doing zone
maintenance.  I see no way to say "if this host requests IXFR, force
it to use AXFR".  I've looked at the code and see no evidence of such a
capability either.

I think QIP is requesting IXFR, we're responding, and they're not
understanding (due to their "pre-standard" support).

> However, when they do that QIP connects, gets rejected, and only
> half-closes the connection.  As a result, the BIND server accumulates
> tons of FIN_WAIT_1 connections.  Eventually the kernel table will fill
> and the machine will crash.

If we're in FIN_WAIT_1, then 'named' has called close() or shutdown().
In fact, in all those places that we call shutdown(), we immediately
call sq_remove() which will call close(), so I think we can conclude
that close() has been called for that socket.

We're waiting for them to ACK our FIN, or to receive their FIN (the
simultaneous close case).

I'm suprised we're not in FIN_WAIT_2, since I'd expect the QIP system
to at least ACK our FIN, even if (due to its nameserver's confusion),
it had not called close() or shutdown() on its socket.

It looks like the TCP connection could get stuck in FIN_WAIT_1 forever if
they didn't ACK our FIN.  Many TCP implementations limit the amount of
time that can be spent in FIN_WAIT_2, but it's not obvious from looking at
BSD or Linux code that they implement a timer for FIN_WAIT_1.

paul