Did you come here from a search engine? Click here for my main page.

What it does

traceroute is a basic network tool that can print out the path (actually, to be completely accurate, "one possible path") that IP packets could take from an originating host (i.e., the machine you're using or that you're logged into) to some destination host.

Network engineers commonly use traceroute to flush out problems in network routing. Its use for spam-hunting purposes is somewhat more limited, and you may not have to use it very frequently. Nevertheless, traceroute is invaluable for helping you find the network locations and upstream providers for a spam operation.

How to get it

If you use a Unix-like system (such as Linux, BSD, Solaris, Apple Mac OS X / Darwin, etc.), you more than likely have traceroute available on your system already. You need only open a terminal window (or otherwise get access to command-line operation) and then type the command as shown below. Use the Unix whereis command (i.e., "whereis traceroute") to find traceroute if it isn't on your normal paths.

Most versions of Microsoft Windows (from Win95 onward) have traceroute pre-installed as a DOS command, although it may actually be called "tracert" (a holdover from the days when DOS filenames and commands could be no more than 8+3 characters long). The command-line options for tracert are fewer in number than, and somewhat different from, the Unix version, but the basic operation is the same. You can simply open a DOS window and run the command.

If you are using some other operating system on your computer (in particular, Mac OS 9 and earlier), you may not have traceroute installed. In this case, you can either find a port of the traceroute command for your particluar system, or else (if you don't like command lines) use one of the GUI-based or web-based alternatives described at the bottom of this page.

How to use it

On this page, we'll deal with the Unix (actually, Apple Darwin / BSD) command-line version of traceroute; web-based and GUI versions should also work in a similar fashion.

Here's the basic syntax for the traceroute (or tracert) command:

You can supply traceroute with either a host name (or alias) or an IP address; if you give it a host name, it will first attempt to resolve the name to an IP address using a DNS query. If it can't find an IP address for the host, it will quit (since it doesn't have a destination address to shoot at).

The traceroute command has many options, but generally none are needed for spam-tracing purposes.

A simple traceroute example

Let's first try a traceroute to this website (www.rickconner.net), which is hosted in Austin, Texas. I'll note that I ran this from my home computer (which is connected via Verizon DSL in Maryland), so there's enough "network distance" between "here" and "there" to make the trace interesting:

[G4733:~] rconner% traceroute www.rickconner.net
traceroute to www.rickconner.net (, 30 hops max, 40 byte packets
1 ( 18.862 ms 16.956 ms 16.157 ms
2 at-1-1-0-1714.core-rtr1.res.verizon-gni.net ( 40.045 ms 16.044 ms 15.843 ms
3 ( 16.41 ms 57.422 ms 14.828 ms
4 ( 15.451 ms 15.653 ms 33.588 ms
5 eqix.asbn.twtelecom.net ( 15.329 ms 16.651 ms 17.255 ms
6 core-01-so-0-1-0-0.asbn.twtelecom.net ( 15.604 ms 44.154 ms 15.568 ms
7 dist-01-so-1-0-0-0.ausu.twtelecom.net ( 52.797 ms 53.82 ms 55.055 ms
8 hagg-01-ge-0-3-0-510.ausu.twtelecom.net ( 52.831 ms 52.668 ms 66.667 ms
9 ( 54.876 ms 54.997 ms 53.919 ms
10 www.rickconner.net ( 55.425 ms 54.034 ms 55.936 ms

Each line of the trace contains the following information in order:

This was a well-behaved example, because all of the hosts responded quickly to the probes and most had fast reverse DNS.

Traceroute problems

A good traceroute among well-engineered networks is very fast and provides fairly complete information, as we saw above. You won't always get off this easy, particularly when you're tracking the kinds of offshore addresses that spammers are so fond of using. For example, here's a very dysfunctional traceroute to a mortgage spammer's website (wuax.wellgold.be):

Is this critter online?
[G4733:~] rconner% ping -c3 wuax.wellgold.be
PING wuax.wellgold.be ( 56 data bytes
64 bytes from icmp_seq=0 ttl=53 time=238.256 ms
64 bytes from icmp_seq=1 ttl=53 time=229.929 ms
64 bytes from icmp_seq=2 ttl=53 time=473.941 ms

--- wuax.wellgold.be ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 229.929/314.042/473.941 ms

When we started...
[G4733:~] rconner% date
Mon Dec 5 23:16:15 EST 2005

The trace...
[G4733:~] rconner% traceroute wuax.wellgold.be
traceroute to wuax.wellgold.be (, 30 hops max, 40 byte packets
1 ( 16.327 ms 14.287 ms 13.81 ms
2 at-1-1-0-1715.core-rtr2.res.verizon-gni.net ( 15.546 ms 37.649 ms 42.375 ms
3 ( 13.357 ms 13.474 ms 14.524 ms
4 ( 15.343 ms 13.843 ms 14.02 ms
5 so-0-2-0-0.e1.washington1.level3.net ( 16.502 ms 22.782 ms 49.131 ms
6 ( 14.93 ms 18.713 ms 15.785 ms
7 if-6-0.core1.aeq-ashburn.teleglobe.net ( 54.87 ms 52.238 ms 54.664 ms
8 if-2-0.mcore3.njy-newark.teleglobe.net ( 49.038 ms 23.517 ms 23.438 ms
9 if-5-0.core1.mln-miami.teleglobe.net ( 66.802 ms 55.339 ms 55.585 ms
10 ix-4-3.core1.mln-miami.teleglobe.net ( 178.857 ms 178.462 ms 186.517 ms
11 fa10-3.arc-rj-rotn-01.telemar.net.br ( 171.906 ms 181.357 ms 171.233 ms
12 ( 311.28 ms 198.261 ms 252.097 ms
13 po0-0.mpi-mg-rotn-01.telemar.net.br ( 182.358 ms 181.865 ms 181.228 ms
14 ( 188.014 ms 185.021 ms 182.673 ms
15 ( 183.108 ms 182.629 ms 183.007 ms
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *

When traceroute gave up...
[G4733:~] rconner% date
Mon Dec 5 23:20:19 EST 2005

I actually ran four commands here for purposes of illustration: a ping (to determine whether the host was online), the traceroute command, and two date commands to print the local date and time so as to "time-stamp" the start and end of the traceroute query.

The first thing to note is that this trace took a very long time (about 4 minutes, judging by the difference between my time stamps). Most of this delay came about when we hit a bunch of hosts (beginning in line 16) that wouldn't or couldn't cooperate with traceroute (they reported no host info and no probe times). Eventually, after trying the default limit of 30 hops, traceroute simply threw up its hands and exited.

Hitting such "silent hosts" does not always mean that traceroute will stop; it can recover and try another route if it can find it (in this case, I guess it got lost somewhere in the Amazon jungles). Since we could ping wuax.wellgold.be, (see the top of the display above) we know that the host is online. It's impossible for us to tell what went wrong here (possibly just substandard network engineering); it could be that if we tried this trace somewhat later on, perhaps jiggling with some of traceroute's options, it might behave better.

Another thing to note is that some of the hosts in this chain did not have reverse DNS set up; this isn't really a problem per se (since reverse DNS is not really required for most hosts). If you need to know where such hosts are, or to whom they belong, you can use IP-whois.

Finally, we'll note that the spammers have used a domain name in the .be top-level domain (for Belgium) even though the site is (apparently) hosted in Brazil and probably not run by Belgians. Just another instantiation of rule #1.

Alternatives to command-line traceroute

If you don't have the whois command available on your system, or don't want to use it, you still have several alternatives. The following websites may be useful:

You may also be able to find GUI-based traceroute applications for your own system (check your favorite freeware/shareware repository).

 Legend:  new window    outside link    tools page  glossary link   

(c) 2003-2008, Richard C. Conner ( )

05096 hits since March 28 2009

Updated: Wed, 11 Jun 2008