On Mon, 18 Aug 2008, Jim Reid wrote:
> On 18 Aug 2008, at 05:11, Dean Anderson wrote:
>
> > Ok, I agree that totally DNSSEC-oblivious servers won't be a problem
> > for DOS, but of course remain susceptible to poisoning even if the
> > stub resolver and the authority server both implement DNSSEC.
>
> Kindly explain how is this any different from when poisoning occurs
> when stub resolver and authority server don't implement DNSSEC.
Its not any different; its exactly the same problem. And DNSSEC creates
more problems, without solving any.
> The fact is DNSSEC is the *only* game in town for preventing cache
> poisoning.
TCP is another 'game in town'. We may also be able to invent other
'games', as DJB suggests.
> So to go back to David's original question: will deploying DNSSEC
> break anything that's already in use that doesn't support DNSSEC?
Yes: DNSSEC enables DDOS attacks that didn't exist before, and doesn't
eliminate any attacks that previously existed.
> >> Now if that resolving server does pay attention to the DO bit, it
> >> will set it on the query it makes to the authoritative server. That
> >> makes the authoritative server return an answer which will contain
> >> the new RRSIG and the resolving server's cache is updated
> >> accordingly.
> >
> > Ok. So what about caching servers that do understand the DO bit but
> > don't actually verify the responses? They just cache the response
> > for the stub resolver to verify? These servers can still be
> > poisoned with invalid record combinations that they pass on to stub
> > resolvers, resulting in the DOS. Such servers may still be subject
> > to the race condition I described.
>
> How is this different from a resolving server not getting the correct
> answer because it queried an authoritative server that hasn't seen the
> latest version of the zone on the master?
In that scenario, the old data is consistent. In my scenario, poisoning
has created inconsistent data on the non-verifying DNSSEC cache.
> In fact in the somewhat contrived scenario you pose, the stub resolver
> gets a validation failure. So they at least know something has gone
> wrong. Which has to be a great leap forward from getting bad
> (poisoned) data and not having the slightest clue that has happened.
The resolver 'knows' perhaps, but the user doesn't know anything. They
just know that they typed in 'www.yahoo.com' and got no IP address.
That's a DOS.
And its no leap forward. In the original cache poisoning case, the user
either gets, nothing, a non-working IP or they get the wrong server. If
they get the wrong server, their SSL verification and trust procedure
will exclude that server from use. That's a DOS, too.
> Ahhh. I see it now. Someone will deploy DNSSEC in their stub resolver.
> But then they'll make that query a resolving server that doesn't speak
> DNSSEC whenever their stub resolver wants to do a DNSSEC-aware lookup.
> Right. Makes perfect sense. [Add scarcasm to taste.]
No, I already agreed that a totally DNSSEC-oblivious wasn't going to
pose a DNSSEC problem. Your sarcasm is misplaced.
--Dean
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
