Traceroute – Protect your DNS

By analyzing this visualized data, CIRA is able to make decisions about where best to put new deployments of the .CA DNS and CIRA’s other DNS products.

In the last year, CIRA has fervently worked to strengthen the stability and resiliency of its DNS offering. It wasn’t too long ago that queries from Asia or Europe for .CA would be handled by the same servers in Toronto that respond to queries from Canadians. This meant these international DNS queries and their responses were crossing continents and oceans, subject to many more potential points of network failure than they are today. Further, it meant attacks targeting .CA DNS servers, no matter their source continent, could theoretically affect the online experience of Canadians.

Today traceroute, and particularly a series of visualization tools built to utilize it, plays a key role in CIRA’s architecture decisions. By analyzing this visualized data, CIRA is able to make decisions about where best to put new deployments of the .CA DNS and CIRA’s other DNS products. The focus here is two-fold:

1. Where can we best serve the largest numbers of Canadians locally?
2. Where can we best pull non-Canadian traffic to ensure the Canadian nodes are mostly reserved for Canadians, and thus more resilient to attacks?

The answer to question 1:  Local IXP’s (Internet Exchange Points), where Canadian networks meet. CIRA exchanges traffic with other Canadian networks, in Canada, in Halifax, Montreal, Ottawa, Toronto, Winnipeg, Calgary, and Vancouver.

The answer to question 2:  Pull globally source traffic away from Canada.

CIRA’s Los Angeles site pulls traffic from the US West Coast and serves as a great backup to our Asian node in Hong Kong.
CIRA’s Miami site pulls traffic from the US East Coast and Latin America.
CIRA’s Hong Kong site pulls most of the traffic from Asia, and gives Australia/Oceania the option of choosing either Hong Kong or Los Angeles for its traffic.
CIRA’s London node, connected to several Internet Exchanges in Europe, currently handles about 95% of all queries coming from Europe.

Every DNS query packet we can prevent from crossing an ocean is one less packet competing with your traffic.

Traceroute – What’s in it for me?

Traceroute is a useful tool for debugging network issues and is available in nearly all operating systems. Traceroute allows you to see the IP address and hostname, if available, of every hop along the way of the network path between you and a remote destination. More often than not, hops along the path crossing major Internet backbones are given hostnames that reflect the nearest airport code or city, giving the operator running the traceroute some view into the path that traffic is taking.

CIRA is working to incorporate a visual traceroute in the next phase of the Internet Performance Test that is targeted for release in 2016. In the meantime, here’s an example of a traceroute from Toronto to Los Angeles:

$ traceroute www.icann.org
traceroute to www.icann.org (192.0.32.7), 30 hops max, 60 byte packets
1  199.253.251.33 (199.253.251.33)  0.082 ms  0.121 ms  0.167 ms
2  v631.core1.tor1.he.net (216.66.14.53)  0.197 ms  0.245 ms  0.303 ms
3  100ge13-1.core1.chi1.he.net (184.105.80.5)  13.762 ms  14.266 ms  14.791 ms
4  10ge11-4.core1.pao1.he.net (184.105.222.173)  73.047 ms  73.043 ms  73.030 ms
5  10ge3-1.core1.sjc2.he.net (72.52.92.70)  71.565 ms  71.150 ms  71.664 ms
6  100ge11-2.core1.lax1.he.net (184.105.223.250)  80.863 ms  72.927 ms  72.969 ms
7  eqx-ix.icann.org (206.223.123.86)  71.502 ms  71.503 ms  71.621 ms
8  www.icann.org (192.0.32.7)  71.454 ms  71.442 ms  71.417 ms

In this traceroute, packets between the source and www.icann.org take the following route:  Toronto, ON -> Chicago, IL -> Palo Alto, CA -> San Jose, CA -> Los Angeles, CA

Each hop along the way has been sent three packets; the round-trip time of each packet is displayed to the right. The round-trip time is the amount of time it took for your packet to reach the destination, plus the time it took for their responses to make it back to you. For the uninitiated, the round-trip time is much like a submarine or aircraft operating radar—a signal is transmitted, hits something, and bounces back, allowing a measurement of distance.

In this scenario, we see the longest portion of the route is between Chicago and Palo Alto. The numbers above reflect this in network round-trip times. The trip from Toronto to Chicago and back takes ~12 milliseconds. The trip from Chicago to Palo Alto and back takes ~60milliseconds. But the localised trip between the three cities in California takes almost no time at all. This is due to the speed of light (yay, fibre optics!) over distance.

An important thing to note when doing traceroutes: The route you see your packets take toward their destination is generally not the same route packets from that end take to get to you. This is particularly true with traceroutes that cross larger networks, which often have multiple circuits / paths / route options in each piece of equipment.

How to traceroute

Standard traceroute is available on most Unix/Linux based systems as the command “traceroute”, and within Windows as “tracert”.

Have you heard of the “mtr” traceroute utility?  At one point it was called “Matt’s Traceroute”, and was later named “My Traceroute.” “mtr” combines the functions of traceroute and ping to keep a running tally of round-trip times over the time period that it is running. Every second, a new series of packets are sent out at each hop along the path. The output of this over 60 seconds looks like:

The above shows that over one minute, there was no packet loss on any hop between us and our destination. Again, we see the longest trip is between Chicago and Palo Alto. This tool is useful in cases where networking issues are intermittent because you can come back to your keyboard 30 minutes after launching it to see which hop along the path showed any weakness, if only for a few seconds.

Tracerouting and local peering help to localize traffic, making CIRA’s DNS offerings more resilient to attack. You can do the same for your clients.

CIRA offers a variety of products to make the DNS more resilient. Ask your Registrar about Registry Lock and DZone Anycast DNS.