Babak Farrokhi

A Tale of Using Public DNS Servers in Iran — Part 2

Babak Farrokhi

8 min read

10 You have liked this article 0 times.
0

This is the second part in a series of articles looking at the use of DNS servers in Iran. For the second part I will continue measuring performance and reachability for two more sets of DNS resolvers: TIC and Verisign.


 

In the first part of this series, I performed a quick reachability and performance analysis on two major public DNS resolvers (Google and Level3) from Iranian networks, using a handful of homebrewed tools and RIPE Atlas .

For the second part I will continue measuring performance and reachability for two other sets of DNS resolvers: TIC and Verisign.

TIC

According to Wikipedia , Telecommunication Infrastructure Company of Iran ( TIC ) is the sole provider of telecommunication infrastructure to all private and public operators in the Islamic Republic of Iran. TIC is also the sole responsible party for all international gateways and IP capacity and connectivity services in the country.

According to TIC, they are running two DNS resolvers on 217.218.127.127 and 217.218.155.155 which are distributed using anycast. However the actual number of instances is not known.

Many local service providers either assign these addresses as DNS address to end-users or forward all their local DNS traffic using their DNS forwarders.

Unsurprisingly, the DNS resolvers did not respond to “id.server” queries so I could not reliably find out their locations and whether they are running anycast or not. So I proceeded with my performance and reachability tests.

For reachability, I turned to RIPE Atlas , chose 50 probes in Iran and queried the A record for wikipedia.org. The results can be found here:

Running my python script on the JSON results to find out reachability level as well as average access time:

 # ./atlas-parser.py RIPE-Atlas-measurement-3458169.json
 
Average Response Time: 77.501 ms Success Rate = 100%
 # ./atlas-parser.py RIPE-Atlas-measurement-3458170.json
 
Average Response Time: 66.521 ms Success Rate = 100%

The TIC DNS resolvers responded to all queries in a timely manner and have been 100% reachable during the tests.

Verisign

I also repeated the same test for two DNS resolvers from Verisign on 64.6.64.6 and 64.6.65.6. Here are the results from RIPE Atlas:

After a quick analysis based on the JSON files I exported from RIPE Atlas, I found very disappointing result:

 # ./atlas-parser.py RIPE-Atlas-measurement-3458171.json
 
Average Response Time: 228.916 ms Success Rate = 58%
 # ./atlas-parser.py RIPE-Atlas-measurement-3458172.json
 
Average Response Time: 169.290 ms Success Rate = 60%

While the average response times were acceptable, reachability was ~40% and there seems to be a serious problem with accessing these hosts from Iran. I decided to give it another try using RIPE Atlas but using probes from Turkey (a neighbouring country) from which Iran transits parts of its Internet traffic.

The results from Turkey were quiet different:

 # ./atlas-parser.py RIPE-Atlas-measurement-3459076.json
 
 Average Response Time: 79.170 ms
 Success Rate =  100%
 # ./atlas-parser.py RIPE-Atlas-measurement-3459077.json
 
 Average Response Time:  82.902 ms
 Success Rate =  100%

Here I can conclude that the reachability problem is limited to Iranian networks and for some reason they cannot reach these hosts. Repeating tests from Iran resulted in different results from a reachability perspective, from 20% to 70% reachability at different times.

DNS Jitter

During my tests I noticed the DNS response times are variable from server to server. The main reason of course is the network latency between your client and the server, therefore the closest the server you use, the better the results would be.

However, using the same DNS resolver I noticed the results vary from time to time. This parameter can also reflect processing delay on the DNS resolver in addition to network delay as well as network jitter.

Looking for a DNS ping utility that can measure jitter yielded no result. So I decided to put together a small DNS ping utility that, similar to standard ping utility, is able to calculate min, max, avg and stddev on any given number of DNS requests. 

DNS ping utility

  Figure 1: dnsping in action

 

I started measuring these parameters for various DNS resolvers to see how they perform. Unfortunately I could not extract this data from RIPE Atlas, so I distributed this DNS ping utility on several hosts on my own observatory platform around Iranian datacenters to gather statistics. 

Here is a quick output from a well connected host under normal conditions.

Level 3 DNS:

 # ./dnsping.py -q -s 4.2.2.4 -c 100 wikipedia.org
 
DNSPING 4.2.2.4: hostname=wikipedia.org rdatatype=A
--- 4.2.2.4 dnsping statistics --- 100 requests transmitted, 93 responses received, 7% lost min=178.046 ms, avg=182.790 ms , max=194.878 ms, stddev=3.237 ms

Google DNS:

 # ./dnsping.py -q -s 8.8.4.4 -c 100 wikipedia.org
 
 DNSPING 8.8.4.4: hostname=wikipedia.org rdatatype=A
--- 8.8.4.4 dnsping statistics ---
100 requests transmitted, 93 responses received, 7% lost min=196.895 ms, avg=263.975 ms , max=396.324 ms, stddev=67.207 ms

TIC DNS:

 # ./dnsping.py -q -s 217.218.127.127 -c 100 wikipedia.org
 
 DNSPING 217.218.127.127: hostname=wikipedia.org rdatatype=A
 
--- 217.218.127.127 dnsping statistics --- 100 requests transmitted, 100 responses received, 0% lost min=3.384 ms, avg=3.909 ms , max=17.738 ms, stddev=1.416 ms

Verisign DNS:

 # ./dnsping.py -q -s 64.6.64.6 -t A -c 100 wikipedia.org
  
DNSPING 64.6.64.6: hostname=wikipedia.org rdatatype=A

--- 64.6.64.6 dnsping statistics --- 100 requests transmitted, 85 responses received, 15% lost min=190.504 ms, avg=231.164 ms , max=664.557 ms, stddev=60.993 ms

DNS Resolver running on localhost:

 # ./dnsping.py -q -s 127.0.0.1 -c 100 wikipedia.org
   
 DNSPING 127.0.0.1: hostname=wikipedia.org rdatatype=A

--- 127.0.0.1 dnsping statistics --- 100 requests transmitted, 100 responses received, 0% lost min=0.630 ms, avg=0.729 ms, max=2.301 ms, stddev=0.177 ms

The tests above show that in public DNS resolvers, TIC performed the best, however from other public DNS resolvers, Level3 had lowest response time and Jitter.

Conclusion

Choosing the closest DNS resolver is always the best choice. A reliable DNS with low response time, low jitter and valid responses is always preferred. However, power users may choose to run their own local resolver , home users have the freedom to choose from various public DNS resolvers. It is wise to never blindly choose your provider’s DNS resolver and try different options to get the best result.

In the next part of this series, I will discuss the integrity of DNS responses. Keeping in mind that “there is no such thing as free lunch”, I will discuss several disadvantages of using public DNS resolvers over your locally owned DNS resolver.

 

Note: This was originally published on Babak Farrokhi's blog .

10 You have liked this article 0 times.
0

You may also like

View more

About the author

Babak Farrokhi is a Computer Scientist and Researcher with over 20 years of experience in UNIX Systems and Networking. His expertise includes IP Networking, BGP, DNS, Internet Performance, System Scalability and Network Security. He provides consulting services and develops products and services related to his expertise.

Comments 0