dns query id not changing

[Mark Andrews]

> 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

	The issue is that the firewall is broken.

	A client can re-use a transaction id as fast as it likes.  They
	are only there to distiguish between multiple concurrent queries.

	A nameserver talking to a forwarder can issue thousands of queries
	a second.  It only takes a couple of seconds to cycle through the
	id space (16 bits).

	A firewall should just add a entry for <Saddr,Sport,Daddr,Dport,ID>
	and allow *multiple* answers to come in that match that tuple for
	a short period of time.  If a client sends another query with
	the same <Saddr,Sport,Daddr,Dport,ID> tuple it should just restart
	the expiry timer.  Any other behaviour is broken.


> 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
> >
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org