zone transfers sticking on one port?

[Chris Fabri]

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.

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?   the avoid-udp port flag allows you to at least block it out, that's 
a pretty useful addition, if a port is blocked for a reason outside your 
control, but it would be cool if named could do this on it's own.  I know, 
that's a lot to ask, I'm just thinking out load.  :)


>         Blocking non-reserved ports is always fraught with danger.
>         You will be creating problems for all applications that may
>         use that port not just the malware.  You just happened to
>         see the problems with named.


Not the one made/making that decision, it was based on virus mitigation.  I 
just had to figure out the fall-out.  Hopefully this incident has instilled 
a bit more responsibility in those blocking ports around here.  :)   chris