CCNA DNS Records: A, AAAA, CNAME, MX, NS and PTR Troubleshooting

DNS records are the entries in a DNS zone that answer questions about a name: which IPv4 or IPv6 address it has, which other name it is an alias for, which hosts accept its mail, which servers are authoritative for it, and which name belongs to an address. Every record has the same five parts: an owner name, a TTL (how many seconds a resolver may cache it), a class (almost always IN), a type and the data.

blog.example.net.   3600   IN   A   203.0.113.44
(owner name)        (TTL)  (class) (type) (data)

In zone files, a name without a trailing dot is relative to the zone (blog in the example.net zone means blog.example.net.), and a name with a trailing dot is fully qualified. Forgetting the trailing dot on a target such as relay.example.net silently turns it into relay.example.net.example.net.

Several components take part in every lookup, and diagnosing a DNS problem means working out which one holds the wrong data:

The first diagnostic question is therefore always: what does the authoritative server say? If it returns the wrong data, the record must be fixed. If it returns the right data but users get the wrong answer, the problem is a cache, a static entry or the path the client uses.

An A record maps a name to an IPv4 address and an AAAA record maps a name to an IPv6 address. A dual-stack server normally has both under the same name, and a name may hold several A or AAAA records when it is served by more than one address. Resolvers return every record in such a set, and clients spread their connections across the addresses (servers usually rotate the order), so two A records holding different servers send some users to each.

docs   IN   A      203.0.113.44
docs   IN   AAAA   2001:db8:44::44

Putting an IPv6 address in an A record (or an IPv4 address in an AAAA record) is invalid: the record type decides the address family, not the data.

Dual-stack clients prefer IPv6. When a client has working IPv6 connectivity, it asks for both A and AAAA records and by default tries the IPv6 address first (default address selection, RFC 6724, with Happy Eyeballs racing IPv4 as a fallback in many applications). This produces a recognisable pattern:

• A missing AAAA record: IPv4-only and dual-stack clients work (they use IPv4), but IPv6-only clients cannot reach the server by name.
• A stale or wrong AAAA record: IPv4-only users are fine, while dual-stack users see delays or timeouts as they try the dead IPv6 address first. The fix is to correct the AAAA data, not to delete it if the service must stay reachable over IPv6.
• A wrong A record: IPv4-only users fail; dual-stack users may still work over IPv6.

So when only one group of clients fails by name, match the failing group to the address family before touching any record.

A CNAME (canonical name) record makes one name an alias of another name: a resolver that asks for the alias is told the canonical name and then looks up that name's records. Use a CNAME when a name must follow another name's addresses, for example a web application hosted by a SaaS or CDN provider whose addresses change without notice:

status   IN   CNAME   status.pagehost.example.

The target of a CNAME is always a name, never an address. Pointing a name at an address is the job of A or AAAA.

The rules a CNAME must follow

• A CNAME stands alone. If a name has a CNAME, it can have no other data: no A, AAAA, MX, TXT or second CNAME at that same owner name. An alias therefore cannot also carry its own address or mail records, and a zone that tries it is invalid; many servers refuse to load it.
• No CNAME at the zone apex. The apex (example.com itself) must carry the zone's SOA and NS records, so a CNAME there would break the stand-alone rule. The apex gets A/AAAA records; other names such as www can be CNAMEs to it. Some DNS providers offer proprietary "alias" or "flattening" records for the apex, but those are not CNAMEs.
• The target can be anywhere. It may be in the same zone or in any other zone; the only requirement is that the target name exists.
• The rule is per owner name. Records at the target name, or at any other name in the zone, never conflict with the alias, because the stand-alone rule only looks at the alias's own name.
• Chains are legal. A CNAME may point to a name that is itself a CNAME. Chains work but add lookups, so keep them short.
• MX and NS targets must not be CNAMEs (see the MX and NS sections).

A common small-site design is an A record at the apex and CNAMEs for the other names, so only one record changes when the server moves:

example.net.   IN   A       192.0.2.140
help           IN   CNAME   example.net.

Following and fixing a chain. A lookup of an alias returns the whole chain in the answer section. When you move a web application, change only the link your zone owns, normally the CNAME target in your zone. You cannot add records for another organisation's name inside your zone (records outside your zone's namespace are not served from it), and asking a provider to repoint its own name changes it for every customer.

media.example.net.          600 IN CNAME media.edgecache.example.
media.edgecache.example.     30 IN A     192.0.2.77

Dangling CNAMEs. If the target name has been deleted, the response is NXDOMAIN with the CNAME still in the answer section. The response code describes the last name in the chain, not the alias you asked for: the alias exists, its target does not. The fix is to repoint the CNAME at a name that exists (or recreate the target). A dangling CNAME at a cloud provider is also a security risk, because someone else may be able to claim the abandoned target name.

An MX (mail exchanger) record tells sending mail servers which hosts accept mail for a domain: mail to user@example.net is delivered to the hosts listed in example.net's MX records. Each MX record has a preference number and a target host name:

example.net.   IN   MX   5  inbound1.example.net.
example.net.   IN   MX   15 inbound2.example.net.

• Lower preference wins. Senders try the lowest number first and move to higher numbers only when the lower ones are unreachable. Here inbound1 is primary and inbound2 is the backup. To reverse the roles, give the new primary the lower number (or the old primary a higher one).
• Equal preferences share the load. Two MX records with the same number are tried in random order.
• The actual number values do not matter, only their order.

What an MX target must be. The target is a host name that has its own A and/or AAAA record.

The fix for an MX that points at a CNAME is either to point the MX straight at the canonical host, or to replace the CNAME with an A/AAAA record for the MX target name.

No MX record at all. If a domain has no MX records, standard mail delivery (RFC 5321) falls back to an implicit MX: senders use the domain's own A or AAAA address as its mail host. So a domain without MX records may receive SMTP delivery attempts at whatever host its own name points to, even if that host is not a mail server. A domain that never receives mail can publish a "null MX" (MX 0 ., RFC 7505) to stop this.

Without a valid MX (or an address for the implicit fallback), senders cannot find a mail host and bounce the message. Only MX records and that address fallback take part in choosing a mail host.

An NS (name server) record names an authoritative server for a zone. NS records appear in two places: at the top of the zone itself, and in the parent zone, where they delegate the child zone. Delegation is how DNS hands a subdomain to another server or team:

; in the example.com zone
eng   IN   NS   ns.partnerdns.example.

Once this record is in the parent, resolvers that ask about anything under eng.example.com are referred to ns.partnerdns.example, and whoever runs that server manages every name in the eng.example.com zone. A CNAME, MX or PTR cannot delegate anything. Like MX, an NS target must be a host name with an address record, not a CNAME or an IP address.

Glue records. If the name server's own name is inside the zone it serves (dns1.eng.example.com serving eng.example.com), a resolver cannot look up its address without already reaching it. The parent zone must therefore also hold an A/AAAA record for that name server, called glue:

; in the example.com zone
eng.example.com.        IN   NS   dns1.eng.example.com.
dns1.eng.example.com.   IN   A    203.0.113.60     ; glue

The A record inside the child zone is not enough, because it can only be read once the server is reachable. Glue is needed only for in-zone ("in-bailiwick") name servers; a delegation to a name server whose name lies outside the delegated zone needs no glue, because resolvers find that address through the server's own zone.

Broken delegations. Two different faults stop a delegation from working. In a lame delegation, the server named in the NS record is reachable but does not hold (is not authoritative for) the child zone. With missing glue, an in-zone name server has no address in the parent, so resolvers cannot reach it at all. Either way, resolvers cannot get an authoritative answer and return SERVFAIL for every name under that subdomain, while the rest of the parent zone still works. A delegation depends only on the NS records pointing at servers that are reachable and authoritative for the child zone.

Changing name servers. When a zone moves to new authoritative servers, the parent (for example the .com registry) is updated with the new NS records, but resolvers may keep using the cached old delegation for as long as the parent's NS TTL, often two days. Keep the old servers answering with the same data as the new ones until that TTL has expired; deleting the zone from the old provider immediately causes failed lookups for anyone still using the cached delegation.

A PTR (pointer) record maps an IP address back to a name, which is called a reverse lookup. PTR records live in special reverse zones, not in the forward zone with the A records:

• IPv4: reverse the four octets and append in-addr.arpa. 192.0.2.66 becomes 66.2.0.192.in-addr.arpa.
• IPv6: expand the address to all 32 hexadecimal digits, reverse them one nibble at a time with dots between, and append ip6.arpa. 2001:db8::42 becomes 2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

66.2.0.192.in-addr.arpa.   IN   PTR   vpn.example.net.

The order is reversed because DNS names are most specific on the left, while IP addresses are most specific on the right. The record type is PTR (an A record in a reverse zone is meaningless), and an A record and a PTR record are created separately: adding one does not create the other.

Who controls a PTR record. Reverse zones are delegated along address allocation: the regional registry delegates them to whoever holds the address block, usually an ISP or cloud provider. A company that hosts only its forward zone cannot add a PTR for its public address inside that forward zone; it must ask the address owner (the ISP) to add it or to delegate the reverse entry (classless delegation, RFC 2317, is used for blocks smaller than a /24).

Where reverse DNS matters.

• Troubleshooting and logs: nslookup 192.0.2.66 returns no name when the PTR is missing, even though forward lookups for the host work.
• Mail: many receivers reject mail from a sending address that lacks forward-confirmed reverse DNS (FCrDNS). The address's PTR must name a host, and that host's A (or AAAA) record must point back to the same address. Both halves are needed.

PTR records play no part in reaching a host by name, in CNAME validity or in MX selection.

A record's TTL is the number of seconds any resolver may cache it, so after a change, users behind a resolver that cached the old answer keep getting it until the cached copy's TTL runs down. The authoritative server changes immediately; caches catch up only as entries expire.

Plan TTL reductions ahead of a change. Lowering a TTL only helps for copies cached after the lowering. Resolvers that cached the record with a 43200-second TTL keep it for up to 12 hours, whatever you do on the server. The correct sequence is:

1. Lower the TTL to a few minutes at least one old-TTL period before the change.
2. Change the address once the old long-TTL copies have expired.
3. Raise the TTL again after the move is confirmed.

Negative caching. "Name not found" (NXDOMAIN) and "no records of this type" (NODATA) answers are cached too, for a period derived from the zone's SOA record (the smaller of the SOA record's TTL and its MINIMUM field, RFC 2308). A user who looked up a name before it was created can keep getting "not found" from the resolver after the record has been added, while a query sent straight to the authoritative server already returns it.

Reading the cache in dig output. The authoritative server always shows the record's full configured TTL. A recursive resolver shows the time left on its cached copy, which counts down between queries. A smaller TTL plus old data from the resolver, while the authoritative server returns new data, proves a stale cache.

Getting rid of a stale answer now.

• On the recursive resolver: clear the cached entry for that name (for example rndc flushname on BIND, or clearing the DNS server cache on Windows Server).
• On a Windows client: ipconfig /flushdns clears the client cache, and ipconfig /displaydns shows it.

A cached copy is cleared only where it lives. Nothing done on the authoritative side reaches copies already sitting in resolver caches: a cached entry keeps the countdown it started with, and the SOA serial number only tells secondary servers that the zone has changed and should be transferred.

NXDOMAIN means the name does not exist, NODATA (NOERROR with an empty answer) means the name exists without the requested type, SERVFAIL means the server tried and failed to get an answer, and REFUSED means it declined to answer by policy. dig shows the code as status, and reading it correctly tells you where the problem is.

Two distinctions decide most diagnoses:

• NXDOMAIN vs NODATA. NXDOMAIN applies to the whole name: if an A query returns NXDOMAIN, the name has no AAAA, MX or any other record either. NODATA is type-specific: the name exists but not with that type, which is not a fault on its own.
• SERVFAIL vs REFUSED. SERVFAIL means the server attempted resolution and failed; REFUSED means it would not try. In dig, the flags help: ra (recursion available) missing from a REFUSED answer shows the server does not offer recursion to you. Clients should use a recursive resolver, not a zone's authoritative server, as their DNS server.

Other useful dig flags: qr (this is a response), rd (recursion desired, set by the client), aa (authoritative answer, set by a primary or secondary server for the zone).

nslookup and dig send a DNS query directly to a DNS server and show its answer, so they test DNS itself rather than everything the operating system does to resolve a name. Their syntax lets you choose the server and the record type, which is how you separate authoritative data from cached data.

In nslookup, the order is name, then server; reversing them looks up the server's name instead. Without a server argument (or @server in dig), the query goes to the default resolver and may come from its cache.

Authoritative vs non-authoritative answers. nslookup prints Non-authoritative answer when the server replied from its cache or by recursion rather than as a server for the zone. It says nothing about whether the data is right; to see the truth, query one of the zone's own name servers (primary or secondary, both answer authoritatively). In dig, the aa flag marks an authoritative answer.

Why nslookup can disagree with ping and the browser. nslookup and dig bypass the hosts file and the client's resolver cache. Applications such as ping and web browsers use the operating system's resolver, which checks the hosts file first (on Windows, C:\Windows\System32\drivers\etc\hosts; on Linux and macOS, /etc/hosts). When DNS tools and applications on the same machine disagree, the difference lies in what the tools skip: a static hosts-file entry survives a cache flush and affects only that machine, while the DNS records themselves are fine.

A diagnosis order that works

1. Query the authoritative server for the exact name and type. Wrong data there: fix the record.
2. Query the resolver the users use. Right at the source, wrong here: a cache (positive or negative).
3. Right in nslookup, wrong in applications on one host: hosts file or OS cache on that host.
4. Read the response code and follow any CNAME chain to the last name.

Cisco IOS XE devices can resolve names to addresses for commands such as ping, traceroute, telnet and ssh. The DNS server is set with ip name-server, lookups are switched on with ip domain lookup, short names are expanded with ip domain name, static entries are added with ip host, and show hosts verifies all of it:

Reading the symptoms

• domain server (255.255.255.255) in the Translating line: lookup is enabled but no name server is configured, so the router broadcasts its query and gets no reply. Fix: ip name-server, which serves every name, rather than one static entry per name.
• Fully qualified names resolve, short names fail: the default domain is missing, so a short name such as nas2 is never expanded to nas2.corp.example.net. Fix: ip domain name corp.example.net, which works for every host rather than one static entry per host.
• The router resolves a name to the wrong address while DNS holds the right one: look at show hosts. Entries flagged perm were configured with ip host and are used before DNS; entries flagged temp were learned from a name server and age out. Remove the static entry with no ip host.

R2# show hosts
Default domain is corp.example.net
Name/address lookup uses domain service
Name servers are 172.16.0.10
Host                       Port  Flags       Age Type  Address(es)
printer3                   None  (perm, OK)  0   IP    172.16.8.30
nas2.corp.example.net      None  (temp, OK)  0   IP    172.16.8.12

How clients learn their DNS server automatically (the DHCP option) is covered with DHCP in the IP services lesson.