Re: [DNSOP] Pointless FUD and confusion about DNSSEC deployment
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
Re: [DNSOP] Pointless FUD and confusion about DNSSEC deployment
On Mon, 18 Aug 2008, Paul Hoffman wrote: At 1:27 PM +0100 8/18/08, Jim Reid wrote: The fact is DNSSEC is the *only* game in town for preventing cache poisoning. Note the subject of this particular thread. A more carefully-worded sentence would be The fact is DNSSEC is the *only* game in town for completely preventing cache poisoning. We have methods to reduce an attacker's ability to poison caches effectively. If the DNSSEC cache doesn't verify the records it caches, it is still suceptible to poisoning. DNSSEC caches that verify are subject to a crypto-overload attack by large numbers of queries. Both kinds of attacks ultimately result in a DOS --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
Re: [DNSOP] Pointless FUD and confusion about DNSSEC deployment
Jim Reid wrote: I suspect you're talking about the absurdly hypothetical scenario where someone gets a non DNSSEC-aware resolving server to lookup some RRSIG, Suppose you are using DNSSEC-unaware caching forwarder shared by others including those who are using PODS, which is often the case when you are behind NAT. RFC3225 does admit such a case as: non-compliant caching or forwarding servers inappropriately copy data from classic headers as queries are passed on to authoritative servers, the use of a bit from the EDNS0 header is proposed. You ask a query on some name, maybe with DO bit set, and receive an answer without any SIG RRs. You now ask SIG RRs of the name through TCP (SIG RRs is usually larger than 1500B and can easily be larger than 64KB) and the SIG RRs will be cached, if everything works fine. Sorry we are talking about RFC 4035 not RFC 2535. RFC 2535 was designed to work through a non-RFC 2535 aware cache. RFC 4035 requires the upstream cache to be RFC 4035 aware. RFC 4035 compliant validators DO NOT request RRSIGs if they are missing from the response. Instead the response is rejected if it is deemed the response should have included them. The type code roll prevents RFC 2535 aware caches impacting on the operation of RFC 4035 validators. There are a lot of possibilities that you can't get any SIG RRs, though. For example, the caching forwarder may not support TCP or may not be able to accept large answers. And lack of TCP support will also break PODS responses as well. Authoritative servers can sometimes get away with disabling TCP. Stub and caches have never been able to get away with disabling TCP. And, you must turn DNSSEC off, which is the instability I already mentioned. If you are little more unlucky, server's cache may overflow, inappropriate code against which may crash the server, which may never occured before with small PODS answers. It should also be noted that, in RFC3225, SIG RR query through TCP, which is unavoidable in this case, is considered harmful as: TCP DNS queries result in significant overhead due to connection setup and teardown. Operationally, the impact of these TCP queries will likely be quite detrimental in terms of increased network traffic (typically five packets for a single query/response instead of two), increased latency resulting from the additional round trip times, increased incidences of queries failing due to timeouts, and significantly increased load on nameservers. Masataka Ohta PS I'm very happy now because my proposal of Simple Secure DNS, which was designed to carefully avoid using large messages, is not deployed. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Pointless FUD and confusion about DNSSEC deployment
Mark Andrews wrote: RFC 4035 requires the upstream cache to be RFC 4035 aware. Thanks. As examplified by assumptions of RFC3225, that's a so unrealistic requirement that no further discussion on DNSSEC is necessary. PERIOD. And lack of TCP support will also break PODS responses as well. Authoritative servers can sometimes get away with disabling TCP. Stub and caches have never been able to get away with disabling TCP. In theory, yes, in practice, only those who supply large RRs requiring TCP (or EDNS) will suffer. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Pointless FUD and confusion about DNSSEC deployment
Mark Andrews wrote: RFC 4035 requires the upstream cache to be RFC 4035 aware. Thanks. As examplified by assumptions of RFC3225, that's a so unrealistic requirement that no further discussion on DNSSEC is necessary. PERIOD. Given just about anyone can configure a validator to talk directly to authoritative servers or can configure it to talk to a cache which *is* DNSSEC aware which in turn talks to the authoritative servers directly, I'm not worried about those that *choose* to use a forwarder which is not DNSSEC aware. In other words just about anyone that wants to use DNSSEC can put themselves in a position to use DNSSEC. The tools are available to do it. We know there is unlikely to ever be universal deployment of DNSSEC. The fact that it is not universal however should not be seen as a reason not to deploy it where it can be deployed. And lack of TCP support will also break PODS responses as well. Authoritative servers can sometimes get away with disabling TCP. Stub and caches have never been able to get away with disabling TCP. In theory, yes, in practice, only those who supply large RRs requiring TCP (or EDNS) will suffer. Well we are there now. Lots of answers require EDNS and/or TCP and the DNS resolution has not fallen over. Masataka Ohta -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
