The Abuse Contact for an IP Address Is Often Nobody's Job. APNIC Wants to Fix That

APNIC's Dave Phelan published the pre-meeting rundown of the seven policy proposals heading to the APNIC 62 Open Policy Meeting on 21 August 2026. Five of them are about how address space gets handed out. Two are about something the registry system has quietly never gotten right: who answers when you report abuse coming from an IP address.

prop-172 would put the first formal definition of "Internet abuse through IP addresses" into any RIR's policy. prop-171 would make the upstream holder responsible for the abuse contact on space it has sub-allocated. Neither creates an enforcement mechanism, and both proposals say so in their own text.

So we measured the gap they are trying to close. It is wider than we expected.

Where an abuse contact actually lives

In the APNIC database, every inetnum is supposed to reference an irt object through mnt-irt. The IRT object carries the abuse-mailbox attribute, APNIC generates a role object from it, and that role is linked as abuse-c. RDAP renders the result as an entity with the abuse role, defined in RFC 9083 as "an entity object instance that handles network abuse issues on behalf of the registrant of the registration", with the mailbox in its vCard.

When the chain is intact, it looks like this:

$ curl -s -H 'Accept: application/rdap+json' https://rdap.apnic.net/ip/180.243.1.1 \
    | jq '.entities[] | select(.roles[] == "abuse")'
{
  "handle": "IRT-IDTELKOM-ID",
  "roles": [ "abuse" ],
  "remarks": [ "[email protected] was validated on 2026-06-19" ],
  "email": "[email protected]"
}

A handle, a mailbox, and a remark saying when APNIC last confirmed the address accepts mail. APNIC-127 section 5.3.3 requires that check at least every six months, in force since 30 June 2019 after prop-125 reached consensus. RIPE validates abuse-mailbox annually under ripe-705, ARIN validates Admin, Tech, NOC and Abuse contacts annually under NRPM 3.6. Every RIR checks that the mailbox exists. None checks that whoever reads it operates the network.

One address, three different abuse contacts

Now try an address where the chain is broken. 120.182.119.229 sits inside 120.182.119.0/24, netname GGSN-3G-ISAT-ID, described in the registry as "INDOSAT's 3g Broadband Customer". The object was last modified on 9 June 2009.

RDAP has no abuse contact for it at all:

$ curl -s -H 'Accept: application/rdap+json' \
    https://rdap.apnic.net/ip/120.182.119.229 | jq -c '.entities[].roles'
["technical","administrative"]

Ask port 43 instead and an answer appears, because APNIC's whois server walks up the hierarchy and prints an inherited contact. This inetnum has no mnt-irt, so inheritance falls all the way through to the person object on admin-c, which is a hostmaster, not an abuse desk. A third address sits in the same object's free-text remarks:

% Abuse contact for '120.182.119.0 - 120.182.119.255' is '[email protected]'

inetnum:   120.182.119.0 - 120.182.119.255
netname:   GGSN-3G-ISAT-ID
remarks:   For abuse and spam report please contact [email protected]
status:    ALLOCATED NON-PORTABLE

The same split appears whenever a National Internet Registry sits in the path. Ask RDAP about 220.143.195.155, a Chunghwa Telecom residential address, and the bootstrap hands you to twnic.rdap.apnic.net, which returns 220.143.0.0/16 ("Residential ADSL/FTTB") with administrative and technical entities and no abuse role. Ask whois.apnic.net about the same address and you get a perfectly good [email protected] off the less specific object. Which answer you get depends on which protocol you speak.

Sometimes it is not policy at all, just a bug. 118.89.0.0/16 is Tencent Cloud, and its whois record is healthy: IRT-TencentCloud-CN, [email protected], validated on 15 May 2026. Here is the RDAP view of the same object:

$ curl -s -H 'Accept: application/rdap+json' \
    https://rdap.apnic.net/ip/118.89.47.7 | jq '.entities[] | select(.roles[] == "abuse")'
{
  "roles": [
    "abuse"
  ]
}

An abuse entity with no handle, no vCard and no mailbox. The inetnum's mnt-irt reads IRT-TENCENTCLOUD-CN in capitals; the object it points at is registered as IRT-TencentCloud-CN. Whois resolves that case-insensitively. The RDAP serializer appears not to, and returns an empty shell rather than an error, which is worse than nothing: a client that tests for the presence of an abuse entity will think it found one. Five other draws showed the same shape.

We sampled 260 APNIC addresses and 44% did not point at the operator

The method, so you can repeat it. We pulled delegated-apnic-latest on 25 August 2026: 58,012 IPv4 delegation records marked allocated or assigned, covering 888,852,224 addresses, roughly 53 /8 equivalents. We drew 260 addresses at random, weighted by delegation size, queried rdap.apnic.net for each, and followed the bootstrap referrals into the NIR servers. Weighting by size means incumbent blocks dominate: 93 draws landed in China, 56 in Japan, 42 in Korea. Right lens for where traffic comes from, wrong lens for a per-organization census. (If you rerun this, fix your sampler's seed and publish it; ours was 20260825.)

235 of the 260 (90.4%) returned an entity with the abuse role. Nineteen (7.3%) returned no abuse role whatsoever. Six (2.3%) returned the empty shell above.

The interesting number is inside the 235. Ninety of them, 34.6% of the whole sample, point at a national registry rather than at a network operator: IRT-KRNIC-KR on 42 draws, IRT-JPNIC-JP on 36, IRT-VNNIC-AP on six, IRT-CNNIC-CN on six. Those mailboxes are reachable and validated. Nobody behind [email protected] can null-route a Korea Telecom subscriber.

That is prop-171's problem statement, measured. 115 of 260 addresses, 44.2%, resolve through RDAP to a registry hostmaster, an empty object, or nothing at all. The 235 records that did answer carried only 64 distinct abuse handles between them.

Validation dates were mostly healthy, with a tail. Of the 47 distinct handles carrying a "was validated on" remark, four were past the six-month mark, the worst being IRT-JPNIC-JP at 2024-11-27, 636 days before we looked. The remark is not always exposed either: KRNIC's RDAP rendering drops it, while APNIC's whois shows [email protected] validated on 2020-04-09, 2,329 days ago, on an object last modified on 12 August 2026.

APNIC's own IRT object says "[email protected] was validated on 2020-02-03", which is 2,395 days. That helpdesk plainly works, and the object states outright that the RIR "cannot investigate complaints of network abuse", so nothing is broken. But the field that exists to prove a contact was checked in the last six months reads 2020 on the registry's own record.

What prop-172 would put in writing

Here is the definition, from prop-172, authored by Alban Kwan:

"Internet Abuse through IP Addresses" means the use of an IP address, or set of IP addresses, registered to or held by an APNIC account holder, in a way that causes technical harm to the security, stability, or trust of the Internet.

Five categories follow: hosting or distributing malware, including botnet command-and-control; originating, amplifying or reflecting DDoS traffic; deliberate or grossly negligent routing-layer abuse, including BGP hijacking and the use of unallocated, reserved or squatted address space; fraudulently acquiring, transferring or sub-allocating IP resources to enable any of the above; and hosting infrastructure for phishing, fraud, scams or impersonation.

The exclusions carry as much weight. "Good-faith operational errors that are identified and promptly corrected ... do not constitute abuse under this definition," and neither does third-party conduct the holder deals with promptly once notified. Then the sentence that keeps the whole thing modest: "For the avoidance of doubt, APNIC does not have the power to adjudicate abuse."

A second clause is doing far more work than the first, extending the definition to unlawful conduct the holder has the practical ability to address. That is where the Policy SIG list pushed back. Jonathan Brewer, who supports the proposal, wrote on 16 August that "unlawful" should come out because it is jurisdiction-dependent, and that the technical half should widen to catch attempts rather than only completed harm. Terry Sweetser, the same day, said the word "places too much faith in certain legal jurisdictions". On 21 August Aftab Siddiqui asked the question the text does not answer: across APNIC's 56 economies, "which law determines whether the activity falls within the definition"?

They are right. The five technical categories are observable: you can see command-and-control traffic in a packet capture and a hijack in a route collector, and no court is needed for either. Attaching a legality test to that turns one definition into 56.

prop-171 has no teeth, and the proposal that does has no agenda slot

Worth being precise about prop-171, because it changes less than the coverage suggests. It does not introduce validation, alters no cadence and touches no schema; Phelan's rundown says exactly that. What it adds is one principle: the upstream holder must ensure "a reliable operational path from the registered abuse or IRT contact to the party able to investigate and resolve abuse reports". How is left open. Authors Tsung-Yi Yu and Alban Kwan note that no other RIR has attempted it.

A principle with no test is easy to dismiss. It would still be the first sentence in RIR policy anywhere that makes "we forwarded it to the address on file" an incomplete answer.

The enforcement language sits in a proposal that is not on the Mumbai agenda. prop-174, posted by Bikram Shrestha on 17 August, would rewrite APNIC-127 section 5.3.3 to codify what APNIC already does: the abuse mailbox must accept automated reports, a web form cannot be the only channel, validation runs every six months, and persistent failure escalates from written notice through to resource revocation under the membership breach provisions. prop-173, prop-174 and prop-175 stay on the mailing list. Only prop-171 and prop-172 reach the floor.

How to check the abuse path for a prefix yourself

If you run an abuse desk or maintain a blocklist, the practical takeaway is that one lookup is not enough.

• Query RDAP first, but treat a missing or empty abuse entity as "ask again elsewhere", not as "no contact exists".
• Fall back to whois -h whois.apnic.net, which does the hierarchy walk RDAP will not do. Add -L to see every less specific object and which one carries the IRT.
• If the record says it was mirrored from an NIR, go to that NIR's own database: whois.twnic.net for Taiwan, whois.nic.ad.jp for Japan. APNIC's copy is a summary, not the operator's record.
• Read the "was validated on" remark. It is the only machine-checkable freshness signal in the record, and it goes missing more often than you would like.
• Read the free-text remarks once by hand. On records like Indosat's, that is where the monitored address is.

Then check who is announcing the prefix. The registered holder and the originating AS are routinely different parties, and the AS operator is usually the one who can act inside an hour.

Both proposals are definitional rather than operational, and we think that is the right order. You cannot write an enforcement rule around a term nobody has defined, or name a responsible party in a chain where policy has never said which link owns the mailbox. The Open Policy Meeting is on 10 September at 09:30 (UTC +5:30), in Mumbai.

Registry data tells you who an address is registered to, not who is announcing it today, and on sub-allocated space those are frequently different organizations. Every Ipregistry lookup returns the originating AS number, its name and registry, the routed prefix and the connection type, which is the fastest way to check an abuse contact against the network actually carrying the traffic. You can try it with 20,000 free lookups to get started.