So, look at other options:
* Widen the query space by using multiple IP addresses as source. This, of course, has all the problems with NAT gw's that the port solution did, except worse.
This makes using your ISP's "properly designed" resolver even more attractive, rather than running a local recurser on your company's /28 of public IP space, but has the unintended consequence of making those ISP recursers even more valuable targets.
Makes you wish for wide deployment of IPv6, eh.
The only real fix I see is to deploy DNSSEC.
You seem to be saying, above, that IPv6 is also a real fix, presumably because it allows for the 64-bit host id portion of an IP address to "fast flux". Or have I misunderstood?
No, IPv6 is a *potential* fix for the *problem being discussed*, in a practical but not absolute sense. Let's discard the "fast flux" concept, because that's not really right. Let's instead assume that an entire 64-bit space is available for a DNS server to send requests from, not due to rapidly changing IP addresses, but because they're all bound to loopback, and hence always-on. This means that the server can simultaneously have outstanding requests on different IP's, which is why I want to discard "fast flux" terminology. We had a problem with DNS. The problem identified by the released exploit was the fairly obvious one that the query ID is only 16 bits. What that means is that you can readily guess a correct answer 1/65536 times. So you simply hammer the server with all 65536 answers while asking questions until you win the race between the time the server sends a query and the legitimate server responds, rendering the QID useless. The "port fix" increases the search space significantly. Probably to the point where you can not practically send 65536 * 64512 packets (4 billion, all 65536 possible qid's to all 64512 nonpriv ports) within an appropriate timeframe. Regardless, you can keep trying a small number of bogus answers, and over time, statistical probability says that you will eventually get lucky. The sharp folks will realize that this is essentially what is happening in the first scenario anyways, just with smaller numbers. Expanding the search space by adding 64 bits brings the potential total up to roughly 64 + 16 + 16 bits, or about 96 bits. This reduces the likelihood of success substantially, and even allowing for increased network speeds and processor speeds over time, I don't think you'd get a hit in your lifetime. ;-) However, DNSSEC is a better solution, because it also works to guarantee the integrity of data (it will work to solve MITM, etc). So, for the vulnerability just released, yeah, IPv6 could be a solution, but it is a hacky, ugly, partial solution. It would fairly exhaustively fix the problem at hand, but not the more general problem of trust in DNS.
It would be nice for someone to explain how (or if) IPv6 changes this situation since many networks are already well into the planning stages for IPv6 deployment within the next two to three years.
Personally, I wouldn't worry too much about it. What we really need is some political backbone behind getting DNSSEC deployed, because the vulnerability that was just released is just one of many possible attacks against the DNS, and DNSSEC is a much better general fix, etc. I do not believe that you will find an IPv6 extension of this sort useful in the short term, and in the long term, I'm hoping for DNSSEC. Now you can fully appreciate my comment: "Makes you wish for wide deployment of IPv6, eh." Because if we did have wide deployment of IPv6, adding 64 bits to the search window would certainly be a practical solution to this particular attack on the protocol. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.