[prev in list] [next in list] [ prev in thread ] [ next in thread ] List: djbdns Subject: dnscurve load From: "D. J. Bernstein" <djb () cr ! yp ! to> Date: 2011-01-06 19:51:20 Message-ID: 20110106195120.28892.qmail () cr ! yp ! to [Download RAW message or body] Happy new year, everybody! I'm writing this message for people who are considering the following three recommended steps to improve their DNS security--- (1) Add DNSCurve to incoming DNS data. This means upgrading your DNS cache to support DNSCurve. (2) Add DNSCurve to outgoing DNS data. This means installing a DNSCurve forwarder, such as Harm van Tilborg's CurveDNS. (3) Have every machine take care of its own incoming DNS data. This means installing an independent cache on each machine, rather than relying on a centralized cache. ---and who are wondering what impact these steps will have on their DNS load. Here's the answer: (1) Upgrading your DNS cache to support DNSCurve will make some packets slightly longer (adding cryptographic protection to your communication with DNSCurve servers) but will have zero effect on the number of packets. (2) Installing a DNS forwarder will make some packets slightly longer (announcing your public keys and adding cryptographic protection to your communication with DNSCurve caches) but will have zero effect on the number of packets. (3) Having a machine use its own DNS cache, rather than relying on a centralized cache, can slightly decrease or slightly increase the number of packets, depending on cache-use patterns. Measurements by Bill Manning showed a 1.15x increase factor at a typical site: http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_12-2/122_dns.html In all situations the change in your network traffic is negligible, far smaller than your normal daily fluctuations in network load. The impact on your CPU time is also negligible. Normally I wouldn't bother commenting on such minor issues; people would simply take steps #1, #2, #3 and see that there's no problem. However, a recent blog post by Dan Kaminsky contains a number of wild misstatements about DNSCurve's impact on DNS load: "DNSCurve Destroys The Caching Layer. This Matters. ... It was ultimately this characteristic of DNSCurve, above all others, that caused me to reject the protocol in favor of DNSSEC. ... 5x-10x ... there's our 100x ... chain reaction ... even 200x" etc. This all sounds quite scary, but it's all completely wrong---a rather embarrassing example of why performance data should always be measured rather than guessed. Here's how Kaminsky gets his numbers: (A) He asserts that DNSCurve turns off caching of DNS information. (B) He observes that most DNS lookups are answered from cache; sites vary but let's imagine 99%. (C) He concludes that DNSCurve sends packets for 100% of queries while regular DNS sends packets for only 1%. Unfortunately for Kaminsky, both A and C are flat-out wrong. It's simply not true that DNSCurve turns off caching of DNS information. When you upgrade your DNS cache software to support DNSCurve, you are continuing to cache all of the DNS results on your own machine, whether or not those results were protected by DNSCurve; and you are (of course!) continuing to answer most DNS lookups from cache, just as before. What if you go beyond upgrading a central cache to support DNSCurve (#1 above)? What if you put DNSCurve caches on each machine (#3 above)? Perhaps the independent caches are more effective, because they have more combined capacity; perhaps the centralized cache is more effective, because it copies answers from one user to another user. But overall these are small effects, as illustrated by Manning's 1.15x measurement. Most of the impact of DNS caching comes from having _some_ nearby cache; the exact size and placement of the cache makes very little difference. I think Kaminsky understands that DNSCurve gives your machine a secure channel all the way to the DNSCurve server, protecting your DNS queries against espionage, corruption, and sabotage by intermediate attackers. This obviously prevents intermediate ISPs from caching your queries: if the ISP can't spy on the contents of your queries then it certainly can't answer the queries from its own cache. But what Kaminsky fails to understand is that _your_ machine has its own cache: the way you turn on DNSCurve for your queries is by installing a DNSCurve cache! Kaminsky's fundamental error is equating * independent machine-specific caches (security recommendation) and * no caches at all (Kaminsky's imagination; no relation to reality) even though these are obviously completely different situations from a performance perspective. Kaminsky keeps talking about the performance benefit of the _first_ layer of caching as if it were a performance benefit of the _second_ layer of caching---but the second layer has almost zero benefit, as illustrated by Manning's measurements. There are many other serious errors in Kaminsky's blog post, but his wild misstatements about caching seems to be the only bits of apocalyptic fearmongering that warrant an immediate response. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago [prev in list] [next in list] [ prev in thread ] [ next in thread ]