Subject: Re: random ip_id must be configurable
To: None <email@example.com>
From: Jun-ichiro itojun Hagino <firstname.lastname@example.org>
Date: 09/16/2003 10:38:42
> Getting back to the original problem I was talking about:
> On Sat, Sep 13, 2003 at 05:04:01PM +1000, Simon Burge wrote:
> > id 52018 last call for id at 465455, current call 465456 (diff 1)
> > id 61704 last call for id at 3483418, current call 3483419 (diff 1)
> Do we have any protocol problems when using this generator in its
> current form? One case I'm specifically wondering about is in
> dns client sends request #1 with id N for host www.foo.com
> dns client sends request #2 with same id N for host www.bar.com
> server replies to request #2 with result 188.8.131.52
> server replies to request #1 with result 184.108.40.206
> Is there anything in the dns client code that would detect that the
> replies were sent in reverse order, or will the application assume that
> because the ID matches that everything is ok?
> Maybe we should #ifdef out the use of the current generator until this
> problem is addressed?
with which revision did you perform the test? if possible put the
test code to src/regress? btw, by calling randomid() too frequently
didn't you put arc4random() into entropy starvation?
if dns clients are different process, they would use the different UDP
source port for #1 and #2, so there's no problem.
otherwise, res_send() checks if the question section of query matches
the reply, so there's no big confusion (id check happens beforehand,
so that could affect the end result).