DNS Zones and Resource Records
Understand DNS zones (forward and reverse lookup) and master all major DNS resource records including SOA, NS, A, AAAA, PTR, CNAME, TXT, and MX records. Learn their formats, use cases, and how to query them using nslookup.
Early in the course, we talked about name resolution and how resolvers can find the authoritative answer to a query via a series of iterative requests against servers down the domain name hierarchy. Obviously, those servers must store that kind of information somewhere to be able to respond to the DNS queries. And so, in this section, we will study the way the DNS data is stored and organized in name servers.
Again and again throughout the course, we have been referring to the DNS as a globally distributed collection of databases. This principle extends to DNS storage as well, since the DNS data is stored in a database that is known as a Zone.
Types of DNS Zones
There are two types of zones:
- Forward Lookup Zone: Used for resolving names to IP addresses, and it's the zone where most of the DNS data is stored
- Reverse Lookup Zone: Mainly stores information used for reverse name resolution (IP address to domain name)
Each of these zones is a collection of what we call Resource Records (RRs), and just like the records of any database, various sets of fields organized in rows. There are many types of resource records in DNS, and each resource record type contains a specific set of data.
Common Resource Record Format
Most DNS resource records follow a common structure with the following fields:
- Name of the Record - The domain name this record applies to
- Type of the Record - The record type (SOA, NS, A, AAAA, PTR, CNAME, TXT, MX, etc.)
- Class of the Record - Usually "IN" for Internet (99% of cases)
- TTL value - Time To Live, how long the record should be cached
- Resource Data Length - Length of the resource data field
- Resource Data - The actual data (IP address, domain name, text, etc.)
Types of Resource Records
Start of Authority (SOA)
- The SOA record indicates the beginning of a zone, and it should be the first resource record specified in any zone file
- There can be only one Start of Authority record per zone
- Contains critical zone management information including serial numbers, refresh intervals, and administrator contact
SOA Record Format
<domain name> <TTL> <class> SOA <m-name> <r-name> (
<serial number>
<refresh interval>
<retry interval>
<expire interval>
<minimum>
)
SOA Record Fields Explained
- Domain Name: The name of the domain this zone represents
- TTL: Time to live value for the SOA record
- Class: Resource record class, should be "IN" (Internet) in 99% of cases
- m-name: The name of the primary authoritative name server for the zone
- This is the name server that secondary DNS servers receive updates from in relation to the zone
- Primary name servers hold the master copy of the zone data
- r-name: Email address of the administrator responsible for the zone
- Note: There is no @ sign - dots replace the @ symbol
- Example:
info.example.comrepresentsinfo@example.com
- Serial Number: Version number of the zone, incremented by one every time a change is made to the zone file
- Secondary servers use this to determine if they need to update their zone data
- Refresh Interval: How often secondary name servers should check with the primary for updates
- Retry Interval: How long to wait before retrying a failed refresh
- Expire Interval: How long secondary servers should keep serving zone data if they can't reach the primary
- Minimum: TTL value for negative caching
- Historical purpose: Default TTL for records without explicit TTL
- Modern use: TTL value for negative answers (domain doesn't exist)
Querying SOA Records
nslookup -type=soa <hostname/IP address>
Linux Command (dig):
dig SOA <domain name>
Name Server (NS) Record
- NS records point to the authoritative name servers of a zone
- These name servers hold the actual DNS information for a domain so that domain can be accessible to internet users
- Without NS records, there would be no references to a domain's name servers, making the domain unreachable
- NS records ensure the availability of a domain
NS Record Requirements
- Every zone must have at least two NS records for redundancy
- Each NS record points to a different name server
- If one name server goes down or becomes unavailable, DNS queries can go to a different name server
- Name servers typically reside in topologically separate networks for further resiliency
When registering a domain, many DNS service providers by default provision sets of 4 name servers listed as:
- ns1.example.com
- ns2.example.com
- ns3.example.com
- ns4.example.com
NS Record Format
<domain name> <TTL> <class> NS <nameserver's hostname>
Syntax consists of a domain name such as example.com, a TTL value, resource record class (IN for internet in 99% of cases), resource record type (NS), and finally the name server's hostname such as ns1.example.com.
Querying NS Records
nslookup -type=ns <hostname/IP address>
Address Record (A)
- A resource record that stores the association between a domain name and an IPv4 address
- The primary record in DNS - the most commonly used record type
- Queried in forward lookup requests (domain name → IP address)
A Record Format
<domain name> <TTL> <class> A <IPv4 address>
It simply contains a domain name, TTL value, resource record class (IN), resource record type (A), and an IPv4 address.
Querying A Records
nslookup -type=a <hostname/IP address>
Quad-A Record (AAAA)
- The cousin of the A record - stores a domain name and an IPv6 address
- Represented by 4 A's to signify that the value stored is four times as big as an A record
- IPv4 address: 32 bits | IPv6 address: 128 bits (4× larger)
AAAA Record Format
<domain name> <TTL> <class> AAAA <IPv6 address>
Format is very similar to the A record: domain name, TTL value, resource record class (IN), resource record type (AAAA), and finally an IPv6 address.
It is perfectly possible for an A record and AAAA record to point to the same domain in cases where dual stack (IPv4 + IPv6) is required. This allows clients to connect using either protocol.
Querying AAAA Records
nslookup -type=aaaa <hostname/IP address>
Pointer Record (PTR)
- DNS supports reverse resolution where we have an IP address and want to resolve it to its associated name
- PTR records allow this to happen by pointing an IP address to a hostname
- Essential for reverse DNS lookups (IP → domain name)
PTR Record Format
<reverse domain name> <class> PTR <domain name>
The format of the pointer record features a reverse domain name (the IP address in reverse format), followed by .in-addr.arpa (a special domain representing the numerical hierarchy of DNS covering the entire IPv4 address space), resource record class (IN), resource record type (PTR), and finally the FQDN of the domain name that the IP address points to.
IPv4 vs IPv6 PTR Records
- IPv4: Uses
.in-addr.arpadomain - IPv6: Uses
.IP6.arpadomain (different namespace under the .arpa TLD) - Pointer records are placed inside the reverse lookup zone
Querying PTR Records
nslookup -type=PTR <hostname/IP address>
Canonical Name Record (CNAME)
- CNAME stands for Canonical Name - the real name of an object referenced by an alias
- Maps one domain name to another domain name
- Makes frequent appearances in DNS configuration, troubleshooting, and name resolution
CNAME Record Format
<alias> <class> CNAME <TTL> <canonical name>
Consists of an alias (e.g., www.example.com), resource record class (IN), resource record type (CNAME), TTL value, and a canonical name (the real name that www.example.com points to, which is example.com).
CNAME Use Cases
- Map subdomains to their apex domain (www.example.com → example.com)
- Redirect multiple TLDs to the same second-level domain
- Example: mydomain.com.au and mydomain.com.nz both redirect to mydomain.com
- Validate ownership or control of a domain
CNAME Restrictions
- A CNAME record must always point to another domain name and never directly to an IP address
- A CNAME record cannot point to an NS or MX record
- A CNAME record cannot co-exist with another record for the same name
CNAME Best Practice
A CNAME can point to another CNAME, a mechanism known as CNAME chaining. However, this is not recommended as it requires multiple DNS lookups before the domain can be loaded, which slows down the name resolution process and impacts user experience. It is considered best practice to point CNAME records directly to canonical names.
Querying CNAME Records
nslookup -type=cname <alias>
Text Record (TXT)
- The DNS Text (TXT) record lets a domain administrator enter text into the Domain Name System
- Originally intended as a place for human-readable notes
- Now also possible to put machine-readable data into TXT records
- One domain can have many TXT records
Example TXT Record
| example.com | record type: | value: | TTL |
|---|---|---|---|
| @ | TXT | This is an awesome domain! Not spammy. | 32600 |
TXT Record Format
<domain name> <class> TXT <TTL> <textual data>
Format of the text record is probably the easiest to remember: domain name, resource record class (IN), resource record type (TXT), TTL value, and textual information.
TXT Record Characteristics
- Official format involves using attribute-value pairs limited by an equal sign and enclosed by quotation marks
- Domain administrators can use their own formats - testament to TXT record flexibility
- Data can be any text the administrator wants to associate with their domain
- Originally intended for human-readable notes, now supports machine-readable data
- One domain can be associated with many TXT records
TXT Record Use Cases
- Associating domains with textual data
- Proving domain ownership - Used by services like Google, Microsoft to verify you own a domain
- Strengthening email security - SPF, DKIM, and DMARC records are TXT records
Querying TXT Records
nslookup -type=txt <domain name>
Mail Exchange Record (MX)
- Mail Exchange (MX) record is a very common record in DNS
- Maps a domain to an email server
- Email has always been heavily reliant on DNS - perhaps more so than any other TCP/IP-based application
- MX records provide the necessary infrastructure for email to work
MX Record Format
<domain name> <class> MX <TTL> <preference-value> <email-server>
Consists of: domain name, resource record class (IN), resource record type (MX), TTL value, preference value, and the hostname of an email server.
MX Record Details
- Why no @ symbol?
- As email clients, we use the @ sign to separate the mail server from the domain (support@example.com)
- For name servers, mail servers in MX records are configured with dots, not @
- Example:
primaryemail.example.cominstead ofprimaryemail@example.com
- Preference Value:
- Allows a DNS administrator to specify multiple email servers
- If the first server is down, emails are forwarded to the backup email server (redundancy)
- Lower preference value = Higher priority
- Possible to specify multiple backup email servers
- Companion A Records Required:
- MX records only specify the hostname of the email server
- A records must be defined alongside MX records to map the email server hostname to an IP address
- Without A records, name servers cannot forward email to the correct endpoint
- A records should be created for as many email servers as the domain is associated with
Querying MX Records
nslookup -type=mx <domain name>
- DNS Zones: Forward Lookup (name → IP) and Reverse Lookup (IP → name)
- SOA Record: First record in zone file, contains zone management info (serial, refresh, retry, expire)
- NS Record: Points to authoritative name servers, minimum 2 required for redundancy
- A Record: Maps domain name to IPv4 address - most common DNS record
- AAAA Record: Maps domain name to IPv6 address (4× larger than IPv4)
- PTR Record: Enables reverse DNS - maps IP to domain name using .in-addr.arpa (IPv4) or .IP6.arpa (IPv6)
- CNAME Record: Creates alias - maps one domain to another (avoid chaining)
- TXT Record: Stores text data - used for domain verification, SPF, DKIM, DMARC
- MX Record: Maps domain to email server with preference values (lower = higher priority)
- All records share common format: name, TTL, class (IN), type, data
- Query records using nslookup (Windows) or dig (Linux)
📚 Practice Exercises
- Query the SOA record for google.com and identify the primary name server
- Find all NS records for your favorite website - how many name servers do they have?
- Perform a reverse DNS lookup on 8.8.8.8 using PTR records
- Check if www.example.com uses a CNAME record pointing to example.com
- Query TXT records for a domain and identify any SPF or DKIM records
- Find the MX records for gmail.com and identify which has the highest priority
- Create a sample zone file with SOA, NS, A, and MX records for a fictional domain
- Explain why MX records require companion A records
- Describe the difference between A and AAAA records and when you'd use both
- Explain why CNAME chaining is not recommended
No comments:
Post a Comment