zone transfers sticking on one port?

[Jim Reid]

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

    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.

    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?