zone transfers sticking on one port?

Barry Margolin barmar at alum.mit.edu
Tue Mar 16 21:19:41 UTC 2004


In article <c37om5$2vok$1 at sf1.isc.org>, Jim Reid <jim at rfc1035.com> 
wrote:

> >>>>> "Barry" == Barry Margolin <barmar at alum.mit.edu> writes:
> 
>     >> The port chosen is essentially random. But it's repeatable. The
>     >> choice the kernel makes is determined by factors like which
>     >> ports are currently in use. So if the overall TCP state of the
>     >> host is unchanged between connection attempts, the chances are
>     >> the kernel will pick the same ephemeral port number. However
>     >> this is an implementation issue for your kernel's TCP/IP stack.
> 
>     Barry> BIND asks the OS to select a port when it first starts up.
>     Barry> So for the life of that named process it always uses the
>     Barry> same port number.
> 
> Yes and no. That's certainly how BIND used to work. But the BIND9
> servers here don't have a TCP socket for zone transfers even though
> they slave several zones. [lsof shows the servers only have (listening)
> TCP sockets for ports 53 and 953.] named is creating and destroying
> sockets for zone transfers as it needs them. When I've forced one of
> these servers to do a zone transfer, it's used a different source port
> each time.

I was describing the UDP socket, not the TCP socket, since the OP's 
filter was blocking UDP.  TCP works as you said (you can't reuse the 
same socket for multiple connections), but is irrelevant to the 
discussion.

-- 
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***


More information about the bind-users mailing list