You are here: Home > Publications > RIPE Labs > Babak Farrokhi > A Tale of Using Public DNS Servers in Iran — Part 1

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

Babak Farrokhi — 05 Feb 2016
While most Internet users are not aware of the importance of DNS resolution in their overall web browsing experience, they often complain about shortage of bandwidth when experiencing sluggish Internet connectivity. It is no surprise that most of the service providers also ignore this fact by redirecting their customer DNS traffic to public DNS servers.

 

I’ve seen this mostly happening to Google’s Public DNS servers. Doing a quick test, it turned out that choosing DNS Public DNS Servers is not a wise choice:

 
      # ./dns-speed.sh wikipedia.org server-list.txt 10
      8.8.8.8   average 163   min 139   max   230 ms   10 responses
      8.8.4.4   average 673   min 174   max  5140 ms   10 responses
      4.2.2.1   average 149   min 133   max   168 ms   10 responses
      4.2.2.2   average 135   min 132   max   140 ms   10 responses
      4.2.2.3   average 150   min 133   max   278 ms   10 responses
      4.2.2.4   average 133   min 131   max   136 ms   10 responses
      4.2.2.5   average 134   min 132   max   138 ms   10 responses
      4.2.2.6   average 134   min 128   max   139 ms   10 responses

Two addresses (8.8.8.8 and 8.8.4.4) belong to Google and are widely in use by end users, while the rest of the addresses (4.2.2.x) belong to Level3 Communications. They are obviously using BGP Anycast to distribute their DNS resolvers around the world. Most DNS servers respond to a specifically crafted query to reveal their physical location:

      # dig +short id.server TXT chaos @4.2.2.1
      “answerx_on_cns3.frf1”

Any experienced network engineer could guess that this host should be located in Frankfurt, Germany, and a traceroute reveals a shorter path with lower latency to this host.

However, Google Public DNS servers respond with an empty reply to ‘id.server’ requests, so it is not easy to say where the host is located:

      # dig +short id.server TXT chaos @8.8.4.4

Running a traceroute from my network, it seems like this host is also located somewhere in Europe (given the latency), but it is 40ms farther from Level3 DNS servers.

At the end, I turned to the RIPE Atlas service to measure the quality of access to public DNS servers from various networks in Iran. I chose to measure DNS connectivity from 50 different nodes in Iran (at various locations) toward 8.8.8.8 and 4.2.2.1, querying A records for the domain wikipedia.org.

The output of these measurements can be found here:

You can see the detailed information on RIPE Atlas reports, but I put together a quick python script to calculate the average success rate and response time for both datasets.

Following is the result for Google Public DNS:

      ./reader.py RIPE-Atlas-measurement-3458036.json
      Average Response Time: 177.360 ms
      Success Rate = 94%

And for Level3:

      % ./reader.py RIPE-Atlas-measurement-3458037.json
Average Response Time: 182.329 ms Success Rate = 94%

Conclusion

While the reachability of public DNS servers from both Google and Level3 are the same, I observed more variable response time from Google DNS servers compared to Level3. But in average they both performed similarly when it comes to reachability and response time.

In the second part of this report, I will dig into reachability and performance of other public DNS servers, such as Verisign and OpenDNS and will also measure the performance of TIC public DNS resolvers which are widely used by local operators.

 Please also see Part 2 of this story.

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

3 Comments

Stéphane Bortzmeyer says:
05 Feb, 2016 10:11 AM
In a country like Iran, there is also the risk that the server you talk with is not the one you want (route hijacking, turkish-style https://ripe68.ripe.net/[…]/158-bortzmeyer-google-dns-turkey.pdf https://ripe68.ripe.net/archives/video/177/ ) Google Public DNS has zero defense (not even a public ID) and others have poor defenses (the server ID can be forged) so you have to rely on latency measurements to detect it.

In the future, resolver authentication will probably be a MUST.
Sergey Myasoedov says:
06 Feb, 2016 12:12 PM
Hi Stéphane, is there any ready-to-use technique for resolver authentication?
Stéphane Bortzmeyer says:
08 Feb, 2016 02:43 PM
Nope. There are (very) weak authentications techniques like NSID (but Google Public DNS do not use them). Otherwise, we have to wait for the work of the IETF DPRIVE working group (DNS over TLS, with possible authentication).
Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.