DNSBL V5 maintains an active registry of working proxies, inactive previously verified proxies and current Tor exit nodes. Legacy iplist, bulk import and discovery are candidate sources only; a candidate never becomes verified merely because it was imported or discovered.
Ordinary proxy processing and Tor synchronization are separated.
php artisan dnsbl:proxy-sweep --no-tor-sync
runs every five minutes and imports newly appended legacy candidates while processing ordinary proxy checks that are due. This does not mean every proxy is checked every five minutes. Working proxies normally use a daily interval and inactive proxies use a weekly interval.
Tor has a dedicated run:
php artisan dnsbl:tor-sync
The default cadence is every 30 minutes through DNSBL_PROXY_TOR_SYNC_MINUTES. Synchronization downloads the authoritative Tor Project export from:
https://check.torproject.org/exit-addresses
This keeps Tor substantially fresher than ordinary long-lived proxy checks without mixing the feed lifecycle into the scanner queue.
iplistiplist is a transition source rather than the new runtime model. The importer keeps an increasing ipid cursor. Catching up once is not terminal: newly appended rows with higher ipid values can still be imported by later sweeps while the legacy system remains active.
Rows with the legacy deleted field already set are skipped.
An active legacy candidate uses these defaults:
DNSBL_PROXY_LEGACY_FAILURES_BEFORE_PURGE=10
DNSBL_PROXY_LEGACY_FAILURE_RETRY_MINUTES=240
That gives ten attempts spaced four hours apart, or about 36 hours from the first to the tenth failure.
iplist row is then removed and the dnsbl_proxy_hosts row is promoted into the permanent runtime model.The same ownership transfer applies when a legacy row is identified as a current Tor exit: after successful Tor publication the Tor flow owns the record and the legacy row is removed.
An open TCP port is not enough. The checker connects through the candidate and fetches the nonce-based Tools probe endpoint:
/dnsbl/proxy-probe
The IP used to connect to the proxy is the connect IP. The remote IP observed by the nonce probe is the exit IP. They can be the same address or different addresses.
The connect IP stays in the local proxy registry because it is the address a client can use. Successful exit observations are retained separately with source, address family, protocol, port, response metadata and observation time.
After the nonce probe succeeds, the checker also performs additional Tornevall-controlled verification through:
https://ipv4.fraudbl.org/
https://ipv6.fraudbl.org/
These FraudBL checks are supplemental verification and can record separate IPv4 and IPv6 observations. They do not replace the nonce probe and cannot make a failed nonce probe count as a working proxy.
Known endpoints are tried first, followed by the configured common ports. Endpoint history includes status, latency, last check, latest observed remote address and last successful check.
Default ports:
80,443,1080,3128,8000,8080,8081,8118,8888,9050,9150
Override the list with DNSBL_PROXY_PORTS.
When the connect and exit addresses differ, the observed exit address is the DNSBL reputation address. The connect address remains scanner metadata and is not substituted for the address that was actually observed leaving the proxy.
If a later successful check observes a different exit, the new exit is published and the previous checker-managed proxy publication is removed. If cleanup synchronization fails, the local row is retained and cleanup stops before local state changes further.
If the connect address itself is also a current Tor exit, Tor publication remains attached to the connect IP while ordinary proxy reputation can be attached to the separate exit IP.
For a working proxy, the proxy-sync API requires the DNSBL reputation ip to match the verified exit_ip. A mismatched reputation address is rejected.
Ordinary proxies use these defaults:
DNSBL_PROXY_FAILURES_BEFORE_PURGE=10
DNSBL_PROXY_FAILURE_RETRY_MINUTES=10
DNSBL_PROXY_INACTIVE_RECHECK_DAYS=7
DNSBL_PROXY_FAILURES_BEFORE_PURGE controls how many consecutive failed checks are required before an ordinary proxy is delisted.
failed and queued for retry.deleted, lifecycle timestamps and a recovery check normally scheduled seven days later.deleted and another weekly check is scheduled without an unnecessary repeated delist.deleted_at is cleared and reactivated_at records the recovery.dnsbl_sync_error so the operation can be retried safely.Automatic hard deletion is limited to source lifecycles that require it: exhausted legacy candidates after successful final delisting, and Tor-only rows that disappear from a complete authoritative snapshot.
When a proxy verifies successfully, checker-managed TXT metadata includes both connect and exit addresses, the protocol, anonymity state and explicit ownership of the second-exit flag.
Example:
Proxy verification: connect=203.0.113.10:8080; exit=198.51.100.20; protocol=http; verified=yes; anonymous=yes; second_exit=yes; second_exit_owned=yes; proxy_bitmask=162; proxy_flags=IP_CONFIRMED,IP_SECOND_EXIT,IP_ANONYMOUS; schema=2; source=Tools proxy checker
second_exit=yes means connect and exit differ. second_exit_owned=yes means the proxy checker is also allowed to remove IP_SECOND_EXIT later when that mapping disappears.
If bit 32 already existed before the proxy mapping and the existing checker metadata does not prove ownership, the new TXT value records second_exit_owned=no. The bit is preserved and is not later removed by the proxy checker. Older schema-2 TXT records that only contain second_exit=yes are not treated as proof of ownership.
IPv6 connect addresses are wrapped in brackets so the endpoint port remains unambiguous. Checker-managed proxy TXT values remain separate from unrelated TXT metadata.
Tor is handled as an authoritative feed rather than an ordinary open-proxy candidate.
On a successful snapshot:
dnsbl_proxy_hosts as tor_exit and published to DNSBLtor_managed=1 and a refreshed tor_last_seen_atTor connectivity classification and DNSBL publication are separate status dimensions. A failed ADD/UPDATE/DELETE therefore does not turn a current Tor row into sync_error. It remains tor_exit or working, while the publication failure is stored in dnsbl_sync_error and retried by the next Tor synchronization.
If the Tor source is unavailable or invalid, no negative Tor cleanup is performed. An unavailable source cannot be interpreted as the Tor network disappearing.
Tor TXT example:
Tor exit: 203.0.113.20; current=yes; tor_bitmask=160; tor_flags=IP_SECOND_EXIT,IP_ANONYMOUS; schema=1; source=Tor Project
| Result | Mask |
|---|---|
| Working transparent proxy, same connect/exit IP | 2 |
| Working anonymous proxy, same connect/exit IP | 130 (2 + 128) |
| Working mapped anonymous proxy | 162 (2 + 32 + 128) |
| Current Tor exit | 160 (32 + 128) |
| Current Tor exit that also works as a proxy on the same IP | 162 (2 + 32 + 128) |
Deprecated bit 1 is removed when checker-managed state is rewritten. Other active reputation bits are preserved. Bit 32 is shared by Tor and second-entry/exit semantics, so the proxy checker only removes it when explicit managed state proves ownership.
Trusted proxy/Tor work inside Tools reuses the same scoped synchronization controller in-process. It does not loop back through HTTP and does not require a persisted DNSBL API token for the internal scheduled scanner.
The external server-to-server boundary remains:
POST /api/dnsbl/proxy-sync
Remote callers require an active persisted DNSBL API token with the add/delete permissions needed for the requested mutation. The ip field is the DNSBL reputation address. connect_ip and exit_ip preserve the scanner mapping used for TXT metadata and second-exit ownership.
Proxy synchronization manages checker-owned proxy/Tor state without deleting unrelated reputation flags or unrelated TXT records. Runtime synchronization failures are sent to the always-on Tools operational diagnostics path. A failed internal synchronization stops the current sweep instead of repeating the same global failure for every remaining candidate.
The public registry is available at:
/dnsbl/proxies
It has separate ordinary-proxy and Tor-exit views. Ordinary inactive/delisted proxies remain visible with lifecycle state and their next recovery check. The Tor view exposes DNSBL publication errors separately from Tor connectivity state.
Registry IP addresses link to the per-IP detail view:
/dnsbl/proxies/{ip}
The detail view combines local normalized state with known endpoints, recent deterministic checks, connect-to-exit observations, live DNSBL/TXT metadata, network information when available and stored discovery evidence.
The administrator view exposes the same lifecycle state. Manual Delist + delete remains an explicit operator action that bypasses the normal recoverable lifecycle; it is not the automatic default for ordinary proxies.
Administrators can add multiple candidates from the DNSBL proxy administration page. Accepted line formats are:
PUBLIC_IP
PUBLIC_IPV4:PORT
[PUBLIC_IPV6]:PORT
http://PUBLIC_IP:PORT
socks4://PUBLIC_IP:PORT
socks5h://PUBLIC_IP:PORT
Private, special-purpose/reserved, hostname-based and invalid candidates are rejected. A candidate with a supplied port is stored as an endpoint candidate and remains pending until the deterministic checker succeeds.
Repeated evidence is deduplicated. Import evidence records when the candidate was seen, how it entered the registry and the administrator actor when known.
Proxy discovery can use the existing source-aware OpenAI web-search path to find published public proxy candidates. Automatic discovery is disabled by default.
Discovery follows these rules:
Administrators can start one guarded discovery run manually. Scheduled discovery runs only occur when DNSBL_PROXY_DISCOVERY_ENABLED=true.
dnsbl_entries provides a generic foundation for future non-proxy reputation categories such as fraud and ecommerce.
The initial phase stores the subject value in plaintext with privacy_mode=plaintext. The schema already separates subject_hash, privacy mode, source, status, bitmask, risk score, metadata, expiry/cooldown and lifecycle timestamps so later GDPR-oriented protection can be introduced without mixing that design into the proxy-host table.
This migration only prepares storage. It does not enable new fraud/ecommerce ingestion or publication by itself.
Common proxy-checker settings include:
DNSBL_PROXY_STALE_AFTER_DAYS=7
DNSBL_PROXY_WORKING_RECHECK_HOURS=24
DNSBL_PROXY_FAILURE_RETRY_MINUTES=10
DNSBL_PROXY_FAILURES_BEFORE_PURGE=10
DNSBL_PROXY_LEGACY_FAILURE_RETRY_MINUTES=240
DNSBL_PROXY_LEGACY_FAILURES_BEFORE_PURGE=10
DNSBL_PROXY_INACTIVE_RECHECK_DAYS=7
DNSBL_PROXY_IMPORT_BATCH_SIZE=2000
DNSBL_PROXY_CHECK_BATCH_SIZE=20
DNSBL_PROXY_CONNECT_TIMEOUT_MS=800
DNSBL_PROXY_REQUEST_TIMEOUT_MS=3500
DNSBL_PROXY_PORTS=80,443,1080,3128,8000,8080,8081,8118,8888,9050,9150
DNSBL_PROXY_TOR_SYNC_ENABLED=true
DNSBL_PROXY_TOR_TIMEOUT_SECONDS=10
DNSBL_PROXY_TOR_CACHE_MINUTES=30
DNSBL_PROXY_TOR_RECHECK_MINUTES=5
DNSBL_PROXY_TOR_SYNC_MINUTES=30
DNSBL_PROXY_DISCOVERY_ENABLED=false
DNSBL_PROXY_DISCOVERY_MAX_CANDIDATES=50
DNSBL_PROXY_DISCOVERY_MAX_SYNC_ERRORS=0
The FraudBL verifier uses the fixed Tornevall-controlled IPv4 and IPv6 verification endpoints and does not use third-party public IP echo services.
The DNSBL V5 migrations are additive and forward-only. The runtime model includes:
deleted_at, last_delisted_at and reactivated_at for recoverable proxy lifecycle statednsbl_entries storage for future fraud/ecommerce categoriesMigration rollback methods remain intentionally non-destructive.