zone transfers sticking on one port?

[Barry Margolin]

In article <c37b4s$2ni7$1 at sf1.isc.org>, Jim Reid <jim at rfc1035.com> 
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.

I think you're being a bit harsh.  Port blocking like this is 
practically always intended to stop incoming traffic to a well-known 
server port.  If an outbound query uses an unpredictable source port, 
it's not possible that the port block could be meant to block it (unless 
they're blocking the whole range of ports from which the source port is 
selected, in which case trying a different port will be futile, but 
won't get around it).

A listening application can't just switch to another port to get around 
a filter, because none of the clients that try to connect to it would 
know about the alternate port.

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