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