[PATCH] nslookup: ensure unique transaction IDs for the DNS queries
Denys Vlasenko
vda.linux at googlemail.com
Wed May 10 08:58:00 UTC 2023
On Tue, May 9, 2023 at 7:48 PM Rich Felker <dalias at libc.org> wrote:
> On Tue, May 09, 2023 at 07:33:40PM +0200, Denys Vlasenko wrote:
> > On Sat, Oct 8, 2022 at 7:23 PM Uwe Kleine-König <uwe at kleine-koenig.org> wrote:
> > >
> > > The transaction IDs generated by res_mkquery() for both glibc and musl only
> > > depends on the state of the monotonic clock.
> >
> > Hmm... did you report this to them?
>
> Yes. It's not a fixable "problem" -- the libc res_mkquery can't know
> when or in what context the caller intends to use the packet it
> produces, so it can't be responsible for guaranteeing it can't have an
> id collision. The space is way too small to avoid collisions in any
> case. If we went out of our way (going stateful) to make the assigned
> ids more sequential (not "independent"), we'd just be reducing the
> (already weak) unpredictability without gaining a useful property.
You miss the point. CLOCK_MONOTONIC may simply be too granular
on some hardware - returning the same value for the duration of
several milliseconds. In this case, musl's IDs will be the same
for successive calls of res_mkquery() - not simply "insufficiently random".
Maybe hash in the message bytes in addition to using current nanoseconds?
(While we are at it. There is a *signed* division by 256 in the code,
intended to mean "take the second byte":
int id;
...
chars[0] = id / 256;
gcc quite often does NOT convert signed divisions to a simple shift.
Maybe change id's type to "unsigned"?
).
More information about the busybox
mailing list