[dns-operations] Why non-repeating transaction IDs?
bert.hubert at netherlabs.nl
Fri Aug 3 20:39:55 UTC 2007
On Fri, Aug 03, 2007 at 05:11:30PM +0000, Paul Vixie wrote:
> > So you randomize source ports too, adding nearly 16 bits to the 16 bits of
> > random already available. 31.97 bits of random is nothing to sneeze at if
> > you have a 100ms timeframe to scan it.
> i first heard this idea from dan bernstein, and it's a good one. in my own
It is indeed very good. It additionally alows a resolver to connect() its
sockets, which means ICMP messages get delivered to the nameserver, allowing
it act more quickly on filtered or non-running remotes.
> hacking (not part of BIND, at least not yet) i've been keeping up to 16
> outbound UDP sockets open with kernel-assigned port numbers, and closing each
> when the number of transactions still using that socket goes to zero. this
> gives me 16 distinct 16-bit ranges, which is almost like a 20-bit query ID
> but i'm sure that the upper 4 bits of that "extended query ID" are quite
> predictable. their purpose is to protect the predictability of the bottom
> 16 bits, rather than to be unpredictable in their own right. should BIND be
> doing something like this? (should there be an I-D on it, and does anyone
> think that dan bernstein would be willing to co-author it since this was
> really his idea?)
If I understand you correctly, having 16 random ports as you describe is a
subset of the proposals in
I'd very much advise BIND to do something like this.
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
More information about the dns-operations