DNS Record Types and Troubleshooting Cues
Key Takeaways
- DNS maps names to data such as IP addresses, mail exchangers, service locations, aliases, and text records.
- A and AAAA records map hostnames to IPv4 and IPv6 addresses respectively.
- CNAME creates an alias, MX identifies mail exchangers, TXT stores text values, and SRV identifies service location.
- TTL affects how long resolvers cache DNS answers before checking again.
- DNS troubleshooting should distinguish name resolution failure from routing, firewall, or application failure.
DNS is a dependency for many network services. A server can be healthy and reachable by IP address while users still report an outage because the name resolves incorrectly.
Common DNS Records
| Record | Purpose | Example clue |
|---|---|---|
| A | Maps a name to an IPv4 address | app.example.com -> 192.0.2.10 |
| AAAA | Maps a name to an IPv6 address | app.example.com -> 2001:db8::10 |
| CNAME | Creates an alias to another name | www points to web-prod.example.com |
| MX | Identifies mail servers for a domain | Mail delivery problem |
| TXT | Stores text values | SPF, DKIM, DMARC, ownership verification |
| NS | Identifies authoritative name servers | Delegation or zone authority issue |
| SOA | Identifies zone authority and timers | Zone serial and replication clue |
| PTR | Maps IP address back to a name | Reverse lookup and mail reputation checks |
| SRV | Identifies service host and port | Directory, voice, or service discovery |
Network+ questions often give a symptom and ask which record is missing or wrong. If web users cannot resolve a hostname to an IPv4 address, think A record. If email for a domain fails, check MX and related TXT records.
DNS Resolution Roles
| Role | Function |
|---|---|
| Stub resolver | Client-side resolver library or OS component |
| Recursive resolver | Performs lookups on behalf of clients and caches answers |
| Authoritative server | Holds final answers for a DNS zone |
| Forwarder | DNS server that sends queries to another resolver |
| Root and TLD servers | Help locate authoritative servers through delegation |
Internal networks often use split DNS, where internal clients receive private answers and external clients receive public answers for the same or related names.
TTL and Caching
TTL is the time-to-live value that tells resolvers how long to cache an answer. A long TTL reduces query load but makes changes slower to take effect. A short TTL can help during migrations but increases query traffic.
Migration pattern:
- Lower the TTL before the planned change.
- Wait for old cached records to expire.
- Change the record to the new target.
- Validate from multiple resolver paths.
- Raise the TTL after the service is stable.
If some users reach the old server and others reach the new server, cached DNS answers or inconsistent authoritative records may be involved.
Troubleshooting Cues
| Symptom | Likely area to check |
|---|---|
| Host works by IP but not by name | A, AAAA, CNAME, search suffix, resolver settings |
| Email does not route to the new provider | MX records and TTL |
| Reverse lookup fails | PTR record and reverse zone delegation |
| Some sites resolve internally but not externally | Split DNS or public zone records |
| Wrong answer only from one office | Local recursive resolver cache or conditional forwarder |
| Browser resolves but app still fails | Firewall, port, TLS, or application issue after DNS succeeds |
Useful commands include nslookup and dig for querying records, ipconfig or resolvectl for client resolver state depending on platform, and ping only as a limited name resolution clue. Ping failure alone does not prove DNS failure because ICMP may be blocked.
PBQ-Style DNS Scenario
Facts:
- Users can connect to 10.20.30.40 directly.
- The name portal.example.com resolves to 10.20.30.25.
- A recent migration moved the portal to 10.20.30.40.
- Some users still reach the old service.
Best actions:
- Query the authoritative DNS server for portal.example.com.
- Verify the A or CNAME chain points to the new target.
- Check TTL and resolver caches.
- Flush or wait out caches where appropriate.
- Confirm firewall and application access to the new IP after DNS resolves correctly.
The decision point is whether DNS returns the correct answer. Once the name resolves to the correct address, move to transport and application troubleshooting.
Users can reach a web server by IPv4 address but not by hostname. Which DNS record should be checked first?
Which DNS records are commonly involved in email delivery and validation? Choose two.
Select all that apply
Order the steps for a planned DNS cutover.
Arrange the items in the correct order