Short answer. A domain is the human-readable address of a site: example.com instead of a numeric 203.0.113.10. Technically it is a node in the DNS tree that a specific owner controls. You never buy a domain outright — you lease the name in a chosen zone and renew it. Domain and hosting are two separate services: the name, and the place your site lives.
What is a domain in simple terms
Computers reach each other by IP address — a numeric identifier such as 203.0.113.10 or 2001:db8::10. Those are hard to remember, and they change whenever you move to another server. A domain solves both problems: it is a stable name you can repoint to a new IP address at any time without changing the sign on the door.
Three clarifications remove most of the confusion:
- A domain does not live on a server. It is a record in a zone registry plus a delegation to DNS servers. The site files live somewhere else entirely, on hosting.
- A domain is not a website. A domain can stay registered for years and lead nowhere: no site, no mail, no records at all.
- A domain is not a URL. A URL includes the scheme, the domain, a port, a path and parameters. The domain is only one part of it.
https://blog.example.com:443/articles/dns?utm=1#top
|_____| |______________| |_| |___________| |___| |_|
scheme domain port path query fragmentIn everyday speech "domain" and "website" get used interchangeably, and in casual conversation that is harmless. The moment you start configuring things — migrating hosting, connecting mail, issuing a certificate — the distinction matters, because otherwise you cannot tell which layer actually broke.
Domain vs domain name: what is the difference
Strictly speaking, a domain name is the string itself (example.com), while a domain is the region of the namespace behind that string: the name plus everything below it (www.example.com, mail.example.com, and so on). In practice the two words are used as synonyms, and that is fine.
The full written form is called an FQDN — a fully qualified domain name. It ends with a dot representing the root: www.example.com. Browsers let you omit the dot, but in DNS zone files it is significant — without it, the name is completed relative to the current zone.
Technical limits on a name
- Each label (the part between dots) is at most 63 octets; the whole name is at most 255 octets (RFC 1035).
- The classic character set is letters, digits and the hyphen. A hyphen cannot be the first or last character of a label.
- Case is irrelevant:
Example.COMandexample.comare the same name. - Non-ASCII scripts are supported through IDN: the name is converted to an ASCII form prefixed with
xn--using the Punycode algorithm (RFC 3492).
# Convert an internationalised name to its ASCII form, no extra packages
python3 -c "print('münchen.de'.encode('idna').decode())"
# xn--mnchen-3ya.de
# And back again
python3 -c "print(b'xn--mnchen-3ya.de'.decode('idna'))"
# münchen.deEvery technical tool — DNS queries, whois, web server logs, certificate fields — works with the ASCII form. If you search for an internationalised domain and find nothing, convert it to its xn-- form first and repeat the query.
What is a website domain and how it resolves to an IP address
When you type an address into a browser, the name travels through a four-link chain. Understanding that chain is half the skill of diagnosing domain problems.
- The stub resolver in the operating system checks its own cache and the
hostsfile. - A recursive resolver — your ISP's, your router's or a public one — does the actual lookup work and caches the answer.
- The root servers say who is responsible for the top-level zone, for example
com. - The zone servers return the NS servers of your domain, and those finally return the A or AAAA record.
# Show the whole delegation chain starting from the root
dig +trace example.com
# Which servers are authoritative for the domain
dig +short NS example.com
# Ask an authoritative server directly, bypassing resolver caches
dig +short A example.com @$(dig +short NS example.com | head -1)
# The final addresses
dig +short example.com A
dig +short example.com AAAAEvery step caches its answer for the duration given in the record's TTL. That is the source of the most common misunderstanding: a DNS change does not "spread across the internet" — it simply evicts stale answers from caches gradually, each resolver on its own schedule.
"DNS propagation" is a misleading term. Nothing is being broadcast. A resolver keeps serving the old value until the TTL it received with the record expires. That is why you lower the TTL in advance, a day before a migration, and raise it back afterwards.
A breakdown of individual record types — A, AAAA, CNAME, MX, TXT, NS, SOA, CAA — lives in a separate piece: the guide to DNS records. Here it is enough to remember that a CNAME cannot sit at the apex of a domain, because NS and SOA records are already required there. Providers work around this with non-standard types such as ALIAS or ANAME, but that is a feature of a particular DNS host, not a standard.
Domain levels: top-level, second-level and subdomains
The name tree reads right to left. Every dot is a step down a level, and every level has a different party in charge.
| Level | Example in blog.example.com | Who controls it |
|---|---|---|
| Root | the trailing dot (usually omitted) | IANA / ICANN |
| First (TLD, zone) | com | The zone registry |
| Second | example | The registrant, through a registrar |
| Third and below | blog | The owner of the second-level domain, in their own DNS |
The key difference between the second and third level is not name length but who creates the name and how. A second-level domain is registered with a registrar, for money and for a fixed term. A third-level subdomain you create yourself by adding one record to your DNS zone — free, instant, and in any quantity.
# Subdomains are just records inside your own zone
blog IN A 203.0.113.10
shop IN A 203.0.113.11
api IN CNAME gateway.example.com.
* IN A 203.0.113.10 ; wildcard: catches everything elseA special case is zones where registration itself happens at the third level, such as co.uk or com.au. Formally you receive a third-level domain, but in practice it is entirely your own — a neighbour under co.uk has no relationship to it. Such "public suffixes" are catalogued in the Public Suffix List, the list browsers consult to decide which names are allowed to share cookies. Without it, any site under co.uk could set a cookie for the whole zone.
Domain zones: .com, .ru, .рф and other TLDs
The top-level zone determines whose rules you register under, what renewal costs and which restrictions apply. IANA maintains the full list of delegated zones in its Root Zone Database; there are well over a thousand of them.
| Zone type | Examples | What is specific about it |
|---|---|---|
| Country code (ccTLD) | .de, .uk, .ru | Two letters, following ISO 3166-1 country codes. Rules are set nationally; some zones require residency or a local contact |
| Classic generic (gTLD) | .com, .net, .org | Open to everyone, governed by ICANN policy, usually registrable for several years at once |
| New generic (new gTLD) | .shop, .online, .dev | Themed zones. Some carry technical requirements — .dev and .app, for instance, are on the HSTS preload list as whole zones, so they only work over HTTPS |
| Internationalised (IDN) | .рф, .中国, .みんな | Names in a national script; every technical interface shows them as xn-- |
The .рф zone appears as xn--p1ai in ASCII. It is not a mirror of .ru: the registry is separate, and example.ru and its Cyrillic counterpart are two independent domains that must be registered and renewed separately. The same logic applies to every IDN zone.
Policy for generic zones comes from ICANN, while each country code zone is governed by its national registry; actual registrations always go through an accredited registrar. How to compare registrars is covered separately in our registrar selection guide.
Check zone restrictions before you pay, not after. Some zones require proof of residency, a licence or membership in an industry, and the mismatch only surfaces at verification — once the money has already changed hands. Read the rules of the specific registry; they change over time.
Domain vs hosting: what is the difference
This is the most common beginner question, and the answer is short: the domain is the name, hosting is the place. You lease the domain from a registrar and the hosting from a provider. They are not technically coupled and can sit with completely different companies.
It is more accurate to think in terms of three or four independent services rather than two:
| Service | Responsible for | Configured in | What breaks without it |
|---|---|---|---|
| Domain registration | Rights to the name, lease term, NS delegation | Registrar account | The name stops existing — no server or DNS can help |
| DNS hosting | Answering queries for the domain: A, MX, TXT and the rest | DNS provider panel | The name exists but leads nowhere: NXDOMAIN or an empty answer |
| Website hosting | Files, code, database, TLS certificate | Hosting panel or the server itself | The name resolves but the browser gets a connection error |
| Mail service | Sending and receiving mail on the domain | MX and TXT records plus a mail panel | The site works, mail does not |
NS records are the link between them. At the registrar you declare which DNS servers are authoritative for the domain; everything else is configured inside those servers. That is why moving a site to a different host does not require moving the domain — changing an A record is enough. And conversely, switching registrars leaves the site untouched as long as the NS records stay the same. The step-by-step order of operations is in our domain transfer checklist.
DNS hosting is often bundled free with registration or with a server: registrars offer it, and so do cloud providers such as Selectel. A dedicated DNS service becomes worthwhile when you need geographically distributed servers, fast zone updates or an API for automation.
Keep the domain and the hosting in separate accounts. This is insurance, not paranoia: a dispute with a provider, a suspended account or a technical failure should never cut you off from control of the name. The domain outlives any hosting.
What is a domain in an email address
The domain in an email address is everything after the @ sign. In info@example.com the mail domain is example.com. The part before the @ is called the local part and is interpreted by the recipient's mail server.
A mail domain usually matches the website domain, but that is neither required nor automatic. Delivery depends on separate DNS records that you have to configure explicitly:
- MX — which servers accept mail for the domain. The number before the hostname is a preference value: lower means higher priority.
- SPF (a TXT record at the domain apex) — which servers are allowed to send mail on behalf of the domain.
- DKIM (a TXT record at
selector._domainkey) — the public key used to verify message signatures. - DMARC (a TXT record at
_dmarc) — what receivers should do with messages that fail SPF and DKIM.
# Where mail for the domain is delivered
dig +short MX example.com
# Sender policy
dig +short TXT example.com | grep spf1
# Policy for messages that fail authentication
dig +short TXT _dmarc.example.com
# The key for a specific DKIM selector
dig +short TXT selector1._domainkey.example.comMX records alone are not enough. A domain without SPF, DKIM and DMARC sends mail that large providers file as spam or reject outright — and it lets anyone forge your address as the sender. Configure all three from day one rather than "when there is time".
You can check a mail domain with our tools: MX Lookup shows the mail servers and their preference values, and the email domain check reads SPF, DKIM and DMARC together and highlights what is missing.
How to check a domain: WHOIS, RDAP and DNS
Checking a domain splits into three independent questions: who owns it and until when, what records it serves, and whether every resolver sees the same thing. Answer them in that order and the real cause surfaces faster.
Registration data: WHOIS and RDAP
WHOIS is an old plain-text protocol; RDAP is its modern replacement returning JSON. Both show the same facts: the registrar, the domain's status, the registration date and the paid-through date.
# Classic whois
whois example.com
# Query a country code registry directly
whois -h whois.tcinet.ru example.ru
# RDAP: the same answer in JSON, convenient for scripts
curl -sL https://rdap.org/domain/example.comIn generic zones the domain's condition is expressed as EPP status codes, and they are worth being able to read:
clientTransferProhibited transfer to another registrar is locked by the owner
clientDeleteProhibited deletion is locked — protection against accidental loss
clientUpdateProhibited changes to the domain data are locked
autoRenewPeriod auto-renewal fired, the expiry date has already moved
redemptionPeriod expired and switched off; recovery is possible but costly
pendingDelete point of no return — the name is queued for deletion
inactive no NS servers set, the domain is not delegatedCountry code registries often use their own vocabulary instead. The .ru registry, for example, answers with a state field (REGISTERED, DELEGATED) and with two dates: paid-till, the paid-through date, and free-date, when the name is released. The gap between them is the window in which the domain is already switched off but only the current holder may still renew it. Generic zones express the same idea through the status codes above.
The three client*Prohibited statuses are not an error — they are correctly configured protection. Lift them only for the duration of a transfer. A domain without those locks can be hijacked through a single compromised mailbox.
Keep in mind that registrant contact data is mostly redacted today: in generic zones because of data protection requirements, and in many country code zones by default for private individuals. Instead of contacts you will see an anonymised web form or a forwarding address. A practical walkthrough of reading these answers is in our WHOIS guide.
The records the domain serves
Next, look at what the domain actually returns. The domain lookup on enterno.io shows registration data and dates, while the DNS lookup returns A, AAAA, MX, NS, TXT, CNAME and SOA records — whatever the resolver held at the moment of the query. From a browser this is faster than assembling dig output one record type at a time.
Whether the domain looks the same everywhere
If a site opens for you after an edit but not for a colleague, resolver caching is almost always the reason. The DNS propagation check queries the domain from several resolvers at once and shows which already return the new answer and which still hold the old one. While the picture is mixed, waiting is the right strategy; editing the records again is not — it only extends the divergence.
Domain lifetime
The most expensive domain incident is not a broken record but a forgotten renewal. The expiry date deserves automated supervision: enterno.io monitoring can watch both site availability and the expiry of the domain and the TLS certificate, so the warning arrives ahead of time rather than from your users.
How to choose and register a domain name
Choosing a name is not a technical task, but mistakes made here cannot be fixed later with configuration.
- Say it out loud. If the name cannot be dictated over the phone without clarification, it will be mistyped forever.
- Avoid hyphens and homophone digits. Something like
site-4-youbecomes a guessing game in speech. - Check neighbouring zones. Even if you only buy one, it is useful to know who occupies the same name next door.
- Check trademarks. Colliding with someone else's registered mark risks losing the domain through a dispute resolution procedure, regardless of what you paid for it.
- Do not chase keywords in the name. Search engines stopped rewarding that a long time ago, while you will live with an awkward name for years.
What happens during registration
You approach a registrar — a company accredited to work with the zone you want. It submits the request to the zone registry over the EPP protocol, the registry creates the record, and from that moment the name is yours for the paid term. Generic zones typically let you pay several years ahead; many country code zones work in one-year steps.
Renewal, expiry and recovery
A domain does not vanish the instant its term ends. First it stops working while still belonging to you, and renewal is still available at the normal price. Then comes a paid recovery period, which costs considerably more. Only after that does the name become available to anyone. Exact durations are set by each registry, so check the actual dates in the domain's own WHOIS or RDAP answer rather than trusting a general article.
The administrative contact address must not sit on the same domain. Ifadmin@example.comis the only contact forexample.com, then an expiry switches off the mailbox together with the domain, and the renewal notice has nowhere to go. Use a mailbox on a different domain and turn on auto-renewal.
Frequently asked questions
Do you buy a domain permanently?
No. A domain is leased for a term and renewed. Permanent purchase does not exist in any zone: even paying for the maximum available period is a lease that will eventually end. The only reliable protection against loss is auto-renewal plus an external reminder of the date.
What is the difference between a domain and hosting?
The domain is the name; hosting is where the site is stored. They are separate services, usually from separate suppliers. You can have a domain without hosting (a name that leads nowhere) and hosting without a domain (a site reachable by IP address or by the provider's technical hostname).
What is a third-level domain and do I pay for it?
It is a subdomain inside your own domain, such as blog.example.com. You do not pay for it — you create it yourself by adding a DNS record, and you can create as many as you like. The exception is zones where registration itself happens at the third level: there it is a paid domain with its own term.
Can I change hosting without changing the domain?
Yes, and it is a routine operation. Domain and hosting are linked only through DNS records. Bring the site up on the new server, confirm it works, then switch the A record. Lower the TTL beforehand so the switch completes faster.
What is a domain in an email address?
The part of the address after the @ sign. It determines where the message is delivered: the recipient is located through that domain's MX records. A mail domain may differ from a website domain, and having a website does not by itself mean mail is configured on the domain.
Why did my site not open right after I registered the domain?
Usually for one of three reasons: no NS servers are set (the domain is not delegated), no A record exists, or your resolver still caches a negative answer from an earlier attempt. Check delegation, then records, then the picture across several resolvers — that order is the diagnostic procedure.
Checklist: keeping a domain under control
- Auto-renewal is on, and the expiry date is duplicated in an external reminder.
- The administrative contact lives on a different domain, and that mailbox is actually read.
- The
clientTransferProhibited,clientDeleteProhibitedandclientUpdateProhibitedlocks are set. - Two-factor authentication is enabled in the registrar account.
- NS records are correct and the domain is delegated.
- An A record exists, ideally an AAAA too, and no CNAME sits at the domain apex.
- Mail has MX, SPF, DKIM and DMARC configured — not just MX.
- The current TTL is written down so it can be lowered ahead of a migration.
- Domain and hosting are split across different suppliers and different accounts.
- Internationalised names are stored in both forms — readable and
xn--.
A domain is the longest-lived part of a project: sites get rewritten and servers get replaced, but the name stays. That is why half an hour spent on locks, auto-renewal and expiry monitoring pays back better than almost any other infrastructure setting.