Exam Objective 4.4: Diagnose issues with DNS records (A, AAAA, CNAME, MX, NS, and PTR) to support host, web application, and mail server access by name.
DNS is the system that translates human-friendly hostnames into the IP addresses (and other information) devices actually need to communicate. Nearly every "I can't reach the website" or "email isn't working" ticket that isn't a pure IP-reachability problem (covered back in objectives 1.3/1.6) traces back to a missing, incorrect, or misconfigured DNS record. This objective expects you to recognize each core record type, know what it's for, and diagnose which specific record is at fault when name-based access fails.
DNS is a hierarchical, distributed database that maps domain names to IP addresses and other resource information, organized into zones managed by authoritative name servers. When a client needs to resolve a hostname, it queries a DNS resolver (often provided by an ISP, an internal corporate DNS server, or a public resolver), which in turn queries the appropriate authoritative name server(s) if the answer isn't already cached, ultimately returning the requested record back to the client.
Key DNS terms relevant to troubleshooting:
Zone — a portion of the DNS namespace managed by a specific set of name servers (for example, everything under example.com)
Authoritative name server — the server that holds the actual, definitive DNS records for a zone and is the ultimate source of truth for that domain
Resolver (recursive resolver) — the server a client actually queries, which performs the work of tracking down the authoritative answer on the client's behalf if it isn't already cached
TTL (Time to Live) — how long a DNS record is permitted to be cached before a resolver must re-query the authoritative server for a fresh copy; a low TTL means changes propagate faster but generates more query traffic, while a high TTL reduces query load but means changes take longer to be seen everywhere
An A record (Address record) maps a hostname directly to an IPv4 address — the most fundamental and common DNS record type, and the one most people mean when they informally say "DNS record" without further qualification.
Example: www.example.com A 203.0.113.10
Symptoms of an A record problem:
A hostname fails to resolve at all (NXDOMAIN or "server not found" errors), indicating either the A record doesn't exist or the domain/zone itself has a deeper problem
A hostname resolves to the wrong IPv4 address (an outdated address after a server migration, or a typo in the configured record), causing the client to attempt to connect to the wrong destination entirely — the connection may fail outright, or connect successfully but to the wrong service
Diagnostic approach: Use nslookup or dig against the hostname specifically requesting an A record, and compare the returned IP address against what the server's actual current IP address should be. If the returned address doesn't match reality, the A record itself needs correction; if no record is returned at all, confirm the record actually exists in the zone.
An AAAA record (pronounced "quad-A") is functionally identical to an A record but maps a hostname to an IPv6 address instead of IPv4 — the naming convention reflects that an IPv6 address (128 bits) is four times the size of an IPv4 address (32 bits), hence "quad A."
Example: www.example.com AAAA 2001:db8::10
Symptoms of an AAAA record problem:
A dual-stack client (one with both IPv4 and IPv6 connectivity) may experience a delay or fallback behavior if the AAAA record exists but points to an unreachable/misconfigured IPv6 address, since some client resolution behavior (like Happy Eyeballs, a technique many modern OSes use) will attempt both A and AAAA results and prefer whichever responds successfully first
A missing AAAA record on an otherwise dual-stack service is not necessarily a problem — the client will simply fall back to using the A record and connect over IPv4 instead, so an absent AAAA record is not automatically evidence of a misconfiguration, only a missing one
Exam Alert: Know that A = IPv4, AAAA = IPv6, and that a missing AAAA record generally causes fallback to IPv4 (a graceful degradation) rather than an outright failure, unlike a missing/incorrect A record, which is far more likely to actually break connectivity for a typical client.
A CNAME record creates an alias, pointing one hostname to another hostname (not directly to an IP address) — the resolver must then perform an additional lookup on that target hostname to ultimately arrive at the actual IP address (via that target's own A or AAAA record).
Example: ftp.example.com CNAME www.example.com
In this example, a client looking up ftp.example.com is told to instead resolve www.example.com, and then uses whatever A/AAAA record exists for www.example.com to actually reach the destination.
Why CNAMEs are used: They allow multiple hostnames to point to a single underlying server/service without needing to maintain separate, identical A records for each alias — if the underlying server's IP address ever changes, only the one target A record needs to be updated, and every CNAME pointing to it automatically resolves correctly without any additional changes.
A critical restriction — CNAMEs cannot coexist with other records at the same name: A hostname that has a CNAME record cannot simultaneously have any other record type (such as an A record, or especially an MX record) at that exact same name — this is a fundamental DNS rule, and violating it is a classic, frequently tested misconfiguration, particularly relevant to mail delivery (covered in the MX section below).
Symptoms of a CNAME problem:
A CNAME pointing to a target hostname that itself doesn't resolve (a broken or nonexistent target) causes the entire chain to fail, even though the CNAME record itself is technically correctly formed
A CNAME chain that's too long or circular (a CNAME pointing to another CNAME, pointing to another CNAME, and so on, or even looping back on itself) can cause resolution delays or outright failures, depending on resolver-specific limits on how many CNAME "hops" it will follow
Exam Alert: The rule that a name with a CNAME record cannot have any other record type at that same name is one of the most specifically and directly tested CNAME facts — especially relevant when troubleshooting mail delivery, since an MX record is never allowed to point to a name that has a CNAME.
An MX record specifies which mail server(s) are responsible for accepting email on behalf of a given domain, along with a priority value used when multiple mail servers are configured.
Example:
example.com MX 10 mail1.example.com
example.com MX 20 mail2.example.com
Understanding MX priority (preference value): Lower numbers indicate higher priority/preference. In the example above, mail1.example.com (priority 10) will be tried first by a sending mail server; mail2.example.com (priority 20) is only used as a backup if the primary mail server is unreachable or fails to accept the message.
Critical detail — MX records point to a hostname, which must then resolve via its own A/AAAA record: An MX record itself never directly contains an IP address; it always references a hostname, and that hostname must separately have a valid, working A (or AAAA) record for mail delivery to actually succeed. This mirrors the CNAME resolution chain concept — MX resolution is a two-step process (find the mail server's hostname via MX, then find that hostname's IP address via A/AAAA).
Symptoms of MX record problems:
Missing MX record entirely — a domain with no MX record generally cannot receive email at all, since sending mail servers have no idea which server to deliver to (some mail systems fall back to the domain's own A record if no MX exists, but this fallback behavior is not universal or reliable and should not be depended on)
MX record pointing to a hostname that has a CNAME record instead of an A/AAAA record — this violates the DNS rule described in the CNAME section above and can cause mail delivery to fail entirely, or behave unpredictably depending on the receiving mail system's tolerance for the violation
MX record pointing to a hostname that doesn't resolve at all (a typo, or the target server was decommissioned without updating the MX record)
Incorrect priority values causing mail to consistently attempt delivery to a backup/secondary server first, or causing load to be distributed unexpectedly between multiple mail servers that were intended to be strictly primary/backup
Exam Alert: Expect a scenario specifically combining CNAME and MX rules — an MX record pointing to a hostname, and that hostname turning out to have a CNAME rather than a proper A record, is a classic, specifically tested mail-delivery failure pattern under this objective.
An NS record identifies which name server(s) are authoritative for a given DNS zone — essentially declaring "these are the servers that hold the real, definitive records for this domain."
Example:
example.com NS ns1.example.com
example.com NS ns2.example.com
Why NS records matter for troubleshooting: If a domain's NS records are incorrect, missing, or pointing to name servers that are unreachable or no longer actually authoritative for that zone, the entire domain can become unresolvable — every other record type (A, AAAA, MX, and so on) becomes irrelevant if a resolver can't even successfully reach an authoritative server to ask for them in the first place.
Glue records — a related concept: When a domain's own NS records point to a name server that is itself within that same domain (for example, example.com's NS record points to ns1.example.com), a special "glue record" is needed at the parent zone level to break the circular dependency (you'd otherwise need to resolve ns1.example.com to find out where to ask about example.com, but ns1.example.com is itself part of example.com). Glue records provide the IP address of that in-domain name server directly at the parent zone, avoiding this chicken-and-egg problem.
Symptoms of NS record problems:
The entire domain fails to resolve for any record type at all, rather than a symptom isolated to just one specific service (web, mail, and so on) — this pattern points toward the zone's NS delegation itself rather than any individual record
Inconsistent behavior between different resolvers/locations, if NS records at the registrar level don't match the NS records actually configured within the zone itself (a "lame delegation")
Exam Alert: A total domain-wide resolution failure (nothing resolves, not just one record type) should point your troubleshooting toward NS record/delegation problems rather than an individual A, AAAA, CNAME, or MX record issue.
A PTR record performs the opposite lookup direction from every other record type covered so far — instead of mapping a hostname to an IP address (forward DNS), a PTR record maps an IP address back to a hostname (reverse DNS), stored in a special reverse lookup zone.
IPv4 PTR records use the in-addr.arpa zone, with the IP address octets reversed:
10.113.0.203.in-addr.arpa PTR mail1.example.com
(This represents the reverse lookup for IP address 203.0.113.10.)
IPv6 PTR records use the ip6.arpa zone, following a similarly reversed, expanded nibble-by-nibble format of the full IPv6 address.
Why PTR records matter — primarily mail server reputation and logging: Many receiving mail servers perform a reverse DNS lookup on the sending mail server's IP address as part of their spam-filtering process, checking whether that IP address resolves back to a hostname (and often further checking whether that hostname's own forward A record matches back to the original IP — a practice called forward-confirmed reverse DNS, or FCrDNS). A missing or mismatched PTR record on an outbound mail server is a common, frequently tested reason legitimate email gets flagged as spam or rejected outright by the receiving server.
Symptoms of PTR record problems:
Outbound email from a server with no PTR record (or a PTR record that doesn't match/align with its forward A record) being rejected or marked as spam by receiving mail systems
Logging and security tools that rely on reverse DNS for readability showing raw IP addresses instead of hostnames, since no PTR record exists to translate them back
General network diagnostic tools (some traceroute/logging utilities) failing to display hostnames for certain hops, again due to a missing PTR record for that specific IP address
Exam Alert: PTR records are the reverse-lookup counterpart to A/AAAA records and are especially critical for outbound mail server reputation — a missing or mismatched PTR record is one of the most commonly tested real-world causes of legitimate email being rejected or spam-flagged, entirely separate from any A, MX, or CNAME misconfiguration on the domain itself.
nslookup — available on Windows, macOS, and Linux; queries a DNS server directly for a specified record type (nslookup -type=MX example.com, for example), useful for basic, quick lookups.
dig (Linux/macOS, and available on Windows via installation) — provides significantly more detailed output than nslookup, including exactly which server answered, the TTL of the returned record, and full record-type-specific query support (dig example.com MX, dig -x 203.0.113.10 for a PTR/reverse lookup, and so on); generally the preferred tool for thorough DNS troubleshooting.
Cisco IOS-side relevant commands: While DNS records themselves are typically hosted and managed on dedicated DNS servers rather than on Cisco routers/switches, IOS devices can be configured with ip name-server [address] to specify which DNS server(s) the device itself should use for its own name resolution needs (useful when a device needs to resolve a hostname for something like an NTP server or a syslog server target), and ip domain-lookup enables/disables the device's own use of DNS for resolving names typed at the CLI.
Exam Alert: Know that nslookup and dig can both be directed to query a specific record type explicitly (A, AAAA, CNAME, MX, NS, PTR) — expect a scenario showing sample nslookup or dig output for a specific record type and asking you to identify what's wrong with it.
Confirm basic IP reachability to the DNS resolver/server itself first (per the ping progression from objective 1.6) — a DNS problem that's actually a reachability problem to the DNS server should be ruled out before investigating individual records.
Determine which specific service is failing (web access, email delivery, a specific hostname) to narrow down which record type is most likely responsible — web/general host access points toward A/AAAA/CNAME, mail delivery points toward MX (and potentially CNAME conflicts or PTR issues on the sending side), and total domain failure points toward NS/delegation.
Query the specific record type directly using nslookup or dig, comparing the returned value against what it should actually be.
For CNAME-related issues, follow the full resolution chain manually — confirm the CNAME's target hostname, then confirm that target hostname's own A/AAAA record, watching specifically for a CNAME improperly coexisting with another record type at the same name.
For mail delivery issues specifically, check the MX record's target hostname and priority values, confirm that target resolves properly via A/AAAA (not CNAME), and separately check the sending server's PTR record for reverse-lookup consistency with its forward A record.
For a total, domain-wide resolution failure affecting every record type, investigate NS records and delegation consistency between the registrar and the actual authoritative name servers, rather than troubleshooting individual record entries.
Consider TTL values when a recently corrected record still appears to be returning stale/incorrect results — a long TTL can cause a fixed record to keep resolving to the old, incorrect value until the cached copy naturally expires across various resolvers.
Q1. Which DNS record type maps a hostname directly to an IPv6 address?
A. A
B. AAAA
C. CNAME
D. PTR
Answer: B. An AAAA record ("quad-A") maps a hostname to an IPv6 address, functionally paralleling how an A record maps a hostname to an IPv4 address. The name reflects that an IPv6 address is four times the bit-length of an IPv4 address.
Q2. A domain's MX record points to mail1.example.com, but that hostname has a CNAME record instead of an A record. What is the most likely result?
A. Mail delivery works normally, since CNAME and MX records are fully compatible
B. Mail delivery may fail or behave unpredictably, since an MX record's target hostname must resolve via A/AAAA, and CNAME records cannot coexist with other record types at the same name in the first place
C. The MX record will automatically be ignored in favor of the domain's own A record
D. This configuration is required for mail servers using IPv6
Answer: B. DNS rules do not allow a name with a CNAME record to simultaneously have other record types at that same name, and an MX record's target hostname must resolve to an actual IP address via its own A or AAAA record for mail delivery to succeed. A CNAME existing where an A record is expected for that mail target is a classic, specifically tested cause of unpredictable or failed mail delivery.
Q3. Which record type is used to perform a reverse lookup, resolving an IP address back to a hostname?
A. NS
B. MX
C. PTR
D. CNAME
Answer: C. A PTR (pointer) record performs reverse DNS resolution, mapping an IP address back to a hostname, stored in the in-addr.arpa zone for IPv4 or the ip6.arpa zone for IPv6 — the opposite direction from every other commonly tested record type, which map a hostname forward to an address or another hostname.
Q4. An organization's legitimate outbound email is frequently being rejected or marked as spam by external recipients, even though the domain's MX and A records are all correctly configured. What is a likely cause specific to this symptom?
A. The domain's NS records are misconfigured
B. The sending mail server's IP address has a missing or mismatched PTR record
C. The AAAA record is missing
D. The CNAME record has too many aliases
Answer: B. Many receiving mail servers check the sending server's reverse DNS (PTR record) as part of spam filtering, often also verifying that the PTR-resolved hostname's own forward A record matches back to the original sending IP address. A missing or mismatched PTR record on the sending mail server is a well-known, frequently tested cause of legitimate outbound email being rejected or flagged as spam, separate from the domain's own MX/A record configuration.
Q5. A domain suddenly fails to resolve for every single record type — web, mail, and every other hostname under that domain all stop working simultaneously. What category of DNS problem does this pattern most strongly suggest?
A. An incorrect AAAA record
B. A CNAME pointing to the wrong target
C. An NS record or delegation problem affecting the entire zone
D. An MX priority misconfiguration
Answer: C. A failure affecting literally every record type under a domain simultaneously, rather than being isolated to one specific service, points toward a problem with the zone's NS records or delegation itself — if resolvers can't successfully reach or identify the domain's authoritative name servers at all, no individual record within that zone can be resolved, regardless of how correctly those individual records are actually configured.
Q6. Which of the following correctly describes MX record priority values?
A. Higher numbers are tried first
B. Lower numbers indicate higher priority and are tried first
C. Priority values have no effect on delivery order
D. Priority values determine IPv4 versus IPv6 delivery
Answer: B. MX records use a preference/priority value where lower numbers indicate higher priority. A sending mail server will attempt delivery to the MX record with the lowest priority number first, only falling back to a higher-numbered (lower-priority) MX record if the primary server is unreachable or otherwise fails to accept the message.