Section 2.2. Internet Address Tools
2.2. Internet Address ToolsThree 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. 2.2.1. digdig (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. 2.2.1.1. Hostname lookupsIn 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: 127 The 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 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.5 This 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. 2.2.1.2. Reverse lookupsSupplied 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: 153 The 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 www.craic.com and got 208.12.16.5. Then we asked for the hostname corresponding to 208.12.16.5 and got gateway.craic.com instead of 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. 2.2.1.3. Back and forthUsing 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, www.macdevcenter.com. I have edited the output heavily to save space. Going forward, dig tells us that www.macdevcenter.com is a CNAME alias of 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.37 Taking 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 www.oreillynet.com. From this asymmetry, we could infer that either macdevcenter.com is a subdivision of oreillynet.comwhich happens to be trueor that perhaps the latter is a web-hosting company that manages 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.
2.2.2. whoiswhois 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 commandfor example, whois 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.
2.2.2.1. Dissecting a whois reportConsider 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.2 When 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 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 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 craic.com and 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. 2.2.2.2. Privacy blocks on domain informationWe 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-8780 The email address is a random string of characters that changes on a regular basis. 2.2.2.3. Diversity in whois outputAs 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.com This 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. 2.2.2.4. Bogus information from whoisMany 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 datawhich 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.NET This is the record for 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. 2.2.2.5. Using whois to query IP address blocksWe 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 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. 2.2.2.6. whois on the WebYou 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. 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. 2.2.3. traceroutedig and whois tell you about specific addresses on the Internet and who controls them. traceroute tells you about the path between two addresseshow 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 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 sprintlink.net. By looking at some of the 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 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. geektools.com provides a list of these at http://www.geektools.com/traceroute.phpbut not all those listed are operational. Table 2-2 lists a few around the world that work at the time of this writing.
|
