dns query id not changing
Mark Andrews
Mark_Andrews at isc.org
Fri Dec 17 00:04:38 UTC 2004
> 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
More information about the bind-users
mailing list