zone transfers sticking on one port?

[Chris Fabri]

At 01:18 PM 3/16/2004, Jim Reid wrote:
> >>>>> "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.


Sorry, when I said it knows what port, I mean that it knows it will be a 
port in that range, not specifically what port it would use.

>     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.

If that's the odds, explain why I was getting virtually all of my outbound 
UDP  connections going out port 39999?   Barry's explanation made sense 
(named picking a UDP port on startup), but that's not what I've seen 
happen.  I"m actually going to look at the traffic again to verify this.

Now, this could have happened at another time on a different port that was 
blocked, so maybe I'd see the exact same behavior on a different port.


>     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.


Well, these are UDP connections.  that's a convention, as you've said, i 
could just hardcode the port.  which is certainly an available 
solution.  We've exempted our nameservers from the block, which is the best 
solution.  But I'm curious as to what is actually going on here.


>     >>  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.  <snip>


Somebody has disputed this.




>     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.

<snip>

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.

And thanks to all for your input.    I'm getting a lot out of this.   I'm 
not trying to come across as adversarial, so I apologize if that's how it 
seems.   There's clearly many aspects of this that I'm not fully up to 
speed on.   chris