← Back to docs

DNSBL / FraudBL API-referens

Language: SV | EN | SV

Endpoint: dnsbl - nuvarande ToolsAPI-modell för DNSBL / FraudBL

Status

Den här sidan dokumenterar den nuvarande ToolsAPI-modellentools.tornevall.* tillsammans med hur WordPress-pluginet arbetar idag.

Det historiska gränssnittet DNSBL v5 / API v3 är deprecated, avvecklat och inte längre den aktiva integrationsmodellen. En legacy-referens ligger längst ned för kompatibilitet och migrering.

GDPR-notis

Äldre blacklistflöden kunde spara mer kontext kring varför en värd eller ett meddelande flaggades. Det är inte längre målet.

I dagens ToolsAPI-riktning måste GDPR och dataminimering beaktas innan data publiceras till DNS. Eftersom reputationslagret nu i praktiken distribueras via DNS-zoner och zonfiler måste anonymisering och minimering ske i själva publiceringsflödet. Endast data som behövs för klassificering, abuse-skydd och fraudskydd ska exponeras.


Innehåll


Nuvarande läge

När vi i detta dokument säger vårt API menar vi ToolsAPItools.tornevall.*.

Den aktiva modellen idag är:

  • reputationsdata konsumeras i slutänden via DNS-uppslag
  • ToolsAPI exponerar DNS zone API och DNS record API för att läsa och underhålla DNS-baserad data
  • WordPress-pluginet gör direkta DNS-uppslag och håller egen cache/statistik
  • gamla 3.0/dnsbl-semantiker är inte längre det primära publika kontraktet

Viktig konsekvens

Det finns ingen ny publik en-till-en-ersättare för gamla PUT /3.0/dnsbl / DELETE /3.0/dnsbl som aktivt kontrakt.

Istället bygger dagens stack på:

  1. DNS-publicering och zonhantering i ToolsAPI
  2. direkt DNS-resolution hos konsumenter som WordPress-pluginet
  3. internt DNSBL/DNS-lager för specialiserade blacklistflöden, inklusive commerce-publicering

Snabbstart

Om du integrerar mot nuvarande DNSBL/FraudBL-stack är normal ordning:

  1. validera tokenet med GET /api/dnsbl/token/info
  2. kontrollera live-läget med POST /api/dnsbl/check-ip
  3. lägg till, uppdatera, delista eller bulk-skicka via /api/dnsbl/records/*
  4. använd hjälpendpointsen bara när du behöver deras dedikerade runtimeflöden:
    • GET /api/dnsbl/stats
    • GET /api/dnsbl/engine-settings
    • POST /api/dnsbl/forum/bounce
    • POST /api/dnsbl/dmarc/report

DNSBL-statistik och räknare

Tools exponerar nu GET /api/dnsbl/stats för API-läsbara DNSBL-räknare.

  • Auth följer samma modell som övriga DNSBL-hjälpendpoints: aktiva DNSBL-token via X-Dnsbl-Token / dnsbl_token, aktiva DNSBL-provider keys och admin-/sessionkontexter som redan resolve:ar för /api/dnsbl/*.
  • stats.api_queries sammanfattar registrerad /api/dnsbl/*-trafik från den lokala api_endpoint_visits-trackern.
  • stats.mutations sammanfattar databasbackade logiska DNSBL-utfall för add/delete/update, inklusive lyckade writes, dry-runs, failures och delete-no-op som already_not_listed.
  • Viktig scope-notis: äldre operatorloggar, Slack-audits och mail-auditspår fanns redan tidigare, men de var inte en stabil API-läsbar räknarkälla för DNSBL add/delete-POST-anrop. Den nya stats-endpointen är därför den kanoniska räknarytan framåt.

Exempel:

curl -s "https://tools.tornevall.net/api/dnsbl/stats" \
  -H "X-Dnsbl-Token: YOUR_TOKEN"

Publik DNSBL-statistik och whitelist-synlighet

Tools har nu också en publik webbsida på:

/dnsbl/statistics

Den sidan kombinerar:

  • samma DNSBL-räknare som ligger bakom GET /api/dnsbl/stats, och
  • de aktiva whitelist-raderna som läses från DNSBL_V5.ipwhitelist.

Viktiga whitelist-notiser:

  • whitelistan är inte bara en passiv testlista,
  • den används också under spamhantering / blacklistflöden så undantagna IP-adresser kan rensas bort i stället för att bli kvar i DNSBL-zonerna,
  • description visas nu publikt när den inte är tom,
  • is_local_network markerar rader som representerar lokalnätsundantag som normalt inte ska ligga kvar i blacklist-publiceringen och därför också ska kunna rensas bort från DNSBL-zonerna när de ändå dyker upp där.

Adminnotis:

  • /admin/dnsbl/engine-settings visar nu samma whitelist-/lokalnätsöversikt,
  • och sidan har nu också en dedikerad åtgärd Purge local networks now som tar bort listade blacklist owners vars dekodade IP matchar de aktiva lokalnätsraderna av typen IP/CIDR i ipwhitelist.

DNSBL-authtransport

För DNSBL-endpointsen är den delegerade authmodellen fortfarande ett DNSBL-token som skickas som:

  • X-Dnsbl-Token: <token>
  • dnsbl_token=<token>

Beroende på endpoint kan även aktiva DNSBL-provider keys och aktiva adminägda Tools-token resolve:a via samma transport.

Minimala curl-exempel

Kontrollera tokenstatus:

curl -s "https://tools.tornevall.net/api/dnsbl/token/info?dnsbl_token=YOUR_TOKEN"

Kontrollera en IP:

curl -s "https://tools.tornevall.net/api/dnsbl/check-ip" \
  -H "Content-Type: application/json" \
  -H "X-Dnsbl-Token: YOUR_TOKEN" \
  -d '{"ip":"203.0.113.4"}'

Delista en IP (serversidan avgör själv scope/zoner):

curl -s "https://tools.tornevall.net/api/dnsbl/records/delete" \
  -H "Content-Type: application/json" \
  -H "X-Dnsbl-Token: YOUR_TOKEN" \
  -d '{"ip":"203.0.113.4"}'

Bitmaskmodellen som används av ToolsAPI och pluginet

Det returnerade reputationsvärdet är ett bitmaskheltal.

Varje bit representerar ett specifikt tillstånd. Flera bitar kan vara aktiva samtidigt.

Bitmaskvärden

Värde Konstant Betydelse Status
1 FREE_SLOT_1_PREVIOUSLY_REPORTED Tidigare använd för äldre reported-IP-flöden. Betraktas som opålitlig. Deprecated
2 IP_CONFIRMED IP-adress verifierad som fungerande proxy. Aktiv
4 IP_PHISHING Värd verifierad som phishing- eller fraudinfrastruktur. Aktiv
8 IP_FRAUDCOMMERCE Reserverad för e-handelsrelaterad fraudklassificering. Får inte återanvändas för annat. Aktiv
16 IP_MAILSERVER_SPAM E-postspammare. Aktiv
32 IP_SECOND_EXIT Sekundär exitpunkt, till exempel TOR-exit eller alternativ abuse-IP. Aktiv
64 IP_ABUSE_NO_SMTP Allmän abuse via webbformulär, attacker, telnet, forum eller liknande kanaler. Aktiv
128 IP_ANONYMOUS Anonym proxy eller anonymiseringstjänst. Aktiv

Hur bitmasken fungerar

Svaret ska tolkas som en summa av aktiva bitar, aldrig som en enum med exakt en status.

Exempel:

4 + 16 + 64 = 84

Det betyder att värden samtidigt är klassad som:

  • phishing / fraudinfrastruktur
  • mailspamkälla
  • generell abuse

Implementationsregler

  • Flera bitar kan vara satta samtidigt.
  • Deprecated bitar ska ignoreras i ny logik.
  • Bitvärde 8 ska använda IP_FRAUDCOMMERCE.
  • Bitvärde 8 får inte återanvändas för något annat.
  • Konsumenter ska kontrollera varje bit individuellt.

Kompatibilitetsnotis

Historisk API v3-kod använde namnet FREE_SLOT_8_PREVIOUSLY_PROXYTIMEOUT för bit 8. Det namnet hör bara till legacy-modellen och ska betraktas som obsolet.


DNS-zoner och publiceringsmodell

Nuvarande DNSBL / FraudBL-stack är DNS-först.

Huvudzoner

  • dnsbl.tornevall.org
  • bl.fraudbl.org
  • ecom.fraudbl.org

Normalt beteende

  • Vanlig DNSBL-publicering använder fortsatt ordinarie DNS-modell.
  • Fraud-publicering speglas nu i den ordinarie DNSBL-registret och i bl.fraudbl.org.
  • I praktiken betyder det att en fraud-add nu kan skapa poster i:
    • dnsbl.tornevall.org
    • opm.tornevall.org
    • bl.fraudbl.org
  • Commerce-relaterad fraud ska kunna publiceras i både:
    • ordinarie bl.fraudbl.org
    • dedikerade ecom.fraudbl.org

Commerce-publicering

När en commerce-blacklisting publiceras ska den inte bara skapa en vanlig FraudBL-post. Den ska även skapa en särskild commerce-post.

Exempel:

X.X.X.X.ecom.fraudbl.org

Den exakta DNS-namnskonstruktionen ska hanteras av DNSBL/DNS-lagret, inte rekonstrueras manuellt av klienter.

Fraud-/icke-commerce-adds fungerar nu annorlunda än commerce-adds:

  • fraud-publicering (publication_type=fraud / fraudbl, eller en bitmask som innehåller IP_PHISHING) speglas nu till dnsbl.tornevall.org, opm.tornevall.org och bl.fraudbl.org
  • commerce-publicering ligger fortfarande bara i bl.fraudbl.org + ecom.fraudbl.org och speglas inte till de vanliga DNSBL-zonerna
  • add/update-svar kan nu också innehålla additiv metadata publication.publication_types[] så klienter kan se vilka publiceringsfamiljer som faktiskt expanderades för skrivningen

GDPR och anonymisering i DNS

Eftersom systemet publicerar via DNS-zonfiler kan modellen inte behandlas som ett databas-API där data alltid kan anonymiseras i efterhand.

Det innebär att:

  • dataminimering måste ske före publicering
  • endast nödvändig klassificeringsdata ska exponeras
  • commerce-publicering ska designas med anonymisering i åtanke
  • om encoding eller hashing införs ska DNSBL-lagret äga den logiken så den blir konsekvent

Aktiva ToolsAPI-endpoints

Aktiva läs-/skrivytor i kodbasen exponeras nu under både:

/api/dns
/api/dnsbl

DNS-endpoints är fortsatt den låg-nivåbaserade DNS-skrivytan.

DNSBL-endpoints är bekvämlighetsalias för reputationspublicering där klienten skickar IP-adress + bitmask och låter DNSBL-lagret avgöra encoding, zonval och commerce-mirroring.

För delete / delist är controllern nu auktoritativ på serversidan:

  • klienten skickar IP-adressen,
  • Tools gör själv den live DNS-inspektion som behövs,
  • endpointen räknar själv fram vilka konkreta owner-namn som faktiskt är listade i dnsbl.tornevall.org, opm.tornevall.org, bl.fraudbl.org och/eller ecom.fraudbl.org,
  • och först därefter byggs de faktiska DNS-DELETE-operationerna.

Klienter behöver därför inte längre avgöra vilken blacklist-subzon som ska raderas för en viss IP. Fält som publication_type och bitmask i ett delete-anrop betraktas nu högst som ledtrådar; den verkliga delist-scope:n kommer från serversidans live-DNS-uppslag.

No-op-notis för delete:

  • när en delete-begäran gäller en IP som redan inte är listad i någon live DNSBL-/FraudBL-zon behandlar Tools detta nu som en accepterad idempotent no-op i stället för ett hårt invalid_dnsbl_publication-fel,
  • success-payloaden för det fallet innehåller nu additivt reason="already_not_listed", already_not_listed=true, forced_success=true och operation_count=0,
  • avsedd klienthantering är att tolka detta som redan rensat / redan delistat läge, inte som ett publiceringsfel som ska retryskickas.

Hygiennotis för privata nät:

  • RFC1918-områden får aldrig förekomma i live-zonerna för DNSBL / FraudBL.
  • Add/update-publiceringar för 10.0.0.0/8, 172.16.0.0/12 och 192.168.0.0/16 stoppas nu innan några DNS-skrivningar hinner skickas.
  • DNSBL add/update-anrop som träffar detta skydd returnerar nu 422 med reason="private_ipv4_not_allowed_in_dnsbl".
  • Tools admin har nu också en hygien-purger på /admin/dnsbl/engine-settings så operatören kan rensa bort äldre privata reverse-owner-rader som kan ha hunnit läcka in i dnsbl.tornevall.org, opm.tornevall.org, bl.fraudbl.org eller ecom.fraudbl.org innan detta skydd fanns.

Hygiennotis för whitelistade lokalnät:

  • vissa blacklist-undantag styrs av aktiva rader i DNSBL_V5.ipwhitelist, inte bara av de tre hårdkodade RFC1918-intervallen,
  • rader markerade med is_local_network=1 behandlas som tabellstyrda lokalnätsundantag,
  • Tools visar nu dessa rader publikt på /dnsbl/statistics,
  • och admin-hygienesidan kan nu rensa listade blacklist owners vars dekodade IP hamnar inom dessa aktiva lokalnätsrader av typen IP/CIDR.

Operativ notis för DNS-transporten:

  • owner-namnen ligger fortfarande kvar som de konkret listade värdnamnen, till exempel 1.2.3.4.bl.fraudbl.org eller 1.2.3.4.opm.tornevall.org,
  • men när dessa blacklist-subzoner uppdateras via dynamisk DNS skickar Tools nu själva DNS UPDATE-anropet mot den verkligt auktoritativa parent-zonen (fraudbl.org / tornevall.org) i stället för att felaktigt använda barnzonen som update-zone-sektion.

Praktisk klientvägledning:

  • när du delistar en IP ska du skicka en delete-begäran för den IP-adressen och låta Tools själv expandera vilka owners/zoner som faktiskt är listade,
  • expandera alltså normalt inte check-ip / delete_candidates till flera efterföljande delete-anrop för samma IP om du inte medvetet delistar flera olika IP-adresser,
  • bulk delete är i första hand till för flera IP-adresser, inte för flera kandidatfamiljer som redan tillhör samma inskickade IP.

Bulk-körningsnotis

Stora DNSBL-bulk-writes kan hålla en och samma HTTP-request upptagen en stund eftersom varje skickad IP fortfarande kan expandera till flera DNS-uppdateringar på serversidan.

Nuvarande implementation förlänger därför runtime-budgeten för sådana DNSBL-bulkrequester och försöker också igen när en retrybar UDP-läsning avbryts (till exempel socket_recvfrom(): Interrupted system call) innan write-körningen slutligen markeras som misslyckad.

Autentisering

Nuvarande endpoints stöder:

  • autentiserad webbsession
  • Authorization: Bearer <token>
  • X-API-Key: <token>
  • ?api_key=<token>
  • IP-whitelist när det är aktiverat server-side

För /api/dnsbl/*-skrivningar är ett dedikerat DNSBL-token fortfarande den normala delegerade modellen. Därutöver får en aktiv Tools API-nyckel/token som ägs av en admin nu automatisk effektiv DNSBL-access via samma X-Dnsbl-Token / dnsbl_token-transport.

När en väntande DNSBL-tokenansökan godkänns från /admin/dnsbl/tokens skickar Tools nu också ett bekräftelsemail till den som ansökte, med information om att tokenen är klar, vilka scopes som beviljats och vilka aktuella delete-guardrails/defaultgränser som gäller för kontot.

DMARC-intagning och granskningskö

Tools exponerar nu också en DMARC-intagning för dnsbl-engine / sajtägarflöden:

  • POST /api/dnsbl/dmarc/report

Syfte:

  • ta emot DMARC-XML / gzip / ZIP / MIME-wrappade DMARC-payloads,
  • inklusive vidarebefordrade/wrappade message/rfc822-mail där själva DMARC-XML/ZIP kommer som nästlad attachment,
  • normalisera dem till lagrad rapportmetadata plus separata rader per käll-IP,
  • låta den slutliga publiceringsbedömningen ligga kvar hos sajtägaren i stället för att auto-blacklista direkt från rapporten.

Autentiseringsregler:

  • DMARC-intagningen kräver nu en aktiv DNSBL-token med add/write-rätt via X-Dnsbl-Token eller dnsbl_token,
  • tokenet måste resolve:a till en aktiv DNSBL-token vars effektiva can_add är true,
  • aktiva DNSBL-provider keys (provider=tornevall_dnsbl) accepteras också via samma token-transport,
  • aktiva adminägda Tools API-nycklar accepteras också via samma token-transport som admin-passthrough,
  • saknade, ogiltiga eller inaktiva DNSBL-token får nu 401,
  • aktiva DNSBL-token utan add-rätt får nu 403 med reason="insufficient_dnsbl_scope",
  • vanliga icke-DNSBL-Tools API-nycklar, adminsessionsfallback och anonyma/interna DMARC-uppladdningar accepteras inte längre på denna endpoint.

Exempel på request body:

{
  "payload_base64": "H4sIAAAAA...",
  "source_type": "dnsbl_engine_dmarc",
  "source_name": "dnsbl-engine",
  "original_filename": "mailru-report.xml.gz",
  "content_type": "application/gzip",
  "content_encoding": "gzip"
}

Typiskt success-svar:

{
  "ok": true,
  "duplicate": false,
  "message": "DMARC payload ingested for admin review.",
  "report": {
    "id": 12,
    "report_id": "33491921110551199191685577600",
    "org_name": "Mail.Ru",
    "policy_domain": "tornevall.net",
    "status": "pending",
    "record_count": 1,
    "source_ip_count": 1,
    "date_begin": "2023-06-01T00:00:00+00:00",
    "date_end": "2023-06-02T00:00:00+00:00"
  },
  "records": [
    {
      "id": 99,
      "source_ip": "60.13.8.218",
      "message_count": 1,
      "disposition": "reject",
      "dkim_result": "fail",
      "spf_result": "fail",
      "recommended_action": "spam_fraud",
      "status": "pending"
    }
  ]
}

Operativ/adminmässig hantering:

  • inskickade rapporter granskas i /admin/dnsbl/dmarc,
  • sajtägaren kan publicera en rapporterad käll-IP som antingen spam (16) eller spam + fraud (84),
  • rader kan också markeras som ignorerade utan publicering,
  • kön är medvetet inte en normal slutanvändarfunktion.

Runtime-inställningar för dnsbl-engine

Tools exponerar nu också de normaliserade runtime-inställningarna som dnsbl-engine använder:

  • GET /api/dnsbl/engine-settings

Syfte:

  • låta hjälparklienter bekräfta aktuell serverside-konfiguration utan att skrapa admin-HTML,
  • exponera operatörskonfigurerade flaggor som forum-bounce-hantering och undantagna forumgrupper,
  • hålla fristående runners synkade med aktuell Tools-admin-konfiguration.

Autentiseringsregler:

  • samma DNSBL-authtransport som övriga /api/dnsbl/*-endpoints,
  • aktiva DNSBL-token, aktiva DNSBL-provider keys, admin-passthrough och befintlig admin/session-kompatibel DNSBL-auth fungerar via den normala DNSBL-resolvern.

Typiskt success-svar:

{
  "ok": true,
  "message": "DNSBL engine settings loaded.",
  "settings": {
    "skip_delivery_status_notifications": true,
    "forum_bounce_enabled": true,
    "forum_bounce_group_id": 156,
    "forum_bounce_exempt_group_ids": [6, 7, 37]
  },
  "auth": {
    "auth_mode": "dnsbl_token",
    "scope_label": "add"
  }
}

FORUM-intagning för studsade mottagaradresser

Tools exponerar nu också en dedikerad intagning för forumrelaterad bounce-/mailer-daemon-analys från dnsbl-engine:

  • POST /api/dnsbl/forum/bounce

Syfte:

  • ta emot avvisade forum-mottagaradresser som extraherats ur bounce-/DSN-mail,
  • matcha dessa avvisade adresser mot vBulletin-användare,
  • lägga till en konfigurerbar grupp för studsad e-post (default 156) som sekundär forumgrupp,
  • lämna undantagna grupper (till exempel admin-/operatörsgrupper) helt orörda.

Autentiseringsregler:

  • aktiva DNSBL-token accepteras via X-Dnsbl-Token / dnsbl_token,
  • aktiva DNSBL-provider keys (provider=tornevall_dnsbl) accepteras också,
  • aktiva adminägda Tools API-nycklar accepteras via samma token-transport som admin-passthrough,
  • inaktiva token returnerar 401, och vanliga icke-DNSBL-Tools-token returnerar 403 med reason="wrong_token_type".

Exempel på request body:

{
  "rejected_recipients": [
    {"email": "user@example.net"},
    {"email": "second@example.net"}
  ],
  "source_type": "dnsbl_engine_forum_bounce",
  "source_name": "dnsbl-engine",
  "original_filename": "1700000000.12345.mail",
  "subject": "Delivery Status Notification (Failure)",
  "sender_identity": "MAILER-DAEMON <mailer-daemon@example.net>",
  "remote_host": "mx.example.net",
  "diagnostic": "550 5.1.1 User unknown"
}

Typiskt success-svar:

{
  "ok": true,
  "message": "Forum bounce recipients were processed against vBulletin users.",
  "summary": {
    "submitted_emails": 2,
    "matched_users": 1,
    "updated_users": 1,
    "skipped_users": 0,
    "already_grouped_users": 0,
    "exempt_users": 0,
    "unmatched_emails": 1,
    "dry_run": false
  },
  "updated_users": [
    {
      "userid": 123,
      "username": "ForumUser",
      "email": "user@example.net",
      "action": "update_membergroups",
      "new_membergroupids": "20,156"
    }
  ],
  "unmatched_emails": [
    "second@example.net"
  ],
  "settings": {
    "enabled": true,
    "target_group_id": 156,
    "exempt_group_ids": [6, 7, 37]
  }
}

Admin-/operatörsnotis:

  • aktuell grupp-ID och undantagsgrupper konfigureras från Tools vBulletin-adminsida,
  • Tools lägger bara till bounced-email-gruppen som sekundär grupp; användarens primära forumgrupp skrivs inte om.

Skrivendpoints

Aktiva skrivvägar är:

  • POST /api/dns/records/add
  • POST /api/dns/records/delete
  • POST /api/dns/records/update
  • POST /api/dns/records/bulk
  • POST /api/dnsbl/records/add
  • POST /api/dnsbl/records/delete
  • POST /api/dnsbl/records/update
  • POST /api/dnsbl/check-ip

Nuvarande implementation:

  • skrivningar går via DnsUpdateService
  • DNSBL/FraudBL-publicering expanderas först av ett dedikerat DNSBL-publiceringslager
  • lyckade skrivningar triggar zonsynk
  • berörda cacheposter synkas eller uppdateras efter behov efter lyckad uppdatering
  • delete kräver en specifik target för att undvika farlig rrset-delete

Vanliga arbetsflöden och exempel

1) Validera tokenet först

Använd GET /api/dnsbl/token/info när en hjälparklient, plugin eller native-klient behöver bekräfta om det skickade tokenet är:

  • aktivt
  • add-kapabelt
  • delete-kapabelt
  • CIDR-delete-kapabelt
  • ett riktigt DNSBL-token eller någon annan typ av Tools-token

Det är snabbaste sättet att skilja mellan:

  • 401 no_token
  • 404 not found
  • 422 wrong_token_type
  • giltigt admin-passthrough

2) Inspektera först, delista sedan

Rekommenderat flöde för en IP:

  1. anropa POST /api/dnsbl/check-ip
  2. visa operatören aktuell live-listning
  3. om delist är rätt åtgärd, skicka en POST /api/dnsbl/records/delete för just den IP-adressen

Viktigt: expandera normalt inte ett check-ip-svar till flera delete-anrop för samma IP bara för att delete_candidates[] innehåller flera publiceringsfamiljer. Serversidan löser redan själv upp vilka owners/zoner som verkligen är listade för den IP:n.

Exempel på delete-svar för en IP som redan är rensad:

{
  "ok": true,
  "reason": "already_not_listed",
  "already_not_listed": true,
  "forced_success": true,
  "operation_count": 0,
  "message": "No active DNSBL/FraudBL listings were found for this IP, so the delete request was accepted as a no-op."
}

3) Lägg till eller uppdatera en reputationspost

Använd DNSBL-endpointsen när klienten har IP-adress + bitmask och vill att Tools ska äga:

  • reverse-owner-namngivning
  • expansion av publiceringsfamiljer
  • fraud-mirroring
  • commerce-mirroring

Exempel på add-request:

{
  "ip": "203.0.113.4",
  "bitmask": 64,
  "publication_type": "dnsbl",
  "ttl": 300
}

Exempel på update-request:

{
  "ip": "203.0.113.4",
  "old_bitmask": 64,
  "bitmask": 84,
  "publication_type": "fraudbl",
  "ttl": 300
}

4) Använd dry-run före riktiga bulkjobb

POST /api/dnsbl/records/add|delete|update|bulk accepterar dry_run=true.

Använd det när du vill validera:

  • payloadform
  • token-scope
  • delete-guardrails
  • publication-expansion

utan att faktiskt skriva till DNS.

5) Använd hjälpendpointsen bara för deras dedikerade jobb

  • GET /api/dnsbl/engine-settings är till för dnsbl-engine-liknande runtime-synk
  • POST /api/dnsbl/forum/bounce är till för intagning av studsade forummottagare
  • POST /api/dnsbl/dmarc/report är till för DMARC-granskningsintagning, inte direkt blacklist-publicering

DNSBL-publiceringspayloads

POST /api/dnsbl/records/add

{
  "ip": "1.2.3.4",
  "bitmask": 12,
  "publication_type": "commerce",
  "ttl": 300,
  "dry_run": true
}

Det publicerar idag till både:

  • 4.3.2.1.bl.fraudbl.org
  • 4.3.2.1.ecom.fraudbl.org

med target:

127.0.0.12

POST /api/dnsbl/records/delete

{
  "ip": "1.2.3.4",
  "bitmask": 12,
  "publication_type": "commerce",
  "dry_run": true
}

Vid delete tas den specifika A-recorden bort från varje ägare som DNSBL-publiceringslagret genererar. För commerce betyder det både ordinarie FraudBL-zonen och dedikerade ecom-zonen.

Delete-flödet removal-loggas nu också server-side. Riktiga delete-försök, dry-runs, nekade delistningar och delete-poster inne i bulk-anrop skapar alla egna DNSBL-removal-audithändelser i backendloggarna med resolved IP, owner-namn, zoner och delete-targets när den informationen finns.

Delete/write-klienter kan nu också skicka additiv audit-tracing-metadata när backendloggen tydligare ska visa var anropet kom ifrån, till exempel:

{
  "source_type": "wordpress_plugin",
  "source_name": "Example Site",
  "source_site_url": "https://example.org/",
  "source_page_url": "https://example.org/removal/"
}

Fälten är enbart additiva och används för operatörs-/auditspårning. De ändrar inte den auktoritativa serverside-resolveringen av delistningen. När explicita source-fält saknas kan Tools fortfarande härleda viss ursprungsinfo från requestheaders som Origin, Referer och User-Agent om de finns med.

Om admin aktiverar Slack-loggkategorin DNSBL removal audit forwardas samma dedikerade removal-händelser också till Slack utan att den bredare auditen API /dnsbl requests måste vara påslagen.

Samma removal-auditering kan nu också skickas som plain-text-mail till mottagarlistan i DNSBL_REMOVAL_AUDIT_EMAIL, för operatörer som vill ha en andra auditsink utöver loggar och Slack.

POST /api/dnsbl/records/update

{
  "ip": "1.2.3.4",
  "old_bitmask": 4,
  "bitmask": 12,
  "publication_type": "commerce",
  "ttl": 300,
  "dry_run": true
}

Update kräver old_bitmask så DNS-lagret säkert kan ta bort tidigare 127.0.0.X innan den nya targeten läggs till.

Token-informationsendpoint

GET /api/dnsbl/token/info

Returnerar behörighet och scopeinfo för ett DNSBL-token utan att kräva en inloggad session.

Auth: X-Dnsbl-Token: <token> header eller ?dnsbl_token=<token> query-parameter.

Returnerar info oavsett tokenstatus (active, pending, revoked) så att klienter kan se exakt tillstånd och varför ett token kanske inte fungerar.

Endpointen gör nu liveinspektion för alla icke-tomma tokensträngar. Den avvisar inte längre ett värde enbart för att det faller utanför en lokal längd-/formatkontroll innan uppslag görs.

Om det angivna värdet matchar en annan Tools-token/provider som tillhör en aktiv adminägd Tools-token behandlar endpointen det nu som ett token med automatisk effektiv DNSBL-access och returnerar ett lyckat svar med token.resolved_via="admin_api_key_passthrough" samt fulla effektiva behörighetsfält.

Exempelsvar:

{
  "ok": true,
  "token": {
    "name": "My Token",
    "status": "active",
    "is_admin_token": false,
    "allow_add": true,
    "allow_delete": false,
    "can_add": true,
    "can_delete": false,
    "scope_label": "add",
    "zones": ["dnsbl.tornevall.org", "opm.tornevall.org", "bl.fraudbl.org", "ecom.fraudbl.org"],
    "approved_at": "2026-04-04T12:00:00+00:00",
    "requested_by_email": "user@example.com"
  }
}

Felstatus:

  • 401 – inget token angivet
  • 404 – token hittades inte i systemet
  • 422 – värdet matchar en annan Tools-token/provider i stället för ett DNSBL write-token och är inte berättigat till admin-passthrough

Exempel på lyckat admin-passthrough-svar:

{
  "ok": true,
  "message": "Det angivna tokenet tillhör en Tools-admin och har därför automatisk DNSBL-läs/skrivaccess via samma X-Dnsbl-Token-flöde.",
  "token": {
    "name": "Tools AI Bearer",
    "status": "active",
    "is_admin_token": true,
    "allow_add": true,
    "allow_delete": true,
    "can_add": true,
    "can_delete": true,
    "scope_label": "admin_api_key_passthrough",
    "zones": ["dnsbl.tornevall.org", "opm.tornevall.org", "bl.fraudbl.org", "ecom.fraudbl.org"],
    "approved_at": null,
    "requested_by_email": "admin@example.com",
    "provider": "tools_ai_bearer",
    "resolved_via": "admin_api_key_passthrough",
    "is_admin_passthrough": true
  },
  "user": {
    "id": 1,
    "name": "Admin User",
    "email": "admin@example.com",
    "is_admin": true,
    "is_acknowledged_admin": true
  },
  "admin_owner": {
    "is_admin_user": true,
    "is_acknowledged_admin": true,
    "automatic_dnsbl_access": true,
    "accepted_for_dnsbl_reads_and_writes_via_token": true,
    "token_is_active": true
  }
}

Exempel på 422 wrong_token_type-svar:

{
  "ok": false,
  "reason": "wrong_token_type",
  "message": "Det angivna tokenet är en giltig Tools bearer-token, men det är inte ett DNSBL write-token.",
  "token_type": "tools_bearer",
  "provider": "tools_ai_bearer",
  "token": {
    "provider": "tools_ai_bearer",
    "name": "Tools AI Bearer",
    "is_active": true,
    "is_global": false,
    "is_personal": true,
    "user_id": 7
  },
  "user": {
    "id": 7,
    "name": "Example User",
    "email": "user@example.com",
    "is_admin": false,
    "is_acknowledged_admin": false
  }
}

Live-endpoint för IP-inspektion

POST /api/dnsbl/check-ip

Gör en live DNS-baserad inspektion för en IP-adress och returnerar vilka DNSBL/FraudBL-publiceringsfamiljer som just nu är listade, tillsammans med de delist-kandidater som det autentiserade tokenet/sessionen kan agera på.

Auth: samma DNSBL-authmodell som write-endpointsen (X-Dnsbl-Token, dnsbl_token eller privilegierad admin/session/API-key-access).

Request:

{
  "ip": "1.2.3.4"
}

Exempelsvar:

{
  "ok": true,
  "ip": "1.2.3.4",
  "message": "Current DNS lookup found active listings and the authenticated context can delist: DNSBL (64).",
  "lookup": {
    "listed": true,
    "combined_bitmask": 64,
    "constants": ["IP_ABUSE_NO_SMTP"],
    "statement": "Current DNS lookup found active DNSBL/FraudBL listings for this IP.",
    "zones": [
      {
        "zone": "dnsbl.tornevall.org",
        "publication_type": "dnsbl",
        "host": "4.3.2.1.dnsbl.tornevall.org",
        "listed": true,
        "bitmask": 64,
        "target": "127.0.0.64",
        "constants": ["IP_ABUSE_NO_SMTP"]
      }
    ],
    "delete_candidates": [
      {
        "publication_type": "dnsbl",
        "bitmask": 64,
        "active_flags": ["IP_ABUSE_NO_SMTP"],
        "zones": ["dnsbl.tornevall.org", "opm.tornevall.org"]
      }
    ],
    "delete_candidate_count": 1
  },
  "token": {
    "auth_mode": "dnsbl_token",
    "has_token": true,
    "can_add": true,
    "can_delete": true,
    "can_update": true,
    "scope_label": "add_delete",
    "token_name": "My Token",
    "token_status": "active"
  }
}

Driftnotering: POST /api/dnsbl/check-ip och dagens DNSBL-write-endpoints loggar nu alltid explicit på backend och försöker dessutom skicka DNSBL API-aktivitet vidare till konfigurerade audit-/notifieringskanaler när sådana kanaler och matchande regler finns aktiverade.

DNSBL dry run-kvittens

POST /api/dnsbl/records/add|delete|update|bulk accepterar nu valfri dry_run.

  • dry_run=true validerar payload, token-scope, zonbehörighet och publication-expansion.
  • Ingen DNS-uppdatering körs och ingen cache-synk görs.
  • Svaret innehåller dry_run: true och dry_run_accepted: true när requesten godkänns.

Exempel på svar:

{
  "ok": true,
  "message": "Dry run accepted. No DNS updates applied.",
  "dry_run": true,
  "dry_run_accepted": true,
  "operation_count": 2
}

Delete-guardrails (användarnivå)

DNSBL-delete kan nu begränsas per tokenägare via adminstyrda guardrails i /admin/dnsbl/tokens.

Aktuella guardrail-fält:

  • delete_min_cidr_prefix - delegerad IPv4-CIDR-gräns för delete för icke-admin-tokenägare (/24 som bredaste intervall, /32 endast enstaka IP, null = CIDR-delete inte delegerad)
  • delete_limit_per_day - max antal delete-enheter per dag för användaren
  • delete_cidr_limit - max antal expanderade IP/delete-targets i en request
  • delete_throttle_limit
  • delete_throttle_window_seconds

Guardrails gäller för POST /api/dnsbl/records/delete och delete-poster i POST /api/dnsbl/records/bulk.

När en request blockeras returnerar API:t tydliga reasons:

  • delete_cidr_not_allowed (422)
  • delete_cidr_prefix_too_broad (422)
  • delete_daily_limit_exceeded (429)
  • delete_throttle_exceeded (429)
  • delete_cidr_limit_exceeded (422)

Additiv metadata delete_guardrails returneras nu också i DNSBL token-info och auth-summary så klienter kan visa effektiva delete-gränser före delist-försök. Token-/authmetadata kan nu även innehålla can_cidr_delete så hjälparklienter kan dölja CIDR-delete tills delegerad CIDR-access faktiskt är aktiverad.

TTL-standard i nuvarande skrivväg

Aktiva DNS-uppdateringslagret använder standard-TTL 300 sekunder för nya poster om inget annat anges. Det matchar den korta TTL-nivå som behövs för snabbföränderlig reputationsdata.


Commerce-flöde, removals och TTL

Commerce-flöde

Avsedd arkitektur idag är:

  1. Request kommer in via ToolsAPI DNSBL / commerce-flödet.
  2. ToolsAPI skickar operationen vidare till DNSBL/DNS-lagret.
  3. DNSBL-lagret ansvarar för encoding / anonymisering om det behövs.
  4. DNS/DNS-zonlagret skriver, uppdaterar eller tar bort de publicerade posterna.

Detta håller anonymisering och namnsättning samlat i ett lager.

Nuvarande encodingansvar

Nuvarande implementation använder fortfarande reverse-IP-encoding för publicerade owner-namn.

Det viktiga arkitekturella kravet är att klienten inte ska bygga dessa namn själv. Om hashing eller annan GDPR-driven encoding införs senare ska den förändringen ske i DNSBL-publiceringslagret och inte i klienter eller generiska DNS-endpoints.

Removals

För commerce-relaterade removals ska delete täcka både:

  • ordinarie bl.fraudbl.org
  • dedikerade ecom.fraudbl.org

TTL-policy

Commerce-relaterade poster ska använda kortast säkra TTL i DNS-miljön.

Rekommenderat riktvärde:

300 sekunder

WordPress-pluginets beteende

Nuvarande WordPress-plugin drivs inte längre av gamla API v3-kontraktet.

Pluginet:

  • gör direkta DNS-uppslag mot konfigurerade resolvers
  • tolkar returvärdet som en bitmask
  • lagrar lokal cache i WordPress
  • registrerar lokal statistik
  • använder whitelist för säker testning och dry-run i wp-admin
  • använder också whitelist under spam-/blacklistflöden så undantagna IP-adresser kan tas bort i stället för att ligga kvar publicerade i DNSBL-zonerna
  • visar nu ett synligt fält för DNSBL / Tools API token i admin-UI:t, där livekontrollen frågar Tools direkt och rapporterar den effektiva DNSBL-accessen för det konfigurerade tokenet
  • den publika checker/removal-flowen ger nu först ett omedelbart lokalt DNS-svar och, när ett token finns, följs det av ett bakgrundsanrop till POST /api/dnsbl/check-ip innan delete-knappen låses upp
  • den andra Tools-inspektionen returnerar fortfarande delist-kandidater grupperade per publiceringsfamilj för UI och felsökning, men själva delete-begäran avgörs nu auktoritativt på serversidan utifrån IP-adressens live-DNS-svar i stället för att WordPress själv måste välja exakta subzoner
  • pluginet stämplar nu också sina Tools write/check-anrop med additiv sajtidentitet (source_type, source_name, source_site_url, source_site_host) så DNSBL-removal-auditen kan visa vilken WordPress-sajt som skickade begäran även i server-till-server-flöden
  • när checker-lägets Delist klickas visar nu just delist-knappen själv skickarstatusen samtidigt som båda checker-knapparna låses tills anropet är klart, vilket minskar risken för dubbelklick och dubbla submits
  • färdiga checker-körningar går nu att återanvända utan sidomladdning: användaren kan direkt ändra IP-fältet igen efter en avslutad kontroll eller klicka på Reset för att nollställa checker/CIDR/bakgrundsstatus och börja om
  • checker- och delist-anrop visar nu också en egen spinner/statusrad under actionknapparna så att det blir tydligare att WordPress-begäran fortfarande arbetar även innan resultatrutan har uppdaterats
  • Turnstile i den publika delist-/removal-flowen är nu uttryckligen opt-in från WordPress-admin i stället för att automatiskt ärvas från kommentar-/registreringsskyddet, vilket gör att operatören kan stänga av just removal-sidans challenge när Cloudflare har tillfälliga problem
  • samma removal-side-Turnstile har nu också en valfri fail-open-checkbox: om widgeten inte kan initieras eller Cloudflares verifiering har ett operativt avbrott kan WordPress tillfälligt bypassa challengen automatiskt för just den publika removal-sidan tills en senare frisk Turnstile-verifiering stänger bypassen igen
  • avancerade CIDR-kontroller för den publika delist-flowen stannar nu inne i WordPress i stället för att använda Tools för själva blockskanningen; pluginet går igenom det delegerade CIDR-intervallet lokalt i små batchar, visar liveprogress och håller en synlig träfflista över listade IP-adresser som hittats i blocket medan skanningen pågår
  • den lokala CIDR-skanningen är medvetet batchad i små steg så att resolversidan inte överbelastas, medan den slutliga CIDR-delete fortfarande går via DNSBL-write-endpointen först när pluginet har en färdig lokal scan-ticket för intervallet, nu bara för de IP-adresser som den lokala CIDR-skanningen faktiskt markerade som listade, och nu sekventiellt en IP i taget
  • om användaren klickar på Kontrollera om adressen är listad medan ett giltigt CIDR fortfarande står kvar i det första checker-IP-fältet öppnar WordPress nu Advanced då, flyttar CIDR-värdet dit automatiskt och behandlar sedan det Advanced-CIDR-värdet som den auktoritativa scopen för den lokala skanningen och den senare delist-submitten
  • delegerade/icke-admin-token kan nu exponera en konfigurerbar CIDR-gräns (till exempel /25../32) via delete_guardrails.delete_min_cidr_prefix; om det värdet saknas håller pluginet fortsatt CIDR-delete avstängt och använder bara delist för en enstaka IP-adress
  • validerar nu den valda huvudsidan för delisting mot livevärdet token.can_delete innan WordPress accepterar sidan som pluginets primära removal/delisting-sida
  • levererar en inbyggd huvudtemplate för removal-sidan i templates/removal-page.php när den valda sidan inte redan innehåller någon av pluginets removal-shortcodes
  • stöder fortfarande egna WordPress-sidor via [dnsbl_removal_form] / [tornevall_dnsbl_removal_form], samtidigt som formuläret döljer operationer som det aktuella tokenet inte får utföra

Huvudsida för removal jämfört med shortcode-sidor

  • Den pluginhanterade huvudsidan för removal är delete-fokuserad och aktiveras bara när det konfigurerade tokenet just då har livebehörighet för delete / delist.
  • Den kontrollen sker i WordPress-inställningarnas save-flöde och återanvänder samma GET /api/dnsbl/token/info-data som admin-knappen Check token permissions redan läser.
  • Om den valda WordPress-sidan redan innehåller en stödd shortcode låter pluginet sidans innehåll vara som det är.
  • Om sidan inte innehåller en stödd shortcode injicerar pluginet i stället sin egen inbyggda layout och renderar det backendkopplade delete-formuläret där automatiskt.
  • Egna shortcode-sidor fortsätter därför att fungera för sajtägare som vill ha eget innehåll, egen layout eller annan omgivande text runt formuläret.

Legacy: historisk DNSBL v5 / API v3-referens

Deprecated

Allt i detta avsnitt är endast historisk referens och inte längre den aktiva integrationsmodellen för ToolsAPI.

Historiska permissions

Legacy-permissions inkluderade bland annat:

  • allow_cidr
  • allow_cidr_update
  • can_purge
  • dnsbl_update
  • fraudbl_update
  • global_delist
  • local_delist
  • overwrite_flags

Historiska typer

Det gamla API:t beskrev bland annat:

  • dnsbl
  • ecommerce

Även i legacy-koden behandlades commerce som specialfall och refererade till:

  • dnsbl.tornevall.org
  • bl.fraudbl.org
  • ecom.fraudbl.org

Historisk flaggnotis

Äldre API v3-kod namngav tidigare bit 8 som:

FREE_SLOT_8_PREVIOUSLY_PROXYTIMEOUT

Det namnet ska inte användas i nya specifikationer.


Relaterad dokumentation

Senast uppdaterad: 2026-04-24