BIND's vulnerability to packet forgery

[D. J. Bernstein]

BIND company employee Jim Reid writes:
> You said that BIND9 used /dev/random for random query ids. The code
> snippet above clearly disproves that.

BIND 9 uses /dev/random for query IDs, through a convoluted chain of
functions including isc_entropy_usebestsource(), reseed_lfsr(), and
dns_randomid(). Other people have already explained that you aren't
reading the code correctly.

  [ random() is easily predictable ]
> Indeed. So is any other computer-generated "random" number process
> unless it's driven off something truly random like radioactive decay.

Wrong again. Cryptographically strong generators start from a short
secret, typically 256 bits, and are unpredictable to everyone who
doesn't know the secret.

> IIRC Mr. Turing had something to say about that.

In fact, what Turing said was that he had a cryptographically strong
generator: ``I have set up on the Manchester computer a small programme
using only 1000 units of storage, whereby the machine supplied with one
sixteen figure number replies with another within two seconds. I would
defy anyone to learn from these replies sufficient about the programme
to be able to predict any replies to untried values.''

> > Randomizing the port number makes a huge difference in the cost of a
> > forgery for blind attackers---i.e., most attackers on the Internet.
> Anyone mounting a serious attack on the DNS is unlikely to be blind.

If you believe that, why don't you rip the useless ID randomization code
out of BIND? Of course, you'll have to find the code first.

> Now Secure DNS prevents faked answers because the DNS packets are
> signed. ie It can be proven an answer for www.amazon.com *really* does
> come from a name server for amazon.com and the answer hasn't been
> tampered with since it left that server.

You are talking about a fantasy world where .com registrants give DNSSEC
keys to VeriSign, which signs and distributes those keys. That isn't
happening now, and it isn't going to happen in the foreseeable future.

---Dan