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.
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 .
Comments 0
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.