> 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
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