Notes

How to pick a domain name without getting burned

Published 2026-10-06 · 6 min read

Choosing a domain name feels like a creative task, and it is, but the part that costs people money is not the creativity. It is two quiet checks that most registrar search boxes do not make clear: whether the name is actually free, and what it costs in year two. This guide covers both, based on a naming search that checked well over a hundred candidates before one survived. Where something is my own opinion rather than a fact, it is marked as such.

Decide the rules before you search

A naming search without rules can turn into endless browsing. Write down two or three constraints first. Mine were simple: the name had to be pronounceable the first time someone reads it aloud, it could not contain a person's name, and it had to work as the root for several separate products. The last two matter more than they might seem. A name tied to one individual cannot easily be handed off, sold or shared, and a name tied to one product becomes awkward the day a second product appears. Opinion: neutral names age better than descriptive ones.

Expect the good words to be gone

The first choice in that search was a single English word, and it was already registered by someone using it for something unrelated. Expanding the search to compounds, synonyms, short invented syllables and a few words from other languages did not change the picture much. Of the candidates that were real, ordinary English words, close to 95% already had an owner on the common top-level domains. That figure comes from one search of a little over a hundred names, not a survey, so treat it as an illustration of scale rather than a statistic about the internet. The practical lesson is to allow time for a long list and be ready to invent a word instead of finding one.

The lookup that says "free" when it is not

At one point, a candidate looked like a genuine find. An ordinary DNS lookup returned nothing at all: no address record, no nameservers, nothing resolving. That is exactly what an unregistered domain looks like from the outside. It is also exactly what a registered domain with no nameservers configured looks like. The domain had an owner; it simply had not been pointed anywhere. A plain DNS query cannot tell those two cases apart, and looking harder with the same tool does not help.

The tool that can tell them apart is RDAP, the Registration Data Access Protocol. Instead of asking the DNS chain whether a name resolves, it asks the registry whether the name is registered. For a .com domain, you can query the registry's service directly, and for other extensions, a general entry point forwards you to the right registry:

# .com: ask the Verisign registry directly
curl -s https://rdap.verisign.com/com/v1/domain/example.com

# other extensions: rdap.org redirects to the right registry
curl -sL https://rdap.org/domain/example.dev

A registered name returns a record with status and dates. A name that is not registered returns a "not found" response (HTTP 404). Treat RDAP as the first check and DNS as the second, never the other way round. A registrar's own availability box is usually reliable, too, but it is worth confirming a promising name with RDAP before you fall in love with it.

A short checklist for each candidate

Check RDAP for the extension you want, and for the two or three nearest alternatives you would be unhappy to see someone else own.
Say the name out loud and read it as a URL. If it needs spelling every time, it will cost you visitors.
Search the name as a phrase. A string that is technically available can already mean something unrelated and distracting in a results page.
Check the renewal price, not the first-year price (next section).

The renewal-price trap

Some newer extensions advertise a first-year price that looks almost like a typo. In my search, .online and .site domains could be had for roughly 50 to 70 Thai baht in the first year. The renewal price in the following years was around $28.84 per year, several times what a .com typically renews for. A domain is a recurring cost, so the number that matters is the one you will pay every year after the introductory offer ends. Opinion: unless you have a specific reason for another extension, .com is still the one people type without thinking, and that is worth more than a cheaper sticker price.

One domain, many products: use subdomains

If you plan to build more than one product, consider a single root domain with one subdomain per product, named after the product (for example product.example.com). It means one registration instead of several, and one domain that builds a track record over years instead of scattering that history across several barely used ones. A Google AdSense account is also reviewed at the root domain, and approval there covers the subdomains beneath it. The flip side is that reputation is shared as well: an unfinished or low-quality subdomain can affect how the whole domain is perceived, so a product should not get a public subdomain until its known bugs are fixed.

Pointing a subdomain at your host

On Firebase Hosting, each product is a separate Hosting site, and a subdomain points to it with a CNAME record: type CNAME, name product, value site-id.web.app. The trap is assuming the value is always the product name plus .web.app. Hosting site ids are global and first-come, first-served across every project in the world. In this workshop, the id altclock was already taken by someone else, so the real site is altclock-crafnia, and the CNAME for altclock.crafnia.com points to altclock-crafnia.web.app. Check the real site id in the console before you create the record.

Two more things can cost real time. First, in the advanced record editor of the DNS provider used here, changing the record type of a row you are editing immediately clears the name, TTL and value fields, with no error. Pick the type first, then fill in the rest. Second, after you add a record, Hosting's verification screen can keep saying "Records not yet detected" for up to an hour even when the record is correct.

Propagating, or never saved?

That one-hour delay comes from negative caching. A resolver that asked for the record before it existed was told "nothing here", and it remembers that empty answer for as long as the zone's SOA minimum TTL says. On the nameservers used here, that value is 3600 seconds, so the stale miss can survive for an hour no matter how often you press Verify.

You can tell "not propagated yet" from "never saved" by skipping every cache and asking the domain's own authoritative nameserver directly:

nslookup -type=CNAME product.example.com ns1.your-dns-provider.example

If the authoritative server has no answer, the record was not saved: a typo in the subdomain, the wrong zone, or a save that did not take. Go back to the DNS panel. If it answers correctly, the record is fine and the lingering message is just the negative cache running out. Waiting an hour is a sensible response only in the second case.

Summary

Write your rules first, expect most good words to be gone, confirm availability with RDAP rather than DNS, compare renewal prices instead of introductory ones, and give each product its own subdomain once it is ready. Most of the pain in domain setup comes from trusting a tool that cannot see the thing you are asking about, so when a result looks too good, ask a second source.