Team Cymru is happy to announce the availability of various service options dedicated to mapping IP numbers to BGP prefixes and ASNs. These services come in various flavors, including:
Each of the services is based on the same BGP feeds from 50+ BGP peers, and is updated at 4 hour intervals.
Using the above services one can obtain all of the following information:
The country code, registry, and allocation date are all based on data obtained directly from the regional registries including: ARIN, RIPE, AFRINIC, APNIC, LACNIC. The information returned relating to these categories will only be as accurate as the data present in the RIR databases.
IMPORTANT NOTE: Country codes are likely to vary significantly from actual IP locations, and we must strongly advise that the IP to ASN mapping tool not be used as an IP geolocation (GeoIP) service.
The exact links for each of the datasets are as follows:
The ASN descriptions are based on data obtained from cidr-report.
If you are looking for an IP geolocation service, please check out one of the following (note: links do not constitute an endorsement, please contact us if you have a major commercial or free IP geolocation service you would like listed here):
Following is a brief summary on how to use each of the services.
The whois daemon acts like a standard whois server would, but with some added functionality. It accepts arguments on the command-line for single whois queries, and it also supports BULK IP submissions when combined with GNU's netcat for those who wish to optimize their queries. When issuing requests for two or more IPs we strongly suggest you use netcat for BULK IP submissions, or DNS since there is less overhead. As a measure of speed, queries of approximately 10,000 IPs should return in less than a minute given a moderately sized Internet link.
WARNING: IPs that are seen abusing the whois server with large numbers of individual queries instead of using the bulk netcat interface will be null routed. If at all possible you should consider using the DNS based query interface since it is much more efficient for individual queries. The netcat interface should be used for groups of IP lists at a time in one single TCP query.
There are presently two whois servers available:
The v4.whois.cymru.com server is primarily designed to map an IP address to a BGP Origin ASN and prefix.
The v4-peer.whois.cymru.com server is designed to map an IP address to the possible BGP peer ASNs that are one AS hop away from the BGP Origin ASN's prefix. This can be useful at times when you're looking for a quick view into who an IP's upstreams might be. Note that this method of finding peers is FAR from perfect and not an exact science. When the Origin ASN is a Tier 1 any concept of 'upstream' tends to lose its meaning.
The syntax for whois and netcat whois IP queries is as follows:
Whois Netcat Action begin enable bulk input mode (netcat only) end exit the whois/netcat client (netcat only) -p prefix include matching prefix -q noprefix disable matching prefix (default) -c countrycode include matching country code -d nocountrycode disable country codes (default) -n asname include asnames (default) -o noasname disable asnames -r registry display matching registry -s noregistry disable registry display (default) -a allocdate enable allocation date -b noallocdate disable allocation date (default) -t truncate truncate asnames (default) -u notruncate do not truncate asnames -v verbose enable all flags (-c -r -p -a -u -a) -e header enable column headings (default) -f noheader disable column headings -w asnumber include asnumber column (default) -x noasnumber disable asnumber column (will not work for IP mappings) -h help this help message
To use the command-line arguments on a single IP query, be sure to enclose the request in quotes and to have a space before the first argument so that your whois client will not try to interpret the flags locally.
For example, to enable the verbose mode (all flags) one would use:
$ whois -h whois.cymru.com " -v 184.108.40.206 2005-12-25 13:23:01 GMT" AS | IP | BGP Prefix | CC | Registry | Allocated | Info | AS Name 23028 | 220.127.116.11 | 18.104.22.168/24 | US | arin | 1998-09-25 | 2005-12-25 13:23:01 GMT | TEAM-CYMRU - Team Cymru Inc., US
You may also query for some basic AS information directly:
$ whois -h whois.cymru.com " -v AS23028" AS | CC | Registry | Allocated | AS Name 23028 | US | arin | 2002-01-04 | TEAM-CYMRU - Team Cymru Inc., US
We recommend the use GNU's version of netcat, not nc. (nc has been known to cause buffering problems with our server and will not always return the full output for larger IP lists). GNU netcat can be downloaded from http://netcat.sourceforge.net. This is the same as gnetcat in FreeBSD ports.
To issue bulk queries, follow these steps:
1. Create a file with a list of IPs, one per line. Add the word begin at the top of the file and the word end at the bottom.
Example of list01:
begin 22.214.171.124 126.96.36.199 ... 188.8.131.52 end
Remember: you can add comments and other flags per the table above if you'd like.
begin verbose 184.108.40.206 2005-06-30 05:05:05 GMT 220.127.116.11 2005-06-30 05:05:05 GMT ... 18.104.22.168 2005-06-30 05:05:05 GMT end
2. Run the list through GNU netcat (NOT the venerable nc).
$ netcat whois.cymru.com 43 < list01 | sort -n > list02
The file list02 will be sorted by origin AS, and should appear as:
Bulk mode; whois.cymru.com [2018-08-29 21:04:00 +0000] 701 | 22.214.171.124 | 126.96.36.199/16 | US | arin | 1992-11-10 | 2005-06-30 05:05:05 GMT | UUNET - MCI Communications Services, Inc. d/b/a Verizon Business, US 6079 | 188.8.131.52 | 184.108.40.206/18 | US | arin | 1996-11-01 | 2005-06-30 05:05:05 GMT | RCN-AS - RCN, US 23028 | 220.127.116.11 | 18.104.22.168/24 | US | arin | 2002-03-15 | 2005-06-30 05:05:05 GMT | TEAM-CYMRU - Team Cymru Inc., US
Additional help can be obtained by issuing the help command:
$ whois -h whois.cymru.com help
For additional support or to report an issue, please contact firstname.lastname@example.org.
The DNS daemon is designed for rapid reverse lookups, much in the same way as RBL lookups are done. DNS has the added advantage of being cacheable and based on UDP so there is much less overhead. Similar to the whois TCP based daemon, there are three IPv4 zones available, and one for IPv6:
The origin.asn.cymru.com zone is used to map an IP address or prefix to a corresponding BGP Origin ASN.
The origin6.asn.cymru.com zone is used to map an IPv6 address or prefix to a corresponding BGP Origin ASN.
The peer.asn.cymru.com zone is used to map an IP address or prefix to the possible BGP peer ASNs that are one AS hop away from the BGP Origin ASN's prefix.
The asn.cymru.com zone is used to determine the AS description of a given BGP ASN.
All DNS-based queries should be made by pre-pending the reversed octets of the IP address of interest to the appropriate zone listed above, demonstrated in the following examples:
$ dig +short 22.214.171.124.origin.asn.cymru.com TXT "23028 | 126.96.36.199/24 | US | arin | 1998-09-25"
The same query could be expressed as:
$ dig +short 108.90.216.origin.asn.cymru.com TXT "23028 | 188.8.131.52/24 | US | arin | 1998-09-25"
IPv6 queries are formed by reversing the nibbles of the address, and placing dots between each nibble, just like an IPv6 reverse DNS lookup, except against origin6.asn.cymru.com instead of ip6.arpa. Note that you must pad out all omitted zeroes in the IPv6 address, so this can get quite long! For example, to look up 2001:4860:b002::68, you would issue the following query:
$ dig +short 184.108.40.206.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.b.0.6.8.4.220.127.116.11.origin6.asn.cymru.com. TXT "15169 | 2001:4860::/32 | US | arin | 2005-03-14"
You can considerably shorten your query if you assume that the long runs of zeroes are in the host portion of the address (as is often the case with IPv6 addresses:
$ dig +short 2.0.0.b.0.6.8.4.18.104.22.168.origin6.asn.cymru.com. TXT "15169 | 2001:4860::/32 | US | arin | 2005-03-14"
To query for a given IP/prefix peer ASNs, one would use the peer.asn.cymru.com zone as follows:
$ dig +short 22.214.171.124.peer.asn.cymru.com TXT "701 1239 3549 3561 7132 | 126.96.36.199/24 | US | arin | 1998-09-25"
When there are multiple Origin ASNs or Peer ASNs, they will all be included in the same TXT record such as in the example above.
Notice that the format is very similar to the data returned in the verbose whois based query. The major difference is that the AS Description information has been omitted. In order to return the ASN Description and additional info, one use:
$ dig +short AS23028.asn.cymru.com TXT "23028 | US | arin | 2002-01-04 | TEAM-CYMRU - Team Cymru Inc., US"
If a given prefix does not exist in the table, the daemon will return a standard NXDOMAIN response (domain does not exist).
The HTTP and HTTPS daemons act as a web based proxy to the whois based service. You can reach the service directly by browsing to:
Simply click on one of the above links and follow the onscreen instructions on how translate IPs to their corresponding BGP ASNs.
We monitor route announcements from multiple locations and from multiple providers. In some cases a network prefix will be announced by multiple, but disparate, networks or autonomous systems. The most likely reason for this is something known as "multihoming". This is perfectly normal. Depending on your view of the Internet topology and the originating network's policies, one of those originating networks will be the preferred path for sending and receiving traffic with the netblock in question. We choose to show you the list of all those we know about.Why, when I query for address 'a.0.0.0' does it show me one originating ASN/network, but when I query for 'a.b.c.d', an address whose first few bits match that of the first address, I'm given a completely different originating ASN/network?
Most likely there are at least two route announcements we know about, one larger prefix that matches your first query and the latter is matched by a separate, more specific route announcement from someone else. This is perfectly normal. It may occur for a variety of reasons, most likely due to the routing policies by the originating networks to influence how traffic is delivered for specific prefixes.Why do I see an originating ASN and route announcement when I query for a bogon address?
Some of the routes we learn from partners may contain "leaked" or otherwise bogon routes. The originating network is likely using those routes internally, and they are not meant to be publicly accessible. All routes we publish through our mapping service are presented unfiltered. Note, these routes may be filtered out by other networks so they may not show up in traceroutes, other route monitoring collectors or other online tools.Is there a limit to the number of addresses we can submit to the bulk interface?
Please keep the total number of addresses per bulk run to a few thousand. This just helps minimize overall load. Please consider using the DNS-based service interface for regular, recurring bulk queries.I have IP addresses within the same IPv4 /24 prefix and/or within the same IPv6 /64 prefix. Should I aggregate them together?
Yes. You are we are not likely going to see more specific routes for /24 and /64 prefixes. Aggregating them together will help eliminate unnecessary load and allow you to improve your query performance.