zone transfers sticking on one port?

Chris Fabri fabric at northwestern.edu
Tue Mar 16 17:46:31 UTC 2004


At 10:45 AM 3/16/2004, Jim Reid wrote:
> >>>>> "Chris" == Chris Fabri <fabric at northwestern.edu> writes:
>
>     Chris> You may say it's stupid firewalls, but the way I see this,
>     Chris> the application is not dealing with this in an optimal
>     Chris> fashion.
>
>You can call it whatever you like. But that doesn't make it so. Think
>about this for a microsecond. If a stupidly configured firewall is
>blocking traffic to/from some port, presumably that's been done for a
>reason. [It may be a stupid reason, but it's a reason nonetheless.]
>How is the application supposed to know it's meant to try some other
>port instead of the one that's been blocked? How will it know which
>other port or ports to try? For bonus points, consider what this means
>for the site's (stupid) security policy. They have blocked traffic to
>some port number in the hope/expectation of denying access to some
>service or protocol. Yet if the application was able to guess some
>other acceptable port for that service/protocol, it can get access.


named uses ports >1024 to initiate these zone update requests, so it knows 
what other ports it can use.      We blocked one port for a specific 
reason, to stop an app that uses that port. Obviously if the  application 
is designed to use a different port, then the port block is useless, and I 
assume those making the decision wouldn't have done this, because it would 
be useless.

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

Can I ask the question of what is trying to be accomplished with these 
connections initiatated on random high ports?       (and yes, I know I can 
lock this down to one port - I'm not doing this to be belligerent.  I'd 
just like to know).



>     Chris> However, would disabling IXFR, which would force a TCP port
>     Chris> AXFR transfer make this specific point a non-issue?
>
>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.


That's not what I've observed.    These were all initiated on UDP 
ports.  bUt I see that this wouldn't make a difference.


>     Chris> Since the TCP connection would realize it's not hearing back,
>     Chris> and then use a different port?
>
>No. You don't seem to have an understanding of how TCP works. Or the
>applications that use TCP. Suppose my client can't connect to your web
>server, what makes you think it should try connections to random port
>numbers in the hope of finding some listener on your server that speaks
>HTTP? If things did work this way, what's the point of doing port
>filtering in a router or firewall? What would be the point in binding
>well known services like SSH, HTTP, FTP, DNS, SMTP, etc to fixed port
>numbers?


Sorry, I got myself all confused on this by the fact that named uses random 
ports for this.      You're right.

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


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









More information about the bind-users mailing list