Three tools play essential roles in helping us query the databases
and names and numbers as well as explore the structure of the network
around those machines. dig , whois, and traceroute are all included in standard Unix
and Mac OS X distributions. Windows users will find variants of all of
these, available for free or as shareware. Unfortunately there are so
many of these that it is hard to make any specific recommendations. Look
them up on your favorite search engine and try a few of them out. Web
page interfaces to the tools can also be found on a number of
sites.
dig (domain information
groper) is a DNS lookup utility that I will use extensively in the course of this book.
dig can help you find the IP
address for a given hostname and the hostname, if any, for a given IP
address.
You may already be familiar with a similar tool called nslookup . A precursor of dig, its use is now discouraged, even though
it is still included in most Unix distributions. The same applies to
host, which is also widely
available. You may find that you prefer the command syntax or output
format of one tool over another. I am only going to describe dig in detail here.
In its simplest form, dig
will get the IP address for the supplied hostname. Here is a typical
example:
1 % dig www.craic.com
2 ; <<>> DiG 9.2.3 <<>> www.craic.com
3 ;; global options: printcmd
4 ;; Got answer:
5 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57325
6 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1
7
8 ;; QUESTION SECTION:
9 ;www.craic.com. IN A
10
11 ;; ANSWER SECTION:
12 www.craic.com. 600 IN A 208.12.16.5
13
14 ;; AUTHORITY SECTION:
15 craic.com. 600 IN NS dns3.seanet.com.
16 craic.com. 600 IN NS dns1.seanet.com.
17 craic.com. 600 IN NS dns2.seanet.com.
18
19 ;; ADDITIONAL SECTION:
20 dns3.seanet.com. 82411 IN A 199.181.164.3
21
22 ;; Query time: 98 msec
23 ;; SERVER: 192.168.2.18#53(192.168.2.18)
24 ;; WHEN: Fri Jan 7 14:16:07 2005
25 ;; MSG SIZE rcvd: 127The format of the output is pretty cryptic, with lots of extraneous text that tends to bury the useful content.
The first five lines are status and version information. Lines
8 and 9 are the Question Section, which merely reiterate the query
we gave on the command line. Lines 11 and 12 are what we care about.
In this case, we see that the hostname http://www.craic.com maps to the IP address 208.12.16.5. Bear in mind that there may
not be an Answer Section. That means that there is no host of that
name in any public DNS server on the Internet. Unfortunately, rather
than just telling us “host not found,” dig does so indirectly by not giving us an
answer. This takes a bit of getting used to.
Lines 14 through 17 are the Authority Section. This tells us which DNS servers carry the Start of Authority (SOA) records for the target machine. In most cases, the authoritative server(s) will be based at the host’s ISP or the site at which that host’s domain was registered. Lines 19 through 25 are largely irrelevant for our purposes but can be valuable in debugging DNS problems.
If the default output is too verbose, you can use the +short option, thus:
% dig +short www.craic.com
208.12.16.5This form is almost too terse. In fact, if the hostname cannot be found, it returns with no output at all. This is useful if you want to embed the command in shell scripts.
Supplied with the -x option
and an IP address, dig will find
the corresponding hostname. This is called a reverse lookup. Here is an
example:
% dig -x 208.12.16.5
; <<>> DiG 9.2.3 <<>> -x 208.12.16.5
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48532
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1
;; QUESTION SECTION:
;5.16.12.208.in-addr.arpa. IN PTR
;; ANSWER SECTION:
5.16.12.208.in-addr.arpa. 84600 IN PTR gateway.craic.com.
;; AUTHORITY SECTION:
16.12.208.in-addr.arpa. 84600 IN NS dns2.seanet.com.
16.12.208.in-addr.arpa. 84600 IN NS dns3.seanet.com.
16.12.208.in-addr.arpa. 84600 IN NS dns1.seanet.com.
;; ADDITIONAL SECTION:
dns3.seanet.com. 82813 IN A 199.181.164.3
;; Query time: 358 msec
;; SERVER: 192.168.2.18#53(192.168.2.18)
;; WHEN: Fri Jan 7 14:09:25 2005
;; MSG SIZE rcvd: 153The line returned in the answer section tells us the hostname that we are seeking. Before we had the hostname on the left side and the IP address on the right. Here we have the IP address in reverse on the left and a hostname on the right.
Notice something interesting in the results that dig has returned? We first asked for the
IP address corresponding to http://www.craic.com and got 208.12.16.5. Then we asked for the
hostname corresponding to 208.12.16.5 and got http://gateway.craic.com instead of http://www.craic.com. This is because the name
gateway is the canonical, or primary, name for this host
and www is an alias that points
to the same machine.
Within DNS you can map many names to a single IP address
either directly, using what are called A
records, or indirectly, using CNAME records that map one name to
another, which in turn maps to a numeric address. The reverse
mapping, however, should only contain a single record for each IP
address, containing the canonical hostname.
In addition, a single hostname can map to multiple IP addresses. This is how large sites distribute their load across multiple servers.
Using dig in this forward
and reverse manner can reveal interesting things about a site. Here
is an example using one of the O’Reilly web sites, http://www.macdevcenter.com. I have edited the output
heavily to save space. Going forward, dig tells us that http://www.macdevcenter.com is a CNAME alias of http://macdevcenter.com and that the hostname maps to
two IP addresses.
% dig www.macdevcenter.com
[...]
;; ANSWER SECTION:
www.macdevcenter.com. 6426 IN CNAME macdevcenter.com.
macdevcenter.com. 4812 IN A 208.201.239.36
macdevcenter.com. 4812 IN A 208.201.239.37Taking one of those addresses and running a reverse lookup returns this output:
% dig -x 208.201.239.36
[...]
;; ANSWER SECTION:
36.239.201.208.in-addr.arpa. 86371 IN PTR www.oreillynet.com.This shows that the canonical name for this server is http://www.oreillynet.com. From this asymmetry, we could infer that either http://macdevcenter.com is a subdivision of http://oreillynet.com—which happens to be true—or that perhaps the latter is a web-hosting company that manages http://macdevcenter.com for a subscriber.
In many cases like this, in which you think the target site is
up to no good, what you really want is the reverse lookup to list
all the hostnames that map to a single address. Unfortunately DNS
won’t give that to us. In principle it can, in response to a
zone transfer request using the
AXFR type, but most DNS servers
have this feature disabled.
whois is the primary tool for
querying the domain registration databases. It is available as a
standard command on Unix and Mac OS X systems, and most domain
registry web sites include a web interface to the command.
The basic way to use whois is
to enter a domain name or an IP address after the command—for example,
whois http://craic.com or whois 208.12.16.5. The command syntax can be
a lot more involved than this, but we don’t need any fancy options
here. The manpage for your implementation will tell you more.
An important point here is that, even though the basic syntax
for whois is essentially the same
as dig, whois tells us about
domains and networks
whereas dig tells us about
individual hosts. Their roles are
complementary.
Consider a basic listing in detail. The following is the
output of a query on my domain name. The real thing contains a load
of disclaimers and “terms of use” statements that have been replaced
with [...] for readability. I’ve
also added line numbers to help refer to specific items.
1 % whois craic.com
2 [whois.crsnic.net]
3 Whois Server Version 1.3
4 [...]
5 Domain Name: CRAIC.COM
6 Registrar: NETWORK SOLUTIONS, INC.
7 Whois Server: whois.networksolutions.com
8 Referral URL: http://www.networksolutions.com
9 Name Server: DNS1.SEANET.COM
10 Name Server: DNS2.SEANET.COM
11 Status: ACTIVE
12 Updated Date: 05-nov-2001
13 Creation Date: 22-may-1997
14 Expiration Date: 23-may-2006
15
16 >>> Last update of whois database: Tue, 17 Feb 2004 06:50:46 EST <<<
17 [...]
18 [whois.networksolutions.com]
19 [...]
20 Registrant:
21 Jones, Robert (CRAIC-DOM)
22 Robert Jones
23 Craic Computing
24 911 East Pike Street #231
25 SEATTLE, WA 98122
26 US
27 Domain Name: CRAIC.COM
28
29 Administrative Contact, Technical Contact:
30 Jones, Robert (RJ1571)
31 Robert Jones
32 Craic Computing
33 911 East Pike St #231
34 SEATTLE, WA 98122
35 US
36 <phone number>
37
38 Record expires on 23-May-2006.
39 Record created on 22-May-1997.
40 Database last updated on 17-Feb-2004 16:12:04 EST.
41
42 Domain servers in listed order:
43 DNS1.SEANET.COM 199.181.164.1
44 DNS2.SEANET.COM 199.181.164.2When you submit a query like this, whois sends it out to the whois server that is the default for your
specific implementation of the command. In this case, according to
line 2, the server used was http://whois.crsnic.net. That server looks up the
domain in its local database to see where it is registered, and then
it queries that registrar for additional information. This
two-tiered approach results in some duplication of information and
usually major differences in the display format.
Line 6 tells us that the domain is registered with Network Solutions and line 18 shows that their database was queried for the second part of the response.
Lines 13 and 39 tell us the database record was created on May 22, 1997. Similarly, lines 14 and 38 tell us how long the domain has been registered for.
Sites of dubious intent will typically have been registered just a few days or weeks before you receive any email from them, and the length of the registration will invariably be the minimum term of one year. In the case of http://craic.com, you can see that the business has been around for several years and expects to continue for several more. These dates can serve as a useful background check on any company that you might want to do business with.
There is a discrepancy between the update dates given in lines 16 and 40, illustrating the fact that two databases have queried to produce this output.
The DNS servers listed in lines 9 and 10 and again in lines 43 and 44 show that a relationship exists between http://craic.com and http://seanet.com. In the majority of cases, the authoritative DNS servers for a domain will either be at the domain registry or at the ISP used by that domain. In this case, Seanet is the ISP that I use and they manage those DNS records on my behalf.
Lines 20 through 36 represent contact information for the person or persons responsible for this domain. In the case of my domain, you can see that I serve as both the registrant and the administrative and technical contacts. You can see my name, business address, email, and phone number. This information is supposed to be accurate and kept up to date so that anyone can contact the owner in case of problems accessing the site or in case the site is up to no good.
We mentioned the introduction of privacy proxies by the registrars a little earlier. Here is a section from a domain record that uses this service:
Domain Name: GREENTREEPROMOS.COM
Administrative Contact:
Media, LLC, Revolution
br52s7fz7ux@networksolutionsprivateregistration.com
ATTN: GREENTREEPROMOS.COM
c/o Network Solutions
P.O. Box 447
Herndon, VA 20172-0447
570-708-8780The email address is a random string of characters that changes on a regular basis.
As soon as you start to work with whois, you will become aware of the
variation in the way the results are presented. In fact it’s a real
mess. It seems like every domain registry has its own format, and
the real information is buried in the middle of verbose legal
disclaimers and warnings.
This can be a real nuisance for people like us who want to
process these records. What we would prefer is a standard format,
preferably in XML, that would make it easy for us to pipe the
results into scripts that parse out the relevant data. The
registrars have intentionally not provided us with this. The problem
is that, in addition to people making legitimate requests, spammers
have used whois to trawl registry
databases in order to build up lists of email addresses. I get a
huge amount of spam, which is undoubtedly due to my email address
having been included in a domain registry since 1997. It can be
really frustrating working with these records but, at least for now,
there is not a lot we can do about it.
On top of this, you should be aware that not all Unix whois clients are the same. RedHat Fedora
2, for example, included jwhois
v3.2.2, whereas Mac OS X has a version from BSD Unix with a
different set of options. We don’t need to use any of those here but
check the manpage for your version to learn more.
RedHat 7.3 included yet another variant with an interesting
feature. That version would interpret a domain name not only in the
literal way it was written but also as a prefix on other domains. In
this form it would search and return all hostnames that matched the
supplied string. This behavior led certain miscreants to create
hostnames that are very rude about our friends at Microsoft and that
are only revealed through whois.
If you have access to this particular version and are not easily offended by bad language, then try the following simple query. It returns a large number of matching hostnames, of which a few of the tamer ones are shown.
% whois microsoft.com
[...]
Microsoft.com.fills.me.with.belligerence.net
Microsoft.com.zzz.is.owned.and.haxored.by.sub7.net
Microsoft.com.should.give.up.because.linuxisgod.comThis and other, more useful, features have been disappearing from both domain and DNS lookup tools over the past few years. The main motivation has been security, as certain features were felt to reveal a bit too much about networks. In the past you could find out all the domains owned by an individual and all the DNS records for a given domain. Sadly those days are gone.
Many of the domains that are associated with Internet fraud contain false contact information. ICANN and the registries make all the right noises about ensuring this information is correct, but they seem unable or unwilling to control the problem. So we just have to live with bad data—which is not to say that domain records are useless. Let’s look at an example of a bogus record and see what can be salvaged from it.
% whois mycitibank.org
[whois.publicinterestregistry.net]
[...]
Domain ID:D104488069-LROR
Domain Name:MYCITIBANK.ORG
Created On:02-Jun-2004 18:53:15 UTC
Expiration Date:02-Jun-2005 18:53:15 UTC
Sponsoring Registrar:R51-LROR
Status:TRANSFER PROHIBITED
Registrant ID:P-BTP31-449435
Registrant Name:Benjamin A Perowsky
Registrant Organization:Benjamin A Perowsky
Registrant Street1:173 Dean St.#3
Registrant City:Brooklyn
Registrant Postal Code:11217
Registrant Country:US
Registrant Phone: <phone number>
Registrant Email:holyky@list.ru
[...]
Tech ID:P-NCT21-63
Tech Name:Hostmaster Hostmaster
Tech Organization:united-domains AG
Tech Street1:Gautinger Strasse 10
Tech City:Starnberg
Tech Postal Code:82319
Tech Country:DE
Tech Phone:<phone number>
Tech Email:hostmaster@united-domains.de
Name Server:SERVER1-NS1.UDAGDNS.NET
Name Server:SERVER1-NS2.UDAGDNS.NET
Name Server:SERVER1-NS3.UDAGDNS.NETThis is the record for http://mycitibank.org, used at one time for a phishing site that pretended to be Citibank. It is safe to assume that Mr. Perowsky of Brooklyn, if he exists, did not register this domain. The fact that the email address is in Russia is a clue. That address may be correct. The registry needs a way to communicate with registrants in order to bill them, but this may not do us any good as we can’t tell who really receives the email. The information about the registry is going to be correct as they created this record. The same goes for the creation, expiration dates, and the authoritative DNS servers. These are all useful snippets of information.
Even if we know the contact information is bad, we can use it if we are looking at a number of domains we think might be related. That’s because people tend to be lazy. If you are registering several bogus domains, are you really going to think up different and convincing fake contact information for each of them? We can use similar or identical fake addresses to build links between apparently unconnected domains, as we do in the worked example at the end of this chapter. They serve as a type of fingerprint of the people involved.
We can also use whois to
look up an IP address. While this may look like the reverse DNS
lookups we used earlier, it is a different function that will turn
out to be very useful.
% whois 208.12.16.5
Sprint SPRINTLINK-BLKS (NET-208-0-0-0-1)
208.0.0.0 - 208.35.255.255
Seanet Corporation FON-34904473604317 (NET-208-12-0-0-1)
208.12.0.0 - 208.12.31.255
# ARIN WHOIS database, last updated 2005-01-06 19:10
# Enter ? for additional hints on searching ARIN's WHOIS database.Nowhere in the output is there any mention of 208.12.16.5 or http://craic.com, so what’s going on here? These are
the subnets of IP addresses that our address is part of. First off,
our target address is located in the United States, so the database
that answered the query is at ARIN. They are telling us that Seanet
Corporation controls addresses 208.12.0.0 through 208.12.31.255 and that Sprint controls the
even larger network, of which Seanet is a part.
We can reasonably infer that Seanet is my ISP or that my ISP
has its addresses allocated to them by Seanet. That is important
information. If we find the IP address of a site that is up to no
good, we may want to ask their ISP to shut them down. This form of
whois query can quickly help us
find out who we need to talk to.
As I say, the form of report you get depends on the regional registry that manages that block of IP addresses. Here are examples of addresses in the other three regions. Unimportant text has been edited out for the sake of readability.
Here is what the output of APNIC looks like for an address in its region of control:
% whois 211.144.162.160
[Querying whois.apnic.net]
[...]
inetnum: 211.144.160.0 - 211.144.175.255
netname: LIANFENGMAN
country: CN
descr: CHONGQING LIANFENG COMMUNICATION Co.,Ltd
descr: 18F, BUIDING-A, CITY PLAZA, 39-WUSI ROAD,YUZHONG
DISTRICT, CHONG QING,PRC.
admin-c: DC278-AP
tech-c: ZL153-AP
status: ALLOCATED PORTABLE
changed: shenzhi@cnnic.cn 20041102
mnt-by: MAINT-CNNIC-AP
source: APNIC
person: DUAN CHUNYAN
nic-hdl: DC278-AP
e-mail: cfc_dcy@sina.com
address: 18F, BUIDING-A, CITY PLAZA, 39-WUSI ROAD,
YUZHONG DISTRICT, CHONG QING,PRC.
phone: <phone number>
fax-no: <phone number>
country: CN
changed: shenzhi@cnnic.cn 20041102
mnt-by: MAINT-CNNIC-AP
source: APNIC
[...]Here is a query for an address in the United Kingdom that gets handled by the RIPE NIC server, responsible for Europe and the Middle East:
% whois 212.20.227.174
[...]
[whois.ripe.net]
[...]
inetnum: 212.20.227.128 - 212.20.227.255
netname: EDNET-COLO-1
descr: edNET Internet Limited
country: GB
admin-c: NS1518-RIPE
tech-c: RM7978-RIPE
status: ASSIGNED PA
mnt-by: EDNET-RIPE-MNT
changed: neil@ednet.co.uk 20030716
remarks: INFRA-AW
source: RIPE
route: 212.20.224.0/22
descr: edNET UK
origin: AS12703
remarks: removed cross-mnt: EDNET-RIPE-MNT
mnt-by: EDNET-RIPE-MNT
changed: neil@ednet.co.uk 20031119
source: RIPE
[...]The output here tells of a block of 128 addresses (212.20.227.128-212.20.227.255) assigned to
EDNET-COLO-1, which is probably a subnet of EDNET used for
collocation of web servers. The line at the start of the second
paragraph (route: 212.20.224.0/22) tells us this is itself
part of a larger block, also assigned to EDNET with the range
212.20.224.0 - 212.20.255.255.
Finally, here is the format of report returned by LACNIC for an address in Chile:
% whois 146.83.12.32
[whois.lacnic.net]
[...]
inetnum: 146.83/16
status: assigned
owner: Red Universitaria Nacional
ownerid: CL-RUNA1-LACNIC
responsible: Claudia Inostroza
address: Canada, 239, Providencia
address: 6640806 - Santiago -
country: CL
phone: <phone number>
owner-c: CIM2
tech-c: CIM2
inetrev: 146.83/16
nserver: TERMINUS.REUNA.CL
nsstat: 20050103 AA
nslastaa: 20050103
nserver: NS.REUNA.CL
nsstat: 20050103 AA
nslastaa: 20050103
created: 19910128
changed: 20010222
[...]In this version, the IP address block is given in the
alternate format we mentioned earlier. 146.83/16 means that the starting address
is 146.83.0.0 with the highest 16
bits fixed and hence the remaining 16 bits being available for
allocation. This translates into the address range of 146.83.0.0 through 146.83.255.255.
I need to stress, once again, that different versions of
whois may behave differently. Mac
OS X will query ARIN first regardless of the IP address. If ARIN
says it is out of their range, it uses their referral to go to the
correct registry. You end up with the correct information buried in
reams of irrelevant verbiage. The version that ships with Linux
(RedHat Fedora Core 2) figures out the correct registry without this
intermediate step, probably through a simple lookup table, and
returns its results quickly and cleanly. Bear this in mind if you
want to write scripts that parse whois output.
You can also access whois
through a variety of web interfaces, in particular at domain
registries. Here are several examples:
Spammers have used domain records as a source of email
addresses for some time now. A standard tactic has been to use a
script to make thousands of requests to web-based whois clients. These days most of the
sites will either prevent you from making more than a certain number
of requests in a period of time, or they will display an image of a
number on the query form that you will need to type into the form
along with the domain name. That can get tedious, but there are
times when a web-based client comes in handy.
These may not provide the full functionality of the Unix clients. Some will only respond to domain name queries, whereas the clients at the four RIRs, shown in Table 2-1, seem to respond only to IP address queries.
Two web-based clients are worthy of special mention. Netcraft
is a company in the U.K. that tracks various aspects of technology
on the Internet. They have a large database of domain names, web
sites, and ancillary data. Their whois-like client (http://searchdns.netcraft.com/?host) lets you search
this resource and offers a number of features not available from
standard whois. In particular you
can search on domain names using substrings and wildcards. A simple
query like craic will return all
domains that contain that string. This can be very useful when you
want to find sites that might be involved in phishing. Try searching
on PayPal or eBay and see how many domains show up. http://sqlwhois.com provides a similar service with
their client (http://www.sqlwhois.com/en/index.html). Here you have
even more control over your query terms, but their database is
limited to the .com and .net registries.
dig and whois tell you about specific addresses on
the Internet and who controls them. traceroute tells you about the
path between two addresses—how to get there from
here. Run on host A, with host B as its target, traceroute fires off packets that are passed
through a series of intervening gateways or routers as determined by
the Internet protocol and the topology of the Internet.
Normal network transactions, like a request for a web page, do
not report the path they take from A to B. traceroute, on the other hand, triggers a
response from every router along the way. It does this by utilizing
the IP protocol time to live
field and attempts to elicit an ICMP
TIME_EXCEEDED response from each machine. If successful, it
captures the IP address of the machine and the time at which the
response was received. It performs a reverse lookup on the IP address
in the hope of getting a hostname. It doesn’t always work as well as
we’d like. Not all machines provide the ICMP
TIME_EXCEEDED response, and many routers do not have
corresponding hostnames, so its output can be very cryptic at times.
But in many cases it provides a very useful perspective on the network
connectivity of the target host and their ISP.
You can infer a lot from the output of traceroute on a particular address. It can
provide clues about the type of network the target machine is part of,
it can reveal their ISP, and it may be able to tell you something
about how the ISP is connected to the rest of the Net.
Here is the output of the command run from a machine in Australia (http://looking-glass.uecomm.net.au/) pointed at one of my servers. I have deleted some timing information from each step to improve readability.
traceroute to 208.12.16.5 from looking-glass.uecomm.net.au,
30 hops max, 38 byte packets
1 vl2021.agg1.cit190.uecomm.net.au (203.94.128.105)
2 180.gi1.br1.que31.uecomm.net.au (218.185.31.122)
3 sl-gw1-mel-6-0-0.sprintlink.net (203.222.35.229)
4 sl-bb21-syd-1-0.sprintlink.net (203.222.33.18)
5 sl-bb21-syd-14-1.sprintlink.net (203.222.32.49)
6 sl-bb21-sj-3-2.sprintlink.net (144.232.8.130)
7 sl-bb23-tac-14-0.sprintlink.net (144.232.20.9)
8 sl-bb20-tac-5-0.sprintlink.net (144.232.17.173)
9 144.232.17.54 (144.232.17.54)
10 sl-seane-2-0-0.sprintlink.net (160.81.116.34)
11 fermat.seanet.com (199.181.164.164)
12 208.12.16.1 (208.12.16.1)
13 gateway.craic.com (208.12.16.5)The first two lines show how the source machine connects to the Internet backbone. The next eight lines show the path taken through the SprintLink backbone to Seattle. The last four tell about the network near to my server. Let’s work back from the last line. The next-to-the-last step (line 12) has only an IP address that is very similar to the target machine. The difference in numbers is so small that it is reasonable to assume they are both on the same network.
Businesses often have a range of IP addresses for their various
publicly accessible server. These typically form a subnet that is
connected to the ISP by way of a router. Simple routers are not
usually given hostnames and are also usually given the first usable IP
address in a subnet. So we can make an educated guess that 208.12.16.1 is a router that controls access
to a small subnet on which the target is located.
Line 11 shows a machine at http://seanet.com. This might well be the ISP that the target connects to. Looking up Seanet on the Web shows it to be based in Seattle. It appears to serve a regional market so it may locate the target machine in the Seattle area.
Line 10 tells us that Seanet connects to the rest of the world via http://sprintlink.net.
By looking at some of the http://sprintlink.net lines and using some creative
reasoning, we can even figure out the path taken between Australia and
Seattle. Those SprintLink routers have hostnames and it looks like the
location of each is embedded in the name. So my guess is that the path
taken was from Melbourne to Sydney (syd), over to the United States to San Jose
(sj), up the West Coast to Tacoma
(tac) and finally to Seattle. Okay,
so maybe the San Jose step is a bit of a stretch, but you get the
idea.
If you are interested in the topology of the network and the
connectivity of an ISP then you can repeat the same analysis using
traceroute from other locations.
Here is the output from the command run on a server in Vienna, Austria
(http://www.vix.at/cgi-bin/lg.cgi).
Tracing the route to gateway.craic.com (208.12.16.5)
1 vix2.core01.vie01.atlas.cogentco.com (193.203.0.113)
2 p6-0.muc01.atlas.cogentco.com (130.117.1.150)
3 p14-0.core01.fra03.atlas.cogentco.com (130.117.1.198)
4 p12-0.core01.dca01.atlas.cogentco.com (154.54.1.17)
5 p6-0.core01.jfk02.atlas.cogentco.com (66.28.4.82)
6 p15-0.core02.jfk02.atlas.cogentco.com (66.28.4.14)
7 p14-0.core02.ord01.atlas.cogentco.com (66.28.4.86)
8 p12-0.core01.mci01.atlas.cogentco.com (66.28.4.33)
9 p5-0.core01.den01.atlas.cogentco.com (66.28.4.29)
10 p5-0.core01.sea01.atlas.cogentco.com (66.28.4.101)
11 g49.ba01.b001696-0.sea01.atlas.cogentco.com (66.250.9.98)
12 Seanet.demarc.cogentco.com (66.28.31.98)
13 fermat.seanet.com (199.181.164.164)
14 208.12.16.1
15 gateway.craic.com (208.12.16.5)Here we see that a different backbone has been used to connect
from Europe. The router locations are more cryptic, but I would guess
that jfk (lines 5 and 6) refers to
New York and den refers to Denver
(line 9). Line 12 shows the end of the path via http://cogentco.com in Seattle followed by the same
server as before at Seanet. This implies that Seanet has direct
connections to both SprintLink and Cogent. Experimentation with
traceroute from a number of other
sites may turn up the same or additional connections and can suggest
how large that ISP is.
There are a number of sites out there that are kind enough to
provide web interfaces to traceroute and several other tools related
to routing and connectivity. These are referred to as “Looking Glass”
servers, since they are typically used to probe your own site. http://geektools.com provides a list of these at http://www.geektools.com/traceroute.php—but not all
those listed are operational. Table 2-2 lists a few
around the world that work at the time of this writing.