DNS Record Types and Troubleshooting Cues
Key Takeaways
- DNS maps names to data: A and AAAA for addresses, CNAME for aliases, MX for mail, NS/SOA for authority, PTR for reverse lookups, TXT for verification, and SRV for service location.
- A records map a hostname to IPv4 (32-bit); AAAA records map to IPv6 (128-bit) - the extra A reminds you it is the larger address family.
- Recursive resolvers cache answers for the record's TTL; lowering TTL before a cutover lets stale answers age out faster.
- Authoritative servers hold the final answer for a zone; forwarders and split DNS change which answer a client receives.
- On the N10-009 exam, match the symptom to the record: name fails but IP works = A/AAAA/CNAME; mail fails = MX/TXT; reverse lookup fails = PTR.
Why DNS Sits Under Everything
The Domain Name System (DNS) translates human-friendly names into the data clients actually need: IP addresses, mail servers, and service endpoints. A server can be powered on, patched, and reachable by IP while every user reports an outage, because the name resolves to the wrong place or fails to resolve at all. The N10-009 blueprint expects you to read a symptom and name the specific record at fault.
DNS query traffic uses UDP port 53 for normal lookups and TCP port 53 for zone transfers and responses larger than 512 bytes. Newer privacy variants you should recognize by name are DNS over HTTPS (DoH) on TCP 443 and DNS over TLS (DoT) on TCP 853. Knowing the port a firewall must permit is a frequent exam detail. Remember that DoH blends into ordinary web traffic on 443, which makes it harder for a security team to inspect or block, while DoT is easier to identify on its dedicated port 853. The exam likes to ask which variant a firewall can filter by port versus which one hides inside HTTPS.
Keep one mental model: DNS is a layered system. The client asks a recursive resolver, the resolver walks the delegation chain from root to TLD to the authoritative server, and the answer flows back and is cached at every layer for the record's TTL. A failure at any layer looks identical to the end user - the name simply will not resolve - so the troubleshooting skill the exam tests is isolating which layer broke.
Common DNS Records
| Record | Maps / Stores | Symptom clue on the exam |
|---|---|---|
| A | Name to a 32-bit IPv4 address | app.example.com -> 192.0.2.10; name fails, IP works |
| AAAA | Name to a 128-bit IPv6 address | dual-stack host unreachable over IPv6 only |
| CNAME | Alias pointing to another name | www -> web-prod.example.com; never coexists with other records for the same name |
| MX | Mail exchanger plus priority value | inbound email bounces; lowest priority number is preferred |
| TXT | Free-form text | SPF, DKIM, DMARC, domain-ownership verification |
| NS | Authoritative name servers | delegation or zone-authority problem |
| SOA | Zone authority, serial, refresh/retry timers | replication or zone-version issue |
| PTR | IP address back to a name | reverse lookup fails; mail reputation checks |
| SRV | Host, port, weight, priority for a service | Active Directory logon, SIP/VoIP discovery |
A classic trap: a CNAME cannot share its name with any other record type, so you cannot put a CNAME on a zone apex (example.com) that already needs MX or NS records. If web users cannot turn a hostname into an IPv4 address, the A record is the first suspect. If email for a domain fails, inspect MX and the TXT-based SPF/DKIM/DMARC entries that receiving servers validate.
Resolution Roles, Split DNS, and TTL
| Role | Function |
|---|---|
| Stub resolver | OS-level resolver library on the client |
| Recursive resolver | Performs full lookups for clients and caches answers |
| Authoritative server | Holds the definitive answer for a zone |
| Forwarder | Sends unresolved queries to a specific upstream resolver |
| Root and TLD servers | Locate authoritative servers through delegation |
Internal networks frequently run split-horizon (split) DNS: internal clients receive private RFC 1918 answers while external clients receive public answers for the same name. A site that resolves a record internally but not externally points straight at split DNS or a missing public zone entry.
TTL and cutover procedure
The time-to-live (TTL) value tells every recursive resolver how long to cache an answer. Long TTLs cut query load but slow changes; short TTLs speed migrations but raise traffic. A safe cutover:
- Lower the TTL (for example to 300 seconds) a day before the change.
- Wait for the old TTL window to elapse so caches expire.
- Update the record to the new target.
- Validate from multiple resolver paths (internal, ISP, public 8.8.8.8).
- Restore a normal TTL once the service is stable.
If some users hit the old server and others hit the new one, stale cached answers or inconsistent authoritative records are the cause - not a routing fault.
Troubleshooting Cues and Tools
| Symptom | First place to check |
|---|---|
| Host works by IP but not by name | A, AAAA, CNAME, DNS search suffix, resolver setting |
| Email will not route to a new provider | MX records and their TTL |
| Reverse lookup fails | PTR record and reverse-zone delegation |
| Resolves internally but not externally | Split DNS or missing public zone record |
| Wrong answer only at one office | Local recursive cache or a conditional forwarder |
| Browser resolves but the app still fails | DNS already succeeded; move to port, TLS, or app layer |
Use nslookup or dig to query specific record types directly against an authoritative server; use ipconfig /displaydns and ipconfig /flushdns (Windows) or resolvectl (Linux) for client cache state. Ping is only a weak name-resolution clue - ICMP may be blocked, so ping failure alone does not prove a DNS fault.
PBQ-style DNS scenario
Facts: users connect to 10.20.30.40 directly; portal.example.com still resolves to 10.20.30.25; a migration moved the portal to 10.20.30.40; some users still reach the old service. Best actions: query the authoritative server for portal.example.com, verify the A/CNAME chain points to 10.20.30.40, check TTL and resolver caches, flush or wait out caches, then confirm firewall and app access to the new IP. The decision gate is whether DNS returns the correct answer; once it does, move to transport and application troubleshooting.
Users can reach a web server by its IPv4 address but not by hostname. Which DNS record should be checked first?
An administrator must add a record at the zone apex (example.com) that already publishes MX and NS records. Which record type is NOT permitted there?
Which two records are commonly involved in email delivery and validation?