zone transfers sticking on one port?
Chris Fabri
fabric at northwestern.edu
Thu Mar 18 18:04:05 UTC 2004
At 05:11 PM 3/16/2004, Chris Fabri wrote:
>THese are UDP connections. It's been established that they are
>handled differently by the kernel when named requests the socket. I'll
>need to look into this portion further, I haven't spent any time looking at
>this, I hadn't even thought of it as part of the problem. I've been
>looking at this more from the network side than the system side (once the
>connection leaves the box, not from where it's initiated by the application.
Ok, I was wrong about these connections. They are being initiated as TCP
connections, although i swore they were UDP at the time. They are using
slowly increasing random port numbers, though. I would say that It's
possible that eventually it will cycle through all the ports enough times
that there would be several sockets that have been opened on 39999 that
just sit there and keep trying. But I had other ports blocked and I would
expect to see this.
UDP connections that are being established are always on the same port. I'm
seeing zone change notifications from the remote server always coming in
from the same UDP port, looks the same for my server.
I don't feel like I've made any more headway on this. UDP connectios
should have only had problems if that port was picked at startup, and I
didn't see the problem right at startup. But TCP connections should have
had problems with all my blocked ports.
I'm clearly missing something somewhere that happened, but without putting
the port blocks on, I'm not sure I'm going to figure this out. I've got
other fish to fry, just thought I'd get this followup information that I
said I'd do. chris
More information about the bind-users
mailing list