Return to UOCC HomeComputing News Home
Header bar

Per-ASN DNS Blackhole Lists: the Latest Boon to System Administrators

Joe St Sauver, Ph.D.
Director, User Services and Network Applications
joe@uoregon.edu

The number and variety of DNS (domain name system)-based blacklists continues to expand. For example, ClueCentral.Net (http://www.cluecentral.net/) is now offering per-ASN DNS lists for all IPv4 address space known to be assigned.

What's an ASN?

An ASN, or "Autonomous System Number," is usually technically defined as a number assigned to "a group of network addresses, managed by a particular network operator, sharing a common routing policy." Most ISP and university networks have an ASN. For example, the UO's network uses AS3582; UC Berkeley uses AS25; Google uses AS15169; Sprint uses AS1239,… and so on.

Some large networks with particularly complex routing policies may have more than one ASN; others, with simple routing policies and only a single upstream network provider, may have none.

Bottom line, think of an ASN as a number that represents a particular provider or network.

What's a DNS Blackhole List?

The Domain Name System is normally used to efficiently translate a symbolic address (e.g., www.uoregon.edu) to a numeric IP address (or "dotted quad") such as 128.223.142.13. The DNS system can also be used in the reverse direction, taking a numeric IP address and returning the symbolic name associated with that dotted quad.

DNS blacklists use that same DNS infrastructure, but cleverly use it to return encoded information associated with a given network address of interest. That information might be whether or not a particular network address is associated with a dialup host, or whether a given network address is associated with a mail server that's known to be insecurely configured, or whether some other dotted quad is a chronic source of unwanted commercial email.

In this case, ClueCentral.net (the new ASN-oriented DNSBL mentioned earlier), allows a mail server administrator to check whether a given dotted quad is associated with an ASN of interest. For example, the DNSBL could be used to see if 128.223.142.13 is associated with AS3582 (it is):

host 13.142.223.128.AS3582.rbl.cluecentral.net
13.142.223.128.AS3582.rbl.cluecentral.net has address
127.0.0.2

If the specified address had not been associated with the specified ASN, the DNS system would have returned the message "domain not found," instead.

Why Would Anyone Be Interested in an ASN-oriented DNSBL?

Most ISPs, including the University of Oregon, have an acceptable use policy and enforce it, requiring their users not to spam or otherwise abuse other users of the Internet. Some ISPs, however, simply don't care and don't make any effort to deal with complaints about abuse their users engage in.

For example, let's assume that over a period of time, it becomes clear (via whatever mechanism) that the fictional ISP, Vladimir's Networked Borscht Shops (VNBS), AS91234, is overrun with spammers, and Vladimir really doesn't care (as long as the spammers keep paying and his borscht doesn't burn).

When that happens, other sites may decide they no longer want to accept any email from VNBS. Having reached that decision, they can then look up the network addresses associated with VNBS and use local filters to begin blocking all messages from those addresses. Using local filters that way can become tedious, since VNBS may add and delete network blocks over time, which means that the locally maintained filters will also require additions and deletions. You can probably keep up with a few providers this way, but if you're shunning traffic from several dozen (or more) entities, you'll need to peddle pretty hard just to keep up with the additions and deletions to those filters.

Enter the ASN-oriented DNSBL. Now, instead of having to look up and specify a set of network address blocks associated with VNSB, your mail administrator simply decides not to accept traffic from Vladimir's ASN, AS91234, and configures his mail server to use the appropriate per-ASN DNSBL zone for that ASN. Voila, he's done! …And, if the network addresses associated with that ASN change, those changes are automatically reflected in the per-ASN DNSBL.

Clearly this is a very powerful and convenient way for a mail server administrator to refuse unwanted traffic from a particular rogue ISP/ASN. Moreover, per-ASN DNSBLs are vastly preferable to the per-country DNSBLs to which some sites have resorted. Network abuse is not associated with all the network addresses assigned to all the networks in Brazil, for example, but rather with addresses assigned to a particular ISP/ASN (or set of ISPs/ASNs) which just happens to be in Brazil (or China, or the United States, for that matter).

Per-ASN DNSBLs do a nice job of matching consequences (e.g., filtering) with the parties responsible for the conditions which make that filtering necessary (e.g., tolerance of abusive customers and insecurely configured customer systems).


Summer 2003 Computing News | Computing Center Home Page