dns query id not changing
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