This chapter covers the seven essential DNS record types you must master for the CompTIA Network+ N10-009 exam: A, AAAA, MX, CNAME, PTR, TXT, and SRV. DNS records are the backbone of network name resolution, and understanding their structure, usage, and troubleshooting is critical—approximately 10-15% of exam questions touch DNS concepts. We'll dissect each record type, explain its format, show configuration examples, and highlight common exam traps. By the end, you'll be able to identify, configure, and troubleshoot these records with confidence.
Jump to a section
Think of DNS as a city's master directory, and each record type as a specific kind of listing. The A record is like a street address (IPv4) for a building. The AAAA record is the same building but with a longer, more complex address (IPv6). The MX record is like a postal service routing number—it tells mail carriers which building handles mail for that street, and includes a priority number so if one mail center is closed, the next one is tried. The CNAME record is like a 'formerly known as' sign: it points a nickname to the official name. The PTR record is a reverse lookup—like using a phone number to find the building's name. The TXT record is a bulletin board where anyone can post notes (SPF, DKIM, etc.). The SRV record is like a directory that says 'for this service (e.g., VoIP), go to this specific building and talk to this person (port).' Each record type has a specific format and purpose, and the resolver reads them exactly like a directory assistant reads a card catalog.
Overview of DNS Record Types
DNS (Domain Name System) is a hierarchical distributed database that maps domain names to various types of data. Each record type serves a distinct purpose. For the N10-009 exam, you need to know the syntax, use cases, and verification of the following record types: A, AAAA, MX, CNAME, PTR, TXT, and SRV.
A Record (Address Record)
- Purpose: Maps a hostname to an IPv4 address (32-bit).
- Format: <name> IN A <IPv4_address>
- Example: www.example.com. IN A 192.0.2.10
- TTL: Default often 300-86400 seconds; lower TTL for dynamic environments.
- Usage: Most common record; used for web servers, mail servers, etc.
- Exam Tip: The A record only returns IPv4; for IPv6, use AAAA.
- Trap: Candidates often think A records can point to multiple IPs (they can, via multiple A records for the same name, but that's round-robin, not failover by default).
AAAA Record (IPv6 Address Record)
- Purpose: Maps a hostname to an IPv6 address (128-bit).
- Format: <name> IN AAAA <IPv6_address>
- Example: www.example.com. IN AAAA 2001:db8::1
- TTL: Same as A record.
- Usage: Required for IPv6-only networks; often used alongside A records (dual-stack).
- Exam Tip: The name 'AAAA' is because IPv6 addresses are four times longer than IPv4.
- Trap: AAAA queries do not fall back to A; if a client prefers IPv6 but only has an A record, the query fails unless the client tries A as well.
MX Record (Mail Exchange Record)
- Purpose: Directs email to a mail server for a domain.
- Format: <domain> IN MX <priority> <mailserver>
- Example: example.com. IN MX 10 mail1.example.com.
- Example: example.com. IN MX 20 mail2.example.com.
- Priority: Lower number = higher priority. Range 0-65535.
- Usage: Multiple MX records for redundancy; priority determines order.
- Exam Tip: MX records point to a hostname, not an IP. The hostname must have an A or AAAA record.
- Trap: Candidates think MX records can point directly to an IP; they cannot—they must point to a hostname.
CNAME Record (Canonical Name Record)
- Purpose: Aliases one hostname to another (canonical name).
- Format: <alias> IN CNAME <canonical_name>
- Example: www.example.com. IN CNAME example.com.
- Restrictions:
Cannot coexist with other record types for the same name (e.g., you cannot have both an A and CNAME for www.example.com).
Cannot point to an IP address.
Must point to a hostname that has an A or AAAA record.
Usage: Common for web servers (www → root domain), content delivery networks.
Exam Tip: CNAME creates a dependency; if the canonical name fails, the alias fails.
Trap: Candidates think CNAME can point to an IP or be used at the zone apex (root domain). It cannot—at the apex, use an A record.
PTR Record (Pointer Record)
- Purpose: Maps an IP address to a hostname (reverse DNS lookup).
- Format: <reverse_ip> IN PTR <hostname>
- Example: 10.0.2.192.in-addr.arpa. IN PTR www.example.com.
- Structure: Stored in special reverse zones: in-addr.arpa for IPv4, ip6.arpa for IPv6.
- Usage: Email servers use PTR to verify sender domain (anti-spam).
- Exam Tip: PTR records must match the forward A record (FCrDNS) for mail delivery.
- Trap: Candidates forget that PTR is manually configured; it's not automatically created.
TXT Record (Text Record)
- Purpose: Stores arbitrary text data, often used for verification and security.
- Format: <name> IN TXT "<text>"
- Example: example.com. IN TXT "v=spf1 include:_spf.google.com ~all"
- Usage:
SPF (Sender Policy Framework): Lists authorized mail servers.
DKIM (DomainKeys Identified Mail): Public key for email signing.
DMARC (Domain-based Message Authentication, Reporting & Conformance): Policy for email authentication.
Domain verification (e.g., Google Workspace).
Exam Tip: TXT records can be multiple strings; each string is enclosed in quotes.
Trap: Candidates think TXT records are only for human-readable notes; they are critical for email authentication.
SRV Record (Service Record)
- Purpose: Specifies the location (hostname and port) of a specific service.
- Format: _service._proto.name. IN SRV <priority> <weight> <port> <target>
- Example: _sip._tcp.example.com. IN SRV 10 5 5060 sipserver.example.com.
- Fields:
Priority: Lower = preferred.
Weight: Within same priority, higher weight = more traffic.
Port: TCP/UDP port number.
Target: Hostname (must have A/AAAA record).
Usage: VoIP (SIP), LDAP, Kerberos, Xbox Live.
Exam Tip: SRV records enable clients to discover services without hardcoding ports.
Trap: Candidates forget that SRV records require a target hostname, not an IP.
Record Type Comparison Table
| Record | Purpose | Example | Key Restriction |
|--------|---------|---------|-----------------|
| A | IPv4 mapping | www IN A 192.0.2.1 | None |
| AAAA | IPv6 mapping | www IN AAAA 2001:db8::1 | None |
| MX | Mail server | @ IN MX 10 mail.example.com. | Points to hostname |
| CNAME | Alias | www IN CNAME example.com. | No other records at same name |
| PTR | Reverse mapping | 1.2.0.192.in-addr.arpa IN PTR www.example.com. | Requires reverse zone |
| TXT | Text data | @ IN TXT "v=spf1 ..." | None |
| SRV | Service location | _sip._tcp IN SRV 10 5 5060 sip.example.com. | Underscore prefix |
Configuration and Verification
- Linux: Use dig, nslookup, or host.
- dig example.com A - query A record
- dig -x 192.0.2.1 - query PTR record
- dig example.com MX - query MX
- dig _sip._tcp.example.com SRV - query SRV
- Windows: nslookup or Resolve-DnsName (PowerShell).
- Exam Tip: Know that nslookup is interactive; dig is more detailed.
Interaction with Related Technologies
DHCP: Can dynamically update DNS (DDNS) for A and PTR records.
Email: MX, TXT (SPF, DKIM, DMARC) work together for email delivery.
Load Balancing: Multiple A records provide simple round-robin; SRV with weight provides more control.
IPv6: AAAA records are essential; PTR records in ip6.arpa.
Common Exam Scenarios
Scenario 1: A user cannot reach a website. Check A record for the hostname.
Scenario 2: Email is not being delivered. Check MX, PTR, and SPF (TXT) records.
Scenario 3: VoIP phone cannot register. Check SRV record for SIP service.
Scenario 4: Alias not resolving. Ensure CNAME is not at zone apex and target exists.
RFC References
A: RFC 1035
AAAA: RFC 3596
MX: RFC 1035
CNAME: RFC 1035
PTR: RFC 1035
TXT: RFC 1035
SRV: RFC 2782
Client initiates DNS query
A user types a URL (e.g., www.example.com) in a browser. The client checks its local DNS cache. If not found, it sends a recursive query to its configured DNS resolver (typically provided by DHCP). The query is a UDP packet to port 53, unless the response is truncated (then TCP is used). The resolver then begins iterative queries starting from the root DNS servers.
Resolver queries root and TLD servers
The resolver first asks a root server for the .com TLD nameserver. The root responds with a referral to the .com TLD servers. The resolver then queries the .com TLD server for example.com, which responds with the authoritative nameservers for example.com. Each referral includes glue records (A/AAAA) for the next-level nameservers to avoid additional lookups.
Resolver queries authoritative nameserver
The resolver queries the authoritative nameserver for example.com (e.g., ns1.example.com). The query type matches the record needed (e.g., A record for www.example.com). The authoritative server checks its zone file for a matching record. If found, it returns the record with its TTL. If not, it may return an NXDOMAIN (non-existent domain) or a referral to another zone.
Record returned and cached
The resolver receives the response (e.g., A record with IP 192.0.2.10) and caches it for the duration of the TTL. The resolver then returns the answer to the client. The client caches the record locally (in the browser or OS cache) and uses the IP to establish a connection. Subsequent queries for the same record within TTL will be answered from cache.
Troubleshooting with dig
A network engineer uses dig to verify DNS resolution. For example: dig www.example.com A. The output shows the query, answer section (the record), authority section (nameservers), and additional section (glue records). The engineer checks the status (NOERROR, NXDOMAIN, SERVFAIL), TTL, and IP address. If the record is wrong, they check the zone file on the authoritative server. If no response, they check firewall rules (UDP 53) or resolver configuration.
In a typical enterprise, DNS records are critical for both internal and external services. For example, a company running its own mail server (e.g., Microsoft Exchange) must have correct MX records. The domain company.com might have two MX records: priority 10 pointing to mail1.company.com and priority 20 to mail2.company.com. Each mail server hostname must have an A record. Additionally, SPF (TXT) records are configured to authorize those mail servers to send email: v=spf1 mx include:_spf.google.com ~all. Without proper SPF, email may be marked as spam. PTR records must also match the sending server's hostname for reverse DNS validation; many receiving mail servers reject email if the PTR does not match the EHLO hostname.
Another scenario: a company uses a CDN for its website. The web server www.company.com is a CNAME that points to cdn.example.net. This allows the CDN to manage the IP addresses dynamically. However, the root domain company.com cannot use a CNAME (per RFC 1912), so it must have an A record pointing to a static IP or use a service like ALIAS (ANAME) which is not standard DNS. The N10-009 exam expects you to know this restriction.
For VoIP services, SRV records are essential. A company deploying SIP phones would create: _sip._tcp.company.com IN SRV 10 5 5060 sipserver.company.com. The underscore prefixes are required. If the SRV record is missing or misconfigured (e.g., wrong port), phones cannot register. Common mistakes include forgetting the trailing dot in the target hostname or using an IP address instead of a hostname. The exam may present a scenario where users cannot make calls, and you must identify the missing SRV record.
Performance considerations: DNS TTL values must balance freshness and load. Low TTL (e.g., 300 seconds) is good for dynamic environments but increases query load. High TTL (e.g., 86400 seconds) reduces load but delays propagation of changes. For failover, multiple A records with low TTL can be used, but clients may cache the failed IP. More robust solutions use SRV with weight or load balancers.
Misconfiguration examples: A common error is creating a CNAME for the root domain (e.g., company.com IN CNAME ...). This is not allowed and will cause resolution failures. Another is forgetting to add a trailing dot to fully qualified domain names (FQDNs) in zone files—the resolver may append the domain name incorrectly. Also, mixing up priority and weight in SRV records leads to unexpected traffic distribution.
The N10-009 exam (Objective 2.5) tests your ability to identify, configure, and troubleshoot DNS record types. You must know the syntax and purpose of each record type. Expect scenario-based questions where you choose the correct record to solve a problem.
Common Wrong Answers and Traps:
1. Using CNAME at the zone apex: Many candidates think you can create a CNAME for example.com. The exam will test this with a question like: 'A company wants their root domain to point to a CDN. Which record should they use?' The wrong answer is CNAME; the correct answer is A (or ALIAS if available, but not standard).
2. MX record pointing to an IP: Candidates often select an answer that lists an IP address in the MX record. The exam expects you to know that MX must point to a hostname.
3. Confusing A and AAAA: A question may ask which record is used for IPv6. The obvious wrong answer is 'A' because it's familiar; the correct answer is 'AAAA'.
4. PTR record configuration: Candidates may think PTR records are automatically created from A records. The exam will test that PTR must be manually configured in reverse zones.
5. SRV record format: The exam may present a malformed SRV record (e.g., missing underscore, wrong order of fields). You must identify the error.
Specific Numbers and Terms to Memorize:
- MX priority range: 0-65535, lower is higher priority.
- SRV fields: priority, weight, port, target (in that order).
- Default DNS port: UDP 53 (TCP 53 for zone transfers or large responses).
- TTL values: often measured in seconds; typical values: 300 (5 min), 3600 (1 hour), 86400 (1 day).
- CNAME restriction: cannot coexist with other record types at the same name.
- PTR reverse zones: in-addr.arpa for IPv4, ip6.arpa for IPv6.
Edge Cases: - CNAME chain: Multiple CNAMEs in a row (e.g., a -> b -> c) are allowed but inefficient; the exam may test that you cannot have a CNAME pointing to another CNAME? Actually you can, but it's bad practice. The exam might present a scenario with a CNAME chain and ask about resolution order. - Wildcard records: An asterisk (*) can be used in A, AAAA, MX, etc., but not in CNAME or PTR. The exam may test that wildcard CNAME is not allowed. - DNSSEC: Not directly tested, but you should know that DNS records can be signed with DNSSEC to ensure authenticity.
How to Eliminate Wrong Answers: - If the question asks for IPv6, eliminate any answer that mentions 'A' without 'AAA'. - If the question involves email, look for MX or TXT (SPF). - If the question involves a service with a port, look for SRV. - If the question involves an alias, look for CNAME, but check if it's at the apex. - If the question involves reverse lookup, look for PTR. - Always verify the format: trailing dots, underscores, and field order.
A records map hostnames to IPv4 addresses; AAAA records map to IPv6 addresses.
MX records must point to a hostname, not an IP, and use priority for mail server selection.
CNAME records create aliases but cannot be used at the zone apex or point to an IP.
PTR records provide reverse DNS lookup and must be manually configured in in-addr.arpa or ip6.arpa.
TXT records store text data, commonly used for SPF, DKIM, and DMARC email authentication.
SRV records define service location with priority, weight, port, and target hostname.
Common exam traps include confusing A/AAAA, using CNAME at apex, and MX pointing to IP.
Use dig or nslookup to query specific record types: dig example.com A, dig -x 192.0.2.1, etc.
These come up on the exam all the time. Here's how to tell them apart.
A Record
Maps hostname to IPv4 address (32-bit)
Format: name IN A ipv4
Used for IPv4 networks
Example: www IN A 192.0.2.1
Most common record type
AAAA Record
Maps hostname to IPv6 address (128-bit)
Format: name IN AAAA ipv6
Used for IPv6 networks
Example: www IN AAAA 2001:db8::1
Increasingly important with IPv6 adoption
CNAME Record
Alias for a hostname
Cannot coexist with other records at same name
Cannot point to IP
Used for web servers, CDN
Not allowed at zone apex
MX Record
Directs email to mail server
Uses priority for failover
Must point to a hostname
Can coexist with other records
Often used with multiple servers
TXT Record
Stores arbitrary text
Used for SPF, DKIM, DMARC
No special format requirements
Can be multiple strings
No port or priority fields
SRV Record
Specifies service location
Includes priority, weight, port
Requires underscore prefix (_service._proto)
Target must be hostname
Essential for VoIP and LDAP
Mistake
CNAME records can point to an IP address.
Correct
CNAME must point to a hostname (FQDN), not an IP. The target hostname must have an A or AAAA record.
Mistake
MX records can point directly to an IP address.
Correct
MX records must point to a hostname (e.g., mail.example.com), which then must have an A or AAAA record. The mail server's IP is resolved separately.
Mistake
PTR records are automatically created when you add an A record.
Correct
PTR records are not automatic; they must be manually configured in the reverse zone (in-addr.arpa or ip6.arpa) by the administrator who controls the IP address space.
Mistake
You can have a CNAME for the root domain (e.g., example.com).
Correct
Per RFC 1912, a CNAME record cannot exist at the zone apex because the zone apex must have SOA and NS records. Using a CNAME there would conflict with those required records.
Mistake
SRV records can point to an IP address.
Correct
SRV records, like MX, must point to a hostname (target). The target must have an A or AAAA record. The port is specified separately in the SRV record.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An A record maps a hostname to an IPv4 address (32-bit), while an AAAA record maps to an IPv6 address (128-bit). Both are used for forward DNS resolution. The exam expects you to know that IPv6 uses AAAA, not A. For dual-stack networks, both records are often configured for the same hostname.
No, you cannot use a CNAME at the zone apex because the apex must contain SOA and NS records. CNAME records cannot coexist with any other record type. Instead, use an A record (or AAAA) for the root domain. Some DNS providers offer an ALIAS or ANAME record to mimic CNAME behavior at the apex, but this is non-standard and not tested on N10-009.
Email rejection often occurs due to missing or misconfigured DNS records. First, ensure MX records point to the correct mail server hostname. Second, the mail server's IP must have a PTR record that matches the hostname used in the EHLO command (FCrDNS). Additionally, SPF (TXT) records must authorize the sending server. Use dig example.com MX and dig -x <ip> to verify.
The SRV record format is: _service._proto.name. TTL class SRV priority weight port target. For example: _sip._tcp.example.com. 3600 IN SRV 10 5 5060 sipserver.example.com. Priority determines preference (lower is better), weight distributes load within same priority, port is the service port, and target is the hostname (not IP). The underscores are mandatory.
To query a PTR record, use the -x option: dig -x 192.0.2.1. This automatically constructs the reverse lookup name (e.g., 1.2.0.192.in-addr.arpa) and queries for PTR. Alternatively, you can manually query: dig 1.2.0.192.in-addr.arpa PTR. For IPv6, use: dig -x 2001:db8::1.
Technically yes, but it is not recommended because it creates a chain that may cause resolution failures and additional latency. RFC 1034 suggests that CNAMEs should point to a hostname with an A or AAAA record. The exam may test that CNAME chains are allowed but inefficient. In practice, avoid chaining.
SPF (Sender Policy Framework) uses TXT records to list authorized mail servers for a domain. The format is: v=spf1 include:... ~all. Receiving mail servers check the SPF record to verify that the sending server is authorized. Without a proper SPF record, email may be flagged as spam. SPF is one of several uses of TXT records; others include DKIM and DMARC.
You've just covered DNS Record Types: A, AAAA, MX, CNAME, PTR, TXT, SRV — now see how well it sticks with free N10-009 practice questions. Full explanations included, no account needed.
Done with this chapter?