A domain you own is not yet a domain that works. The records you need, the order to create them in, and the two settings that take a site offline when they are done at the wrong moment.
The transfer completes on a Tuesday afternoon and the name is yours. You type it into a browser out of habit and get a registrar parking page, a certificate warning, or nothing at all. Nobody warns you about this part: owning a domain and having a working domain are two different jobs, and the second one is a handful of records that take twenty minutes if you know which, and a week of confused emails if you do not. What follows is the short version, in the order to do it.
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.
# Order of operations
#
# 1. records at the new DNS host A / CNAME / MX / TXT
# 2. confirm they answer dig @ns1.newhost.example example.com
# 3. nameservers at the registrar NS -> ns1.newhost.example
# 4. certificate once the name resolves, not before
# 5. DNSSEC last, and never during a move
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.
The rest of the portfolio
The names in these examples are real ones from the portfolio: 867 domains across 73 extensions, none of them parked behind ads, all held in a single account. The full list is on the home page with its filters, and every entry shows the two dates this article keeps referring to.
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.
Looking for a name?
All 867 domains are on one page, filterable by extension, category and length, with the registration and expiry dates printed on every entry. No login, no price gate, and one address to ask at.
