How Our Domain Age Checker Uses RDAP and WHOIS

Our domain age checker answers a question that sounds simple: when was this domain registered?

The calculation is easy once we have a trustworthy creation date. Getting that date is the difficult part. There is no single database that publishes the same fields for every top-level domain (TLD), and an unsuccessful lookup can mean several different things.

This post explains the lookup path we built, the public data sources behind it, and why domains under extensions such as .de and .bg still cannot return an exact age.

What domain age means

The checker measures the age of the current domain registration from the creation date published by its registry or registrar. It does not determine when the website launched.

Those dates can differ. A domain may sit unused for years before a website appears. It may also expire and get registered again, which means an older historical website does not prove that the current registration is equally old.

We therefore use registration data only. We do not estimate age from DNS records, TLS certificates, search results, copyright notices, or web archives.

The data sources

The lookup uses four public sources, each for a specific job.

The IANA root-zone TLD list

The IANA TLD list is the current list of delegated top-level domains. We use it in our coverage audit instead of maintaining a hand-written list of extensions.

At the time of our August 2026 audit, the list contained 1,438 TLDs. This count changes as IANA adds or removes delegations, so it is a snapshot rather than a permanent support number.

The IANA RDAP bootstrap registry

RDAP, or Registration Data Access Protocol, is the structured successor to traditional WHOIS. The IANA RDAP bootstrap file maps TLDs to their authoritative RDAP services.

Our audit found:

• 1,438 TLDs in the IANA root list
• 1,200 TLDs advertised in the RDAP bootstrap
• 238 TLDs without an advertised RDAP service

The checker sends its primary lookup through rdap.org. That service reads the IANA bootstrap data and redirects the request to the correct authoritative registry endpoint. A successful RDAP response is JSON with named events such as registration, expiration, and last changed.

A simplified record looks like this:

{
  "ldhName": "EXAMPLE.COM",
  "events": [
    {
      "eventAction": "registration",
      "eventDate": "1995-08-14T04:00:00Z"
    }
  ]
}

We accept the registration event only when its timestamp is valid RFC 3339 data and is not in the future.

IANA WHOIS referrals

Not every registry has RDAP. For those TLDs, IANA may publish an official WHOIS server in the TLD's registry record.

The fallback follows IANA's documented WHOIS referral process. It first queries whois.iana.org on TCP port 43 with the TLD. If IANA returns a whois: referral, the checker queries that server for the normalized domain. During our audit, 167 of the 238 non-RDAP TLDs had an IANA WHOIS referral. The remaining 71 had no referral.

A referral means there is somewhere official to ask. It does not mean the response contains a creation date. WHOIS is plain text, and each registry chooses its own fields, date formats, query rules, and rate limits.

Official registry responses

The final source is always the registry named by RDAP or IANA. For the TLDs that prompted this work, those sources were:

• .ch: SWITCH at whois.nic.ch
• .de: DENIC at whois.denic.de
• .bg: Register.BG at whois.register.bg

We deliberately avoided unofficial WHOIS aggregators and did not scrape registry websites. That keeps the result tied to a public machine-readable source and avoids turning a page layout into an API contract.

Why an RDAP 404 is ambiguous

The original checker treated every rdap.org 404 as "domain not found." That was wrong for TLDs without RDAP.

For a registered .ch, .de, or .bg domain, RDAP.org returned a 404 response titled:

No RDAP service is available for this resource

That message says RDAP has no service for the TLD. It says nothing about whether the domain is registered.

The corrected state machine is:

RDAP success
  -> parse the published registration date
 
Authoritative RDAP says domain not found
  -> report domain_not_found
 
RDAP says no service exists for this TLD
  -> ask IANA for an official WHOIS referral
 
WHOIS record has an exact creation date
  -> parse and return it
 
WHOIS record exists without an exact creation date
  -> report creation_date_unavailable

That distinction also matters during cleanup. A missing date is incomplete registry data, not evidence that a registered domain disappeared. Only an authoritative domain_not_found response can remove a stored domain check.

Making the WHOIS fallback safe

WHOIS requires raw outbound TCP connections, so the fallback has a narrower security boundary than an ordinary HTTPS request.

The checker applies these controls before opening a registry connection:

1. Normalize the input to one registrable domain.
2. Send only the ASCII domain or TLD, never the original user input.
3. Accept a WHOIS hostname only from the anchored whois: field in IANA's response.
4. Reject schemes, ports, paths, credentials, IP literals, whitespace, and invalid host labels.
5. Resolve the hostname once and reject the complete answer if any address is private, local, link-local, reserved, or documentation space.
6. Connect to the validated IP address instead of resolving the hostname again. This closes the DNS-rebinding gap between validation and use.
7. Enforce an absolute timeout and a response-size limit.
8. Keep registry lookups inside the existing concurrency and per-client rate limits.

The IANA referral cache is bounded and short-lived. Positive referrals are cached for 24 hours, while a missing referral is retried sooner. Registry IP addresses are not cached because they must be resolved and checked again for each connection.

Parsing WHOIS without inventing dates

WHOIS has no universal response schema. Common creation fields include Creation Date, Registered, and First registration date. Some registries use a separate line for the value, while JPRS uses bracketed fields and an English-query suffix.

We accept only recognized creation labels and unambiguous date formats. We reject:

• invalid calendar dates such as 2023-02-29
• dates in the future
• locale-ambiguous dates such as 01/02/2020
• ranges and qualified values such as before 1996-01-01
• update or expiration dates presented without a creation date

That last qualified value is real. SWITCH can return it for older .ch registrations. JavaScript's permissive Date.parse() can turn that phrase into a precise timestamp even though the registry supplied only an upper bound. The checker rejects it instead.

An unavailable result is better than a confident but false age.

Why some TLDs work and others do not

We verified RDAP results for .com, .org, .net, and .uk.

We also verified exact creation dates through the WHOIS fallback for .be, .ch, .co, .dk, .io, .it, .jp, .li, .ru, and .se.

The important cases that do not return an exact age are:

.ch: supported, with a caveat

SWITCH publishes First registration date, so ordinary .ch domains now work. If SWITCH returns a qualified value such as before 1996-01-01, the checker reports that an exact date is unavailable.

.de: no exact date in the machine-readable record

DENIC's port-43 WHOIS and RDAP service publish domain status and last-change information, but not the exact creation date needed for this calculation. A web page may expose additional information, but we do not scrape it or treat a layout-dependent page as a stable data API.

The checker therefore reports creation_date_unavailable for .de instead of claiming the domain does not exist.

.bg: registration status without creation date

Register.BG's official WHOIS service tells us whether a domain is active and includes nameserver and DNSSEC information. It does not publish a creation date.

Again, the correct result is creation_date_unavailable.

Other limitations

An exact age may also be unavailable when:

• the TLD has neither RDAP nor an IANA WHOIS referral
• the official WHOIS service blocks or rate-limits the request
• outbound TCP port 43 is unavailable from the application host
• the registry publishes a record but omits its creation date
• the date is qualified, ambiguous, malformed, or conflicts with another creation field

Registry support changes. The checker uses current IANA referrals rather than freezing a permanent TLD table, and we keep a manual audit command for checking the latest coverage against IANA's source files.

Try the checker

Use the free domain age checker to inspect a domain's published registration date, age, registrar, nameservers, and DNSSEC status. If the registry does not publish enough data, the result will say so instead of guessing.