The Lost Symbol Traceroute Mystery

Dan Brown’s most recent thriller novel The Lost Symbol we find Robert Langdon on the train of a bad guy who uses Dr. Langdon knowledge of ancient symbols to track down a mysterious talisman of the Masons. Mean while another character is trying to uncover the identity of a web server containing some vital but redacted information. I really enjoy Dan Brown novels but it drives me crazy when authors try to inject technical details that they really do not understand. This was a fatal flaw of one of his previous books, Digital Fortress. That book was enjoyable but filled with technical inaccuracies that were distracting for me. The latest novel is not as technical.

The secondary character is trying to identify a web site. She knows enough to try a traceroute. The problem is that a traceroute doesn’t tell you the identity of a server. It only tells you the path to that server from your location. It is helpful for diagnosing congestion or routing problems. Since the route between two points on a network is not always the same that information is not really helpful. I can tell you some information if that server is inside another organization’s network but it is not the best way to accomplish this. The character in the novel is stymied when the traceroute abruptly stops. Actually that is very common. Some protocols like ping, finger and traceroute are blocked by some routers because they are considered noise or even a security risk.

So what does a traceroute look like. Let me do a sample traceroute to whitehouse.gov. Let’s see what happens. The first response look promising. I’ll skip it because it is only showing me the path out of my house and to my ISP.

traceroute to whitehouse.gov (96.17.90.135), 64 hops max, 52 byte packets
1 10.0.1.1 (10.0.1.1) 1.117 ms 0.326 ms 0.305 ms
… omitted lines ….
7 ae-1.r21.dllstx09.us.bb.gin.ntt.net (129.250.4.181) 9.127 ms 8.965 ms 9.704 ms
8 as-0.r21.chcgil09.us.bb.gin.ntt.net (129.250.3.16) 36.514 ms 53.158 ms 32.594 ms
9 po-3.r00.chcgil09.us.bb.gin.ntt.net (129.250.3.9) 46.263 ms 32.090 ms 31.928 ms
10 * * *

These first few lines look promising. By line 10 however we are just getting the response * * *. Which is basically a non-response. The routers at that point in the trace have stopped responding. The trace will continue but you will probably not see any more meaningful information.

What’s interesting is that you can repeat the trace and get a different result.

traceroute to whitehouse.gov (96.17.90.135), 64 hops max, 52 byte packets
1 10.0.1.1 (10.0.1.1) 1.117 ms 0.326 ms 0.305 ms
… omitted lines ….
5 69.220.8.51 (69.220.8.51) 35.616 ms 35.308 ms 35.390 ms
6 chi-bb1-link.telia.net (213.248.96.117) 35.262 ms 35.124 ms 35.175 ms
7 nyk-bb2-link.telia.net (80.91.249.111) 56.628 ms
nyk-bb1-link.telia.net (80.91.248.193) 53.706 ms
nyk-bb1-pos0-3-0.telia.net (213.248.80.153) 54.319 ms
8 ash-bb1-link.telia.net (213.248.83.20) 74.448 ms
ash-bb1-link.telia.net (80.91.248.184) 54.519 ms
ash-bb1-pos7-0-0-0.telia.net (213.248.80.136) 58.251 ms
9 * * *

The second time the trace used telia.net instead of ntt.net. Somewhere there’s a map that shows these two paths and for at least that milisecond it was a faster route for our trace to take. Ten years ago the physical pathing was more limited and traceroute was more reliable. Today it is hobbled by security sensitive router managers.