zone transfers sticking on one port?

[Jim Reid]

>>>>> "Chris" == Chris Fabri <fabric at northwestern.edu> writes:

    Chris> named uses ports >1024 to initiate these zone update
    Chris> requests, so it knows what other ports it can use. 

No it doesn't. In most cases, the kernel decides what source port gets
used for an outbound TCP connection. The application -- named in this
case -- usually doesn't care about that. And it has no easy way of
knowing which ports may be available. That's why the kernel generally
makes that choice for the application. Read the section on "Ephemeral
Ports" in Stevens' "UNIX Network Programming Vol 1". named provides
hooks in named.conf so the source port and address can be set for
things like NOTIFYs and zone transfers. So if you insist the name
server must use a specific source port, you can make it do that.

    Chris> Named is an application that uses multiple ports for this
    Chris> specific function.  But blocking one caused it to get
    Chris> totally confused, and keep trying this port.  So despite
    Chris> using all these ports, a block on one port basically
    Chris> stopped named from performing this function correctly.  And
    Chris> named has all these ports to try, yet it got hung up on
    Chris> this one.

No it didn't. It got blocked because your firewall or router blocked
the traffic. You were just unlucky that the kernel picked the port
your firewall doesn't like. The best/worst odds of this happening are
65535 to 1.

    Chris> Can I ask the question of what is trying to be accomplished
    Chris> with these connections initiatated on random high ports?

Er, TCP connections? Consult the Stevens reference above. Clients are
expected to use high source port numbers for their connection requests.

    >>  No. The choice between IXFR and AXFR has no bearing on port
    >> numbers.  And in reality, most IXFR traffic won't go over UDP
    >> anyway.

    Chris> That's not what I've observed.  These were all initiated on
    Chris> UDP ports.

That's what the IXFR spec says. RFC1995 says make the IXFR request
over UDP but if the reply is too big, the client has to repeat the
request over TCP. In principle this is just like how truncated
responses are handled. If the IXFR deltas are tiny, they will fit into
the standard 512 byte UDP payload. If they're bigger, TCP is needed.

    Chris> Basically what's happening is named is initiating a
    Chris> process, and this process will keep trying to use that same
    Chris> port, regardless of it failing.  It's not talking back to
    Chris> named to say "hey, I'm not getting a response what do I
    Chris> do," and being told "use another port."

    Chris> Am I on the right track to why I'm seeing what I'm seeing?

Sort of, though your choice of terminology is confused. [And you don't
seem to understand how TCP connections get made. I recommend you run
to a bookshop for a copy of "TCP/IP Illustrated Vol 1" and read it
thoroughly.] There's no process being initiated. An application
creates a TCP socket and tries to use it to make a connection to some
name server. Unless the application gives explicit instructions to the
kernel -- a bind() system call in UNIX -- the source port for that
socket will be decided by the kernel. 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.

So if you don't want the name server to get this port number that your
firewall doesn't like, you have two choices. You can put a transfer-source
(or whatever) clause in named.conf to make the name server use some
other port number. Or you could create a dummy application which
listens on this port number and run that on the client. This should stop
the kernel from assigning that port to any outbound TCP connections.