What Is a DNS Zone?

What Is a DNS Zone?

The Domain Name System (DNS) is a naming database that enables your computer to identify and translate a domain name (e.g., google.com) into an IP address (e.g., 74.125.226.72). DNS zones are specific portions of the DNS managed by a particular organization or administrator. These DNS zones are critical to the DNS as a whole as they simplify the management of DNS records across large, distributed networks. This article is a deep-dive into DNS zones. We explain what DNS zones are, how they work, and why they are important for managing DNS records.

Understanding the Basics of DNS Zones

A DNS zone is a logical entity that refers to a specific domain and its subdomains managed by a single administrator. This concept is quite complex, so let’s break it down.

What Exactly Is a DNS Zone?

A DNS zone is not a material entity. It is a term people use to show that a specific domain—or a part of it (a subdomain/subdomains)—is managed by a single administrator. The administrator can manage DNS records related to their DNS zone by changing, adding, or deleting records.

When you buy a domain, you automatically get control of its DNS zone; you can manage the DNS record of this domain and its subdomains. However, if you want, you can separate out (delegate) some subdomains so that they are managed by someone else. Such a separation means that you create a new DNS zone which contains only the separated subdomain(s).

Why Create a Separate DNS Zone?

The domain owner can separate subdomains and create a new DNS zone for the convenience of managing DNS records. For example, gcore.com has many subdomains, including:

  • account.gcore.com
  • api.gcore.com
  • speedtest.gcore.com

Let’s say a dedicated team is responsible for the speedtest. To allow them autonomy, we can separate speedtest.gcore.com into a separate DNS zone and let the speed test team become the administrator. If they want to move the speed test to different servers, or perhaps link it to a mail server, they can do so themselves without affecting the main site or requiring an external approval process.

FAQs About DNS Zones

What components does a DNS zone include?

A DNS zone includes resource records as its components. One SOA and two NS records are mandatory.

Are top-level domains also DNS zones?

Yes. They simply delegate control over their subdomains (i.e., second-level domains) to the owners of those subdomains.

How can you separate subdomains into a separate DNS zone?

You need to add NS records for the relevant subdomains to the main domain. For more info, check out the DNS Zone Delegation section of this article.

Does each DNS zone correspond to one file with its DNS records?

Yes. One DNS zone corresponds to one file that contains all the DNS records for that specific DNS zone.

Can one DNS zone contain different second-level domains?

No, it can only contain subdomains of the same domain or the domain itself.

Are DNS zones tied to specific DNS servers?

No. One DNS zone corresponds to one file with DNS records. Such a file can be stored on any DNS server. In other words, different files for different DNS zones can be stored on the same server.

What Is a DNS Zone File?

A DNS zone file is usually presented in the form of a plain-text file containing all the important information about a domain name. It contains resource records that are used to map and link domain names to corresponding requests.

A DNS zone file typically contains a Start of Authority (SOA) and NS record and other relevant resource records (RRs,) including—but not limited to—MX, CNAME, A, and TXT records. Let’s take a quick look at what the most common types of records do.

Resource records in DNS zone filesFunction(s)
SOA (start of authority) recordsProvide the primary source of authority for the domain, including all essential information like the primary DNS server, contact email address, and settings that control how the domain operates
NS (nameserver) recordsSpecify IP addresses of authoritative nameservers and which servers are responsible for providing DNS information about the domain
A (address) recordsMap the domain names to their associated IP addresses
MX (mail exchange) recordsIdentify the mail servers responsible for handling email for the domain
CNAME (canonical name) recordsProvide an alias with an actual domain name for existing A records.
TXT (text) recordsContain text-based information associated with the domain, such as SPF (Sender Policy Framework) records used for domain ownership validation.

What Does a DNS Zone File Look Like?

Here is an example of what a DNS zone file for gcore.com could look like in BIND format:

$TTL 1h
@               IN      SOA     dns1.gcore.com. hostmaster.gcore.com. (
                        20211209
                        1d
                        2h
                        4w
                        1h
                        )

                IN      NS      dns1.gcore.com.
                IN      NS      dns2.gcore.com.

                IN      MX      10      mail.gcore.com.

dns1            IN      A       192.168.0.1
dns2            IN      A       192.168.0.2
mail            IN      A       192.168.0.3
web             IN      A       192.168.0.4

www             IN      CNAME   web
ftp             IN      CNAME   web

@		IN	TXT     "v=spf1 a mx include:spf.gcore.com ~all"
spf		IN	TXT	"v=spf1 include:spf.protection.outlook.com include:spf.emailsignatures365.com -all"

In this example, the DNS zone file begins with a time-to-live (TTL) directive, which sets the duration for caching DNS records. The “@” symbol represents the root of the domain. Next is the start of authority (SOA) record, which identifies the primary DNS server for the domain, and includes the administrator’s email address. Two nameservers are specified using the IN NS (Internet Nameserver) command, and an MX record is added to designate the mail server, and assign it a priority value of 10.

Several A records are included to define the IP address of various servers. These A records specify the DNS server, mail server and web server IP addresses. The zone file also contains CNAME records, which serve as aliases or alternative names for the web server. This allows different domain names to point to the same web server. Finally, a TXT record is included to specify the Sender Policy Framework (SPF) record for email authentication purposes. This record helps verify that incoming emails originate from authorized servers.

By structuring the DNS zone files like this, administrators can effectively manage the DNS records for their domain. This ensures proper routing of emails, website accessibility, and email authentication.

DNS Zone Delegation

DNS zone delegation is a process that involves dividing a larger DNS zone into smaller zones and assigning them to different DNS servers. This process enables more efficient and localized handling of DNS queries, particularly for larger organizations with multiple subdomains. By delegating zones, the burden on a single server is reduced, leading to improved performance and availability of the overall DNS infrastructure.

Let’s consider a scenario where a large organization manages a primary domain (e.g., example.com) as well as several subdomains (e.g., it.example.com, europe.example.com, us.example.com, etc.) To optimize DNS operations, the organization can delegate each subdomain to separate DNS servers, distributing the workload and enhancing efficiency.

How To Delegate a DNS Zone

To delegate a DNS zone, certain steps need to be followed. The administrator must create NS (nameserver) records for the subdomain. These NS records assign the authoritative servers responsible for handling DNS queries for the subdomain. For example, if the administrator delegates it.example.com subdomain, an NS needs to be added to the example.com zone file. This NS record signifies that the zone file governing the “it” subdomain has the authority to handle all associated DNS queries.

How Do DNS Zones Work?

Imagine that you own the domain example.com. Whenever someone enters example.com into their web browser, their device sends a DNS query to a server requesting the IP address for your website. The server then searches for authoritative DNS zones related to your domain and asks them for the IP address of your website. Once obtained, this IP address is used to establish a connection between the visitor’s device and the server hosting your website.

As the website owner or administrator, DNS zones allow you to manage DNS records for specific parts of your domain. For example, you can have separate DNS zones for mail.example.com or blog.example.com without affecting the records for the entire example.com domain.

To create such a DNS zone, you must specify the subdomain you want to manage in the server’s control panel and create NS records for the subdomain. The NS record can be in the form of an “A” record, which associates the subdomain with an IP address, or an “MX” record, which specifies the mail server for handling email for the subdomain.

What Are DNS Zone Changes?

DNS zone changes are modifications to the DNS information associated with a particular domain. These can include changes to the IP address of the server responsible for hosting the website, adjusting the mail server settings, or adding new servers. These modifications can occur intentionally or accidentally when the domain owner or their authorized representative makes them. However, it’s important to note that DNS zone changes can be maliciously induced by cybercriminals.

Why Track DNS Zone Changes?

Tracking DNS zone changes is crucial for maintaining smooth operation and security of a website. Changes to DNS records can have a significant impact on website functionality. A prime example is the 2021 Facebook outage, during which the website was inaccessible for about seven hours. The outage was caused by the loss of IP routes to the Facebook DNS servers. The resulting revenue loss for Facebook was between $60-100 million.

Furthermore, malicious DNS zone changes can pose serious risks. They can redirect visitors to unauthorized websites, compromising user security. These changes can also open back doors for intrusions into databases and potential breaches of user privacy, which are often triggered by DDoS attacks.

Companies can monitor changes to their domain’s DNS records by actively tracking DNS zone changes. This monitoring allows companies to identify and address any unauthorized or unexpected changes promptly and is essential for safeguarding online presence and protecting user trust.

How To Track DNS Zone Changes

There are five techniques that companies can deploy to track DNS zone changes:

Tracking TechniqueHow It Works
Zone Change Notification (ZCN)This feature allows DNS servers to send notifications to other DNS servers when a change occurs in a DNS zone. By enabling ZCN, DNS servers can stay updated with their zone information, and be used for replication of zones as and when needed.
DNS LoggingMany DNS servers provide logging capabilities, which monitor DNS queries and updates. These logs provide a record of DNS zone changes, enabling you to identify and troubleshoot issues arising from DNS zone changes.
External Monitoring ServicesThese services use automated tools to monitor DNS answers continuously. They detect changes, such as adding or removing DNS records, and send real-time alerts when DNS zone changes occur. This enables quick responses to potential issues.
DigThis command-line tool allows the user to retrieve DNS information, including DNS records, name servers, and IP addresses. Dig can also be used to track DNS zone changes by comparing DNS queries to DNS servers before and after the zone change, helping the user pinpoint differences.
DNS Query AnalysisThis technique analyzes DNS queries received by DNS servers to track changes in DNS zones. It provides valuable insights into the domains and subdomains being queried, the types of queries received, and the frequency of queries to specific DNS records. Monitoring these patterns can flag changes to the corresponding DNS zones.

Why Monitor DNS Zone Changes?

Monitoring DNS zone changes has three main benefits: detecting unauthorized changes immediately, ensuring DNS record accuracy, and improving IT resource management.

Immediate Detection of Unauthorized Changes

Unauthorized changes to DNS zones, whether accidental or malicious, can result in DNS errors, slow query response times, and even domain name resolution failures. Attackers may attempt to modify DNS records to redirect users to phishing sites, intercept traffic, or compromise sensitive information. Actively monitoring DNS zone changes helps mitigate these risks, promptly identifying any unauthorized modifications and enabling DNS administrators to take immediate action.

DNS Record Accuracy

When changes are made to a website or server IP address, corresponding updates to DNS records are necessary to ensure seamless user access to the new server. Incorrect or outdated DNS records can result in website downtime, slow page loading times or even complete website inaccessibility. By monitoring DNS zone changes, companies can verify the accuracy of DNS records, which is crucial for a seamless user experience and for proactively preventing potential problems.

Better IT Resource Management

Regular monitoring of DNS zone changes helps efficiently allocate IT resources. By staying up to date about changes, teams can optimize activities, minimize downtime, and reduce operational costs.

What Is a Reverse Lookup Zone?

A reverse lookup zone enables the identification of domain names associated with specific IP addresses. It works opposite to the more common forward lookup zone, which finds the IP address linked to a domain name.

The reverse DNS hierarchy with IPv6

A reverse lookup zone utilizes special PTR (Pointer) records. It uses the in-addr.appa domain, and IP addresses are arranged from the less specific to the more specific, while the domain names are arranged from the more specific to the less specific. Consider the figure above, for example, the customer’s IP address is 22.64.202.in-addr.appa.

PTRs are always managed in the reverse zone (not forward zone,) like in-addr.arpa or ip6.arpa e.g <octet_2>.<octet_1>.in-addr.arpa. Your ISP must delegate the zone to your NSes. Therefore, when you perform a reverse lookup, the DNS server searches for the PTR record corresponding to the IP address you provide and retrieves the associated domain name.

Reverse lookup zones are particularly valuable in larger networks with numerous IP addresses for troubleshooting network issues. For example, if you detect suspicious activity originating from a particular IP address on your organization’s network, it’s easy to determine visually the domain name associated with that IP address.

Additionally, PTR records are widely used in public networks. You can identify the name associated with an IP address and make a fair assumption about who is responsible for the part of the network that is overloaded or generates malicious traffic. For example:

traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 52 byte packets
 1  192.168.31.1 (192.168.31.1)  10.842 ms  3.846 ms  3.389 ms
 2  192.168.178.1 (192.168.178.1)  5.021 ms  5.808 ms  5.727 ms
 3  dhcp-077-249-057-001.chello.nl (77.249.57.1)  16.033 ms  13.006 ms  15.976 ms
 4  212.142.51.25 (212.142.51.25)  11.897 ms  14.024 ms  12.946 ms
 5  asd-tr0021-cr101-be112-2.core.as33915.net (213.51.7.92)  15.071 ms  14.261 ms  15.145 ms
 6  nl-ams14a-ri1-ae51-0.core.as9143.net (213.51.64.186)  18.707 ms  16.519 ms  23.037 ms
 7  213.46.191.210 (213.46.191.210)  15.810 ms  16.197 ms  16.946 ms
 8  172.71.96.2 (172.71.96.2)  15.055 ms
    172.70.44.2 (172.70.44.2)  14.475 ms
    172.71.180.2 (172.71.180.2)  16.163 ms
 9  one.one.one.one (1.1.1.1)  19.013 ms  17.318 ms  21.799 ms

You may notice that some addresses don’t have associated PTR records. Usually those addresses are from private IP spaces, and are being used on internal interfaces of the routers. Although we can’t see their name in public, most providers have PTRs for them on their own nameservers, and they are resolved when those nameservers are in use e.g., inside the provider’s network.

It is also worth mentioning that it is not mandatory for a PTR record to correspond to the forward record, and in general it can be an arbitrary domain name. As such, anyone with access to the in-addr.arpa subzone can create PTR for google.com or any other domain name, which in turn can mislead a user or network administrator.

Conclusion

DNS zones play a critical role in the broader DNS system, enabling efficient management of specific subsets of DNS records. Effective DNS management is essential for maintaining website accessibility and email delivery, and supporting various online activities. Poor DNS management can lead to reduced traffic, revenue loss and diminished user trust. Fortunately, companies can optimize DNS management by using appropriate tools and resources, enhancing both efficiency and security in communications between user devices and their chosen servers.

Gcore offers advanced features that empower companies to track DNS zones, detect unauthorized changes, and quickly resolve issues. Gcore’s services include comprehensive tracking, monitoring, and security functionalities. Gcore also provides fast, resilient, and reliable enterprise-grade DNS hosting services. With Gcore, companies can streamline DNS management and ensure a secure, seamless online experience for their users.

Subscribe and discover the newest
updates, news, and features

We value your inbox and are committed to preventing spam