TechTheft

Building a DNSBL

Besides the intricacies of list policies and DNS, etc. There are some recognised procedures that all well-trusted RBL use tp give the general public a method of testing before they use the list in any application. These procedures also provide an excellent and safe way for members of the public to learn that an RBL has died for any reason. Be it the formal closure by its maintainer or an accidental outage.

These procedures have been formalised in a draft proposal for all DNSBL, RHSBL, and RBL Maintainers and Client Developers in 2006. the full text of the proposal is below.

The proposal allows a useful standard set of methods for testing any compliant RBL list for party involved with a list to know immediately if it has been closed or in undergoing any problems.

*Operation*

While publishing both A and TXT records is often done, a number of DNSBLs chose not to do so. What records are published and how data should be represented is a policy discussion left to the DNSBL and its users.

The first policy consideration for DNSBL operation is how long a listing should be cached on a remote system before the remote is required to recheck its value. For this DNSBL operators should consider an appropriate time to live (TTL). Additionally it should be noted that while a client may hold onto a cached value until its TTL is reached, there is no requirement for them to hold it until that time, only that they can not cache this value for any longer than the TTL. (please see RFC-1035)

Negative caching, how long a non-listing may be cached in DNS, is also controlled via TTL values. DNSBL operators may publish TTLs to be used to cache negative responses in the SOA's minimum field (please see RFC-2308 for further discussion)

DNS A record responses historically have been within 127/8 and more specify 127.0.0.2 or some value greater than or equal to 2 using the 24 least significant bits (the last three octets).

DNSBL operators may publish policy information via bit flagging, scoring within single DNS responses or multiple A record responses. This may allow more sophisticated clients to reduce overall queries of multiple lists or otherwise allow for more sophisticated scoring mechanisms. However, it should be noted that if operators chose to do so, that they avoid publishing a response of 127.0.0.0 or 127.0.0.1. Also, should DNSBL operators publish policy flag data in their responses, they need to consider that not all implementations will know how to interpret these responses and ones that do not will consider any listing to be a positive one.

*Implementation*

Implementations of DNSBL clients should quantify the responses they receive to ensure the following;

1. DNS A record responses are within 127/8.
2. DNS A record responses are not within 127.0.0.0/31.
3. DNS responses have RCODE set to 0 (No Error) or 3 (Name Error).

Should a client implementation discover any of these conditions as false it should consider it an error and appropriately log the event. How the client recovers from these errors is up to the implementation and its configuration.

While unusual, client implementations should ensure that responses where RCODE has been set to 0, and no answer is given, are treated as a negative listing.

Client implementations should allow as its configuration, bit flagging, scoring, and multiple A record responses to reduce overall load on the DNS system by the querying of aggregate lists, even if the configuration choses to use only a subset of that aggregate. How a DNSBL choses to publish its data is a policy discussion left to the DNSBL and its users.

Implementations should also allow, via configuration, the queried namespace to be used as its own output responses should its users not wish to use the DSNBLs own TXT records. Examples of the need for this is where the DNSBL doesn't publish TXT records or the site using the DNSBL wishes to provide users with its own explanation or white listing procedures.

Users of DNSBLs should check with their operators often to ensure they receive important information regarding its use. Historically a large number of DNSBL operators have used web pages to convey such important information as DNSBL closing down of operations, publishing of new or aggregate lists, or other operational information.

Additionally, it has been noted that periodic checking of the DNSBL's test address may be useful.

Such checks may include checking both the DNSBL's test listing (normally 127.0.0.2) and loopback (127.0.0.1) to ensure both positive and negative operation.

A positive response to 2.0.0.127.list.example.com could be construed that the list is operational.

A listing of 1.0.0.127.list.example.com should be construed that the DNSBL is listing all of IPv4 space and its use should be stopped.

Also, should a client start receiving responses in 127.0.0.0/31, outside of 127/8, or RCODE has been set to anything other than 0 or 3, it should be noted and the users of the DNSBL should investigate why.