How to check reputation before you buy IP addresses

Table of Contents

How to check reputation before you buy IP addresses

Why reputation checks matter

The secondary market for IPv4 addresses exists because the world has almost finished the free supply. This lack has made addresses a valuable digital asset. It has also pulled in people who act in bad faith, and it has created risks for buyers. If you do not carry out full checks, you may pay for space that causes many problems. You may get:

• Hijacked space that the seller does not truly own and that may be taken back by the real holder.
• “Burned” ranges that carry a long record of spam, malware, or harmful traffic, and these marks do not go away easily.
• Addresses blocked by email providers like Gmail or Microsoft, and this means you cannot send mail to users in a normal way.

The effect of poor checks is serious. A company may find that the space it has bought cannot be routed well across the Internet. It may find that emails to customers do not get delivered. It may also face a large number of abuse reports that harm its name. Rebuilding trust for addresses linked to abuse is very slow because mail systems and security feeds hold long memories. In some cases, the ranges do not recover their good standing at all, even after long use by a clean owner.

Confirming legal ownership and transfer eligibility

Using RDAP and registry records

The Registration Data Access Protocol (RDAP), documented by IANA, is the first step when you check the ownership of an IP block. It shows the registered holder of a prefix, and it shows which regional Internet registry (RIR) manages the block. RDAP is not the same as the old WHOIS system. It is standardised, and it is machine-readable, and it supports redirection so the query goes to the correct RIR. This makes RDAP more clear and more useful when you want to confirm the holder of the space.

When you look at the RDAP record, you need to make sure the seller’s name is the same as the registered holder. If the name is different, you must stop the deal. You also need to check that the contact emails in the record are valid, and they are linked to the domain of the organisation. If the contact emails do not work, or they point to another domain, that is a warning sign.

• If the seller’s name is not the same as the holder in the record, you should walk away.
• If the contact emails are not valid, or they are not linked to the right domain, you should not continue.

Cross-checking transfer policies

Each regional Internet Registry (RIR) has formulated its own resource transfer rules. Be sure to carefully review them before operation. These rules clearly define the subject of transfer qualification, the required documents and materials, as well as the prerequisites for the implementation of the transfer.

Take ARIN as an example: It requires that the transferee must be the current official record holder of the resource, and the transferred IP address block must meet the minimum scale requirement (for example, the /24 address block). If the block is smaller, or if the source is not the registrant, the transfer will not be approved. In the RIPE region, there may also be a transfer lock. In APNIC and AFRINIC, local rules can also apply. Because rules are not the same in all regions, you must check the policy of the registry that manages the block.

Fraud reporting

If you see anything in the record that looks irregular, the RIRs say you should report it. ARIN says clearly: “If you believe a block may have been inappropriately obtained, submit a fraud report.” This protects your own deal, and it also protects the Internet community from fraud and hijack attempts. Other registries have similar reporting channels, and you should use them if you see signs of abuse.

Routing legitimacy — BGP, RPKI, and IRR

Reviewing routing history

When you plan to buy IP addresses, you need to look at how the prefix has been routed in the past. Tools like RIPEstat show the routing history, and they tell you when and where the block has been announced. If a prefix appears for a short time in BGP, and it is announced by an autonomous system that is not linked to the holder, this is a clear sign of a hijack. If the block shows many short and irregular announcements from different systems, it may have been abused before. If the block is not visible for a long time, and it then appears again with a new origin, you should check it with care because this can also point to risk.

Validating with RPKI

The Resource Public Key Infrastructure (RPKI) gives proof about which autonomous systems are allowed to originate a prefix. RIPE NCC says that RPKI “proves the association between IP address blocks and their legitimate holders.” This is important because routing on the Internet is built on trust, and without RPKI it is easy for others to announce space they do not own.

A good block should have valid Route Origin Authorisations (ROAs) that match the origin ASN. If the ROA is invalid, then the block is being announced by a system that is not allowed. If the ROA points to another party who is not the seller, this is a warning sign because it shows that someone else has control. If there are no ROAs at all, then you need to be careful, because more networks now drop routes that cannot be validated.

Checking IRR objects

The Internet Routing Registry (IRR) is used by networks to make filters for routes. It holds route objects, and these objects say which ASN can announce a prefix. If the IRR objects for the block are not present, or if they list an ASN that does not match the expected origin, many networks may reject the route. If the IRR objects are still under the control of someone else, you may not be able to fix them, and this can stop your routing. So you must make sure that the IRR records are correct, they are current, and they are under the control of the seller who can give them to you.

Screening for reputation and abuse

Blocklists and reputation feeds

When you check the reputation of an IP block, you start with the main blocklists and reputation feeds. The most common sources are Spamhaus and Cisco Talos. Spamhaus focuses on spam and abuse, and Talos gathers data from many security systems. If the block is already listed on a spam or malware database, it causes problems at once. Mail from the block is stopped, and traffic from the block is treated as unsafe. Even if the seller says the block is fine, the listing shows the addresses have been used for harmful activity, and this history does not go away quickly. You must check carefully before you buy.

Abuse exposure scans

The Shadowserver Foundation runs daily scans across the Internet, and it looks for open resolvers, open proxies, DDoS amplifiers, and unsafe services. If a prefix shows many exposed services, this means the addresses were poorly managed before, and they are still linked with abuse. A block like this needs cleaning before safe use. You may have to shut down the services, and you may have to wait for new scans to confirm the block is fixed. If you buy without checking, you face higher costs, and you face delays because you cannot use the block right away.

Mail provider requirements

Large mail providers also set rules that affect IP reputation. Google and Microsoft both require valid PTR records, and these records must point back to domains that you own. They also require authentication, and this means SPF, DKIM, and DMARC must be set up and must align with the sending domains. They also watch complaint rates. If too many users report your messages as spam, delivery from the IPs is blocked.

Even if you buy a clean block with no listings and no abuse history, you cannot send large volumes right away. Google and Microsoft expect you to warm up the IPs. You must send small amounts first and then increase slowly. This step shows that you are a trusted sender, and it builds positive reputation over time. If you skip this step, even a clean block can be flagged, and once flagged, recovery is slow and difficult.

Abuse contacts and contractual safeguards

Ensuring abuse contactability

When you buy IP addresses, you need to check that the abuse contacts are correct and that they work. The RIPE Database requires an abuse-c attribute, and this field must point to a valid contact. The contact receives reports about spam, malware, or other abuse, and it helps the holder fix problems. You should test the contact before you move forward. If the email bounces, or if no one answers, you should expect that handling abuse will be difficult. If you take such a block, you may miss reports, and you may not be able to respond in time, and this can harm the reputation of the space.

What to require in contracts

When you make a purchase agreement, you need to make sure the seller is required to take clear actions. The seller must update the RIR records, and the seller must finish the transfer approval. The seller must revoke or update RPKI ROAs, because without this step you may face problems when you announce the block. The seller must correct or remove old IRR objects, because if they stay, filters may block your routes.

The seller must also delegate reverse DNS to you, because you need control of reverse DNS to manage email and service reputation. The agreement must also include indemnities against disputes, because there can be claims from other parties if the block has a complex history.

If the block is in the RIPE region, you need to ask if a transfer lock is set. A transfer lock stops unwanted or fake transfers, and it protects both sides. You should confirm that the lock will stay in place until the deal is ready, and you should ask the seller to release it only when the payment is in escrow. This way the transfer stays safe, and the chance of fraud or conflict is lower.

Planning for remediation

Even if you buy a block that has problems from the past, you must prepare a clear plan before you use it. If you do not make a plan, the same issues will stay with the block, and they will affect your network and your services.

You should first record all blocklist entries that exist. You must check Spamhaus and Cisco Talos and other main lists, and you must save the results. You then need to follow each delisting procedure, because every provider has rules and steps. Some will ask you for proof that abuse has stopped, and some will ask you to explain how you will prevent future abuse.

You should also fix the exposed services that the Shadowserver Foundation scans find. If the prefix is linked to open resolvers or DDoS amplifiers or unsafe proxies, you must close them. You may need to work with hosting providers or past users to remove the services. You should then wait for the next Shadowserver scans, and you should confirm that the block is now clean.

You also need to warm up the block if you want to send email. You must increase the volume slowly, and you must use authentication such as SPF and DKIM and DMARC. You should begin with small volumes, and you should raise the level step by step. This slow process helps you build a record of safe use, and it shows Google and Microsoft and other providers that you are a trusted sender. If you send too much mail at once, your messages may be blocked, and the block will gain a new bad record.

You must also watch RIPEstat and BGP feeds after you announce the block. You should look for anomalies, because they can show hijacks or leaks or routing errors. If you see an origin ASN that is not expected or a sudden route that lasts for a short time, you must act fast. By monitoring from the first day, you show that you are a responsible holder, and you keep control of the block.

FAQs

1. Can I skip reputation checks if I only use IPs for hosting and not for email?
No. Bad reputation also affects routing and firewalls and security systems, and it can stop connections.

2. What is the simplest way to see if a block was hijacked?
You can check RDAP for ownership, and you can compare with BGP announcements in RIPEstat, and you can confirm with RPKI.

3. Are brokers safe to use?
They are safe if they are approved. You should use brokers on the ARIN Qualified Facilitators list, and you should avoid unknown names.

4. How long does it take to clean a block with a bad reputation?
It can take weeks or months. In some cases, a block never fully recovers, because large providers keep long memory of abuse.

5. Do IPv6 addresses face the same risks?
They do not face the same level of risk. The supply of IPv6 is much larger, but you still need to check ownership and routing and abuse contacts.