dns query id not changing

Adam Denenberg straightflush at gmail.com
Fri Dec 17 15:24:03 UTC 2004

yeah i understand it will be reused.  My issue is that in the
application, every time i run tcpdump and check, the 3rd request for a
certain A record is always the same as the 2nd (same Transaction ID).=20
So my conern is why the resolver is doing this.  This is reproducable
behavior and is inconsistent with the way other queries are run.

I wrote a small test script to do a gethostbyname_r() in a for loop of
100 queries and this never happens.  However in the application
(pam_ldap/nss_ldap) the 3rd Transaction ID is always the same as the

i am trying to find the cause of this behavior, b/c it is breaking the
applicatoin when dns requests traverse the FW.


On Fri, 17 Dec 2004 07:13:38 +0000 (UTC), phn at icke-reklam.ipsec.nu
<phn at icke-reklam.ipsec.nu> wrote:
> Adam Denenberg <straightflush at gmail.com> 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.
> As this id os a 16-bit value it will be reused fast.
> Do as others suggested, fix the pix! Change vendor if needed.
> --
> Peter H=E5kanson
>         IPSec  Sverige      ( At Gothenburg Riverside )
>            Sorry about my e-mail address, but i'm trying to keep spam out=
>            remove "icke-reklam" if you feel for mailing me. Thanx.

More information about the bind-users mailing list