DNSBL

A DNSBL (DNS-based Blackhole List, Block List, or Blacklist; see below) is a list of IP addresses published through the Internet Domain Name Service (DNS) either as a zone file that can be used by DNS server software, or as a live DNS zone that can be queried in real-time. DNSBLs are most often used to publish the addresses of computers or networks linked to spamming; most mail server software can be configured to reject or flag messages which have been sent from a site listed on one or more such lists.

DNSBL is a software mechanism, rather than a specific list or policy. There are dozens of DNSBLs in existence,^[1] which use a wide array of criteria for listing and delisting of addresses. These may include listing the addresses of zombie computers or other machines being used to send spam, listing the addresses of ISPs who willingly host spammers, or listing addresses which have sent spam to a honeypot system.

Since the creation of the first DNSBL in 1997, the operation and policies of these lists have been frequently controversial, both in Internet advocacy and occasionally in lawsuits. Many email systems operators and users consider DNSBLs a valuable tool to share information about sources of spam, but others including some prominent Internet activists have objected to them as a form of censorship. In addition, a small number of DNSBL operators have been the target of lawsuits filed by spammers seeking to have the lists shut down.

History of DNSBLs

The first DNSBL was the Real-time Blackhole List (RBL), created in 1997, at first as a BGP feed by Paul Vixie, and then as a DNSBL by Eric Ziegast as part of Vixie's Mail Abuse Prevention System (MAPS); Dave Rand at Abovenet was its first subscriber.^[2] The very first version of the RBL was not published as a DNSBL, but rather a list of networks transmitted via BGP to routers owned by subscribers so that network operators could drop all TCP/IP traffic for machines used to send spam or host spam supporting services, such as a website. The inventor of the technique later commonly called a DNSBL was Eric Ziegast while employed at Vixie Enterprises.

The term "blackhole" refers to a networking black hole, an expression for a link on a network that drops incoming traffic instead of forwarding it normally. The intent of the RBL was that sites using it would refuse traffic from sites which supported spam — whether by actively sending spam, or in other ways. Before an address would be listed on the RBL, volunteers and MAPS staff would attempt repeatedly to contact the persons responsible for it and get its problems corrected. Such effort was considered very important before blackholing all network traffic, but it also meant that spammers and spam supporting ISPs could delay being put on the RBL for long periods while such discussions went on.

Later, the RBL was also released in a DNSBL form and Paul Vixie encouraged the authors of sendmail and other mail software to implement RBL support in their clients. These allowed the mail software to query the RBL and reject mail from listed sites on a per-mail-server basis instead of blackholing all traffic.

Soon after the advent of the RBL, others started developing their own lists with different policies. One of the first was Alan Brown's Open Relay Behavior-modification System (ORBS). This used automated testing to discover and list mail servers running as open mail relays—exploitable by spammers to carry their spam. ORBS was controversial at the time because many people felt running an open relay was acceptable, and that scanning the Internet for open mail servers could be abusive.

In 2003, a number of DNSBLs came under denial-of-service attacks. Since no party has admitted to these attacks nor been discovered responsible, their purpose is a matter of speculation. However, many observers believe the attacks are perpetrated by spammers in order to interfere with the DNSBLs' operation or hound them into shutting down. In August 2003, the firm Osirusoft, an operator of several DNSBLs including one based on the SPEWS data set, shut down its lists after suffering weeks of near-continuous attack.

URI DNSBLs

A URI DNSBL is a DNSBL that lists the domain names and IP addresses which are found in the "clickable" links contained in the body of spams, but generally not found inside legitimate messages.

URI DNSBLs were created when it was determined that much spam made it past spam filters during that short time frame between the first use of a spam-sending IP address and the point where that sending IP address was first listed on major sending-IP-based DNSBLs.

In many cases, such elusive spams contain in their links domain names or IP addresses (collectively referred to as a URIs) where that URI was already spotted in previously caught spam and where that URI is not found in non-spam e-mail.

Therefore, when a spam filter extracts all URIs from a message and checks them against a URI DNSBL, then the spam can be blocked even if the sending IP for that spam has not yet been listed on any sending IP DNSBL.

Of the three major URI DNSBLs, the oldest and most popular is SURBL,^[3] created and operated primarily by Jeff Chan. After SURBL was created, some of the administrators and contributors to SURBL started the second major URI DNSBL, URIBL.^[4] More recently, another current and long-time SURBL administrator, Rob McEwen,^[5] started the third major URI DNSBL, ivmURI.^[6]

URI DNSBLs are often confused with RHSBLs (Right Hand Side BLs). But they are different. A URI DNSBL lists domain names and IPs found in the body of the message. An RHSBL lists the domain names used in the "from" or "reply-to" e-mail address. RHSBLs are not very effective because most spams either use forged "from" addresses or use "from" addresses containing popular freemail domain names, such as @gmail.com, @yahoo.com, or @hotmail.com addresses. In contrast to marginally effective and not-often-used RHSBLs, URI DNSBLs are very effective and are used by the majority of spam filters.

How a DNSBL works

To operate a DNSBL requires three things: a domain to host it under, a nameserver for that domain, and a list of addresses to publish.

It is possible to serve a DNSBL using any general-purpose DNS server software. However this is typically inefficient for zones containing large numbers of addresses, particularly DNSBLs which list entire Classless Inter-Domain Routing netblocks. For the large resource consumption when using software designed as the role of a Domain Name Server, there are role-specific software applications designed specifically for servers with a role of a DNS blacklist.

The hard part of operating a DNSBL is populating it with addresses. DNSBLs intended for public use usually have specific, published policies as to what a listing means, and must be operated accordingly to attain or sustain public confidence.

DNSBL queries

When a mail server receives a connection from a client, and wishes to check that client against a DNSBL (let's say, dnsbl.example.net), it does more or less the following:

1. Take the client's IP address—say, 192.168.42.23—and reverse the order of octets, yielding 23.42.168.192.
2. Append the DNSBL's domain name: 23.42.168.192.dnsbl.example.net.
3. Look up this name in the DNS as a domain name ("A" record). This will return either an address, indicating that the client is listed; or an "NXDOMAIN" ("No such domain") code, indicating that the client is not.
4. Optionally, if the client is listed, look up the name as a text record ("TXT" record). Most DNSBLs publish information about why a client is listed as TXT records.

Looking up an address in a DNSBL is thus similar to looking it up in reverse-DNS. The differences are that a DNSBL lookup uses the "A" rather than "PTR" record type, and uses a forward domain (such as dnsbl.example.net above) rather than the special reverse domain in-addr.arpa.

There is an informal protocol for the addresses returned by DNSBL queries which match. Most DNSBLs return an address in the 127.0.0.0/8 IP loopback network. The address 127.0.0.2 indicates a generic listing. Other addresses in this block may indicate something specific about the listing—that it indicates an open relay, proxy, spammer-owned host, etc. For details see RFC 5782.

URI DNSBL

A URI DNSBL query (and an RHSBL query) is fairly straightforward. The domain name to query is prepended to the DNS list host as follows:

example.net.dnslist.example.com

where dnslist.example.com is the DNS list host and example.net is the queried domain. Generally if an A record is returned the name is listed.

DNSBL policies

Different DNSBLs have different policies. DNSBL policies differ from one another on three fronts:

• Goals. What does the DNSBL seek to list? Is it a list of open-relay mail servers or open proxies—or of IP addresses known to send spam—or perhaps of IP addresses belonging to ISPs that harbor spammers?
• Nomination. How does the DNSBL discover addresses to list? Does it use nominations submitted by users? Spam-trap addresses or honeypots?
• Listing lifetime. How long does a listing last? Are they automatically expired, or only removed manually? What can the operator of a listed host do to have it delisted?

Uses of DNSBLs

DNSBLs can be used in rule based spam blocking software like Spamassassin where different black list are given point scores that can be mitigated by white rules to reduce false positives. They can also be used by MTAs like Exim, Sendmail and Postfix to outright block email if the senders IP address or host name is listed in a DNSBL.

One way to do this is to first check white lists and pass the email if the server is on a white list. A technique developed by Junk Email Filter^[7] uses Yellow Lists and NoBL lists to mitigate the false positives that often occur when using multiple black lists. Yellow lists are host names and IP addresses of servers that are known to be a source of mixed spam and non-spam. Examples would be yahoo, hotmail, and gmail. If the forward confirmed rDNS FCrDNS resolves to one of these hosts then the IP address contains no information as to if the message is or isn't spam. Thus other DNSBL tests should not occur because the IP carries no useful information.

Here's a list of different kinds of DNS Lists.

White List - IP is a trusted email source
Black List - 100% spam. Message should be rejected.
Yellow List - Message comes from a mixed source and IP should not be tested further
NoBL list - IP is not a spam source but may be a ham source

Messages should first be checked for yellow listing. If listed, then no further checking is needed. Then the message should be white list tested. If it is found listed in a white list, the message should be accepted as good. Then the NoBL lists should be tested. If listed then black list tests should be bypassed. Finally the black list testing should apply. The message is rejected if it is found in a black list. To be safe one might score the blacklists and reject if listed on multiple lists.

Criticisms

Email users who find their messages blocked from mail servers that use DNSBLs may object, sometimes to the extent of attacking the existence of the lists themselves. The following listing practices are controversial:

• Lists of dynamic or dial-up IP addresses. These lists most often also include "static" ADSL addresses, thus "end-user IP addresses" might have been a better description. Some mail sites choose not to accept messages from such addresses, since they are often home computers exploited by spammer viruses.
  This can seriously inconvenience SOHO users who wish to run their own mail servers on residential ISP connections or local MTAs on laptops for example. Forcing users to relay their outbound email through their ISP's mail server often yields unsatisfactory results. For example, many ISP-provided mail servers reject "foreign" "From" email addresses, i.e., those outside the ISP's domain, and this may prevent the perfectly legitimate use of personal and/or company domain names. Some ISP's outbound mail servers are chronically overloaded or unreliable (perhaps because they're swamped by spam from other users that has been forced through them). Without administrative access to the server, users have no way to determine if their mail has been successfully delivered, is still pending delivery, or has been lost and will never be delivered. Even when the ISP's outbound mail server is fast and reliable, the same problem arises when the destination mail server is overloaded or unreliable. Running one's own outbound mail server, to which one presumably has administrative access, is the only practical solution to these problems.

• Lists that include "spam-support operations", such as MAPS RBL.^[8] A spam-support operation is a site that may not directly send spam, but provides commercial services for spammers, such as hosting of Web sites that are advertised in spam. Refusal to accept mail from spam-support operations is intended as a boycott to encourage such sites to cease doing business with spammers, at the expense of inconveniencing non-spammers who use the same site as spammers.
• Predictive ("early warning") lists, notably SPEWS. SPEWS listed addresses belonging to spam-support operations, under the hypothesis that such addresses were more likely to send spam in the future. SPEWS "escalated" listings, increasing the size of the netblock listed, as a site continued to support spam.
• Some lists have unclear listing criteria and delisting may not happen automatically nor quickly. A few DNSBL operators will request payment (e.g. uceprotect.net)^[9] or donation (e.g. SORBS). Some of the many listing/delisting policies can be found in the Comparison of DNS blacklists article.
• Because lists have varying methods for adding IP addresses and/or URIs, it can be difficult for senders to configure their systems appropriately to avoid becoming listed on a DNSBL. For example, the UCEProtect DNSBL seems to list IP addresses merely once they have validated a recipient address or established a TCP connection, even if no spam message is ever delivered^[10] .

Although many^[who?] have voiced objections to specific DNSBLs, few people object to the principle that mail-receiving sites should be able to reject undesired mail systematically. One who does is John Gilmore, who deliberately operates an open mail relay. Gilmore accuses DNSBL operators of violating antitrust law.

For Joe Blow to refuse emails is legal (though it's bad policy, akin to "shooting the messenger"). But if Joe and ten million friends all gang up to make a blacklist, they are exercising illegal monopoly power.^[11]

A number of parties, such as the Electronic Frontier Foundation and Peacefire, have raised concerns about some use of DNSBLs by ISPs. One joint statement issued by a group including EFF and Peacefire addressed "stealth blocking", in which ISPs use DNSBLs or other spam-blocking techniques without informing their clients.^[12]

Spammers have pursued lawsuits against DNSBL operators on similar grounds:

• In 2003, a newly formed corporation calling itself "EmarketersAmerica" filed suit against a number of DNSBL operators in Florida court. Backed by spammer Eddy Marin, the company claimed to be a trade organization of "email marketers" and that DNSBL operators Spamhaus and SPEWS were engaged in restraint of trade. The suit was eventually dismissed for lack of standing.^[13]
• In 2006, a US court ordered Spamhaus to pay $11,715,000 in damages to the spammer "e360 Insight LLC". The order was a default judgment, as Spamhaus (which is a UK operation, outside the court's jurisdiction) did not defend itself. See e360 Lawsuit. This decision was later overturned by an appeals court.

See also

• Comparison of DNS blacklists
• DNSWL

References

1. ^ DNS & RHS blackhole lists
2. ^ McMillan, Robert (1997-12-xx). "What will stop spam?:". http://sunsite.uakom.sk/sunworldonline/swol-12-1997/swol-12-vixie.html. Retrieved 2008-05-16. 
3. ^ SURBL
4. ^ URIBL
5. ^ Rob McEwen
6. ^ ivmURI
7. ^ Junk Email Filter
8. ^ MAPS RBL
9. ^ UCEprotect.net
10. ^ Simpson, Ken. "Getting onto a blacklist without sending any spam". MailChannels Blog. MailChannels Corporation. http://mailchannels.com/blog/2010/11/getting-off-of-blacklists-uceprotect-in-particular/. Retrieved 16 September 2011. 
11. ^ TOAD.com
12. ^ Coalition statement against "stealth blocking"
13. ^ Linxnet.com

External links

• blacklists at the Open Directory Project
• Blacklists Compared - List of Compared Blacklists from 2001 to Current times
• Blacklist Monitor - Weekly statistics of success and failure rates for specific blacklists
• Blacklist comparison - Monthly and weekly statistics about hit rates and probable false entries in black- and whitelists
• How to Create a DNSBL - Tutorial on how to create a DNSBL (DNS Black List)