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