US Telco Support > Verizon > Verizon Fiber Optics > DNS Service Provider Performance Comparison

DNS Service Provider Performance Comparison

DNS Service ···ison.htm 3610 bytes
(DNS Service Provider Performance Comparison.htm.zip)

It took me a little while to actually look at the download.

Question on test method: NSLookup on the same domain name from a specified DNS server, is it

Query1 DNS1, Query2 DNS1, Query3 DNS1...., OR

Query1 DNS1, Query 1 DNS2, ... Query2 DNS1, Query2 DNS2...?

Results are interesting. It might explain some of the slow page load problems experienced by some. Although you'd have to balance against the faster response once the DNS was serving from cache. The Seattle vs. Chicago timings are evident.

reply to NOYB
NOYB, you might want to fix the file extension on that file upload. I had to change the extension to be able to view it.
--
It's all fun and games in a Team Fortress 2 battle until your sentry gun is sapped by the Spycrab!

.zip

See the fine print description below the link to download.

reply to birdfeedr
If I understand the question the answer would be: Query1 DNS1, Query2 DNS1, Query3 DNS1…

Unless more than a few name resolutions are required for a page it is unlikely to be humanly perceptible. – Just My Opinion.

Also the sites most people visit the most will most likely already be cached. You know, sites like Fox News.

As for the file renaming thread branch guess I don't follow what is being asked for / said there. It is an html (*.htm) file, and when uploaded BBR zips it up. Opening the downloaded zip should make the html file available. Works here.

--
Be a Good Netizen - Read, Know & Complain About Overly Restrictive Tyrannical ISP ToS & AUP »comcast.net/terms/ »verizon.net/policies/
Say Thanks with a Tool Points Donation

It downloads as "DNS ... Comparison.htm" Need to rename to add .zip extension.

That's what happened to me in ubuntu. Easy enough fix, caught it right away. What I meant earlier was I downloaded it for later review.

Just verified, it downloads as a zip for me here. Maybe my system is detecting it by mime type or something rather than by extension.

reply to birdfeedr

reply to NOYB
While it makes a nice anecdotal addition to the table, the latency/ping time to the DNS server is really irrelevant or rather only part of the equation.

In other words, if I ping 1ms to a DNS server, but it's so overloaded that it takes 50ms to return a response to the query, a server that's 20ms away but responds in 10ms is better.

That's why in my ns_bench program I only print the total time of the query itself.

One other thing I should mention is that my ns_bench program only times a cached query (it does a lookup first to ensure the nameserver in question has the record cached). The reason I didn't bother trying to time an uncached host is it can and will vary, depending on the auth nameserver and the relative route/"distance" to the auth server as traced recursively from the nameserver you're testing against.

One other point. The GTEI servers (and I believe also the OpenDNS servers) are anycast, so your results (and hence conclusions) are really only relevant for folks in your service area which would take the same route to the nearest anycast servers.

Anyway, good stuff. Here's the ns_bench results for your test servers (and the two I personally use) from my FiOS connection (20/20 business with 1 static in Middletown, DE - south of Wilmington)

Nameserver              Response Time (ms)
                        min/avg/max/stdev/retries
 
4.2.2.1                 14.97/15.00/15.10/0.05/0
4.2.2.2                 14.97/15.47/17.47/1.00/0
4.2.2.4                 14.97/15.97/17.47/1.22/0
4.2.2.5                 185.00/206.99/257.59/25.95/0
208.67.222.222          14.97/14.97/14.97/0.00/0
208.67.220.220          14.97/14.97/14.97/0.00/0
68.238.128.12           92.43/92.48/92.55/0.06/0
68.238.0.12             34.96/34.99/35.09/0.05/0
68.238.128.14           92.42/92.48/92.55/0.06/0
68.238.0.14             34.96/34.99/35.09/0.05/0
151.197.0.39            7.35/7.48/7.60/0.08/0
71.242.0.14             7.48/7.48/7.48/0.00/0
 

Added the ping as an after thought to show how much of the time is network latency dependent rather than name server.

The automatically assigned (by DHCP) Verizon DNS servers for folks in other areas would likely have similar results. If I were in Seattle the Verizon DNS server response times would likely be single digit. I would not expect you or anyone on other side of country to have as good of result using the Seattle located Verizon DNS server from DE. What is the performance of the Verizon DNS servers that gets auto assigned to you? Those are the ones that you should use for comparison.

In some cases, such as infrequently requested addresses, several request need to be made in order to ensure the response is from cache, as can be seen in the results of my performance comparison. Does the ns_bench tool account for this? If so how is the tool determining whether or not the request is from cache?

During my testing I did not experinance any failed lookups from any of providers DNS.

--
Be a Good Netizen - Read, Know & Complain About Overly Restrictive Tyrannical ISP ToS & AUP »comcast.net/terms/ »verizon.net/policies/
Say Thanks with a Tool Points Donation

My first thought on the caching delay is load-balancing across several non synchronized servers.

One thing the ns_bench tool could do for determining if the response is cached would be to query the authoritative name server and capture the TTL. Then run the test and compare the TTL. If it less than what was received from the authoritative name server then it is likely to be from cache. If the TTL is equal or greater then it is likely uncached.

This way both cached and uncached results could be provided.

Looks like you are using one verizon DNS server and one Bell Atlantic DNS server.

nslookup 151.197.0.39
Name: home4.bellatlantic.net
Address: 151.197.0.39

nslookup 71.242.0.14
Name: nsphil02.verizon.net
Address: 71.242.0.14

--
Be a Good Netizen - Read, Know & Complain About Overly Restrictive Tyrannical ISP ToS & AUP »comcast.net/terms/ »verizon.net/policies/
Say Thanks with a Tool Points Donation