De todo lo que rodea a una compra de direcciones IPv4, la due diligence es, con diferencia, lo que m\u00e1s dinero te ahorra. Pi\u00e9nsalo un momento: con los bloques \/24 movi\u00e9ndose entre $30 y $60 por direcci\u00f3n, una sola compra fallida puede dejarte tirados decenas de miles de d\u00f3lares. Y no solo el dinero. Heredar un rango en listas negras o con una disputa de propiedad encima es una pesadilla operativa que puede durar meses. Da igual que seas un ISP ampliando su pool o una empresa preparada para crecer: verificar titularidad, integridad de enrutamiento y reputaci\u00f3n antes de firmar no es opcional.<\/p>\n
Aqu\u00ed comparo las tres patas de esa diligencia previa: consultas WHOIS en los registros, validaci\u00f3n RPKI y los comprobadores de listas negras DNSBL. Por separado, cada herramienta deja puntos ciegos. Juntas forman una checklist bastante s\u00f3lida antes de desembolsar nada.<\/p>\n
In this article:<\/strong><\/p>\n Una consulta WHOIS contra el Registro Regional correspondiente (ARIN, RIPE NCC, APNIC, LACNIC o AFRINIC) te dice qui\u00e9n sostiene legalmente un bloque hoy mismo. Ojo: hoy mismo. Eso es solo una foto fija, y para una diligencia debida en IPv4 no alcanza.<\/p>\n Ah\u00ed entran los archivos de historial WHOIS (WhoisXML API, DomainTools…), que muestran registros anteriores. \u00bfPor qu\u00e9 importa tanto? Porque desde que ARIN y RIPE agotaron sus free pools en 2015 y 2019 respectivamente, la ola de transferencias IPv4 no ha parado. Los bloques han cambiado de manos una y otra vez, y cuando llega una disputa de propiedad, lo que te salva es un rastro documental limpio.<\/p>\n Resource Public Key Infrastructure (RPKI) ata criptogr\u00e1ficamente los prefijos IP a los sistemas aut\u00f3nomos (ASN) autorizados a anunciarlos. Para el comprador, los datos RPKI responden dos preguntas clave: \u00bfel prefijo tiene un Route Origin Authorization (ROA) que lo cubra? \u00bfY ese ROA est\u00e1 bien configurado?<\/p>\n Un matiz importante: el estado “unknown” en RPKI no es malo en s\u00ed \u2014 muchos holders legacy simplemente nunca crearon ROAs. Aun as\u00ed, exigir al vendedor que establezca un ROA v\u00e1lido antes de la transferencia se est\u00e1 volviendo pr\u00e1ctica habitual, y con raz\u00f3n: aproximadamente el 50% del espacio IPv4 enrutado ya lleva ROAs y las pol\u00edticas de filtrado siguen endureci\u00e9ndose.<\/p>\n Un bloque t\u00e9cnicamente impecable puede estar, en cambio, con la reputaci\u00f3n por los suelos. Y eso destroza la entregabilidad de correo y te convierte en el sospechoso habitual de cada investigaci\u00f3n de abuso. Los checks DNSBL revelan para qu\u00e9 us\u00f3 el bloque su anterior due\u00f1o.<\/p>\n Herramientas como MultiRBL.valli.org, MXToolbox o HetrixTools permiten contrastar un \/24 completo contra decenas de DNSBLs de una sola vez. Presta atenci\u00f3n a los listings ligados a spam traps o actividad de botnets: se\u00f1alan que el bloque lo usaron actores maliciosos y que la remediaci\u00f3n, v\u00eda solicitudes de delisting, puede llevar semanas. Algunos bloques quedan da\u00f1ados para siempre, \u00bfy hay algo peor que comprar eso? Ten en cuenta que las tasas de \u00e9xito del delisting var\u00edan much\u00edsimo seg\u00fan el operador de cada lista.<\/p>\n So how do these tools fit together in practice? Here’s the order I’d suggest:<\/p>\n Often, yes. Most DNSBLs remove listings after a cooling-off period once abusive activity stops \u2014 typically days to weeks. But there are exceptions. Spam trap listings on aggressive lists can stick around, and some operators simply refuse to delist blocks with a severe abuse history. So gauge the severity before you buy, and build remediation time into your deployment plans.<\/p>\n Not yet. No RIR currently requires ROAs for transfers, though the industry is clearly heading that way. Major networks increasingly filter unauthenticated routes, which means a block without a valid ROA is at an operational disadvantage. Create a ROA right after transfer. It costs you almost nothing and saves headaches later.<\/p>\n A seller whose name doesn’t match the registered organization \u2014 and who can’t produce a documented chain of authorization. That’s a problem. It suggests the block may be sold without the holder’s consent, which exposes buyers to reclamation claims down the line.<\/p>\n With clean documentation and RIR approval, most transfers complete in two to six weeks. The exact timing depends on the registry and how complicated the paperwork is.<\/p>\n<\/div>\n No single tool covers everything. WHOIS tells you who owns the block<\/em>. RPKI tells you who may route it<\/em>. Blacklist checkers tell you what it was used for<\/em>. Only when you stack them together do you get the full picture \u2014 legal, technical, and reputational \u2014 of what you’re actually buying.<\/p>\n If your team doesn’t have in-house transfer experience, working with an established marketplace is often the most efficient path. IP4 Market combines verified sellers, transparent pricing, and guided escrowed transfers \u2014 helping network engineers and IT managers acquire clean, routable IPv4 space without the guesswork. Start your search with due diligence already built in.<\/p>\n\n
WHOIS Lookups: Verifying Ownership and History<\/h2>\n
What to Check in WHOIS<\/h3>\n
\n
Supplementing WHOIS with History Data<\/h3>\n
RPKI Validation: Confirming Routing Authorization<\/h2>\n
How to Check RPKI Status<\/h3>\n
\n
Blacklist Checkers: Assessing IP Reputation<\/h2>\n
Key Blacklists to Query<\/h3>\n
\n
How to Run Checks Efficiently<\/h3>\n
Side-by-Side Tool Comparison<\/h2>\n
\n\n
\n \nTool Type<\/th>\n What It Verifies<\/th>\n Best Free Options<\/th>\n Limitations<\/th>\n<\/tr>\n<\/thead>\n \n WHOIS \/ RIR<\/strong><\/td>\n Legal ownership, registry of record, transfer history<\/td>\n RIR WHOIS, RIPEstat, WHOIS history services<\/td>\n Snapshots can be outdated; legacy records messy<\/td>\n<\/tr>\n \n RPKI<\/strong><\/td>\n Routing authorization, ROA validity, origin ASN<\/td>\n RIPEstat, Cloudflare RPKI, Routinator<\/td>\n Many legacy blocks have no ROA (“unknown”)<\/td>\n<\/tr>\n \n Blacklist checkers<\/strong><\/td>\n Spam and abuse reputation, prior usage patterns<\/td>\n MXToolbox, MultiRBL, HetrixTools<\/td>\n Lists vary in quality; delisting can be slow<\/td>\n<\/tr>\n \n BGP looking glasses<\/strong><\/td>\n Current routing announcements and hijack detection<\/td>\n bgp.he.net, RIPEstat, RouteViews<\/td>\n Shows current state only, not intent<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n A Practical Pre-Purchase Workflow<\/h2>\n
\n
Frequently Asked Questions<\/h2>\n
Can a blacklisted IPv4 block be cleaned?<\/h3>\n
Is RPKI validation mandatory when buying IPv4?<\/h3>\n
What’s the biggest red flag in WHOIS during IPv4 due diligence?<\/h3>\n
How long does a typical IPv4 transfer take?<\/h3>\n
Conclusion: Layer Your Checks, De-Risk Your Purchase<\/h2>\n