Recursive queries fail if query source port is not fixed

Hans F. Nordhaug Hans.F.Nordhaug at hiMolde.no
Thu Aug 14 07:48:09 UTC 2008


* Mark Andrews <Mark_Andrews at isc.org> [2008-08-14]:
> 
> > * Mark Andrews <Mark_Andrews at isc.org> [2008-08-14]:
> > > 
> > > 	Does "dig ns . @198.41.0.4" succeed when run from the box
> > > 	running the nameserver?
> > 
> > Yes.
> > 
> > I still don't understand why most recursive queries only works after
> > many, many tries - argh. Oh, I just tested doing one query, waiting 
> > 30 seconds and then trying - success. Hm, maybe there is a time-out 
> > issue after all? 
> > 
> > And "dig porttest.dns-oarc.net txt" never seems to work ;-) Because it
> > changes all the time ...
> > 
> > Hans
> 
> 	I suspect that you are overwhelming some state table in
> 	one of the firewalls.

Hm, that actually seems like a plausible reason. I don't get any
obvious reports from the Cisco ASA, but I'll dig into it.

> 	With "port 53" you didn't need to keep state in the firewall
> 	as you were allowing all packets to port 53 which includes
> 	reply packets.

(Or with port 40053 which I also tested.)

> 	When you remove "port 53" then the firewall needs to keep
> 	state to allow the reply to come back in. 
> 
> 	When you make the second or third request of the nameserver
> 	it starts its lookups from deeper in the heirachy which allows
> 	it to succeed before the firewall is overhelmed.

OK, that makes sense, but we aren't talking 2-3 requests - sometimes I
have to make 10-20 requests before I get a reply.

Hans


More information about the bind-users mailing list