Iterating on a Domain Checker: Adding Timestamps, Sources, and IANA Bootstrap

A few days ago, I wrote a post about how I built a bulk domain availability checker using PHP and RDAP (instead of the traditional WHOIS protocol) over at Site Tools Box.

To my surprise, the post got some fantastic technical feedback from the community. One comment from a developer named Furqan completely nailed some of the pain points I was already struggling with in production.

Here are the three brilliant suggestions he made, and how I'm currently implementing them to make the tool more reliable.

1. The "Premium Domain" Illusion: Why a 404 is Just a Hint

In my previous post, I mentioned that querying RDAP returns a 404 Not Found if a domain is available, and 200 OK if it's registered.

The problem? Premium and reserved domains. Sometimes, a registry will return a 404 because it's technically unregistered, but it's actually a premium name that requires a 5-figure price tag at the registrar.

Furqan's suggestion: Flag 404s as "Likely Available" instead of a hard "Yes".

This is a brilliant UX change. I'm now updating the frontend to display a "Likely Available" badge with a tooltip explaining that premium domains can sometimes show as available but are locked behind a premium price wall.

2. Transparency: Adding "Last Checked" Timestamps and Sources

Right now, when you check a domain on Site Tools Box, you get the result, but you don't know when it was checked or where the data came from.

Furqan suggested adding a "last checked" timestamp and the source (RDAP vs. WHOIS).

This is crucial for debugging. When doing bulk checks of 100+ domains, network timeouts happen. By displaying the exact timestamp and the specific RDAP server endpoint used (e.g., rdap.verisign.com), users can immediately tell if a result is stale or if the query failed.

3. Ditching the Hardcoded Map for IANA Bootstrap

In my original PHP code, I had a massive switch statement and array mapping TLDs to their respective RDAP servers (e.g., .com -> Verisign, .io -> Identity Digital).

Furqan pointed out the obvious scaling issue: This hardcoded map is a nightmare to maintain. What happens when a new TLD like .xyz or .ai changes its registry?

His solution: Use IANA's Bootstrap file.

IANA provides a public JSON file (https://data.iana.org/rdap/dns.json) that automatically maps every TLD to its current RDAP endpoint. I'm currently rewriting my backend to fetch this file, cache it locally, and dynamically route queries. This means the tool will automatically support new TLDs without me lifting a finger.

php
// Pseudo-code for the new dynamic approach
$bootstrapUrl = 'https://data.iana.org/rdap/dns.json';
$bootstrapData = json_decode(file_get_contents($bootstrapUrl), true);

// Dynamically find the endpoint for .com
foreach ($bootstrapData['services'] as $service) {
    if (in_array('com', $service[0])) {
        $endpoint = $service[1][0];
        break;
    }
}



The Takeaway: Build in Public, Iterate Fast
This whole experience has been a masterclass in building in public. The feedback from the dev community is invaluable. What you think is a solid MVP might have fatal edge cases in the real world.

If you want to see the updated tool (and test the new features as they roll out), you can check it out here: Free Domain Availability Checker.

Have you ever built a tool that had to handle messy edge cases like premium domains or dynamic TLD routing? Let me know in the comments!