What does DNS do in one request?
DNS turns a name such as www.example.com into the data a computer needs, most often an IP address. One request passes through up to four kinds of server, and each one either knows the answer or knows who to ask next.
- The resolver. Your device sends the question to a recursive resolver. This is run by your internet provider, your company, or a public service such as
1.1.1.1or8.8.8.8. If it has a recent copy of the answer, it replies at once. - A root server. If not, the resolver asks one of the root servers. There are 13 root server names,
a.root-servers.nettom.root-servers.net. The root does not know the answer. It replies: "ask the servers for.com". - A TLD server. TLD means top-level domain, the last part of the name. The
.comserver replies with the nameservers forexample.com. - The authoritative server. This server holds the real records for
example.com. It replies with the answer.
The resolver hands the answer to your device and keeps a copy. How long it keeps the copy is set by the record's TTL, covered later in this guide.
How a record is written
The records for one domain are called a zone. A zone file lists them one per line, in a format set by RFC 1035:
; name TTL class type value
www.example.com. 300 IN A 192.0.2.34| Field | Meaning |
|---|---|
| Name | The hostname the record is about. The dot at the end means "this is the full name". |
| TTL | Seconds a resolver may keep a copy. 300 is 5 minutes. |
| Class | Always IN (internet) in practice. |
| Type | What kind of answer this is: A, MX, TXT and so on. |
| Value | The answer itself. |
Most DNS control panels hide the class and show @ for the bare domain, which is also called the apex. The examples below use the full zone file form.
What do A and AAAA records do?
An A record points a name at an IPv4 address, and an AAAA record points a name at an IPv6 address. They are the records a browser needs to reach your site.
A record
example.com. 300 IN A 192.0.2.34
www.example.com. 300 IN A 192.0.2.34You can have more than one A record for the same name. Resolvers return all of them and clients pick one, which spreads visitors across servers.
Common mistake: adding the new IP address without removing the old one. Now there are two A records, and about half of your visitors are sent to the old server. Check what is really published with the A record lookup.
AAAA record
example.com. 300 IN AAAA 2001:db8::34Common mistake: publishing an AAAA record for a server that does not answer on IPv6, or leaving an old AAAA behind after a move. Visitors whose network prefers IPv6 get timeouts, while the site works for you on IPv4. Test it with curl -6 -I https://example.com and the AAAA record lookup.
What is a CNAME record, and why can it not go at the apex?
A CNAME record says "this name is another name for that name". The resolver then looks up the second name to find the address. It cannot go at the apex because a name with a CNAME may hold no other records, and the apex must hold SOA and NS records.
www.example.com. 3600 IN CNAME example.com.
shop.example.com. 3600 IN CNAME stores.example.net.CNAMEs are useful when another company hosts something for you. They can change their IP addresses and your record stays correct.
The rule: a CNAME stands alone
RFC 1034 says that if a name has a CNAME, it must have no other data. So shop.example.com cannot have a CNAME and also an MX or TXT record.
Your bare domain, example.com, always has an SOA record and NS records. A CNAME there would break the rule. It would also hide your MX records, so mail would stop.
ALIAS, ANAME and CNAME flattening
Many DNS hosts offer a way round this. It is called ALIAS, ANAME or CNAME flattening, depending on the provider. You enter a hostname as the target, and the DNS host looks up that hostname itself and answers with plain A and AAAA records.
These are provider features, not standard record types. The name and behaviour differ between DNS hosts, and they do not carry over when you export a zone to another provider.
Common mistakes
- Leaving off the final dot in a zone file.
stores.example.netwithout the dot is read asstores.example.net.example.com. - Pointing an MX or NS record at a CNAME. RFC 2181 does not allow it, and some mail servers refuse to deliver.
- A dangling CNAME. You delete the hosted service but leave the CNAME. Someone else can register that target and serve their content on your subdomain.
See where a name really ends up with the CNAME lookup.
What does an MX record do?
An MX record names the server that accepts email for a domain. Each MX record has a priority number, and sending servers try the lowest number first.
example.com. 3600 IN MX 10 mx1.example.net.
example.com. 3600 IN MX 20 mx2.example.net.Here, mail goes to mx1. If mx1 does not answer, the sender tries mx2. Two records with the same number share the mail between them.
The value must be a hostname that has its own A or AAAA record. It cannot be an IP address and it should not be a CNAME.
Two special cases
- No MX record at all: sending servers fall back to the domain's A record and try to deliver there.
- A domain that should never get mail: publish a "null MX", defined in RFC 7505. Senders then fail at once with a clear error.
example.com. 3600 IN MX 0 .Common mistake: leaving the old provider's MX records in place after moving to a new mail provider. Some mail is then delivered to mailboxes nobody reads. Remove every old MX, then confirm with the MX lookup.
What is a TXT record for?
A TXT record holds free text attached to a name. Today it is mostly used to prove you own a domain and to publish email rules.
example.com. 3600 IN TXT "v=spf1 include:_spf.example.net -all"
example.com. 3600 IN TXT "site-verification=4f9a2c71b8"A name can have many TXT records. The reader picks out the one it needs by how the text starts, for example v=spf1.
The 255 character limit
One quoted string in a TXT record can hold at most 255 characters. A longer value, such as a DKIM key, is written as several quoted strings in one record. The reader joins them with nothing in between:
s1._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."
"...rest of the key..." )Most control panels do the splitting for you. Paste the value as one line and check what was saved.
Common mistakes
- Two SPF records. A domain may have only one TXT record that starts with
v=spf1. Two give an error and SPF fails for all mail. - The wrong name. Many panels add the domain for you. Typing
_dmarc.example.cominto the name box can create_dmarc.example.com.example.com. - Extra quote marks. If the panel adds quotes and you paste your own, the quotes become part of the value.
Read back exactly what is published with the TXT lookup.
What do NS and SOA records do?
NS records say which servers hold the records for a zone. The SOA record holds settings for the zone itself: who is in charge, a version number, and timers.
NS record
example.com. 86400 IN NS ns1.example-dns.net.
example.com. 86400 IN NS ns2.example-dns.net.NS records exist in two places. One copy is held by the TLD servers, and you set it at your registrar (the company where you pay for the domain). The other copy is inside the zone at your DNS host. The two sets should be the same.
Common mistake: editing records at a DNS host that the domain no longer points to. If your changes seem to do nothing, run dig example.com NS +short or the NS lookup and check you are logged in to the provider it names.
A second mistake is switching nameservers before copying every record to the new host. Anything you did not copy stops resolving.
SOA record
SOA means "start of authority". Every zone has exactly one.
example.com. 3600 IN SOA ns1.example-dns.net. hostmaster.example.com. (
2026101201 ; serial
7200 ; refresh
3600 ; retry
1209600 ; expire
3600 ) ; minimum| Field | Example | Meaning |
|---|---|---|
| MNAME | ns1.example-dns.net. | The primary nameserver for the zone. |
| RNAME | hostmaster.example.com. | The contact email, with the @ written as a dot. This one is [email protected]. |
| Serial | 2026101201 | A version number. Secondary servers copy the zone when it goes up. A common format is the date plus a two digit counter. |
| Refresh | 7200 | How often secondary servers check for a new serial: every 2 hours. |
| Retry | 3600 | How long a secondary waits before it tries again after a failed check: 1 hour. |
| Expire | 1209600 | How long a secondary keeps answering if it cannot reach the primary: 14 days. |
| Minimum | 3600 | How long resolvers remember that a name does not exist (RFC 2308): 1 hour. |
Common mistake: editing a zone file by hand and not raising the serial. The secondary servers see the same serial and keep the old data. Hosted DNS providers manage the serial for you. View yours with the SOA lookup.
What are CAA, SRV and PTR records?
These three are less common, and each has one clear job. CAA limits who may issue certificates, SRV says where a service runs, and PTR maps an IP address back to a name.
CAA record
A CAA record lists the certificate authorities that are allowed to issue certificates for your domain. It is defined in RFC 8659.
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild ";"
example.com. 3600 IN CAA 0 iodef "mailto:[email protected]"Line 1 allows one authority. Line 2 says nobody may issue wildcard certificates. Line 3 asks for reports of refused requests. With no CAA record at all, any authority may issue.
Common mistake: adding a CAA record for one authority, then moving to a host or CDN that uses another. Certificate renewal then fails the next time it runs. See the SSL certificate expiry guide, and check the record with the CAA lookup.
SRV record
An SRV record gives the hostname and port for a named service. It is defined in RFC 2782. The name starts with the service and the protocol, each with an underscore.
_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sip1.example.com.The four values are priority (10), weight (60), port (5060) and target. Lower priority is tried first. Weight shares the load between records with the same priority.
Common mistake: expecting an SRV record to send a website to another port. Browsers do not look up SRV records for web pages.
PTR record
A PTR record is the reverse of an A record. It lives under a special domain, with the IP address written backwards. For 192.0.2.34:
34.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com.You do not set PTR records at your DNS host. The owner of the IP address controls them, which is usually your hosting provider.
Common mistake: running a mail server with no PTR record, or one that does not match. Many receiving servers reject or mark down mail when the PTR name does not point back to the same IP address. Check with dig -x 192.0.2.34 +short.
How do SPF, DKIM and DMARC work as TXT records?
All three are TXT records that help a receiving mail server decide whether a message that claims to be from your domain is real. SPF lists who may send, DKIM publishes a key to check a signature, and DMARC says what to do when both fail.
SPF
SPF lists the servers that may send mail for your domain. It is defined in RFC 7208 and sits at the domain itself.
example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.10 include:_spf.example.net -all"ip4:192.0.2.10allows that address.include:_spf.example.netalso allows whatever your mail provider lists in its own SPF record.-allmeans "reject everything else".~allis the softer form: "treat everything else as suspect".
Common mistake: going over the limit of 10 DNS lookups. Each include, a, mx, exists and redirect counts, and so do the lookups inside each included record. Over 10, SPF returns an error. Count yours with the SPF checker.
DKIM
DKIM (RFC 6376) adds a signature to each message. The receiver fetches your public key from DNS to check it. The record name contains a "selector", which your mail provider gives you.
s1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."The value after p= is the key, shortened here. A real 2048 bit key is longer than 255 characters, so it is split into several strings.
Common mistake: a key cut short when pasted. Every signature then fails.
DMARC
DMARC (RFC 7489) tells receivers what to do with mail that fails both SPF and DKIM for your domain, and where to send reports. It always lives at _dmarc.
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"| Tag | Meaning |
|---|---|
p=none | Take no action. Only send reports. Start here. |
p=quarantine | Put failing mail in the spam folder. |
p=reject | Refuse failing mail. |
rua= | The address that gets the daily summary reports. |
pct=25 | Apply the policy to 25% of failing mail. Useful while you tighten it. |
Common mistake: going straight to p=reject. Any service that sends as your domain and is not yet in SPF or signed with DKIM has its mail refused. Start at p=none, read the reports, fix each sender, then move up. Check your record with the DMARC checker.
What is TTL, and how long does a DNS change really take?
TTL (time to live) is the number of seconds a resolver may keep a copy of a record. A change is seen by everyone once the old TTL has run out, counted from the moment you made the change.
People call this "propagation", but nothing is pushed out. Your new record is live on the authoritative servers within seconds or minutes. Each resolver simply keeps its old copy until that copy runs out, then asks again.
| TTL | In plain time | Good for |
|---|---|---|
| 300 | 5 minutes | Records you are about to change, or may need to change fast |
| 3600 | 1 hour | A sensible default for most records |
| 86400 | 24 hours | Records that almost never change, such as NS |
Worked example: moving a site to a new server
Your A record has a TTL of 86400. You want to move on Friday at 10:00.
- Thursday before 10:00: lower the TTL to 300. Do not change the IP address yet. Resolvers that fetched the record just before this will keep the 86400 copy for up to 24 hours.
- Friday 10:00: change the IP address. Every resolver now holds a copy that lasts at most 300 seconds.
- Friday 10:05: resolvers that respect the TTL are all using the new address.
- Keep the old server running for a day or two. Some resolvers and apps hold records for longer than they should.
- Next week: raise the TTL back to 3600.
If you skip step 1, the same move takes up to 24 hours, and for that time visitors are split between the two servers.
Three cases that take longer
- Nameserver changes. The NS records held by the TLD have their own TTL, which you cannot change. For
.comit is 172800 seconds, which is 48 hours. - A name that did not exist. If someone looked up a name before you created it, the "not found" answer is cached for the SOA minimum, 3600 seconds in the example above.
- Local caches. Browsers and operating systems keep their own short copies. Restarting the browser clears the first.
How do you look up DNS records with dig and nslookup?
Use dig name type on Linux and macOS, or nslookup -type=TYPE name on Windows. Both ask a resolver for one record type and print the answer.
dig
# Just the value
dig example.com A +short
# The full answer line, with the TTL
dig example.com MX +noall +answer
# Ask a chosen public resolver
dig @1.1.1.1 example.com TXT +short
# Ask the authoritative server directly, with no cache in the way
dig @ns1.example-dns.net example.com A +norecurse
# Follow the whole path: root, TLD, authoritative
dig +trace www.example.com
# Reverse lookup (PTR)
dig -x 192.0.2.34 +short
# DMARC and SOA
dig _dmarc.example.com TXT +short
dig example.com SOA +shortA full answer line looks like this:
example.com. 287 IN A 192.0.2.34The number 287 is the TTL counting down. The record was published with 300, and this resolver fetched it 13 seconds ago. Run the command again and the number will be lower. That tells you that you are reading a cached copy.
On Debian and Ubuntu, dig is in the dnsutils package. On Fedora and RHEL it is in bind-utils.
The status line
Without +short, dig prints a header with a status. It is the fastest clue you have.
| Status | Meaning |
|---|---|
NOERROR with an answer | The record exists. |
NOERROR with no answer | The name exists, but has no record of that type. |
NXDOMAIN | The name does not exist at all. |
SERVFAIL | The resolver could not get a valid answer. The nameservers are unreachable, wrongly delegated, or DNSSEC checks failed. |
REFUSED | That server will not answer for this zone. |
nslookup
nslookup -type=MX example.com
nslookup -type=TXT _dmarc.example.com 8.8.8.8
nslookup 192.0.2.34The optional last value is the resolver to ask. The third command is a reverse lookup.
No terminal? The DNS lookup tool shows the records for a domain in the browser.
Which record is behind which symptom?
Start from what you can see, then check the one record most likely to cause it. Always compare the authoritative answer with what a public resolver returns, because the gap between them is a cache.
| Symptom | Likely record | How to check |
|---|---|---|
| After a move, the site is new for some people and old for others | A: old copies still cached, or two A records published | dig @1.1.1.1 example.com A and dig @8.8.8.8 example.com A. Compare the values and TTLs. |
| Works on one network, times out on another | AAAA pointing at a server with no IPv6 | dig example.com AAAA +short then curl -6 -I https://example.com |
www works, the bare domain does not | No A record (or ALIAS) at the apex | dig example.com A +short |
| Incoming email does not arrive | MX missing, wrong, or pointing at a name with no A record | dig example.com MX +short, then dig each target |
| Mail you send lands in spam | SPF, DKIM, DMARC or PTR | dig example.com TXT +short, dig _dmarc.example.com TXT +short, dig -x your sending IP |
| A certificate will not issue or renew | CAA blocks the authority, or the _acme-challenge TXT record is missing | dig example.com CAA +short |
| A new subdomain says "not found" after you added it | The "not found" answer is cached (SOA minimum) | Ask the authoritative server with dig @ns1.example-dns.net. If it answers, wait out the SOA minimum. |
| Changes in your DNS panel do nothing | NS points at a different provider | dig example.com NS +short |
| The whole domain returns SERVFAIL | NS delegation is broken, or a DNSSEC record was left at the registrar after a move | dig +trace example.com and see where it stops |
| A service cannot verify your domain | TXT at the wrong name, or with extra quotes | dig example.com TXT +short and compare character by character |
| A subdomain shows someone else's page | A CNAME left pointing at a service you closed | dig shop.example.com CNAME +short |
If the records look right and the site is still unreachable, the fault is past DNS. The website down checklist walks through the next steps in order.
Which DNS records should you monitor?
Monitor the records that would take your site or your mail offline if they changed: the A and AAAA records of your main hostnames, your MX records, your NS records and your SPF and DMARC TXT records. A wrong DNS record breaks things for everyone, and your servers show no error.
| Record | Why watch it |
|---|---|
| A and AAAA | A wrong address sends visitors to the wrong server or to nothing. An uptime check on the server's IP address would not see it. |
| CNAME | A hosted service can change or remove the target you point at. |
| MX | If it changes or vanishes, incoming mail stops or goes elsewhere. It can go unnoticed, because missing mail makes no noise. |
| NS | A change here moves control of the whole domain. It should never change without you knowing. |
| TXT | An SPF or DMARC record removed during a tidy-up sends your mail to spam. |
Check from outside, on a schedule
DNS breaks at the moment someone edits a record, and that person is often not the one who would notice the damage. A check that runs every few minutes from outside your network turns that into an alert.
PULSX has a DNS monitor type for A, AAAA, CNAME, MX, TXT and NS records, next to its HTTP, TCP port, ping and heartbeat monitors. Checks run as often as every 60 seconds. It is free for 20 monitors and you can sign up without a card.
Three habits that prevent most DNS incidents
- Export the zone before every change. A text copy lets you put every record back as it was.
- Lower the TTL a day before a planned change and raise it afterwards.
- Read the record back after you save it. Use
digagainst the authoritative server, not your memory of what you typed.