Verisign RDAP: .com Lookups and the 404 Domain Not Found Response

If rdap.verisign.com just answered 404 Not Found for a domain that definitely exists, nothing is down. The endpoint is strict about what it accepts, and RDAP's 404 — the protocol's way of saying domain not found — has four common causes. Three of them are bugs on your side of the request.

The endpoint in question is the authoritative source for .com and .net registration data:

curl https://rdap.verisign.com/com/v1/domain/google.com

A successful lookup returns JSON per RFC 9083: creation and expiration dates, nameservers, EPP status codes, DNSSEC data, and the sponsoring registrar. Verisign operates the registry for both TLDs, which between them account for nearly half of all registered domains (Verisign's Domain Name Industry Brief tracks the exact counts quarterly).

This guide covers the endpoint's exact shape, the common causes of a 404 domain not found response, and what to do with the thin response you get on a 200.

The endpoint, exactly

The URL pattern is:

https://rdap.verisign.com/{tld}/v1/domain/{domain}

.com domains: https://rdap.verisign.com/com/v1/domain/example.com
.net domains: https://rdap.verisign.com/net/v1/domain/example.net

The TLD appears twice: once in the path prefix and once in the domain itself. They must match — more on that below.

Verisign's other TLDs (.cc, .name, and its IDN TLDs) live on a different host, tld-rdap.verisign.com:

https://tld-rdap.verisign.com/cc/v1/domain/example.cc
https://tld-rdap.verisign.com/name/v1/domain/example.name

None of this needs to be memorized or hardcoded. The IANA bootstrap registry maps every TLD to its RDAP base URL, and it is the reason these URLs can change without breaking clients that do discovery properly.

A few practical details, verified against the live server:

Case does not matter. GOOGLE.COM and google.com return the same response.
Internationalized domains work in both forms. The server accepts the Unicode form (münchen.com) and the punycode A-label (xn--mnchen-3ya.com).

Why you are getting "404 domain not found"

Four common causes produce the same 404. If your domain clearly exists, start with the first three — they are all on the client side.

1. You queried a subdomain. The registry only knows about registered domains, not hosts under them:

curl -s -o /dev/null -w '%{http_code}' https://rdap.verisign.com/com/v1/domain/www.google.com
# 404

www.google.com is not a .com registration — google.com is. Strip the domain down to the registrable part before querying. (For TLDs with multi-label public suffixes like .co.uk, you need the Public Suffix List to do this correctly.)

2. The path TLD and the domain TLD do not match. Querying a .com domain against the .net path returns 404, not a redirect:

curl -s -o /dev/null -w '%{http_code}' https://rdap.verisign.com/net/v1/domain/google.com
# 404

Each path prefix serves exactly one registry zone. If you build the URL from a hardcoded base and the domain's TLD varies, this is the bug.

3. A trailing dot. The fully-qualified form google.com. — valid in DNS — returns 404 here. Trim it.

4. The domain really is not registered. In RDAP, 404 is not an error — it is the specified answer for "this domain does not exist in the registry," per RFC 7480 §5.3. That makes it a useful availability signal, though not a perfect one — reserved and premium names complicate the picture, as covered in checking domain availability with RDAP.

One more trap: Verisign's 404 responses come back with an empty body. That is allowed — RFC 7480 makes the body optional on a negative answer — but many other RDAP servers do send a JSON error object there. If your client assumes every RDAP response parses as JSON, Verisign's not-found path is where it breaks.

What a 200 actually contains

Verisign runs .com and .net as thin registries: the registry stores which registrar sponsors the domain, its nameservers, dates, and status — but not who registered it. The response reflects that:

curl -s https://rdap.verisign.com/com/v1/domain/google.com | jq '{
  ldhName,
  registrar: (.entities[0].vcardArray[1][] | select(.[0] == "fn") | .[3]),
  registrar_iana_id: .entities[0].publicIds[0].identifier,
  related: [.links[] | select(.rel == "related") | .href]
}'

{
  "ldhName": "GOOGLE.COM",
  "registrar": "MarkMonitor Inc.",
  "registrar_iana_id": "292",
  "related": [
    "https://rdap.markmonitor.com/rdap/domain/GOOGLE.COM"
  ]
}

(Yes, extracting the registrar name requires digging through vcardArray — jCard is RDAP's least loved corner, decoded field by field in our guide to the RDAP JSON response.)

What you get on a 200:

events — registration, expiration, and last-changed dates in ISO 8601, instead of the 15-sep-1997 and 1997/09/15 variants WHOIS parsers grew up fighting.
status — the domain's EPP status codes (client transfer prohibited, server delete prohibited, and so on) in RDAP's lowercase spelling.
nameservers — the delegated NS set as structured objects.
secureDNS — whether the domain has DS records published.
entities — exactly one entity, with the role registrar, identified by its IANA registrar ID. No registrant, no admin, no tech contact. That data lives at the registrar, not at Verisign.

Getting the full record: follow the referral

The registry response includes a rel: "related" link pointing at the sponsoring registrar's own RDAP server:

{
  "rel": "related",
  "href": "https://rdap.markmonitor.com/rdap/domain/GOOGLE.COM"
}

Query that URL and you get the registrar's record for the same domain — richer entity data (subject to GDPR redaction), registrar abuse contacts, and sometimes reseller information. This two-step dance is standard for every thin-registry lookup, and it is where the real-world messiness starts: every registrar runs its own RDAP server, with its own uptime, rate limits, redaction policy, and interpretation of the JSON spec.

Rate limits

Verisign does not publish thresholds for its RDAP service, and occasional lookups will never notice a limit. But RDAP's standard mechanism is defined in RFC 7480 §5.5: a server that declines a query due to rate limiting answers 429 Too Many Requests, and clients should slow down and honor the Retry-After header if present. If you are checking domains in volume — against Verisign or the registrar servers you follow referrals to — you need backoff, caching, and 429 handling built in, or a provider that does that for you.

Do not hardcode any of this

rdap.verisign.com/com/v1/ is stable today, but the correct way to find any TLD's RDAP server is bootstrap discovery against IANA's dns.json, cached with its expiry. That is also the only way to handle the other 1,200+ TLDs, each with its own base URL, quirks, and availability.

If you would rather skip bootstrap discovery, referral-following, empty 404 bodies, and per-server rate limits entirely, that is the plumbing RDAP API abstracts away:

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://rdapapi.io/api/v1/domain/google.com?follow=true"

One endpoint for every TLD, with ?follow=true automatically merging the registry and registrar responses into flat, normalized JSON. See the API documentation for the full schema.