Testing 36200 DNS servers

Introduction

DNS is an important part of the Internet and the speed and security are paramount for a good browsing experience. I thought it would be a good idea to scan the internet for DNS servers and test every single one of them. However, the latency of a particular DNS server depends highly on the distance and connection technology between you and the DNS server, and since I'm geographically located in Denmark, the results speed-wise only pertain to people located in/around Denmark.

Testing methodology

I scanned the IPv4 Internet using NMap on port 53/UDP and stopped the scan after a few hours. The results were DNS 36200 servers, some of which are owned by ISPs, companies and a whole lot of private people. Since the IP scan was randomized, it should represent a good sample.

Almost all DNS servers have some sort of caching mechanism that makes sure requested DNS names are kept for as long as the Time-To-Live (TTL) as defined by the domain owner. To ensure we don't just test a bunch of cached entries, we need to test uncached domains as well.

Reliability is also important, so we need to register when a query is dropped. The drop might be from a router between us and the DNS server, or it might be the DNS server itself, so we can't exactly measure the reliability of a particular server, but a high rate of dropped packets will disqualify never the less.

Security is also an important factor, and there are 2 main things to look for:

Popular servers

There are a bunch of "known good" DNS servers out there that has a good reputation for being stable and fast. I added them to the list, just to make sure we test them as well.
  • Google: 8.8.8.8
  • OpenDNS: 208.67.222.222
  • Level3: 4.2.2.1
  • UltraDNS: 156.154.70.1
Note that I did not add secondary clusters for each of the nameservers.

Performing the test

GRC has a DNS benchmark tool that accomplishes the cached, non-cached and reliability tests, but it only supports 200 nameservers at the same time. I split the list into chunks and used the command line to automate checking 200 servers at the time.

After it finished running, I sorted the lists by average response time and ended up with the 200 fastest DNS servers. I then ran the test again on those servers and ended up with the 10 fastest DNS servers.

Each of those 10 servers then went through a DNSSEC validation test:
  • dig sigok.verteiltesysteme.net @<DNS IP HERE>  (should return NOERROR)
  • dig sigfail.verteiltesysteme.net @<DNS IP HERE> (should return SERVFAIL)
The 10 servers were then subjected to the DNS spoofability test over at GRCs DNS page to determine the source port and transaction ID entropy.

Results

The table below is ordered from fastest to slowest based on the average response time.

IP Owner DNSSEC validation Anti-spoof
195.215.95.11 TDC Yes Bad
89.233.43.71 censurfridns.dk Yes Bad
94.126.178.9 censurfridns.dk Yes Bad
94.143.10.52 dandomain.dk No Moderate
147.29.10.6 sdn.dk No Moderate
86.58.175.12 j.net No Excellent
194.239.10.180 webspeed.dk No Very bad
94.143.10.43 dandomain.dk No Moderate
193.219.27.222 ipweb.dk No N/A (rate limit)
195.190.31.129 Welcom Hosting Aps Yes Moderate

If we take a look at just the popular DNS servers - as above, order by latency relative to my geographical location.

IP Owner DNSSEC validation Alti-spoof
8.8.8.8 Google Yes Moderate
4.2.2.1 Level3 No Excellent
208.67.222.222 OpenDNS No Excellent
156.154.70.1 UltraDNS Yes Excellent

Conclusion

It seems TDC's DNS server is the fastest but unfortunately it has bad anti-spoofing capabilities. It seems there is no clear winner regarding speed and security. UltraDNS has the best security but was also the slowest (70% slower than TDC) of the servers in relation to my geographical location. I'm sure that people located closer to the servers will have lower latency, and then UltraDNS becomes the clear winner.

In the end, there is little to no difference between the top 10 DNS servers and even the 4 popular servers. Run a test yourself to see just how big the difference is between your current DNS server and the popular ones, maybe there is better latency and a little more secuirty to get.

Comments

Post a Comment

Popular posts from this blog

.NET Compression Libraries Benchmark

Image
I often find myself needing a compression library in a software development project, and after a few tests with disappointing results I usually fall back to spawning 7Zip as an external process. This time however, the application specification prohibits any data written to disk, which 7Zip needs to do in order to work correctly. I needed to do everything in memory, and so I had to test some of the C# libraries available for compression as well as the different compression algorithms. Here is a full list of the tested libraries: .NET DeflateStream ICSharpCode SharpZip Zlib.NET DotNetZip Managed LZMA LZMA SDK QuickLZ    Compression 101 Before I get to the results of the benchmark, I think it is important to understand the different archive formats and compression algorithms in order to compare the results with other benchmarks/and or tests. Lets get to it! A compression algorithm can be compared to a small machine that takes in some data, do some math on it and transfor
Read more

Reducing the size of self-contained .NET Core applications

Just for note keeping, I've written down some methods of reducing the size of a .NET Core application. I thought others could use it as well, so here you go. Original Size First off, let's see how much disk space a self-contained 'hello world' application takes up. > dotnet new console > dotnet publish -r win-x86 -c release Size: 53.9 MB -  yuck! Trimming Microsoft has built a tool that finds unused assemblies and removes them from the distribution package. This is much needed since the 'netcoreapp2.0' profile is basically .NET Framework all over again, and it contains a truckload of assemblies our little 'hello world' application don't use. > dotnet new console > dotnet add package Microsoft.Packaging.Tools.Trimming -v 1.1.0-preview1-25818-01 > dotnet publish -r win-x86 -c release /p:TrimUnusedDependencies=true Size: 15.8 MB Much better! Although, we have only removed unused assemblies - what about unused
Read more

Convex polygon based collision detection

Image
A lot of people have asked me: Why use a convex polygon only engine like Box2D? In this post I will provide some info on why convex polygons is the optimal polygon type to use. What does convex mean? Convex polygons needs to satisfy the following requirements: All internal angles must be below 180 degrees Every line segment between two vertices can be contained fully inside or at the edge the polygon A non-convex polygon is called a concave polygon and it must have an internal angle measuring greater than 180 degrees. As you might have thought about yourself; concave polygons can be quite handy. Convex-only engines can’t represent a simple player polygon like Pac-Man . Why use convex-only? There are really only one big juicy reason: performance Physics engines are able to take quite a few shortcuts and use cheap algorithms to determine the closest vertex, shortest distance and a lot more. An algorithm like Separating Axis Theorem and the Gilbert – Johnson –
Read more