Endpoint: dnsbl - DNSBL v5 with API v3


We used to snapshot the that rendered the blacklist reason.

However, as of 25th may 2018, when the data protection law changed the history of personal integrity, we no longer store this kind of content. It might sound strange that we do not store spam that works like a proof for why e-mail has been blacklisted. It also normally helps system administrators (especially those who administers email services) to trace the source of spam. But to protect the receivers part data, the mail spam storage project has been abandoned.

Table of contents

DNSBLv5 is a part of the deprecated APIv2 interface. However, we missed two things in the interface:

  • Proper documentation
  • API Configuration abilities (meaning, API keys was a nightmare if you wanted to create them, since you was forced doing this manually)

Both problems are solved: The documentation is being written as the DNSBL are developed and the API Configuration can be done by using TorneAUTHv4.
DNSBLv5 at the level of APIv3 is a bit different to the old API. Instead of doing weird requests, the APIv3 is properly utilizing the use of HTTP methods.

Take a look below at the big differences.


In the DNSBLv3-API a new set of permissions are assigned to the DNSBL. Normally, no permissions are required (to list blacklisted hosts).

Requesting permissions?

The special permissions need to be requested manually via support@tornevall.net
Permission flagDescription
allow_cidrThe usage of CIDR-blocks are normally not permitted by the DNSBL API, in more functions than listing them. This permission also opens up for usage in DELETE/UPDATE cases (in our local e-mail requests where support sometimes cover CIDR-block removals, this would help a lot). However, adding data with CIDR and different flags might be a problem (this permission does not exist in the API yet)

Setting that partially allows CIDR-block updates for the DNSBL (there migt me limitations linked to this permission - see the documentation for this information)

Current limitations: Not larger than a /24. This permission is also, currently, limited for internal use.

can_purgeSpecial ability to purge hosts instead of marking them deleted in the database
dnsbl_updateStandard DNSBL ability to update data in the DNSBL (dnsbl.tornevall.org and bl.fraudbl.org)
fraudbl_updateExtended ability to handle fraudbl-commerce (this is not the regular bl.fraudbl.org resolver)


Global delisting permission (can use as delisting service for visitors)
local_delistLocal delisting permission (server can delist self)

When sending new or updated data to DNSBL, clients can only add more flags to the host. This feature makes it possible to overwrite old flags

Not yet implemented

DNSBL Version

The DNSBL system itself is still running on 5.0, it is only the API that communicates with the system that is actually changed.


In DNSBLv5APIv2 a request of checking a listed ip looks like this:

MethodURL/dataThe parameterExpected response
HTTP POSThttps://api.tornevall.net/2.0/dnsbl/ip/

HTTP POST variables?bulk[]=ipaddr1&bulk[]=ipaddr2bulk[]=ipAddr

Arrayed (or not arrayed by only using bulk=ipAddr) request should return information about the current blacklisted ip (if it is blacklisted). To return fingerprints about the ip address, you could add ipAddr|e, where e stands for extended information.

To add or delete a host in the blacklist, with specific permissions additional parameters was used: |a|<bitValue> for adding the address with a bit value (described here), or |d for deletion. Additional parameters (with permissions) could be used to purge (p) content.

FIngerprints are used to make API requesters get more information about the


In DNSBLv5APIv3 a request is simplified like this:

MethodURLInformationData (POST parameters)Expected response




HTTP POST has the same role as HTTP GET but with post parameters. Supports IPv6.

URL-encoded or JSON-formatted:

// simple json
// simple http post
// multiple json
{"ip":["", ""]}
// multiple http post

This example is the same for the rest of examples in this table.

Is ip listed?
HTTP PUThttps://api.tornevall.net/3.0/dnsbl/Insert or update ip address
ipArray with ip address and bitmasked flag-per-ip

The bitmask flags mentions here


Do blacklist
	"ip": {
		"": 64
	"type": "dnsbl"

Response Look:

Response parameters (status) described

successThe insertion ID
addressThe address that was update or inserted
stateDefines if the request already has the address blacklisted or if it was updated. Answers can be new or update.
arpaDelegationsA list of DNS-records that was registered or updated
flagThe flag of the blacklisted address

Do blacklist
	"dnsblResponse": {
		"status": [{
			"success": "1934699",
			"address": "",
			"state": "new",
			"arpaDelegations": [
			"flag": "64"

HTTP DELETEhttps://api.tornevall.net/3.0/dnsbl/Delist (delete/remove) ip address


Do blacklist

Registration types

The default "type" used in some of the examples above is using the standard registration behaviour. It is simply just "dnsbl". As fraudbl.org is using the same flagset (see DNSBLv5: About and usage), normally we don't need to know anything else than this. Adding a host with the flagid 4 (phishing) will also automatically update the fraudbl tables with proper data.

In the new plugin for Wordpress, however, there's a new supported method that includes ecommerce. The refresh rate for this method are much higher than the normal hosts registry (and normally, you want to use the API for this as DNS requests might be a bit delayed). The ecommerce method is specifically used for fraud controls in ecommerce sites (with for example ecommerce plugins that supports fraud controls). As this method should be used with caution, since this directly might affect ecommerce sites, the hosts also have a shorter time to live and should - by a supported plugin - also handle ecommerce unfreezing (which means, if your site is flagging a host as fraudulent, it should also deflag hosts when they are confirmed non fraudulent).

We should also consider how to block website visitors as orders flagged as fraud, might also deny access to websites instead of order confirmations. However, the real purpose of this functionality is to block visitors to shop if they are really used for frauding (for example, fraud-customers that visits many shops at the same time to buy things before discovered). In this case, the checkout shoule be rejected.

The typeset for such scenarios is "ecommerce" and will be flagged differently to the regular lookups. Here's an example: