[dns-operations] adns vuln posted

[Paul Vixie]

> > libbind in BIND 9 has the same problem, by the way.
> 
> libbind, lacking asynchrony, can reasonably expect its callers to either
> lockstep their queries, or if threaded, to do their own birthday protection.
> 
> adns, possessing asynchrony and offering it as a feature, needs birthday
> protection.

that having been said, if res_mkquery() were to want a random QID rather than
just incrementing the last one, it would need more state to keep track of
duplicate/outstanding queries, and an API change to release these QID's as
transactions timed out.  failure to hold this state and change this API would
yield random failures due to occasional far-end duplicate QID suppression.

further, if res_nsend() were to bind() its socket to a specific port number
then it may need to loop a few times if the one it randomly chooses was busy.
small numbers for "a few" would yield occasional failures when sockets were
actually available.  large numbers for "a few" would lead to occasional high
latency on DNS transactions on extremely busy systems (making them busier.)

finally, if we chose QID's and port numbers at random in the libbind resolver,
using the libc PRNG, they'd still be quite guessable.  if some callers of the
stub resolver lack arc4random() then we'd have to provide that.  if some
callers are embedded systems who don't have room for arc4random() then this
patch would not be universally popular.

openbsd fixes this by making bind() to UDP port 0, or the implicit bind() if
you connect() an unbound socket, choose a fully random port number.  and they
supply arc4random() in their libc so they just call it from their res_mkquery.
(note that they're tolerating occasional failures due to far-end QID duplicate
suppression, which may be the right engineering choice.)

for the portable libbind, what's your proposal?

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.