DNS: The Complete Guide for Admins

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

Resolvers, authoritative servers, and the path a lookup takes

DNS looks simple because a name becomes an address. The path is a chain of responsibilities. The stub resolver is the library on the host. It asks a recursive resolver. The recursive resolver walks the tree from the root, to the top-level domain, to the authoritative servers for the zone, unless it already holds a cached answer. Authoritative servers do not browse the Internet for you. They answer for the zones they host.

If the recursive resolver is wrong, every name looks broken and a packet capture on the authoritative server shows nothing. If the authoritative server is wrong, the recursive resolver is doing its job and caching your mistake for the TTL. Those are different faults. The first question in a DNS incident is which of the two you are talking to.

Split horizon means the same name answers differently on the inside and the outside. It is useful for a service that has a private address internally and a public address externally. It is dangerous when the two views drift and a laptop on VPN gets the public answer for an internal name, or the reverse. Document which view a resolver serves. Do not run two views by accident because a lab server was promoted.

This page does not zone-transfer your domains, scan your resolvers, or publish records. Lookups you run from the tools on this site use a public resolver path for a name you type. A zone transfer is a server feature you allow only to your secondaries, not a check you point at the Internet.

Record types you will actually edit

The A record holds an IPv4 address. Use one A record per address you mean. Several A records are a simple way to offer several addresses. They are not a health check. A dead address still in DNS is a client-side timeout. When you add one, write the owner name, the type, the TTL, and the value in the ticket. A record without a TTL is a record that will inherit a default you did not read. A record with a week-long TTL is a record you cannot undo quickly. Use a short TTL the day before a migration, then put it back.

The AAAA record holds an IPv6 address. Publish a AAAA record only after the IPv6 path works. A name can have both A and AAAA. Clients that prefer IPv6 will try the AAAA first. When you add one, write the owner name, the type, the TTL, and the value in the ticket. A record without a TTL is a record that will inherit a default you did not read. A record with a week-long TTL is a record you cannot undo quickly. Use a short TTL the day before a migration, then put it back.

The CNAME record holds an alias to another name. A CNAME may not sit at the zone apex next to SOA and NS in a normal zone. Do not chain five CNAMEs. Point at the name that has the address. When you add one, write the owner name, the type, the TTL, and the value in the ticket. A record without a TTL is a record that will inherit a default you did not read. A record with a week-long TTL is a record you cannot undo quickly. Use a short TTL the day before a migration, then put it back.

The MX record holds where mail should be delivered. The preference is a number. Lower is tried first. The target is a name, not an IP address. That name needs an A or AAAA record. Do not point an MX at a CNAME. When you add one, write the owner name, the type, the TTL, and the value in the ticket. A record without a TTL is a record that will inherit a default you did not read. A record with a week-long TTL is a record you cannot undo quickly. Use a short TTL the day before a migration, then put it back.

The NS record holds which servers answer for a zone. The parent zone delegates by NS records. The child zone should list the same servers. A mismatch is a lame delegation and a long troubleshooting day. When you add one, write the owner name, the type, the TTL, and the value in the ticket. A record without a TTL is a record that will inherit a default you did not read. A record with a week-long TTL is a record you cannot undo quickly. Use a short TTL the day before a migration, then put it back.

The TXT record holds a text string. SPF, DKIM, and site verification live here. A TXT record is not free-form policy. Keep SPF under the lookup limits and do not stack two SPF records on one name. When you add one, write the owner name, the type, the TTL, and the value in the ticket. A record without a TTL is a record that will inherit a default you did not read. A record with a week-long TTL is a record you cannot undo quickly. Use a short TTL the day before a migration, then put it back.

The SRV record holds a service location. SRV carries priority, weight, port, and target. It is how some applications find a host without you hard-coding a port in every client. The target still needs an address record. When you add one, write the owner name, the type, the TTL, and the value in the ticket. A record without a TTL is a record that will inherit a default you did not read. A record with a week-long TTL is a record you cannot undo quickly. Use a short TTL the day before a migration, then put it back.

The PTR record holds a reverse name. Reverse DNS is a separate tree. An A record does not create the PTR. Mail servers and some appliances expect the PTR to exist and to agree with the forward name. When you add one, write the owner name, the type, the TTL, and the value in the ticket. A record without a TTL is a record that will inherit a default you did not read. A record with a week-long TTL is a record you cannot undo quickly. Use a short TTL the day before a migration, then put it back.

The SOA record holds the start of a zone. The SOA holds the primary name, a mailbox, a serial, and the timers. Increase the serial when you change the zone or secondaries will keep the old copy. When you add one, write the owner name, the type, the TTL, and the value in the ticket. A record without a TTL is a record that will inherit a default you did not read. A record with a week-long TTL is a record you cannot undo quickly. Use a short TTL the day before a migration, then put it back.

The CAA record holds which certificate authorities may issue. CAA does not install a certificate. It tells a careful authority whether it is allowed to issue for the name. It is useless if you never check it, and it is harmful if it lists the wrong authority. When you add one, write the owner name, the type, the TTL, and the value in the ticket. A record without a TTL is a record that will inherit a default you did not read. A record with a week-long TTL is a record you cannot undo quickly. Use a short TTL the day before a migration, then put it back.

The TLSA record holds a fingerprint for DANE. TLSA only helps if clients validate DNSSEC and look the record up. Publishing one and forgetting DNSSEC does not add the protection you think it does. When you add one, write the owner name, the type, the TTL, and the value in the ticket. A record without a TTL is a record that will inherit a default you did not read. A record with a week-long TTL is a record you cannot undo quickly. Use a short TTL the day before a migration, then put it back.

The HTTPS record holds an HTTPS service hint. The HTTPS and SVCB records can carry protocol hints. Add them when the application team asked for them, not as decoration beside every A record. When you add one, write the owner name, the type, the TTL, and the value in the ticket. A record without a TTL is a record that will inherit a default you did not read. A record with a week-long TTL is a record you cannot undo quickly. Use a short TTL the day before a migration, then put it back.

TTL, caching, and the serial

A TTL is a promise that resolvers may remember the answer. A 300-second TTL means a change is widely visible within a few minutes, plus the time clients keep their own stub cache. An 86400-second TTL means you can be wrong for a day. Lower the TTL at least one old TTL before the change. Lowering it at the moment of the change does not evict what is already cached.

The SOA serial is how a secondary decides to fetch a new copy. A common format is the date and a counter, such as 2026102301. It must increase. Wrapping it backwards, or editing the zone file and forgetting the serial, leaves secondaries on the previous version while the primary is already new. Users then see a split that depends on which server they hit.

Negative caching stores the fact that a name does not exist. A typo you just fixed can stay broken for the negative TTL. That timer is in the SOA. When you are about to add a name that clients may already have queried, know that negative cache. It explains a failure that a freshly queried authoritative server will not reproduce.

Delegation and a worked name

Suppose example.com is served by ns1.example.com and ns2.example.com. The parent zone, com, must have NS records for example.com and glue address records when the nameserver names are inside the delegated zone. Glue is the address of the nameserver handed out with the delegation so the resolver does not need the zone in order to find the zone. Missing glue, or glue that points at an old address, is a delegation fault. The zone file on your server can be perfect and still be unreachable.

Inside the zone, www.example.com as a CNAME to app.example.com, and app.example.com as an A record to 203.0.113.10, is a normal pattern. A resolver that asks for www gets the CNAME and then the A, and it caches both according to their TTLs. If you change only the A and the CNAME TTL is long, you did not have a CNAME problem. If you change the CNAME target and the old target still has a long TTL, clients keep the old alias.

Mail for example.com with MX 10 mail.example.com requires mail.example.com to have an address. An MX that points at mail.example.com, which is a CNAME, is a mistake you should not ship. An MX that points at 203.0.113.10 is also a mistake. The value is a hostname. SPF, if you publish it, is a TXT record on the domain that sends mail, and it should name the servers you actually send from. This guide does not replace the mail guide. It only stops the DNS half of the mistake.

Reverse lookup for 203.0.113.10 lives under the in-addr.arpa tree, not in the example.com zone. You may not even host that reverse zone. The provider often does. Ask for the PTR when you ask for the address. A forward record you control and a reverse record you do not is a normal split of responsibility. Track it so a server move updates both.

Operating DNS without making it a surprise

Keep the zone in version control if you generate it, and keep secrets out of it. A TSIG key is a secret. A zone file full of public records is not. Review a generated zone the way you review a generated router config. A tool that adds a record should show you the diff. A person should raise the serial.

Health checks do not belong inside a long TTL. If you remove an address, resolvers will keep it. Prefer a short TTL on names that change during incidents, or take the address out of rotation at the load balancer and leave DNS stable. DNS is a poor load balancer and a worse incident switch.

The lookup and health tools linked here ask the DNS system about a name you provide. Read the answer, the server that answered, and the TTL. Then decide whether you are looking at cache, delegation, or the record itself. Those are three different edits.

Name the zone, the authoritative servers, and the recursive resolver the users actually use.
Write the record as owner, type, TTL, and value.
Check that a CNAME is not at the apex and that an MX target is an address name.
Increase the SOA serial if you serve secondaries.
Query the authoritative server directly and confirm the new value.
Query the recursive resolver and confirm whether you are seeing the new value or a cached one.
Only then tell users the name has moved.

Walk a lookup before you edit the zone

Start with the name users type, not with the server you suspect. Ask the recursive resolver the users use. Note the answer, the TTL, and whether the response is a CNAME chain. Then ask an authoritative server for the zone directly. If those two disagree, you are looking at cache or at the wrong view, not at a record you should edit yet. If they agree and the value is wrong, the zone is wrong. Edit the zone, raise the serial, and query the authoritative server again before you blame resolvers.

Walk www.example.com as a concrete case. The recursive resolver needs the root, then the com servers, then the NS set for example.com. You do not perform that walk by hand during an ordinary change. You do it when a name is newly delegated or when a nameserver address changed. The failure mode is specific: the parent still has the old NS or the old glue, your new server is perfect, and the world never arrives. Querying your new server directly will not show that. Querying from the parent side will.

Split horizon needs its own walk. From a laptop on the office network, app.example.com might be 198.51.100.20. From a laptop on a guest network or at home, the same name might be 203.0.113.20. Both can be correct. A ticket that says the name is broken because two people see two addresses is not a ticket until you write down which view each person was in. Fix the view that is wrong. Do not make both views match if the whole point was that they differ.

During a migration, set the TTL to 300 the day before, on the records that will move, and raise the serial then, not only on the day. On the day, change the address, raise the serial again, and query an authoritative server. Then query a recursive resolver that is allowed to cache, and expect some clients to keep the old address until the previous TTL dies. Have a rollback address ready. DNS rollback is another record change, not a reboot. It is also cached, so the rollback TTL should already have been short.

Write the evidence in the ticket in four lines: the name, the resolver you asked, the authoritative server you asked, and the value each returned with the TTL. That is enough for the next person to see whether the change landed. A screenshot of a browser error is not DNS evidence. The browser fails for TLS, proxy, and application reasons that never touch the record you just edited.

A small zone still deserves a checklist. example.com has NS records, an apex that is not a CNAME, mail as an MX to mail.example.com, mail.example.com as an A or AAAA, www as a CNAME or an address, and a TXT record only if you meant to publish SPF or a verification string. Each of those is a separate line in the ticket with a TTL. The lookup tools on this page will show you what the world, or a resolver, currently says. They will not edit the zone. The edit stays in your DNS server, with a serial that went up, and a second person who read the diff. If the second person cannot explain the TTL and the view, the change waits. A green lookup from the server console is not that review.

Mistakes that survive a green lookup

Two SPF TXT records on one name. Mechanisms belong in one record.

A CNAME and another record on the same name. The alias replaces the name. It does not sit beside an A record.

Forgetting glue after you rename a nameserver.

Lowering the TTL after the change and expecting caches to forget.

Testing only from the DNS server itself, which often uses a different resolver path than a laptop.

Pointing a public name at a private address, then being surprised when off-site users cannot connect.

Leaving a retired server in the NS set because the remaining server still answers in your lab.

Editing the zone and not the serial, so half the world still has yesterday.

Querying only A records during an IPv6 incident. The name can be broken in AAAA and fine in A, or the reverse.

Adding a verification TXT record and accidentally replacing the SPF record because both are TXT on the apex.

Assuming a CDN hostname and the origin hostname share a TTL. Change the one users resolve, and check the one the CDN fetches.

Leaving a test A record for lab.example.com in the public zone after the lab ended, with a TTL long enough to outlive the project.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.

Companion: Security: SPF, DKIM and DMARC Explained.