zone transfers sticking on one port?

[Chris Fabri]

At 06:35 PM 3/15/2004, Mark Andrews wrote:

> > At 05:56 PM 3/15/2004, Mark Andrews wrote:
> >
> >
> > >         Failure to get a answer is not normally a reason to change
> > >         port.  It normally indicates that a host / link is down.
> > >         Changing port is not a indicated solution to this problem.
> > >
> > >         Even if named was capable of receiving the ICMP message
> > >         (your firewall does generate a ICMP message?) there is
> > >         nothing in ICMP messages to say "Try a different source
> > >         port".
> >
> >
> > Not a firewall.  Just a port block on the border.  But this is what I need
> > to know, named should behave that way.   And I know what to look for in 
> the
> > future.
>
>         You implemented a firewall when you blocked the port.  While
>         firewall often perform other functions the simplest firewalls
>         are just port blockers.


Ah yes, Mr. Specific, that is true.  :)  I like to think of a port block as 
a port block, and a firewall as something a bit more complex .  Po-tay-to, 
po-tah-to, just how we look at it.     I think lumping a simple port block 
into the category of "firewall" justs adds to the confusion when you have 
to describe this stuff to the non-technical, despite the fact that they do 
in fact server the exact same function.

>
> > named may not be capable of receiving an ICMP message, but it knows if it
> > doesn't get a response back or not, right (based on whether the zone gets
> > transferred or not)?    Is this something that would be useful for bind to
> > do, skip on to another port if it's not successfully loading the
> > zone?
>
>         No.  Stupid firewalls should be fixed not worked around.


My suggessting was for dealing with stuff outside of *my* control.   If NU 
made the mistake of blocking this port, it's certainly feasible for other's 
to do the same.     I can't fix somebody else's stupid firewall, and will 
perhaps only be marginally more successful dealing with it's adminstrator.


You may say it's stupid firewalls, but the way I see this, the application 
is not dealing with this in an optimal fashion.

However, would disabling IXFR, which would force a TCP port AXFR transfer 
make this specific point a non-issue?  Since the TCP connection would 
realize it's not hearing back, and then use a different port?   Obviously 
this is sub-optimal for a number of other reasons, but I'm just trying to 
get my head around all aspects of this.   chris