zone transfers sticking on one port?

[Chris Fabri]

At 12:58 PM 3/16/2004, Ragnar Paulson wrote:







>So a client randomly chooses an "ephemeral" port, (actually the OS chooses 
>the port when the client requests a random port)
>one of the free ports in the range 1025->65535.   As soon as the OS has 
>told the client a port is free it will initiate the connection 
>attempt.  There is no mechanism for the client to distinguish the failure 
>to respond to this port due to your firewall rule from a failure to 
>respond because the remote server is unavailable.  Would you have clients 
>cycle endlessly through all known ports whenever a remote server failed?

Isn't named going to endlessly query on the same port if it's can't get 
through?    That's essentially what was happening here on 39999.   If the 
server was down, wouldn't every query fail and keep hammering away on 
whatever port it happened to choose?

Let me provide a little more data that I hadn't really considered until 
now.   We're also blocking several other ports that are > 1023.   Was only 
seeing this problem with port 39999.     I would expect the same behavior 
when it hits these other blocked ports.     Is there something different 
about 39999?     These blocks are tcp/udp.    In this case I would expect 
to see the same problem for every blocked port, but this wasn't the case.

So maybe there is something else in addition to the block that needs to 
happen?    We also have a packeteer at our border, but DNS traffic was not 
being shaped in any way, so this shouldn't have introduced any extra 
delay.   chris