DNSBL API Compatibility and Reliability Fixes

We have completed a set of server-side fixes for the Tornevall Networks DNSBL integration after identifying authentication and reliability problems affecting existing clients, including the currently released WordPress integration.

Existing WordPress installations remain supported

One of the most important requirements was that existing installations must continue working without forcing users to upgrade their plugin just because the server-side authentication model has evolved.

ToolsAPI therefore continues to recognize the authentication method used by released DNSBL clients. Existing DNSBL API keys remain valid through the legacy-compatible authentication path, while the newer DNSBL token model continues to work alongside it.

No API key rotation or WordPress plugin update should be required solely because of these changes.

Internal retries no longer lose authentication

We also found a separate problem in the DNSBL reliability system.

Failed DNSBL mutations can be buffered and retried internally. Those retries were executed inside an authorized server process, but the replayed request itself did not contain authentication in a form understood by the API controller.

The result could be misleading errors such as:

401 unauthenticated

even though the original operation had been properly authenticated.

The retry mechanism now carries a strictly internal, runtime-only authorization marker. It is accepted only while the trusted retry process is executing and cannot be reused as an external API credential.

Better handling of temporary DNS socket failures

Another source of failures was transient UDP socket conditions during direct DNS updates, particularly:

Resource temporarily unavailable

These conditions can occur while waiting for a DNS server response and do not necessarily mean that the DNS update itself is invalid.

The DNS update layer now recognizes transient conditions such as EAGAIN, EWOULDBLOCK and interrupted socket reads and performs bounded retries before treating the operation as failed.

Real DNS errors, authentication failures and TSIG errors are still reported normally.

Additional reliability improvements

The same operational review also uncovered a few related problems in ToolsAPI.

Transit Planner image uploads were too aggressively rate-limited for the intended multi-screenshot workflow. The upload limits have been adjusted while keeping abuse protection in place.

Deploy health reporting was also made page-wide instead of depending on a specific Statuspage component name, making recovery reporting more robust if components are renamed or reorganized.

What this means for users

For users of Tornevall Networks DNSBL integrations:

  • Existing released WordPress clients remain supported.
  • Existing DNSBL API keys continue to work.
  • Internal retry operations no longer fail simply because authentication context was lost.
  • Temporary DNS socket conditions receive bounded retries instead of immediately generating a server error.
  • Missing or genuinely invalid credentials still fail normally.
  • No new versioned API endpoint has been introduced.

The fixes were implemented in ToolsAPI and merged on September 27, 2026.

If you recently encountered unexpected 401 responses while adding or removing DNSBL records, or intermittent DNS update failures, the problem may have been related to the server-side issues addressed by this update.

Posted in No category.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.