dns query id not changing

Adam Denenberg straightflush at gmail.com
Thu Dec 16 22:09:35 UTC 2004


well the issue is that this is not a retry.  The linux box makes a
successful DNS request with Transaction ID A, then the DNS Server
replies with Transaction ID A.  Then the linux box makes another
request with ID A however the Firewall still has the original request
in its state table so the firewall drops the reply.   This is very
inconsistent behavior, since in almost all other cases the DNS
Transaction ID is unique per request.  So i am trying to figure why in
some situations is it not unique.  If the linux box make 2 reqeusts in
too short of a time frame for the same A record, coming from the same
UDP port, same IP and same Transaction ID within say 30ms, the FW
drops the request.  The firewall needs some piece of informatino to
distinguish DNS requests and it uses DNS Transaction ID.

Can anyone explain why the linux resolver would use the same
Transaction ID, isnt this supposed to be random per DNS request?

adam

On Fri, 17 Dec 2004 08:31:34 +1100, Mark Andrews <Mark_Andrews at isc.org> wrote:
> 
> > Hello,
> >
> > I am experiencing an issue on redhat 8 with the resolver where the
> > "Transaction ID" in the dns query is not changing.  This is causing our
> > firewall to drop packets b/c a second dns request is coming in with the
> > same udp port, ip, and transaction id.  The firewall still has the
> > first dns request in its state table and is causing the firewall to
> > drop the susequent packets due to this.
> >
> > Has anyone encountered this issue (possibly the resolver in glibc 2.2?)
> > and know if there is a workaround?
> >
> > thanks
> > adam
> 
>         Get a decent firewall.  The transaction ID is allowed
>         (expected) to be the same on retries of an query.  A firewall
>         which blocks this is broken.
> 
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
>



More information about the bind-users mailing list