Chris's Wiki :: blog/spam/IPToASN

Mapping IP addresses to ASNs

December 3, 2008

Prompted by my old SpamByASN entry, I was recently asked how you would do IP to ASN lookups, and ideally ASN to IP lookups too. Since the full answer is complicated, I will do the simple and useful one first.

Assuming that nothing funny is going on, each IP address has exactly one ASN that ultimately announces it. The easiest way to find out this mapping for a given IP address is to use the asn and aspath reverse DNS lookup zones that routeviews.org provides; these return TXT records with the relevant information. For most people, the more useful one is asn.routeviews.org:

; sdig txt 1.100.100.128.asn.routeviews.org
"239" "128.100.0.0" "16"

This says that 128.100.100.1 is announced by AS 239, using the CIDR netblock 128.100.0.0/16. (See routeviews.org for details on what is returned for IP addresses with no routing information available.)

This doesn't tell you what AS 239 is, though, and it doesn't tell you what else AS 239 is responsible for (or at least claims to route). You can look up ASN details in various registration bodies, but the simplest resource I know of is the potaroo.net AS report lookup, which for any given ASN is 'http://asNNN.potaroo.net/' (eg, ours).

Unfortunately, as far as I know looking up all of the IP addresses that belong to an ASN is harder. While potaroo.net will tell you all of the CIDR netblocks that an ASN advertises, I don't know if it will tell you if another ASN is advertising more specific routes to portions of them (which I think happens routinely). However, for anti-spam work I believe that the potaroo data is usually going to be good enough (possibly coupled with some research about what the advertised netblocks theoretically are).

Note that there are a boatload of cautions associated with using ASNs this way, which I will summarize for now by saying that the Internet does not have a consistent global view of this stuff; what you see may depend on where you look from.

Comments on this page:

By rdump at 2008-12-03 18:55:19:

While ASN info is useful for research, you'll want to avoid taking it too far. In particular, using it for abuse reporting is too far.

In addition to the lack of consistent global view, you're going to run into problems if you improperly conflate route announcements with administrative control over the hosts on the subnets announced.

For one pathological example, a particular anti-spam tool developer once decided that I was responsible for hosts on subnets run by the Colorado State Government and an .edu in another state entirely. His reasoning (and I use the term loosely) was that because I receive mail for abuse@ our domain, and a staff member address in our domain is listed as a technical contact for an upstream ASN that announces routes to all those subnets, I therefore own any issue he wants to give me about the foreign subnets as well as ours.

Worse, he became rather insistent about that mispurposing. He suggested (and I use that term loosely as well) we should reorganize the .edu and government IT efforts to match his desire to use an address he derived from an ASN record's tech contact as his single point of contact for abuse issues on all announced subnets. He wackily greeted with derision my suggestion that he pay attention to the accurate OrgAbuse* contact info listed in the ARIN allocation records for the subnets.

I still regard that guy as a kook to this day.

So, when you look up ASNs, be careful to avoid conflating routing announcements with any kind of administrative control over announced subnets. You generally won't want to expect an ASN to get you better contact results than an ARIN record. And you certainly won't want to insist that the folks you end up bothering via ASN contacts re-organize to match mispurposing ASN contacts for abuse contacts.

Written on 03 December 2008.

«	A thesis: Sun should fork Solaris

The rewriting problem on ZFS and other 'log structured' filesystems