No!
We have evolved!
FraudBL.org may look unusually quiet if you only visit the public website. Most of the development and daily operation have moved to Tornevall Networks Tools, where FraudBL is now part of a larger DNSBL and abuse-protection platform.
The original FraudBL website remains as a landing page and historical reference. The actual machinery is now running through ToolsAPI at tools.tornevall.net.
From a standalone service to a DNS-first platform
The older FraudBL and DNSBL systems relied heavily on a traditional database API. That model has gradually been replaced by a DNS-first architecture.
Reputation data is now distributed through DNS zones and consumed through ordinary DNS lookups. ToolsAPI manages the underlying records, publication flows, permissions, cache handling and administrative operations.
The primary zones are:
dnsbl.tornevall.orgbl.fraudbl.orgecom.fraudbl.org
The regular DNSBL handles spam, abuse and other unwanted network activity. FraudBL provides classifications related to phishing, fraud infrastructure and other activity that may cause financial harm. The separate commerce zone is used for classifications connected to e-commerce fraud.
A new API model
The historical DNSBL v5 and API v3 interfaces are now deprecated. They are still documented for migration and compatibility work, although they are no longer the primary integration model.
The current DNSBL API is exposed through ToolsAPI and provides endpoints for:
- Checking whether an IP address is listed.
- Validating DNSBL access tokens.
- Adding, updating and removing records.
- Submitting bulk operations.
- Inspecting DNSBL statistics.
- Receiving specialized reports, including DMARC-based review material.
The API also supports dry-run operations. Integrators can validate permissions, payloads, publication rules and deletion limits without making actual DNS changes.
Safer listing and removal workflows
Clients no longer need to determine every DNS zone or reversed DNS record involved in a removal.
When a removal request is submitted, ToolsAPI performs a live DNS inspection and determines which records currently exist in the relevant zones. It then builds the required DNS operations from the actual published state.
This reduces the risk of incomplete removals, incorrect zone selections and outdated assumptions in external clients.
Delegated tokens can also be restricted through removal guardrails. These controls include CIDR limits, daily limits, request throttling and maximum operation sizes.
FraudBL is still DNS-compatible
Consumers do not need to use the HTTP API for ordinary blacklist checks.
Services can continue querying FraudBL through DNS and decoding the returned 127.0.0.X address as a bitmask. Multiple classifications can be active simultaneously, allowing one address to be marked for several forms of abuse.
The WordPress DNSBL plugin follows this model. It performs direct DNS lookups, keeps a local cache and stores local activity statistics. ToolsAPI is used when additional functionality is needed, such as token validation, administration or removal requests.
Better privacy handling
The rebuilt platform also changes how contextual information is handled.
Older blacklist systems could store more information about why an address or message was flagged. The current design focuses on data minimization. Information must be anonymized and reduced before it reaches the published DNS layer.
Only information required for classification, abuse prevention and fraud protection should be exposed through DNS.
Public statistics and documentation
Tools now includes public DNSBL statistics showing API activity and selected public whitelist information. The documentation describes the current bitmask model, DNS publication rules, token handling, removal limits and integration workflows.
FraudBL.org remains the recognizable home of the FraudBL name. Development, automation and operational control now live inside a broader platform built to handle DNSBL, FraudBL and related reputation services together.
