NameRobo now supports and .co — here’s the RDAP reality check

We just shipped .co support in NameRobo.

That’s more surface area for brandable hunting, more “good inventory” for founder-style naming, and a better signal mix when you’re iterating fast. But there’s a practical constraint we want to call out up front:

Until other domains have full, clean RDAP coverage (and are properly discoverable in the broader RDAP ecosystem), lookup depth can be limited.

You’ll still get what you actually need to move: availability checks and core insights. What can be inconsistent is the richer registration intelligence that modern tooling expects from RDAP-first registries.

What RDAP is (and why the industry is moving there)

RDAP (Registration Data Access Protocol) is the modern successor to WHOIS. Instead of brittle, unstructured text, RDAP is HTTP-based and returns structured JSON, with better support for internationalization and access control.

ICANN has also been very explicit on direction-of-travel: as of January 28, 2025, RDAP is positioned as the definitive source for gTLD registration data as WHOIS is sunset in that ecosystem.

So if you build domain tooling in 2025+, RDAP isn’t “nice to have” — it’s the strategic baseline.

Why RDAP matters to NameRobo (beyond “is it taken?”)

NameRobo isn’t just a boolean availability checker. We’re building a signal layer that’s fast, scalable, and automation-friendly.

When a TLD is RDAP-ready, it typically unlocks more consistent access to things like:

• standardized status codes (client/server hold, redemption, etc.)
• structured events (created/updated/expiry — when published)
• predictable referrals from registry → registrar
• machine-readable responses that don’t break every time someone changes a WHOIS banner

That’s the difference between “it works” and “it works reliably at scale.”

Not to mention, WHOIS searches can be incredibly unreliable, hence the industry shift to RDAP

The domain situation today

For example, both .CO and .IO are ccTLDs (country-code TLDs), and ccTLDs don’t all move in lockstep with the gTLD world. Some ccTLDS have added support for RDAP, as they should, but it hasn't been enforced as so in the gTLD world.

So our product stance is simple: .co now, but until RDAP is fully operationalized and discoverable, some RDAP-dependent domains enhancements will remain constrained.

“Holdouts” — who hasn’t completed the integration yet?

When people say “RDAP holdouts,” it’s usually not one single blocker — it’s a few layers of the stack that need to align.

1) Some TLD operators (especially ccTLDs)

The IANA RDAP bootstrap registry for the domain name space has a published “last updated” date of 2022-04-04, which is a strong signal that not every TLD is wired into the canonical bootstrap workflow that many clients rely on.

When a TLD isn’t in the expected bootstrap/discovery path, RDAP clients may not be able to automatically find the authoritative server (even if an RDAP endpoint exists somewhere).

2) Discovery + publication plumbing (Root Zone / IANA processes)

Publishing RDAP endpoints for broad consumption isn’t just “spin up a server.” IANA runs conformance checks and there’s a defined publication path for getting RDAP base URLs into registries clients can consume.

3) Registrar-side referrals (and legacy WHOIS-era workflows)

Even when registry RDAP exists, the “follow the referral to the registrar” step can be inconsistent depending on how the registrar has implemented RDAP, what they expose, and what access controls are in play. That means downstream enrichment can be partial depending on sponsorship/registrar behavior.

What this means for NameRobo users, and domain registrars across the world (the practical version)

Here’s the operating model going forward:

• We’ll keep expanding TLD coverage (.co) because naming shouldn’t be gated by protocol politics.
• **When a RDAP server appears, we'll implement it, so you have accurate domain lookups at your fingertips.
• RDAP-first where possible, because it’s the most future-proof integration surface.
• Where RDAP isn’t cleanly available, expect “support” to mean availability + core signals, with some registration intelligence being thinner until the registry ecosystem catches up.

If you run into a domain where you think we should be getting richer data, send it our way — that feedback helps us prioritize the highest-impact upgrades in the pipeline.

TL;DR

We added .co support because they matter for modern naming. .co recently implemented RDAP support in October of 2025 this year. Here's to hoping more will implement as well.

RDAP is where the industry is going — and for gTLDs it’s already the primary path forward — but ccTLD adoption and discoverability is still uneven.

NameRobo will keep shipping coverage now, and keep hardening RDAP-grade intelligence as the ecosystem completes the transition.