zone transfers sticking on one port?

[Chris Fabri]

At 10:52 AM 3/16/2004, Barry Margolin wrote:
>In article <c37913$2m5i$1 at sf1.isc.org>,
>  Chris Fabri <fabric at northwestern.edu> wrote:
>
> > You may say it's stupid firewalls, but the way I see this, the application
> > is not dealing with this in an optimal fashion.
>
>How is it supposed to know that the port is being blocked?  If it
>doesn't get a response, it's much more likely to be a problem with the
>remote server than a block on a randomly-chosen port.


Well, named does know if it's gotten an updated zone, independently of 
getting the packets back.    Theoretically, I imagine you could figure it 
out, although I don't think it would be pretty, and in the case of the 
server being unreachable, maybe all the extra work would DOS itself.     I 
know, I'm looking at a solution for a very narrow problem, and it isn't the 
right one.




>And as was pointed out, you can configure a specific port for it to use,
>if you know you have blocks on ports in the ephemeral range.


Yup, although if for some reason that port got blocked, you'd be 
hosed.   But I was sorta hosed anyway.     Hence my question about what was 
the initial goal of having it choose a random port in the first 
place.  Would I be better off just using a source port of 53, since 
(almost) nobody would be brain-dead enough to block that off?       chris