Case Study

AbuseRoute: who to report a domain to, in one API call.

A private, access-controlled API for SOCs, CERTs and abuse desks. Given a domain, it returns the registrar and hosting-network abuse contacts and says when a CDN is hiding the real host.

1 call

Routed abuse contacts

RDAP + RIR

Authoritative sources

5 RIRs

Network coverage

Private

Access by request

The problem

When a security team finds a phishing page or a malware host, the slow part is rarely the detection. It is working out who can actually take the content down: the registrar, the hosting network, or a CDN that is only forwarding traffic. That means WHOIS or RDAP lookups against the registry, a separate query to the right Regional Internet Registry for each IP, and a judgement call about whether a Cloudflare or Fastly address is the real host. The free ACID Tool on this site's work page answers that question for one domain at a time in a browser. Security teams asked for the same answer as structured data they could call from their own tooling, at volume, with consistent output.

What we built

AbuseRoute is a private, access-controlled HTTP API. Given a domain, one call returns the sponsoring registrar, its IANA ID and the abuse contact it publishes; the network operator and abuse contact for every IP the domain resolves to; and an infrastructure classification that says whether a CDN or reverse proxy fronts the site and which mail and DNS providers are in use. The response ends with a routed list of abuse contacts, deduplicated and ordered by who can act fastest. When the origin is visible the hosting network comes first, then the registrar. When a CDN hides the origin the registrar comes first and the CDN is labelled as a forwarding channel, so an analyst knows a report sent there will be passed on rather than actioned.

How a lookup works

The domain is normalised (lowercased, Unicode converted to punycode) and resolved with the service's own recursive resolver: A, AAAA, MX, NS, TXT and the CNAME chain. The IANA bootstrap files identify the authoritative RDAP server for the TLD and the responsible RIR for each IP, and the service queries them directly, falling back to port-43 WHOIS for ccTLDs that have not adopted RDAP. All sources are public and authoritative. Requests to each registry are serialised over a persistent connection with an identifying User-Agent, results are cached briefly in memory and not written to disk, and person objects and administrative contacts returned by registries are discarded. Every customer key is rate limited.

Access and outcome

There is no anonymous or self-service access. Keys are issued on request to organisations that identify themselves and describe their abuse-handling or security use, with per-key limits. The service is live and documented at abuseroute.com, with a quickstart, a full field reference and published coverage limits (for example, .uk registration data is not currently returned). AbuseRoute is published by WAPPDEV UK. It grew directly out of the ACID Tool case study on this site: the same question, answered as an API for teams who need it inside their own workflow.

Screenshots

AbuseRoute homepage explaining what a lookup returns: registrar abuse contact, hosting network abuse contacts, infrastructure classification and a routed contact list
abuseroute.com: what one lookup returns, and why the routed list puts the registrar first when a CDN hides the origin.

Technology stack

HTTP APIJSONRDAPWHOISDNSRIR data

Continue exploring