[dns-operations] Why non-repeating transaction IDs?

[bert hubert]

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
http://ds9a.nl/tmp/draft-ietf-dnsext-forgery-resilience.html#anchor17

I'd very much advise BIND to do something like this.

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services