[dns-operations] CERT VU#800113 Multiple DNS implementations vulnerable to cache poisoning

[bert hubert]

On Fri, Jul 11, 2008 at 07:28:16AM +0000, Lutz Donnerhacke wrote:
> * bert hubert wrote:
> > Right now, DNS as it is really only needs (say) an additional 16 bits of
> > entropy beyond what source port randomisation can provide. DNS over TCP
> > offers that today, btw.
> 
> Those 16bit shift the attack time from seconds to hours. For poisoning a
> central resolver of a large broadband access provider, this does not matter.

Lutz,

Unless my math is way off, which is very possible, the 16 source port bits
move you from seconds to hours. The additional 16 bits I described above
would get you from hours to years.

But you may be right. I haven't heard of any TCP/IP hijacks lately, the
famed 'Mitnick-attacks' of the past. However, TCP/IP has around 16+32+32=80
bits of entropy to play with. Some bits are lost because of window size etc,
and to other things, so give it a good 70 bits.

If we get DNS to the same level of entropy, we should be safe, or at least
as safe as TCP which I hear no worries about.

DNS is now at 16 (source port) + 16 (id) + 1 (nameserver), so indeed the 16
extra bits I mentioned above would only get us to 49.

So adding 32 bits or even 48 bits of additional random would be best.

The algorithm might in fact be quite simple: 
	1) See if a remote nameserver talks extended query id. 
	2) If it doesn't fall back to TCP and get the bits from there. 
	3) If that doesn't work, wait for people to fix their firewalls.

What do you think? Move to DNSEXT? There has already been extended query id
discussion there.

	Bert

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