dns query id not changing

Fri Dec 17 02:06:55 UTC 2004

> i agree.  However, this seems to be happening over and over.  The 3rd
> dns request (as part of about 4 or 5  that are required for a pam_ldap
> loginvia ssh)  are always using the same query ID as the 2nd request. 
> THis is not random.  Something in the resolver is causing it to use
> the same query ID and i am trying to find out if this is either a bug
> in the resolver (probably not since i tried this on various flavors of
> linux) or some other predictable behavior.  I just cant seem to find
> an explanation for the behavior.  If each request is to be random then
> it should be random.  But if every 3rd request is the same as the 2nd,
> then this is not random.  I can reproduce this behavior every time.
> 
> is there anything in the resolver that would cause it to reuse a query
> Transaction ID.  I assume its nothing for performance?  Something is
> definitely up here...
> 
> adam

	When all else fails.  Read the source.

> On Fri, 17 Dec 2004 11:04:38 +1100, Mark Andrews <Mark_Andrews at isc.org> wrote
> :
> > 
> > > Well the issue is that that same "tuple" is coming in as the firewall
> > > is tearing down the connection.  The firewall needs about 60ms for the
> > > connection to expire according to Cisco.
> > >
> > > I agree that there is definitely an issue with the firewall, but it
> > > was also my understadning  the resolver used random query IDs for each
> > > request.  Out of nowhere, the resolver appears to re-use a query ID
> > > that it just used in a very short span (20ms) and it confuses the
> > > firewall b/c the firewall has not torn down the previous connection.
> > > Shouldnt this behavior be somewhat consistent?
> > >
> > > We have an application (pam_ldap) that needs to make 3 or 4 DNS
> > > requests. The 3rd dns request is _always_ using the same ID as the 2nd
> > > DNS request and occurs in about 10ms before the firewall has torn down
> > > the original connection and thus causes a timeout (the FW drops it).
> > >
> > >  I guess what i am trying to figure out is why the behavior of the
> > > resolver for creating a query ID is not consistent.  It should either
> > > reuse the same one, or create totally random ones.  It is doing a
> > > little bit of both and thus breaking the app.
> > >
> > > thanks
> > > adam
> > 
> >         Think about random numbers.  Truely random numbers can bring up
> >         the same number multiple times in succession.
> > 
> >         This is a random sequence of digits.
> > 
> >                 1 4 6 3 4 3 5 9 8 7 7 3 2 0
> > 
> >         Mark
> > 
> > > On Fri, 17 Dec 2004 10:34:31 +1100, Mark Andrews <Mark_Andrews at isc.org> w
> rote
> > > :
> > > >
> > > > > 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 i
> n
> > > > > some situations is it not unique.  If the linux box make 2 reqeusts i
> n
> > > > > 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 querie
> s.
> > > >
> > > >         A nameserver talking to a forwarder can issue thousands of quer
> ies
> > > >         a second.  It only takes a couple of seconds to cycle through t
> he
> > > >         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 f
> or
> > > >         a short period of time.  If a client sends another query with
> > > >         the same <Saddr,Sport,Daddr,Dport,ID> tuple it should just rest
> art
> > > >         the expiry timer.  Any other behaviour is broken.
> > > >
> > > >
> > > > > On Fri, 17 Dec 2004 08:31:34 +1100, Mark Andrews <Mark_Andrews at isc.or
> g> w
> > > rote
> > > > > :
> > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > I am experiencing an issue on redhat 8 with the resolver where th
> e
> > > > > > > "Transaction ID" in the dns query is not changing.  This is causi
> ng o
> > > ur
> > > > > > > firewall to drop packets b/c a second dns request is coming in wi
> th t
> > > he
> > > > > > > same udp port, ip, and transaction id.  The firewall still has th
> e
> > > > > > > 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 firewa
> ll
> > > > > >         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.o
> rg
> > > > > >
> > > > --
> > > > 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
> >
> 
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org