When your machines lose their ability to speak to each other, it's usually DNS.
Anyone who has worked with IT infrastructure for any length of time has most likely heard that a Domain Name System (DNS) problem caused an outage. It hits enterprises of all sizes, including major cloud-based companies. Whether by accident or a DNS server malfunction, records can disappear from DNS. When this happens, services fail almost immediately when clients cannot get to a computer on your network. Learn how to protect your organization by getting familiar with the DNS backup and restore process.
What does DNS do?
It's helpful to understand the role of DNS in the corporate network to see how important it is.
Every website or service on the internet has a unique IP address. When you type in a URL or domain name, DNS converts those entries into the corresponding IP address. DNS operates at scale to track these millions of IP address assignments by building a database of services and their associated network information that it accesses as needed. DNS also seamlessly transitions from private DNS servers on the corporate network to public DNS servers.
DNS provides an easy way to access information on the internet and inside our corporate networks by using names rather than the specific configuration information. Without DNS, trying to use the internet and internal enterprise networks would be very difficult.
However, DNS is much more than simple name-to-IP lookups. DNS has many types of data records to manage all the internet plumbing.
Whether it's a print job to a network printer or an email, DNS gives the information to your computer to handle the routing automatically. Mail servers, file servers, web servers, routers and many other computers and services all have DNS entries that make it effortless to locate the proper service.
What is Active Directory-integrated DNS?
DNS can be a service that runs on a domain controller with other services, such as DHCP, or it can run independently on a dedicated DNS server.
Most corporate networks use Active Directory-integrated DNS, which stores DNS records in the Active Directory database. With this setup, DNS is a replicated service; a record change on one DNS server should propagate to the other DNS servers in a few seconds.
There are many tasks related to DNS that require attention from IT, but for daily records management, Active Directory-integrated DNS zones handle most of the arduous tasks behind the scenes automatically.
Records are the core of DNS
A DNS server answers queries called DNS lookups from other computers on the network. Computers send a DNS query to the DNS server, which returns the relevant information requested or forwards the request to another DNS server that better answers the query. There are more than 90 DNS record types, but the list below shows the eight most common ones.
|A||Maps domain names to IPv4 addresses|
|AAAA||Maps domain names to IPv6 addresses|
|CNAME||Redirects a domain to another domain|
|PTR||Resolves IPv4 or IPv6 addresses to domain names|
|NS||Provides a list of the authoritative name servers responsible for the domain|
|MX||Provides the domain names of mail servers that receive email on behalf of a domain|
|SOA||Provides important details about a DNS zone; required for every DNS zone|
|TXT||Provides any type of descriptive information in text format|
An A DNS record is the most common. The A is short for address. These A records resolve host names to IP addresses. This request type is known as a forward lookup.
My lab's domain is called mk.lab and has a domain controller named DC01 with an IP address of 192.168.15.20. In DNS, there is an A record with this host information.
The DNS Manager console provides a graphical representation of DNS records. Notice on the left-hand side, we have the domain name mk.lab. The right panel shows the records in the mk.lab zone. You can see the entry for DC01, the record type and the IP address associated with DC01.
To query this information using PowerShell, use the following command:
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
dc01.mk.lab A 211538 Answer 192.168.15.20
The opposite of an A record is a pointer (PTR) record. The previous command is an example of a forward lookup: I provided the name, and DNS returned the IP address. PTR records work in reverse: I provide an IP address, and DNS returns the host name. This is called a reverse lookup.
To look up PTR records with PowerShell, run the following command:
Resolve-DnsName 192.168.15.20 | ft -AutoSize
Name Type TTL Section NameHost
---- ---- --- ------- --------
22.214.171.124.in-addr.arpa. PTR 210407 Answer dc01
126.96.36.199.in-addr.arpa. PTR 210407 Answer dc01.mk.lab
The last record type I will cover is a canonical name (CNAME) record that is used to reference a host with an alias. A CNAME record points to an A record.
To understand how CNAME works, let's say I have a server called AZBUILD01 in my domain. To reach the server with the name MyTestServer, you can create a CNAME record for MyTestServer that refers to the AZBUILD01 DNS record.
PowerShell can look up all types of DNS records. The following PowerShell command queries the MyTestServer alias and outputs the DNS information.
Resolve-DnsName mytestserver.mk.lab -Server dc01
Name Type TTL Section NameHost
---- ---- --- ------- --------
mytestserver.mk.lab CNAME 3600 Answer AZBuild01.mk.lab
Name : AZBuild01.mk.lab
QueryType : A
TTL : 1200
Section : Answer
IP4Address : 192.168.15.25
Understanding the difference between DNS lookup zones
Administrators who manage networks should know how to work with forward lookup and reverse lookup zones. A zone contains all the records for a domain. Forward lookup zones contain A records and CNAME records; they resolve a host name to an IP address. Reverse lookup zones contain PTR records and resolve an IP address to a host name.
If you host a DNS server, you must have a forward lookup zone, but there is no requirement for a reverse lookup zone. Most DNS requests are by name and not IP. A records and CNAME records are the most common DNS requests. My current lab build is more than a year old, and I haven't needed a reverse zone for it to function normally.
While forward lookup zones always appear the same way with one zone per domain, reverse zone configurations will vary for each network. Best practice says there should be only one reverse zone, but I have rarely seen only one reverse zone in the real world.
The best way to protect against DNS outages
DNS servers are attractive hacking targets, so they should be patched and rebooted regularly. In my experience, most DNS issues revolve around records management. In Active Directory, a user needs a high level of privilege to change DNS configurations.
With DNS, less access is better. Most users have no business making DNS changes except for their own computer records. IT workers should perform security reviews of the DNS Admins and Domain Admins groups in Active Directory and use automation to make changes on behalf of users.
Another way to maintain the DNS server is to set up automatic DNS scavenging. This clears dead records from decommissioned machines, such as retired servers, on a set schedule; the default is seven days. Dead records lead to DNS queries that return answers that will not resolve and cause phantom outages.
It's important to check the DNS scavenging settings to make sure they are set properly. While Microsoft best practices recommend DNS scavenging on all domain controllers, in an Active Directory-integrated DNS environment, the setting just needs to be on the main domain controller, which will replicate to the other domain controllers.
How to back up DNS records for safekeeping
How do you back up DNS? A typical DNS server stores DNS records in a simple text format. The format is similar to an Excel spreadsheet with several columns and rows of data. Each domain on the network has a DNS zone file.
Two options are available to back up DNS: back up individual records or back up the entire DNS. The following PowerShell example performs a single record backup:
Resolve-DNSname mytestserver.mk.lab | export-csv c:\temp\test.csv -NoTypeInformation
The file looks like this:
When you have multiple DNS servers with different record types as you do with Active Directory-integrated DNS, this type of PowerShell export will not work because the columns won't match because it involves both CNAME and A records. The DNSCMD utility used to manage DNS servers will face the same limitations.
You need to use other methods to solve this backup challenge.
How to perform a full DNS backup
It's a good practice to perform a regular backup to prepare for data loss. So how do you back up DNS? Microsoft produced the DNSServer and DNSClient PowerShell modules for this type of DNS work, specifically the Export-DnsServerZone cmdlet. The syntax to back up DNS is straightforward, as shown in the following example:
Export-DnsServerZone -Name $DNSZone -FileName $Filename -CimSession $CIMSession
Make sure you back up relevant zones and skip the ones that can't be exported because the DNS server created them automatically. Use this modified version of the backup script I created and use in my corporate network to back up the DNS server daily. The script connects to a specified DNS server and then gets all zone information. It then loops through each DNS zone and exports the information to create a .DNS file that is readable in a text editor.
You can run this script via a scheduled task or any automation software, such as Jenkins, GitHub Actions, Azure DevOps or Ansible.
How to restore a DNS backup
Microsoft's prescribed method to back up and restore DNS settings is not consistent. While you can use either PowerShell or the DNSCMD utility to make the backup, you need to use another tool, the New Zone Wizard in the DNS manager, to perform the restore when dealing with many records.
A typical enterprise environment might contain many DNS records. My organization's main DNS zone contains more than 25,000 records with five forward lookup zones to maintain and many reverse DNS zones.
To restore one record, find the backup and use PowerShell to recreate the record rather than overwrite the entire zone information, which might be preferred for a simple restore of a few records.
When dealing with many records, it might be preferable to restore an entire zone file. The process is simple but not intuitive. First, place a copy of your DNS backup into the c:\windows\system32\dns folder of your DNS server. Next, open the DNS Manager and right-click on the DNS server name and select Create new zone.
Select Next and pick the Primary zone type and be sure to uncheck the Store the zone in Active Directory (available only if DNS server is a writeable domain controller) option.
Next, select the proper zone type for the new zone: forward or reverse. When you name this zone, use the same name for the zone that you are restoring. In my instance, I am using mk.lab from my lab. Next, choose to restore from an existing file and select the backup file.
Next, pick a security setting for dynamic updates. I recommend picking the default option and enabling DNS scavenging.
Finally, you will see a summary. Click Finish to restore the zone.
I need to make a few more adjustments because I did not use the Integrate into Active Directory option during the restore process.
From the DNS Manager, right-click on the zone and select Properties. Under the General tab, click on Change by the zone type. Make the zone type Primary and select the Store the zone in Active Directory (available only if DNS server is a domain controller) option.
Avoid a catastrophe and get familiar with DNS management
With so much vital information stored in DNS, it's important to understand what a DNS backup and restore procedure entails.
Some aspects of DNS server management are not straightforward. This guide and script will help you get started quickly, but DNS administration in a production environment requires a deeper dive into Microsoft's documentation to build your expertise with this service.