dns query id not changing

[Adam Denenberg]

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


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> wrote
> > :
> > >
> > > > 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> w
> > rote
> > > > :
> > > > >
> > > > > > 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 o
> > ur
> > > > > > firewall to drop packets b/c a second dns request is coming in with t
> > he
> > > > > > 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
> > >
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
>