Diagnosing DNS records: A, AAAA, CNAME, MX, NS and PTR

Why this matters

Users never type addresses. They type names: a file server, an intranet site, a cloud application, an email address. Every one of those depends on DNS answering correctly, so when DNS is wrong the ticket says "the network is down", even though every link is up and every ping to an address works. A help-desk analyst moving into networking learns quickly that "can you reach it by address but not by name?" is one of the most useful questions in troubleshooting.

The faults are usually small and specific: a missing record type, an alias pointing at a name that no longer exists, a record changed this morning that clients will keep ignoring until tomorrow, a mail server whose reverse record does not match. Each record type does one job, and knowing which record serves which purpose turns a vague "names do not work" into a precise fix. Network engineers also meet DNS on their own devices, because a router with the wrong lookup settings stalls every time someone mistypes a command.

The lesson

Fixing name resolution for hosts, web applications and mail

DNS (Domain Name System) turns names into addresses, and addresses back into names. A client sends its question to a resolver, usually a DNS server set by DHCP. The resolver finds the answer by asking the authoritative servers for the name, starting from the root and following delegations down through the tree, then caches the answer. The records for a part of the tree, such as everything under example.com, are held in a zone.

Each record has a name, a type, a value and a TTL (time to live): the number of seconds a resolver or client may keep the answer in its cache.

The six record types

A short zone file shows them together:

example.com.        3600  IN  NS     ns1.example.com.
example.com.        3600  IN  MX     10 mx1.example.com.
example.com.        3600  IN  MX     20 mx2.example.com.
www.example.com.    3600  IN  A      192.0.2.10
www.example.com.    3600  IN  AAAA   2001:db8:10::10
shop.example.com.   3600  IN  CNAME  shop.hosting.example.net.
mx1.example.com.    3600  IN  A      192.0.2.20
mx2.example.com.    3600  IN  A      198.51.100.20

Host access: A and AAAA

An A record answers a request for an IPv4 address and an AAAA record (pronounced "quad A") answers a request for an IPv6 address. They are separate. If users reach www.example.com over IPv4 but a new IPv6-only laptop cannot resolve it, the name has an A record and no AAAA record. The A record is useless to a client that has no IPv4.

The reverse problem is common too. After an AAAA record is added for app.example.com, dual-stack users report slow or failed connections, while IPv4-only users are fine. Dual-stack clients usually prefer IPv6, so they try the AAAA address first. If that IPv6 address is unreachable from outside, they fail or wait before falling back to IPv4. The direct fix is to repair IPv6 reachability, or to remove the AAAA record until it works. Deleting the A record would break the IPv4-only users as well.

Web applications: CNAME and TTL

A CNAME says "this name is an alias; ask for that other name instead". Companies use it to point their own names at a hosting provider's names, so the provider can change addresses without the company editing its zone. A CNAME never holds an address. The address must come from the target's own A or AAAA record.

So if shop.example.com is a CNAME for shop.hosting.example.net and the provider deletes the A record of shop.hosting.example.net, clients get no address. Nothing in example.com is wrong. The fix is to restore the A record of the CNAME target. Adding a PTR or MX record does nothing for a forward lookup.

Two rules limit CNAMEs:

• A name that has a CNAME may have no other records. The zone apex, example.com itself, must hold the SOA and NS records, so a DNS server refuses a CNAME at the apex.
• An MX record must not point at a CNAME (see below).

The TTL explains the most confusing web complaint: "we changed the record, but some users still go to the old server". If a web server moved to a new IPv4 address and its A record was updated ten minutes ago, but the TTL was 86400 seconds, a full day, resolvers and clients that cached the old answer may keep using it for up to a day. The fix for next time is to lower the TTL a day or two before a planned move. On a Windows client you can clear the local cache with ipconfig /flushdns, but that does not clear the resolver's cache.

Mail servers: MX and PTR

An MX record tells sending mail servers which host accepts mail for a domain. If mail to staff at example.org is not arriving, the first record to check is the MX record of example.org, not its NS or A record.

Each MX record carries a preference value. The lowest number is tried first. With MX 10 mx1.example.com and MX 20 mx2.example.com, senders try mx1 first and fall back to mx2 when mx1 does not answer. A higher number is less preferred. Mail is not split evenly, and senders do not queue it while a working backup exists.

The value of an MX record is always a host name, never an IP address, and that host name must have its own A or AAAA record. If the MX of example.org points to mailhost.example.org and mailhost is itself a CNAME, the standards are broken, and some senders reject or delay the mail. The fix is to point the MX at a name that has an A record.

Outbound mail brings in PTR records. Many receiving servers run a forward-confirmed reverse DNS check on the sender. Suppose mail.example.net sends from 192.0.2.25. The receiver looks up the PTR record for 192.0.2.25 and gets a name, then looks up the A record of that name and checks it returns 192.0.2.25. So two records must agree: a PTR for 192.0.2.25 naming mail.example.net, and an A record for mail.example.net pointing back to 192.0.2.25. If either is missing or different, the sender's mail may be rejected. The MX record of example.net plays no part, because it controls where inbound mail goes.

Reverse lookups and the in-addr.arpa tree

Reverse lookups use PTR records in a special part of the tree, in-addr.arpa for IPv4. The octets are written in reverse, because DNS names get more general from left to right while addresses get more specific.

Worked example: where is the PTR for 192.0.2.25?

1. Write the address: 192.0.2.25.
2. Reverse the octets: 25.2.0.192.
3. Add the suffix: 25.2.0.192.in-addr.arpa.
4. The /24 zone is 2.0.192.in-addr.arpa, and the record inside it is named 25.

A record placed in a zone called 192.0.2.in-addr.arpa, with the octets in forward order, will never be found. IPv6 reverse lookups work the same way under ip6.arpa, one hex digit at a time. If the forward lookup of mail.example.net works but a reverse lookup of 192.0.2.25 returns nothing, the PTR record in 2.0.192.in-addr.arpa is missing.

Delegation: NS records

NS records name the authoritative servers for a zone. When a parent zone delegates a child, it holds NS records that send resolvers to the child's servers. Suppose example.com delegates branch.example.com to ns1.branch.example.com, but that server was rebuilt and no longer holds the branch zone. Resolvers follow the NS records, ask ns1, and get no authoritative answer, so every branch lookup fails. The fix is to restore the zone on the server, or update the NS records that delegate the zone to a server that has it. MX, PTR and CNAME records are not involved in delegation.

Querying records from a client

On Windows, macOS and Linux, nslookup asks the configured DNS server directly, bypassing guesswork. The -type option selects the record:

C:\>nslookup -type=mx example.com
Server:  dns1.corp.example
Address:  10.1.1.53

Non-authoritative answer:
example.com     MX preference = 10, mail exchanger = mx1.example.com
example.com     MX preference = 20, mail exchanger = mx2.example.com

-type=ns returns the name servers, -type=aaaa the IPv6 addresses, -type=ptr a reverse name. On macOS and Linux, dig example.com MX gives the same answer with the TTL shown. "Non-authoritative" simply means the answer came from a resolver, not from a server that is authoritative for the zone. Lesson 6 covers checking a client's DNS server settings.

DNS on Cisco devices

IOS can resolve names too, so engineers can type ping core-sw1.corp.example or ssh -l admin core-sw1.corp.example. Three commands control it:

R1(config)#ip domain lookup
R1(config)#ip name-server 10.1.1.53
R1(config)#ip domain name corp.example

ip domain lookup is on by default. ip name-server says which DNS server to ask. ip domain name appends a suffix to unqualified names, so ssh -l admin core-sw1 becomes core-sw1.corp.example. ip host adds a static name-to-address entry on the router itself.

With lookup on and no name server set, IOS broadcasts its queries to 255.255.255.255 and waits for an answer that never comes. This produces a familiar delay. IOS treats any word it does not recognise as a host name to connect to:

R1#shwo
Translating "shwo"...domain server (255.255.255.255)
% Unknown command or computer name, or unable to find computer address

The broadcast address in the message is the clue: no name server is configured. A configured server that is dead would show its own address instead. On lab routers, engineers often add no ip domain lookup to stop the pause.

The same missing setting breaks real lookups. If ssh -l admin core-sw1.corp.example from R1 fails after a Translating message, while SSH to the switch's IP address works, the likely missing command is ip name-server 10.1.1.53. ip domain name would not help, because the name is already fully qualified, and ip helper-address is for DHCP relay (lesson 7).

What the exam is really asking

• Match the record to the job. IPv4 address: A. IPv6 address: AAAA. Alias: CNAME. Mail destination: MX. Delegation: NS. Address to name: PTR.
• A and AAAA are independent. An IPv6-only client needs AAAA; a broken IPv6 path behind an AAAA record hurts dual-stack users.
• A CNAME has no address of its own. Fix the target's A record. No CNAME at the apex, and no other records beside a CNAME.
• Lowest MX preference wins. Higher numbers are backups. An MX names a host with its own A record, never an IP and never a CNAME.
• Reverse means reversed. 192.0.2.25 lives at 25.2.0.192.in-addr.arpa. Mail senders need matching PTR and A records.
• TTL explains "it still goes to the old server". Caches keep an answer until it expires.
• On IOS, 255.255.255.255 in a Translating message means no ip name-server. ip domain name only adds a suffix.