That is not bad luck, it is arithmetic. Somewhere around 360 million domain names are registered across all extensions, and only a fraction of them carry a working site. The short ones went in the first decade. What is left unregistered is what nobody wanted, which is why a search box hands you worse options the longer you sit with it.

The names worth having are not unregistered. They are registered and idle, and the way to get one is not a search box, it is asking whoever holds it. What follows is why the register looks like this, what a whois record tells you before you make contact, and what actually happens between agreeing a price and the name pointing at your server. None of it is complicated. It is only unfamiliar, because most people do it once.

Why the good ones are gone

A domain is not stock on a shelf. It is a renewable lease on a string, and nobody has to justify holding one. Keeping an ordinary name costs about as much a year as lunch, so the cheapest thing to do with one you might use someday is nothing at all. Millions of people have made that decision, one name at a time, for thirty years.

The result is a register full of names that are neither for sale nor in use. A search box cannot tell the difference between a name behind a live business and a name someone bought in 2011 and forgot about. Both come back taken. The second kind is most of them, and it is the only kind worth chasing.

None of this is a secret. Verisign’s quarterly brief counts the register every three months, and the total keeps climbing while the share of names attached to a real site does not. .com passed a hundred and fifty million a long time ago, and the extensions added since have absorbed the overflow rather than relieved it. ICANN’s transfer policy is the other half of the picture: it is what makes a registered name transferable at all, which is why an idle domain is an asset rather than a dead end. The expired registration recovery policy covers the case people count on and should not. A name that lapses does not become available the next morning. It goes through a renewal grace period, then redemption, then a short pending-delete window, and by the time it is genuinely free a drop-catching service has usually taken it. Waiting for a good name to expire is not a plan, it is a queue, and you are at the back of it.

What a registrar search does not tell you

A whois record is the public half of a registration, and it answers what a search box will not: when the name was first registered, when it expires, which registrar holds it, and whether it is locked. Registrant contact details are mostly redacted now, so you often get a relay form instead of an address, but the dates and the status codes are always there, and those are the parts that matter. ICANN’s EPP status codes list what each of those codes means, and every accredited registrar answers to the same set.

A record for one of the names in this portfolio reads like this:

# Index

> Freelance creative frontend engineer based in Vienna, working
> worldwide on animation-heavy, interaction-rich sites on headless
> CMS stacks (Next.js, TypeScript, Sanity, Tailwind, Motion,
> Vercel). Shipped work for Buck, Disney, Porsche, Red Bull, and
> Getty. Awwwards juror and Codrops contributor.

## Core pages

- [Index](https://unusedomain.com/): Role, stack, selected
  work, and the primary way to get in touch.
- [Works](https://unusedomain.com/works): Portfolio index of
  production client projects.
- [Lab](https://unusedomain.com/lab): Interaction experiments
  in motion, scroll, and novel UI.
- [Blog](https://unusedomain.com/blog): Writing, including
  deep dives on content architecture.

## Articles

- [UnUse Domain I: CMS Structure](https://unusedomain.com/blog/the-content-architecture-cms-structure):
  How to structure a CMS for long-term maintainability.
- [UnUse Domain II: Content Models](https://unusedomain.com/blog/the-content-architecture-content-models):
  Designing schemas that match real content.
- [UnUse Domain III: Page Composition](https://unusedomain.com/blog/the-content-architecture-page-composition):
  Assembling pages from reusable sections.
- [UnUse Domain IV: Content Primitives](https://unusedomain.com/blog/the-content-architecture-content-primitives):
  Low-level building blocks for flexible pages.

## Optional

- For a quick hiring decision: Index, Works, a recent case study,
  and UnUse Domain series. To start a project, use the
  contact path on the Index page.

Two lines do most of the work. The creation date tells you whether a name survived the years when short strings were still there for the taking, and one first registered in the nineties has a history nobody can manufacture. The expiry date tells you whether it is being held deliberately or quietly let go. A record sitting in redemptionPeriod is not for sale, it is already gone, and the person who let it lapse is usually the last one who can help you.

Status codes are the other half. A name a registrar has marked clientTransferProhibited is locked, which is normal and reversible: the holder unlocks it once a transfer is agreed. A name showing pendingDelete is on its way out of the register and cannot be bought from anyone, at any price, until it has dropped. Two lines of a free lookup save you the email.

None of this needs a broker. Every accredited registrar publishes the same fields, the lookup costs nothing, and it takes ten seconds. Doing it first changes the message you send: instead of asking whether a name is available, you are asking about a name you already know is held, renewed, and transferable.

There is one thing the record will not tell you, and it is the one that decides everything: whether the holder will sell. A name registered in 2004 and pointing nowhere is a good sign and nothing more. The only way to find out is to ask, which is why every entry in this portfolio prints its whois dates beside a contact link. The dates are the argument. Ask before you assume is the whole method, and it works far more often than people expect.

That is what the list on this site is for. Every name carries its category, its extension, its length and both of its dates, so 867 of them narrow down to the handful worth writing about without opening a lookup tool once.

How a name actually changes hands

A transfer between two people who have agreed a price is a short, boring procedure, and knowing its shape removes most of the anxiety. The holder unlocks the name at their registrar and hands over an authorisation code. You start a transfer at your own registrar with that code. Both sides confirm, and the name moves. Money and code usually cross through an escrow service, which is the part worth paying for.

The registrar shows the state of all this in the Domain Status field. A name mid-move reads pendingDelete only when it is on its way out; a healthy transfer reads pendingTransfer instead, and clears in five days unless someone cancels it. The code itself is a per-domain password, an authCode, sometimes called an EPP code or a transfer secret. It proves the holder agreed, and it is the only thing that can move a name between registrars. Everything else in a whois record is there so you can check the story before you get that far.

One rule catches people out more than any other. A domain that has changed registrar, or changed registrant, inside the last sixty days cannot be transferred again: registrars apply a sixty-day lock after either event, and no amount of asking removes it. It is a fraud control, not an obstruction. If a name you want moved recently, the answer is a date, not a refusal, and the seller can usually tell you exactly when the window opens.

The alternative to a registrar transfer is a change of account inside the same registrar, which is instant and free. If the seller happens to use the registrar you already use, the whole procedure collapses into a push between two accounts and the name is yours the same afternoon. This is why the first question in a serious enquiry is not the price. It is which registrar the name sits at, and what the Domain Status line currently says.

The part that surprises people

Choosing between two available names feels like a taste question. It is mostly a mechanical one, and the mechanical part is what still matters in five years when the taste has worn off.

The naive version is to pick whatever sounds clever today. It works until you say it out loud on a call, spell it twice, and watch the other person type it wrong anyway. Every character you have to explain is a character you will explain for as long as the name is in use.

The version that holds is boring and checkable. Read it aloud once and see whether it survives a phone call. Count the characters. Check what the record says under Creation Date, because age is the one property nobody can add later. Check Registry Expiry Date to see it is being renewed rather than abandoned. Check the Registrar line so you know who you will be dealing with. Four fields, all public, all free, and between them they answer most of what people pay consultants to guess at.

The line most buyers never reach is the one about extension. A name is read before it is typed, and the extension is read as a signal: .com as the default, a country code as a place, everything newer as a deliberate choice you will be asked about. None of those is wrong. Picking one without noticing which signal you are sending is what goes wrong, and it is the cheapest mistake to avoid, because it costs a minute of thought and nothing else.

It looks inconsistent that a portfolio holding names across 73 extensions would say that. It is not. A .com is the safe read, and it is also the most expensive and the most picked over, which is exactly why a three-character .cn or a plain English word on .org is worth a look. The point is not that one extension wins. The point is to choose it on purpose, once, and never think about it again.

What the two dates are worth

Age is the closest thing a domain has to provenance. A name first registered in 1998 has been paid for, every year, by someone, for nearly thirty years. That is not a guarantee of anything, but it is a record, and it is the only part of a name that cannot be bought forward. A .com registered last Tuesday and one registered in 1998 look identical in a browser and are not remotely the same asset. The second one has survived every clear-out, every renewal decision, and every price rise since dial-up. Which is why the second question, after the authCode logistics, is always the creation date. Two hundred and seventeen names in this portfolio predate 2010 and the oldest goes back to August 1996.

The expiry date is the quieter one and it answers a different question: is this name being kept, or is it drifting? A registration renewed years ahead is someone who intends to hold it. One expiring in six weeks is either about to be renewed or about to be lost, and either way it tells you how much time the conversation has. Both dates are printed on every card in the list for exactly that reason.

Why a shortlist beats a search box

A search box answers one question, over and over: is this exact string free right now? It is the least useful question you can ask, because the answer is almost always no, and a no tells you nothing about whether the name is gettable. You end up optimising for availability instead of for the name, which is how projects end up with three consonants missing.

A list works the other way round. Everything on it is already registered, so availability stops being the filter and the actual questions move to the front: how long is it, how does it read out loud, what extension is it on, how old is it. Nothing here is going to lapse into redemptionPeriod while you think about it, and nothing here is going to be gone tomorrow because a drop-catcher was faster. The work is choosing, which is the only part that ever deserved your attention.

That is the whole idea behind publishing the portfolio as one page rather than a set of listings. In UnUse Domain, every name is on the same screen with its category, its length, its extension and its dates, and the filters exist so you can throw away 800 of them in four clicks. A .com under four characters, an English word on .org, a pinyin name registered before 2010: each of those is a single filter combination away, and what is left is short enough to read.

All 867 are on this page, with no login and no price gate.

Common questions

Can I buy a domain that is already registered?

Usually, yes. Most registered domains are not in use, and their holders are reachable through the registrar’s relay form or a contact address on the record. There is no obligation on anyone to sell, and no fixed price, so the first message is an enquiry rather than an offer. What makes it work is knowing before you write that the name is held, renewed and unlocked, which the public record tells you for free.

What happens if I wait for a domain to expire?

Almost always, someone faster gets it. An expired name is not released the next morning: it spends about forty days in a renewal grace period the holder can still use, then thirty days in redemptionPeriod where only they can recover it, then five days pending delete. Drop-catching services queue for the moment it is released and file requests in bulk. If a name is good enough for you to wait for, it is good enough for them to catch.

How long does a domain transfer take?

Between five minutes and five days. A push between two accounts at the same registrar is immediate. A transfer between registrars needs the holder to unlock the name and give you the authCode, and then runs on a five-day clock the losing registrar can shorten by approving early. The one thing that cannot be hurried is the sixty-day lock after a recent transfer or registrant change, which shows on the record as clientTransferProhibited and simply has to run out. Ask which registrar the name is at before anything else; it decides which of these you are in for.

Two places, not one

There are two separate places a domain is configured, and confusing them is the most common reason a new name does not resolve. The registrar is where the registration lives and where you say which nameservers are authoritative. The DNS host is where the records live: what the name points at, where its mail goes, what each subdomain does. Very often one company is both, which is exactly why people assume there is only one place.

• The registrar, which holds the registration and the NS records that delegate the name. Change these and you have changed which service answers questions about the domain, without touching a single record inside it.
• The DNS host, which answers with the A record a browser needs and the TXT records other services read to check you own the name. Move the delegation and every one of these has to exist at the new host too, or the domain goes dark.

Once you know there are two, debugging stops being guesswork. You ask which of them is wrong, not whether the domain is broken. Nearly every new-domain problem is a delegation pointing at the wrong nameservers, or the right nameservers with a record missing.

Ask the domain what it is doing

Before changing anything, ask. Run dig +trace example.com and, when you want the short answer, plain dig. Both walk the chain from the root servers down and print who answered at each step, which tells you in one command whether the delegation is right and a record is missing, or the delegation itself still points at a service you stopped paying for two years ago.

When the records look right and the browser still disagrees, the answer is almost always time. A resolver that cached the old answer keeps serving it until that answer expires, and nothing you do at the registrar makes it expire faster. Change it, wait, then check again from a network you have not used yet.

Two checks are worth memorising. dig NS example.com +short prints the nameservers the world currently believes in, and whois example.com prints the ones the registry has on file. When those two disagree, a delegation change is still spreading, and the answer is to wait rather than to change something else.

Delegation is the first decision

Leave the name on ns1.registrar.example and the registrar answers for it. For a name you are holding, or one that only ever redirects somewhere, that is fine and it is one fewer account to manage. The trouble starts when a site, a mail provider and a certificate all want records, and the registrar panel turns out to support three record types and no API.

The usual fix is to delegate to a dedicated DNS host and point the site there with a CNAME. Do it in this order: create every record at the new host, confirm it answers, and only then change the nameservers at the registrar. Reverse those two steps and the domain is down for as long as it takes you to retype the records. At the apex, where a CNAME is not allowed, hosts offer an ALIAS or flattened equivalent, and that is what you want rather than a hardcoded address that will change without telling you.

One more thing about delegation: the NS records live at the registry rather than at your DNS host, so changing them is a registrar action and it is the slowest step in any move. Records inside the zone update in minutes; a delegation can take hours to be believed everywhere.

Time to live is not a detail

TTL 300 tells resolvers they may keep an answer for five minutes. That is what you want in the day either side of a change, because a mistake then corrects itself almost immediately. It costs more queries, which matters to nobody at the scale of an ordinary site.TTL 86400 is a day, which is a sensible steady state and a nightmare mid-migration: every resolver that read the old answer holds it for that long, and you cannot reach into their caches. TTL is the only knob here, and most people meet it on the day it hurts. Drop it the day before, make the change, watch it settle, put it back up.

The records you will actually need

Most domains need four or five records and no more. Start with the apex, written @ in most panels, and www beside it, so both forms of the address reach the same place.

After that it is mail and proof. An MX record if the domain receives mail and none at all if it does not, a TXT record for whatever service wants to verify ownership, and, if anything sends mail as this domain, TTL values low enough that a mistake is recoverable. Sending also needs SPF to list which servers may send, DKIM to sign what they send, and DMARC to say what a receiver should do when a message fails both. Skip those three and your mail lands in spam, which is the complaint that always arrives a week later.

// Invalidation flow
//
// Publish -> GROQ webhook -> POST /api/revalidate -> revalidateTag(tag)
//   -> Next.js Data Cache drops the tag -> next request MISS
//   -> Sanity live API (useCdn: false) -> fresh page

That is the whole set for most names. Everything beyond it is a subdomain for something specific, and subdomains are cheap: one record each, no registration, no renewal, no approval from anybody.

Certificates and the locks nobody mentions

A working address is not the same as a trusted one. The certificate that turns the address green is issued by an authority that checks you control the name, usually by looking for a record you were asked to add, and that check runs against the same DNS you just changed. Get the order wrong and the certificate fails for reasons that have nothing to do with your host. Two records govern the rest, and the first is CAA, which names the authorities allowed to issue for this domain and, with issuewild, whether wildcards are allowed at all.

The other one is quieter. Every zone carries a start-of-authority record whose serial number changes each time you edit the zone, and comparing that number across nameservers is the fastest way to see whether an edit reached all of them. The field is called serial, it lives in the SOA record, and a PTR record is the one you will not need unless you are running your own mail server, in which case your host sets it, not you. Reading the serial takes one command and settles most arguments about whether a change has landed, which is the same job the NS check does one level up.

Redirects are the last piece and the one most often done wrong. If the domain is an alternative spelling, or a shorter version of a name you already use, it should send visitors on with a 301 Moved Permanently, which browsers and search engines both cache and treat as final. A 308 does the same while preserving the request method, which matters for anything but a plain page view. What you should not do is frame the real site inside the new domain: it looks like it works, and it breaks links, analytics and search results all at once.

The apex and the subdomain are different problems

A surprising amount of DNS confusion comes from treating these as one thing. The bare name, the apex, cannot hold a subdomain-style alias in the standard, which is why hosts invented flattened records; a subdomain can point anywhere with a plain CNAME and no special handling. Decide early which form is canonical, send the other one there with a redirect, and never let both serve the same content. Everything downstream, from certificates to analytics to whatever you put in an email signature, is easier once that decision exists and is written down. Use a subdomain for staging and keep it out of search with a header rather than a robots file, and the whole MX and certificate story stays simple.

Is DNSSEC worth switching on

Most registrars now offer a one-click DNSSEC toggle, which publishes a DS record at the registry so resolvers can verify that the answers they get about your domain were not tampered with. It is a genuine improvement and, for a name that will hold mail or logins, worth having.

It is also the one setting that can take a domain offline by itself. Because a DS record commits resolvers to verifying every answer, a signing key that expires or a zone that moves to a new host without the keys moving with it makes the whole domain fail closed: not slow, not partly broken, simply gone for anyone whose resolver validates. The rule is to turn it on after the domain is settled, never during a migration, and to turn it off at the registry before moving hosts and back on afterwards. Leaving a stale DS behind is the single most common way a competent person takes their own site down for a day.

The part nobody warns you about

None of this is difficult and all of it is unfamiliar, which is a bad combination on the day a name finally becomes yours. The order is the whole trick: records first, delegation second, certificate third, DNSSEC last and only once nothing is moving. Do it in that sequence and the domain is live in an afternoon. Do it in any other order and you spend a week waiting for caches you cannot see.

It is also the part nobody quotes for, because it takes twenty minutes when it goes well. Buying the name from UnUse Domain is the short half; the records are the half that decides whether anyone can reach it. The set above covers NS delegation, the apex, mail, proof of ownership and redirects, which is every domain most people will ever configure. For the half before this one, the piece on buying a name that is already taken covers how a name gets to you in the first place.

Common questions

Why does my new domain not work yet?

Two places have to agree: the registrar, which says which nameservers are authoritative, and the DNS host, which holds the records. A name with the wrong delegation has nowhere to ask; a name with the right delegation and no A record has nothing to answer. Check the delegation first, then the records, and expect a delay measured in hours rather than minutes after any nameserver change.

Why does the domain work on my phone but not my laptop?

Because they use different resolvers, and one of them still has the old answer cached. Mobile networks and home routers cache independently, and neither can be flushed from your side. This is normal and it resolves itself once the previous record expires, which is why lowering the time-to-live before a change is worth the two minutes it takes.

Should NS point at my registrar or at a DNS host?

At the registrar for a name you are only holding or redirecting, and at a dedicated DNS host for anything with a site, mail and a certificate. The dedicated host gives you every record type, sensible time-to-live control and an API; the registrar gives you one fewer account. Whichever you pick, create the records first and change the delegation second.

How do I check a DNS change has propagated?

Query the nameservers directly rather than trusting your browser. Ask each authoritative server for the record and compare the answers, or read the zone serial with DMARC and the rest of the records checked the same way, for example dig TXT example.com, from a network whose resolver has not seen the old value.

Is DNSSEC worth switching on?

Yes, once the domain is settled. It stops answers about your domain being forged, and the cost is that a DS record left behind after a host change takes the whole domain offline for validating resolvers. Turn it on after everything else works, and turn it off at the registry before you move nameservers again.

Do I need a CAA record?

Not strictly, but it is cheap insurance. A CAA record names the certificate authorities allowed to issue for your domain, so an authority that is not on the list refuses the request. Add it after your certificate is working, list the authority you actually use, and remember to update it if you change providers or add a CNAME for a service that issues its own.