DNS Records Explained for Beginners: A, CNAME, MX, TXT, Nameservers, @ and www
Published on September 22, 2026 by Muhammad Raza Bangi
You Typed a Name, But the Internet Needs an Address
Imagine you want to visit a friend's house for the first time. You know their name — but a name alone will not get you there. You need their street address. So you open a directory, look up the name, find the address, and drive there.
Visiting a website works almost exactly the same way. A visitor wants to open 92nodes.com. They know the name, but their computer does not yet know the numeric address of the server that name points to. DNS (the Domain Name System) is the directory that looks up the name and returns the address. Once the browser has that address, it connects to the correct server directly.
This guide uses that same idea — domain names as easy-to-remember names, and DNS as the address directory that connects them to real servers — throughout. Every technical word is explained the first time it shows up, so if you have never touched a DNS dashboard before, you can follow this end to end.
1. What Is DNS? The Internet's Address Directory
Every device on the internet — every server, every phone, every laptop — is reachable at a numeric IP address (Internet Protocol address), something like 192.0.2.10. Computers are perfectly happy working with numbers like that. People are not — we remember names, not strings of digits.
DNS solves that mismatch. It is a distributed, publicly queryable directory that maps human-friendly domain names (like 92nodes.com) to the IP addresses and other technical details that keep the internet running. Using the address analogy throughout this guide:
- Domain name— the easy-to-remember name, like a person or business's name.
- IP address — the physical street address of the building that name belongs to.
- DNS— the internet's address directory or phonebook, connecting names to addresses.
- Nameserver— the specific office that holds and answers questions about one domain's directory entry.
- DNS record— one specific instruction written in that directory entry ("this name's address is this number").
- Browser — a visitor trying to find the house.
- DNS resolver— the person or service that runs around asking different offices for directions on the visitor's behalf.
- TTL and caching — jotting the address down temporarily so you do not have to ask again for a while.
Where the analogy stops: A directory only tells you where a building is — it does not unlock the door, check your ID, or guard the property. DNS only finds the correct server; it plays no role in login, authentication, or access control, and it does not encrypt anything. Those are separate systems (like HTTPS/TLS, a firewall, or a login form) that run only after DNS has already done its one job.
In simple words: DNS is a lookup system. It turns a name into an address so a browser knows where to connect — nothing more, nothing less.
Quick answer
What is DNS?
DNS (Domain Name System) is the internet's directory service. It converts a domain name like example.com into the IP address a computer needs to actually connect to that site's server.
2. What Happens After You Type a Domain
When a visitor types 92nodes.com and presses enter, a short chain of lookups happens — usually in a fraction of a second — before the browser ever contacts the actual website.
- A visitor enters a domain, such as 92nodes.com, in their browser.
- The browser and operating system first check their own cache — have they looked this up recently? If so, they may already have a recent answer saved.
- If not, a recursive DNS resolveris contacted (often run by the visitor's internet provider or a public service like Cloudflare's 1.1.1.1 or Google's 8.8.8.8). Its job is to do the legwork of finding the answer.
- The resolver asks a root DNS server, which does not know the answer directly but points it toward the correct TLD (top-level domain, like
.com) server. - The .com TLD server does not know the final answer either, but it knows which nameservers are authoritative for 92nodes.com, and points the resolver there.
- The authoritative nameserver— the office that actually holds this domain's directory entry — returns the requested DNS record, such as an A record containing an IP address.
- The resolver hands that IP address back to the visitor's browser.
- The browser opens a connection directly to the server at that IP address.
- From there, HTTPS/TLS (the padlock in the address bar) and the web server itself take over to securely deliver the actual website. DNS's job is already finished by this point.
In simple words: Finding a website is a relay race: browser asks resolver, resolver asks root, root points to .com, .com points to the domain's own nameserver, and that nameserver gives the final answer.
3. DNS Dashboard Fields Explained
Before looking at individual record types, it helps to know what you are actually filling in. Almost every DNS provider's "add record" form asks for some combination of the same fields, just sometimes under different labels:
| Field | What it means |
|---|---|
| Type | Which kind of record you are creating — A, CNAME, MX, TXT, and so on. |
| Name / Host | The hostname the record applies to. This is where @, a blank field, or www usually goes (see the next section). |
| Target / Value / Content / Points To | What the record resolves to — an IP address for an A record, another hostname for a CNAME, quoted text for a TXT record, and so on. |
| Priority | Used mainly by MX (and, alongside weight, by SRV) to say which destination should be tried first. Lower numbers are usually tried first. |
| TTL | Time to live — how many seconds a resolver is allowed to cache this record's answer before it must ask again. |
| Proxy status | Provider-specific (notably Cloudflare's orange-cloud toggle). When enabled, traffic is routed through the provider's proxy/CDN instead of connecting straight to your server's real IP. |
Labels vary by provider: "Value", "Content", "Target", and "Points To" all mean the same thing at different DNS providers. There is no universal standard label — always match what your specific provider's interface and documentation call it.
4. What @, a Blank Host, and www Actually Mean
This is one of the most confusing parts of DNS for beginners, and it is worth slowing down for.
What @ represents
@ is a shorthand many DNS providers use for the zone apex, also called the root domain or bare domain — the domain by itself, with no subdomain label in front of it. For 92nodes.com, @ means exactly 92nodes.com, nothing more.
- Some providers display and accept @ directly in the Name/Host field.
- Some providers expect you to leave that field completely blank instead.
- Some providers expect the full domain name typed out in full.
- There is no single universal convention — follow the interface and documentation of the specific DNS provider you are using.
Common mistake: @ is not part of the public domain name. Nobody ever types @92nodes.com into a browser — @ is purely an editing convention inside the DNS dashboard for "the root domain itself."
What www represents
www is simply a hostname label. Combined with a domain, it forms www.92nodes.com — technically a subdomain, even though decades of convention have made it feel like "the same thing" as the main website. There is no technical rule requiring www; it became a habit in the early web and many sites still support or default to it.
Because @ and www are two different hostnames, they do not automatically point to the same place. Both need their own DNS record, or one needs to be configured to lead to the other, and often a redirect is added so visitors always land on whichever version you prefer.
| Type | Name | Value | Purpose |
|---|---|---|---|
| A | @ | 192.0.2.10 | Points 92nodes.com to an IPv4 server |
| CNAME | www | 92nodes.com | Makes www.92nodes.com resolve through the main hostname |
Example data only: 192.0.2.10above is a reserved documentation-only IP address (per RFC 5737) used purely to illustrate the format of an A record. Do not copy it into a real production DNS setup — use the actual IP address your own host or server provides.
A DNS record is not the same thing as a redirect
These two configuration tables often get confused with each other, but they operate at different layers:
- A DNS record resolves a hostname to a destination (an IP address or another hostname). It happens before the browser connects to anything, and the address bar keeps showing whatever the visitor typed.
- An HTTP redirect (like a 301 or 302) is issued by a web server after DNS has already resolved and the browser has connected. It changes the URL visible in the browser, sending the visitor from one address to another.
- You cannot use DNS alone to make www.92nodes.com "redirect" to 92nodes.com in the browser's address bar — that visible change requires a redirect configured at the hosting or application level, on top of correct DNS.
CNAME and apex limitations: A CNAME generally cannot coexist with other records at the exact same hostname, and by the original DNS standard a CNAME is not allowed at the zone apex at all, because the apex must also carry mandatory SOA and NS records. Some DNS providers offer a proprietary workaround — often called CNAME flattening, ALIAS, or ANAME — that behaves like a CNAME internally while still publishing a standard A/AAAA record externally. This is a provider-specific feature, not a guaranteed universal DNS behavior, so confirm your provider actually supports it before relying on it.
Quick answer
What does @ mean in DNS?
@ is a common shorthand for the root domain itself (the zone apex) — for example, just 92nodes.com with no subdomain in front of it. Depending on the provider, you may instead need to leave the field blank or type the full domain name.
Quick answer
Is www a CNAME?
Not inherently — www is just a hostname label. It is very commonly configured as a CNAME pointing at the root domain, but it can also be set up as its own direct A or AAAA record. Either approach is valid; the choice depends on your provider and setup.
Quick answer
What is the difference between an A record and a CNAME?
An A record points a hostname straight at a numeric IPv4 address. A CNAME points a hostname at another hostname, which is then looked up separately. A records resolve to addresses; CNAMEs resolve to names.
In simple words: @ means "the domain by itself." www means "the www subdomain." They are two separate DNS entries, not two names for the same thing.
5. Registrar vs DNS Provider vs Nameserver vs Hosting
A single company sometimes offers several of these services under one roof, which makes it easy to assume they are the same thing. Conceptually, they are not — and understanding the difference is what makes troubleshooting DNS problems possible.
| Item | What it is | Real-world analogy | Example |
|---|---|---|---|
| Domain registrar | Where the domain name itself is registered and renewed | Property registry office | Namecheap |
| DNS provider | Stores the authoritative DNS records for the domain | The official address directory | Cloudflare |
| Nameserver | Tells the rest of the internet where that directory is hosted | The directory office's own address | Provider-assigned nameservers |
| Web host | The server the website actually runs on | The physical building | Vercel, a VPS, or shared hosting |
| Email provider | Handles sending and receiving email for the domain | The post office | Google Workspace or Microsoft 365 |
A realistic setup often mixes all five:
- The domain is bought and renewed at Namecheap (the registrar).
- Its nameservers are set to Cloudflare, which stores and serves the actual DNS records (the DNS provider).
- The website itself is hosted on Vercel or another hosting provider.
- Email is handled separately by Google Workspace or Microsoft 365.
Two distinctions matter a lot in practice:
- Nameservers are usually changed at the registrar — that is what tells the internet which DNS provider is authoritative for the whole domain.
- Individual DNS records are managed at the DNS provider (whoever the nameservers point to) — that is where you add or edit an A, CNAME, MX, or TXT record.
Common mistake: Editing DNS records in the registrar's dashboard has no effect if the nameservers have already been pointed elsewhere — the registrar's own DNS panel is no longer authoritative. Always confirm which provider your current nameservers actually point to before editing records.
Nameserver changes are bigger than record changes: Changing nameservers moves authority for the entire domain to a new provider at once. If the website, email, and verification records that existed at the old provider are not recreated at the new one, those services can break — even though the visible action was "just changing nameservers." This is different from delegating a single subdomain with its own NS records, which hands off authority for only that one subdomain while leaving the rest of the domain untouched.
In simple words: The registrar sells you the name. The DNS provider stores the directory entries. The nameserver tells the internet where that directory lives. The host runs the actual site.
6. DNS Record Types at a Glance
Here is every record type covered in this guide, side by side, before the detailed breakdown below.
| Type | Full name | What it points to | Common use |
|---|---|---|---|
| A | Address record | An IPv4 address | Pointing a hostname to a website server |
| AAAA | IPv6 address record | An IPv6 address | Same as A, for IPv6 networks |
| CNAME | Canonical Name record | Another hostname | Aliasing www or a subdomain to another host |
| MX | Mail Exchange record | A mail server hostname, with priority | Routing incoming email |
| TXT | Text record | Arbitrary text | Ownership verification, SPF, DKIM, DMARC |
| NS | Name Server record | A nameserver hostname | Declaring who is authoritative for a zone |
| CAA | Certification Authority Authorization | An allowed certificate authority | Restricting who can issue SSL certificates |
| SRV | Service record | A hostname, port, priority, and weight | Locating a specific service, like SIP or chat |
| PTR | Pointer record | A hostname | Reverse lookup — IP address to hostname |
| SOA | Start of Authority record | Zone administration data | Automatic zone metadata, rarely hand-edited |
| DS | Delegation Signer record | A cryptographic key digest | Linking DNSSEC trust from the parent zone |
| DNSKEY | DNS Key record | A public cryptographic key | Signing records for DNSSEC validation |
Which records does a normal website usually need?: Most personal or small-business sites only ever touch four record types day to day: an A (or AAAA) record for the website itself, a CNAME for www or other subdomains, an MX record for email, and a few TXT records for email security and ownership verification. NS is usually set once by whichever DNS provider you choose. CAA, SRV, PTR, SOA, DS, and DNSKEY are typically automatic, provider-managed, or something your host configures for you.
7. DNS Record Types Explained in Detail
A Record
What it does:Maps a hostname directly to an IPv4 address — the most basic "this name lives at this number" entry in the directory.
Analogy: The street address written next to a name in the directory.
Type: A
Name: @
Value: 192.0.2.10
TTL: 3600Multiple A records: A hostname can have more than one A record. Resolvers will then hand out one of the listed addresses, often rotating between them — a simple form of load distribution. It does not check whether a server is actually healthy on its own.
Domain vs IP: A domain (92nodes.com) is the name; an IP address (192.0.2.10) is the address that name points to. The A record is the line in the directory that connects the two.
Common mistake:Leaving an A record pointing at an old hosting provider's IP address after migrating to a new host — the domain keeps resolving to a server that no longer serves the current site.
Do you usually need to edit it? Yes — this is one of the records most website owners edit directly, typically once when setting up hosting and again if hosting changes.
AAAA Record
What it does: The IPv6 equivalent of an A record — maps a hostname to an IPv6 address instead of an IPv4 one.
Analogy: The same directory entry, just written in the newer, much longer address format that IPv6 uses.
Type: AAAA
Name: @
Value: 2001:db8::1
TTL: 3600How it differs from A: IPv4 addresses (used by A records) are running out of unique numbers globally; IPv6 (used by AAAA records) uses a much larger address space designed to replace it long-term. Many networks and devices support both today.
Common mistake: Devices that prefer IPv6 will try the AAAA record first. An AAAA record that is missing, stale, or pointing at a server that is not actually reachable over IPv6 can make the site slow or fail for those visitors, even while it loads fine for everyone using IPv4 only.
Do you usually need to edit it? Only if your host provides IPv6 hosting and asks you to add one — otherwise it is safe to leave out entirely; a missing AAAA record simply means IPv6-preferring devices fall back to the A record.
CNAME Record
What it does: Makes one hostname an alias of another hostname. Whoever looks up the alias gets redirected, at the DNS level, to look up the target hostname instead.
Analogy:A forwarding note in the directory that says "for this name, go look up this other name instead."
Type: CNAME
Name: www
Value: 92nodes.com
TTL: 3600
Type: CNAME
Name: blog
Value: hosting-provider-target.example.netUse cases: Pointing www at the root domain, pointing a subdomain like blogat a third-party platform, or connecting a subdomain to a CDN or SaaS product's hostname.
Important rule:A CNAME's target must be a plain hostname, never a full URL. Do not include https://, a trailing slash, or any path — the value should look like a domain name, not something you'd paste into a browser's address bar.
Do you usually need to edit it?Yes — commonly for www and any third-party service that asks you to "point a CNAME" at their platform. See the apex limitation and provider-specific flattening/ALIAS/ANAME note in section 4 above before trying to use a CNAME on the root domain.
MX Record
What it does: Tells the internet which mail servers are responsible for accepting email sent to addresses at your domain.
Analogy: A primary post office and a backup post office — mail is tried at the primary first, and only routed to the backup if the primary cannot be reached.
| Type | Name | Value | Priority |
|---|---|---|---|
| MX | @ | mx1.example-mail-provider.com | 10 |
| MX | @ | mx2.example-mail-provider.com | 20 |
Priority: Lower numbers are normally tried first. In the example above, mx1 (priority 10) is the primary mail server, and mx2 (priority 20) only receives mail if the primary is unavailable.
Important:An MX record's value must be a mail server hostname, not an ordinary web URL and not an IP address.
Common mistake: Replacing or deleting existing MX records while changing unrelated DNS settings (like website hosting) is one of the fastest ways to stop all incoming email without realizing it until messages start bouncing.
Do you usually need to edit it? Yes, once — when setting up or switching your email provider (such as Google Workspace or Microsoft 365) — and it should otherwise be left untouched.
TXT Record
What it does: Stores arbitrary text in the DNS directory. It is a general purpose slot used for several unrelated, important jobs:
- Domain ownership verification — proving to a service (Google, Microsoft, and others) that you control the domain by publishing a specific string they give you.
- SPF (Sender Policy Framework) — lists which mail servers are allowed to send email claiming to be from your domain, to reduce spoofing.
- DKIM (DomainKeys Identified Mail) — publishes a public key so receiving mail servers can verify that a message was not altered in transit and genuinely came from a server holding the matching private key.
- DMARC (Domain-based Message Authentication, Reporting & Conformance) — tells receiving mail servers what to do when a message fails SPF or DKIM checks (ignore it, quarantine it, or reject it), and where to send reports.
These three email-security mechanisms are related but distinct — SPF checks the sending server, DKIM checks message integrity via a signature, and DMARC decides what to do based on the results of both. They are not interchangeable, and most legitimate mail setups use all three together.
; SPF
example.com. TXT "v=spf1 include:_spf.example-mail-provider.com -all"
; DKIM (public key shortened for readability)
default._domainkey TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."
; DMARC
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"
; Domain ownership verification
example.com. TXT "google-site-verification=exampleTokenOnly"Never store secrets in TXT records: DNS records, including TXT records, are generally publicly readable by anyone who queries your domain. Never publish real passwords, API keys, private keys, or other secrets in a TXT record — only publish values a provider specifically designed to be shown this way, such as verification strings and email-authentication policies.
Do you usually need to edit it? Yes — most sites accumulate several TXT records over time for email security and third-party verification, and they should be preserved carefully during any DNS migration.
NS Record and Nameservers
What it does: Declares which nameservers are authoritative for a domain (or subdomain) — in other words, which DNS provider holds the real directory entries.
Analogy:The sign outside the directory office telling you which office actually has this domain's file.
example.com. NS ns1.example-dns-provider.com.
example.com. NS ns2.example-dns-provider.com.NS records for the whole domain are normally changed at the registrar (this is what "changing nameservers" means). Individual DNS records like A, CNAME, MX, and TXT are then managed inside whichever DNS provider those nameservers point to — see the full comparison in section 5.
Delegating a subdomain is different: Adding NS records for a specific subdomain (for example, handing shop.example.com off to a different provider) only transfers authority for that one subdomain. It is a much smaller, more contained change than replacing the nameservers for the entire domain.
Common mistake: Changing nameservers when only a single A or CNAME record actually needed to change. This moves the entire domain's DNS to a new provider and risks breaking every service that depended on records left behind at the old one — including email.
Do you usually need to edit it? Rarely — typically only once, when first choosing a DNS provider, or deliberately migrating to a different one.
CAA Record
What it does: Restricts which certificate authorities (organizations that issue SSL/TLS certificates) are allowed to issue a certificate for your domain.
Analogy:A note on file saying "only this specific notary is allowed to certify documents for this address."
example.com. CAA 0 issue "letsencrypt.org"Common mistake: Adding a restrictive CAA record and then forgetting about it — if it does not list the certificate authority your host actually uses, certificate issuance or renewal can fail, breaking HTTPS.
Do you usually need to edit it? No, not for most sites. Many domains have no CAA record at all, which permits any certificate authority. Only add one deliberately, as an extra security measure, and keep it in sync with whichever authority your host uses.
SRV Record
What it does: Helps a client application locate a specific service — the exact server, port, and protocol to connect to — rather than assuming a fixed, well-known port.
Analogy:Instead of just an address, this is a note saying "go to this address, ask for this specific department, on this specific floor."
_sip._tcp.example.com. SRV 10 5 5060 sipserver.example.com.| Field | Meaning |
|---|---|
| Priority | Lower value is tried first, similar to MX priority (10 in the example) |
| Weight | Relative preference among records that share the same priority (5) |
| Port | The network port the service listens on (5060) |
| Target | The hostname that actually runs the service (sipserver.example.com) |
Common uses include VoIP/SIP communication systems, some enterprise directory and chat services, and certain game server discovery setups.
Do you usually need to edit it? Only when a specific service you are integrating explicitly asks you to add one — most standard websites never need an SRV record.
PTR Record (Reverse DNS)
What it does: The reverse of an A record — given an IP address, it returns a hostname, instead of the other way around.
Analogy: Looking a street address up in the directory to find out whose name is on file there, instead of looking a name up to find the address.
10.2.0.192.in-addr.arpa. PTR mail.example.com.This example is the reverse-lookup entry for the documentation address 192.0.2.10. PTR records are usually controlled by whoever owns the IP address — your VPS or hosting provider — not created in your domain's normal forward DNS zone. They matter most for mail servers, where a missing or mismatched PTR record can hurt sender reputation and cause outgoing email to be flagged as spam.
Do you usually need to edit it?Rarely directly — for a typical website owner this is either not applicable or handled through your hosting/VPS provider's control panel, not your domain's DNS zone.
SOA Record
What it does: Holds administrative information about an entire DNS zone — which nameserver is primary, an administrative contact, and timing values other nameservers use to stay in sync.
Analogy: The cover page of the directory entry, listing who maintains it and when it was last updated — not an actual address entry itself.
example.com. 3600 IN SOA ns1.example-dns-provider.com. admin.example.com. (
2026092201 ; serial number
7200 ; refresh interval (seconds)
3600 ; retry interval (seconds)
1209600 ; expire time (seconds)
3600 ) ; minimum TTL (seconds)Do you usually need to edit it? No — the SOA record is created and maintained automatically by your DNS provider. Most users should not edit it manually.
DS and DNSKEY Records (DNSSEC)
What they do: Together, these implement DNSSEC (Domain Name System Security Extensions), which lets resolvers cryptographically verify that DNS answers have not been tampered with in transit.
- DNSKEY— a public cryptographic key published inside your DNS zone, used to verify signatures on that zone's records.
- DS (Delegation Signer) — a digest of that key, published at the parent level (usually submitted through your registrar), which anchors trust from the parent zone down into your DNSKEY.
Analogy: DNSKEY is the official seal your office stamps its own documents with. DS is the record the higher authority keeps on file confirming that seal is genuinely yours.
; DS record (submitted at the registrar/parent zone)
example.com. DS 12345 13 2 3B1EAB4F5F5C6B5C...
; DNSKEY record (published in your own zone)
example.com. DNSKEY 257 3 13 mdsswUyr3DPW132mOi8V9xE...Warning: Enabling or changing DNSSEC incorrectly — publishing a DS record that does not match your current DNSKEY, or removing one out of order — can make your entire domain stop resolving for every visitor using a validating resolver. Follow your specific DNS provider and registrar's documented DNSSEC enable/disable process exactly; do not hand-edit these records without provider instructions.
Do you usually need to edit it?No — if you use DNSSEC at all, enable and manage it through your DNS provider and registrar's dedicated DNSSEC controls, not by writing these records by hand.
8. TTL, Caching, and DNS Propagation
TTL (time to live) is a number, in seconds, attached to every DNS record. It tells any resolver that looks the record up how long it is allowed to reuse that answer from its cache before it must ask again. Using the directory analogy: TTL is like someone jotting an address down in their own notebook so they do not have to look it up again — they keep using their written note until it expires.
This is exactly why DNS changes can appear inconsistent: one visitor's resolver might have already fetched a fresh answer, while another visitor's resolver is still using its own cached copy from before the change, with time left on its TTL.
| Time since the record was changed | What a resolver caching the old value sees |
|---|---|
| 0 minutes | Change saved at the DNS provider. Resolvers with a fresh cached copy still show the old value. |
| Up to 60 minutes (with a 3600-second TTL) | Each resolver keeps serving its own cached answer until that specific copy's TTL runs out. |
| After 60 minutes | Any resolver that had cached the old value at the moment of the change has now expired it and will fetch the new value on its next query. |
| Immediately, for new lookups | A resolver that never cached this domain before gets the new value right away on its first query. |
A few things worth being precise about:
- "DNS propagation" is a convenient phrase, but much of the delay people experience is really just previously cached records expiring on their own individual schedules, not the change slowly spreading like a wave.
- Nameserver changes and ordinary record changes are not necessarily equivalent — a nameserver change can involve additional caching at the registry level beyond a single record's TTL.
- There is no universal rule that every change takes exactly 24 to 48 hours. The real time depends on the previous TTL, how many resolvers had cached an answer, provider processing time, and the type of change being made.
- Lowering the TTL after making a change does not retroactively shorten a cached copy that a resolver already holds — that resolver is still working from whatever TTL was in place when it fetched the old answer.
In simple words: TTL is a cache expiry timer. Lower TTL means faster-visible changes but more DNS lookups; higher TTL means fewer lookups but slower-visible changes.
Quick answer
How long do DNS changes take?
It depends on the previous TTL and how many resolvers cached the old answer — anywhere from a few minutes to roughly a day, not a fixed 24–48 hours. Lowering TTL in advance, before you make the change, is what actually speeds this up.
9. Practical DNS Configuration Examples
Example 1: Root domain and www on a traditional server
| Type | Name | Value | TTL |
|---|---|---|---|
| A | @ | 192.0.2.10 | 3600 |
| CNAME | www | example.com | 3600 |
192.0.2.10is a reserved documentation-only address, not a real server — replace it with your own server's actual IP address.
Example 2: Connecting a domain to a managed host
Managed platforms like Vercel commonly ask for an A record on the apex, a CNAME on www, or sometimes a provider-specific record type, and their required target values can change over time. Always copy the exact values shown in your own project's dashboard at the moment you configure it — not generic values from an article or an older tutorial — since a mismatched or outdated target will fail domain verification.
Example 3: Website and email hosted separately
The website and email for one domain routinely live at two completely different companies, using different record types that do not interfere with each other:
| Type | Name | Value | Purpose |
|---|---|---|---|
| A | @ | 192.0.2.10 | Website (hosting provider) |
| CNAME | www | example.com | Website alias |
| MX | @ | mx1.example-mail-provider.com (priority 10) | Email (mail provider) |
| TXT | @ | v=spf1 include:_spf.example-mail-provider.com -all | Email sender authorization |
Use the exact MX and TXT values your email provider's own setup documentation gives you — Google Workspace and Microsoft 365, for instance, each publish their own current records rather than a single fixed value that works for everyone.
Example 4: Creating a subdomain
| Goal | Type | Name | Value |
|---|---|---|---|
| blog.example.com | CNAME | blog | hosting-target.example.net |
| api.example.com | A | api | 192.0.2.20 |
| portal.example.com | CNAME | portal | portal-target.example.net |
Most dashboards only want the label itself — blog, api, or portal — in the Name field, though a few providers display or accept the fully written-out hostname instead.
Example 5: Moving from old hosting to new hosting
- Lower the TTL on the records you plan to change (for example, to 300 seconds) a day or more before the migration, so any later change expires from caches quickly.
- Record or export your current DNS entries so you have a complete backup to compare against.
- Change only the records that actually need to move — typically A/AAAA and possibly CNAME — not the whole zone.
- Preserve MX, SPF, DKIM, DMARC, and any domain-verification TXT records exactly as they were, unless the migration specifically requires changing them too.
- Test the new server before fully relying on DNS — for example, by temporarily overriding the hostname in your local hosts file so only your own machine sees the new server. See our guide to the Linux and macOS filesystem for exactly how that file works.
- Once records are updated, wait for the old TTL to fully expire before assuming every visitor sees the new server.
- Raise the TTL back to a normal value (such as 3600 seconds or higher) once everything is confirmed working.
Set expectations honestly: This process minimizes visible downtime, but it does not guarantee zero downtime — some visitors with long-cached DNS answers may briefly reach the old server after the new one is already live, or vice versa, until caches catch up.
10. How to Check DNS Records
A handful of free command-line tools, already built into most operating systems, can check exactly what DNS is currently returning for a domain:
dig example.com A # Show the current A record(s)
dig www.example.com CNAME # Show what www is aliased to
dig example.com MX # Show mail server records and priority
dig example.com TXT # Show TXT records (SPF, DKIM, DMARC, verification)
dig example.com NS # Show which nameservers are authoritative
dig +trace example.com # Walk the full path: root -> TLD -> authoritative nameserver
nslookup example.com # A simpler, cross-platform DNS lookup tool| Command | What it checks |
|---|---|
| dig example.com A | The current IPv4 address(es) the domain resolves to. |
| dig www.example.com CNAME | What hostname www is currently aliased to, if any. |
| dig example.com MX | Which mail servers are configured to receive email, in priority order. |
| dig example.com TXT | All published text records — SPF, DKIM, DMARC, and verification strings. |
| dig example.com NS | The nameservers currently marked authoritative for the domain. |
| dig +trace example.com | The full delegation path a resolver follows, from the root down to the authoritative nameserver — useful for spotting exactly where a lookup breaks. |
| nslookup example.com | A quick, simpler alternative to dig for a basic address lookup. |
Browser-based tools such as DNSChecker.org are also useful — they query several public resolvers around the world at once, which makes it easy to see whether a change has reached some resolvers but not others. Let it query the record type you care about (A, AAAA, CNAME, MX, NS, PTR, SRV, SOA, TXT, CAA, DS, or DNSKEY) and compare the results side by side.
What is actually authoritative: A public checker is convenient for comparing cached results across locations, but it is not the ultimate source of truth. The most direct, current answer always comes from querying your domain's authoritative nameserver directly (which dig can do explicitly) — public resolvers shown in a checker may still be serving a cached value.
11. DNS Troubleshooting Checklist
- Confirm the domain is active and has not expired at the registrar.
- Check which nameservers are actually configured at the registrar right now.
- Confirm those nameservers match the DNS provider you are trying to edit records in.
- Verify @ (the root domain) and www separately — do not assume one working means the other does too.
- Check for A, AAAA, and CNAME conflicts at the same hostname.
- Check whether an old, stale AAAA record exists that no longer matches your current server.
- Confirm the record's value does not contain https:// or a URL path — it should be a bare hostname or IP address.
- Check the record's TTL and whether cached results elsewhere could still be showing an old value.
- Confirm hosting-side domain verification has completed (many hosts show a pending/verified status).
- Check SSL/TLS certificate status only after DNS has actually resolved correctly — certificate issuance depends on DNS being right first.
- Preserve existing MX and TXT records related to email whenever changing other DNS settings.
- Check DNSSEC configuration if the domain returns validation failures or refuses to resolve for some networks.
- Test using both the domain's authoritative nameserver directly and common public resolvers, to see whether the difference is caching or an actual misconfiguration.
12. Common DNS Mistakes Beginners Make
- Editing DNS in the registrar's dashboard even though the nameservers actually point somewhere else.
- Treating @ as if it were part of the public, typeable domain name.
- Assuming @ and www automatically point to the same place without configuring both.
- Putting a full URL (with https:// or a path) into an A or CNAME value.
- Pointing an A record at a hostname instead of a numeric IPv4 address.
- Pointing a CNAME at an IP address instead of a hostname.
- Deleting MX or TXT records while changing website hosting, breaking email delivery.
- Creating conflicting records — like an A and a CNAME — on the exact same hostname.
- Changing nameservers when only a single A or CNAME record actually needed editing.
- Forgetting to update or remove an old AAAA record after a server change.
- Publishing real secrets or credentials in a TXT record, which is generally publicly readable.
- Confusing DNS resolution (finding the server) with an HTTP redirect (changing the visible URL).
- Confusing DNS with SSL/HTTPS — DNS finds the server; it does not encrypt anything or issue certificates.
- Expecting a lower TTL set today to instantly clear a copy some resolver already cached under the old TTL.
- Copying example values straight from a tutorial instead of the real values shown in your own hosting dashboard.
- Enabling DNSSEC without following the provider's exact process, risking the domain failing to resolve.
- Adding a wildcard record and assuming it always wins — a more specific matching record normally takes precedence over a wildcard.
13. DNS Safety Checklist
- Back up or export your full DNS zone before making any significant change.
- Lower TTL in advance of a planned change, not after it.
- Never write real secrets, passwords, or private keys into a TXT record.
- Double-check every A/CNAME value for a stray https://, trailing slash, or path.
- Confirm MX and related TXT (SPF/DKIM/DMARC) records survive any migration untouched.
- Verify changes with dig or nslookup before assuming a browser test is conclusive.
- Treat nameserver changes and DNSSEC changes as higher-risk than a single record edit.
- Keep a CAA record, if you add one, in sync with the certificate authority your host actually uses.
14. Frequently Asked Questions
Q: What is DNS in simple words?
A: DNS (Domain Name System) is the internet's address directory. It translates easy-to-remember domain names, like example.com, into the numeric IP addresses computers use to actually find and connect to a server.
Q: What does @ mean in a DNS record?
A: @ is shorthand many DNS providers use for the zone apex, also called the root domain — for example example.com by itself, with no subdomain in front of it. Some providers use @, some expect you to leave the Name/Host field blank, and some want the full domain typed out. Check your specific provider's interface.
Q: What does www mean in DNS?
A: www is a hostname label that, combined with your domain, forms a subdomain: www.example.com. It is not a special protocol requirement — it is simply the conventional name many sites use for their main website. www and the root domain (example.com) are separate hostnames and must each be configured.
Q: Should www be an A record or CNAME?
A: Either can work. A common pattern is to point the root domain (@) with an A (or AAAA) record to a server IP, then point www at the root domain with a CNAME so it always follows whatever @ resolves to. Some hosts instead ask for a direct A record on www — follow what your host's dashboard specifies.
Q: What is the difference between an A record and a CNAME?
A: An A record maps a hostname directly to an IPv4 address (a number). A CNAME maps a hostname to another hostname (a name), which the resolver then looks up again. A records point to addresses; CNAMEs point to other names.
Q: Can a domain have multiple A records?
A: Yes. Adding more than one A record for the same hostname is a simple form of load distribution — resolvers will hand out one of the listed IP addresses, often on a rotating basis. It does not provide health checking or failover on its own.
Q: Can I use a CNAME on the root domain?
A: Traditionally, no — a CNAME is not permitted to coexist with other records (like the mandatory SOA and NS records) at the zone apex, per the DNS standard. Some DNS providers offer a proprietary workaround, often called CNAME flattening, ALIAS, or ANAME, that behaves like a CNAME at the apex internally but still publishes an A/AAAA record externally. This is provider-specific, not a universal DNS feature.
Q: What happens if I change my nameservers?
A: Changing nameservers moves authority for your entire domain to a different DNS provider. Every record — website, email, verification, subdomains — must exist at the new provider or those services can stop working, even though you only meant to change one thing. It is a bigger, riskier change than editing a single record.
Q: Will changing website DNS affect email?
A: It can, if you are not careful. Email depends on MX and supporting TXT records (SPF, DKIM, DMARC), which are separate from the A/CNAME records that point to your website. Changing nameservers or bulk-editing DNS without preserving those records is a common way email delivery breaks.
Q: How long does a DNS change take?
A: It depends on the previous TTL (time to live) on the record, how many resolvers have it cached, and what kind of change it is. A record with a 300-second TTL can be fully refreshed within minutes almost everywhere; a record that previously had a 24-hour TTL may show old data to some users for up to a day. There is no single guaranteed number.
Q: Why does my site work without www but not with www?
A: Because @ (the root domain) and www are two separate hostnames with two separate DNS records. If only the root domain has a working A record and no record exists for www — or it points somewhere else — the root domain resolves fine while www fails or shows something different.
Q: Why does DNSChecker show different results by location?
A: Public DNS checker tools query multiple resolvers around the world at once. If you just changed a record, resolvers that cached the old value will keep showing it until their cached copy expires, while resolvers seeing the domain for the first time will show the new value immediately. That mix is what produces different results by location.
Q: Does DNS provide SSL or HTTPS?
A: No. DNS only resolves a hostname to an address so a browser knows where to connect — it does not issue certificates, encrypt traffic, or handle login and authentication. HTTPS/TLS is a separate layer, usually configured at your hosting provider or web server, once DNS is pointing correctly.
Q: What is the difference between DNS and a redirect?
A: A DNS record resolves a hostname to a destination server; the address bar keeps showing whatever hostname the visitor typed. An HTTP redirect (like a 301) is issued by a web server after DNS has already resolved, and it changes the URL the visitor sees. They solve different problems and often work together.
Q: Is it safe to add verification text to a TXT record?
A: Ordinary domain-ownership verification strings (from Google, Microsoft, and similar services) are safe and designed to be published this way. What is not safe is putting real secrets — passwords, private keys, API tokens — in a TXT record, because DNS records are generally publicly readable by anyone who queries your domain.
Q: How can I find my current authoritative nameservers?
A: Run a WHOIS lookup on your domain, or query the NS record directly with a command like dig example.com NS. The nameservers listed there are the ones actually authoritative for your domain right now, which may differ from what you remember setting if it was changed at some point.
15. DNS Cheat Sheet You Can Bookmark
- @ = the root domain by itself; www = a separate subdomain — configure both, or link one to the other.
- A record → points to an IPv4 address. AAAA record → points to an IPv6 address.
- CNAME → points to another hostname, never a URL, never an IP address.
- MX → lower priority number is tried first; never delete these casually.
- TXT → holds SPF, DKIM, DMARC, and verification strings; never secrets.
- NS → changed at the registrar; moves authority for the whole domain.
- TTL is measured in seconds and controls cache lifetime, not how the change "spreads."
- DNS finds a server. It does not log anyone in, authenticate anyone, or provide HTTPS by itself.
- Always verify with dig/nslookup against the authoritative nameserver, not just a browser refresh.
Conclusion
DNS looks intimidating mostly because dashboards throw a lot of unfamiliar labels at you at once — Type, Name, Value, Priority, TTL — without explaining what any of them actually mean. Underneath all of that, it is still just a directory: a name goes in, an address comes out, and every record type in this guide exists to answer one specific kind of question about that domain, whether it is "where is the website," "where does email go," or "who is allowed to issue a certificate for this name."
Need help connecting your domain, fixing DNS records, or moving a website without disrupting email? The 92 Nodes team handles web development and ongoing support and maintenance for production sites, including exactly this kind of DNS and email setup.
For deeper technical reference beyond this guide: ICANN's overview of DNS fundamentals, Cloudflare's DNS documentation on record behavior and caching, and RFC 1035, the original DNS specification, for anyone who wants the full technical detail.