Getty Images/iStockphoto
DNS server troubleshooting for Linux and Windows
Steps in DNS server troubleshooting include checking the DNS status, looking at zone configurations and evaluating logs. Follow these best practices for Windows and Linux servers.
Name resolution is an essential part of modern networks. Name resolution services relate names, which are easy for people to remember, with IP addresses that are more difficult to remember.
Name resolution uses an address (A) record to resolve names with IPv4 addresses and a quad-A (AAAA) record to relate names with IPv6 addresses.
End users rely on name resolution to browse websites. Computer technicians may use names to map network printers or drives, and system administrators can connect remotely to servers or VMs via names.
The first step in troubleshooting name resolution is to understand it. The first article of this series defines name resolution and provides examples of features, such as the hosts file and DNS. The second article covers troubleshooting name resolution issues from the client perspective using tools such as ping, nslookup, host and dig.
This article discusses troubleshooting DNS services at the server. Specifically, it covers checking the service status and primary configuration files on both Linux and Windows DNS servers.
Troubleshoot Linux-based DNS
Troubleshooting name resolution on a Linux server begins with the basics. First, is the service installed and running? Next, are the zone files accurate, and do they contain the needed resource records to resolve the network host?
The name resolution service for Linux is Berkeley Internet Name Domain (BIND), currently at version 9.
1. Check if BIND is installed
Ensure BIND is installed and running when troubleshooting a name resolution server. Use the following command to confirm BIND9 is installed:
$ named -v
The output should indicate BIND9 is installed and display the version number. If it's not installed, that is why name resolution queries to this server are failing.
On Red Hat, Fedora and similar distributions, type the following to install BIND9:
$ sudo dnf install -y bind bind-utils
On Ubuntu, Debian and similar distributions, type the following:
$ sudo apt install bind9 bind9-utils bind9-dnsutils
Whether admins need to install the various extra utilities depends on how they intend to use the name resolution server.
2. Ensure BIND is running
Assuming BIND is installed, the next step is to ensure the service is running. Use the systemctl command with the following syntax:
$ sudo systemctl status bind9
Admins can use the systemctl start, stop, restart, enable and disable commands to manage the service.
Don't forget to set the firewall to permit port 53/udp for queries and 53/tcp for zone transfers.
3. Check zone configuration
The primary directories that store BIND9 configuration files are usually /etc/bind and /var/cache/bind. The main service configuration files are named.conf, named.conf.default-zones, named.conf.local and named.conf.options. These files define how the name resolution service performs its tasks.
Note that exact directory and file names, as well as locations, may vary depending on the distribution. This isn't an uncommon occurrence on Linux systems. It may be useful to grep the /etc and /var directories for strings containing named.
Zone files contain the actual resource records that relate a particular hostname to an IP address. Zone files are usually found in /var/cache/bind. Standard resource records, such as start of authority (SOA) and name server (NS) records, are stored here, along with A and pointer (PTR) records used for name resolution queries. If the server resolves queries for multiple zones, each zone will have its own file.
Check the zone file configuration with the following command, where zonename is the name of the DNS zone admins are troubleshooting:
$ sudo named-checkzone zonename.com db.zonename.com
The named-checkzone utility checks the zone file's syntax. This check offers the opportunity to test and troubleshoot existing zone files and confirm the configuration of new ones before loading them into BIND9.
The result should indicate the zone is responding correctly by providing exit code 0. If the check returns exit code 1, check the zone file contents for errors. Admins might encounter the following errors:
- There is an incorect zone name.
- The zone files may contain incorrect A and PTR resource records.
- The record may have typographical errors.
Note: Admins may find it useful to troubleshoot from the client system using tools such as dig, host and nslookup to identify some issues correctly.
Troubleshoot Windows-based DNS
Microsoft Active Directory Domain Services (AD DS) integrates several services to provide security and ease of management. The first of these is DNS AD integrated zones. This feature enables replication of the DNS database with the AD database -- a more comprehensive replication design. The second service is Dynamic Host Configuration Protocol (DHCP)-owned dynamic updates of A and PTR records. DHCP registers the client's hostname and IP address with DNS after leasing an IP address configuration, ensuring -- hopefully -- that the DNS zone is populated with accurate information. Because these three services work together, it often makes sense to colocate them on the same server.
Any name resolution troubleshooting necessarily also involves AD DS and DHCP. Keep this in mind when reviewing Event Viewer messages or attempting to narrow the scope of name resolution problems.
Several consoles and Windows PowerShell cmdlets are available for troubleshooting DNS.
1. Verify DNS is installed
First, verify DNS is installed on the server by checking Server Manager or the Services console. If necessary, add the DNS Role, and configure the server as part of the AD domain.
Any services, including DNS, are available in the Services console within the Tools menu of Server Manager. Admins can check the status of the service and restart it from this console.
2. Check zones
Open the DNS Manager console to display and manage existing zones. Admins can also create new zones here, plus manage configurations like zone replication, security settings and forwarding.
3. Use PowerShell to troubleshoot configurations
As long as admins remember the appropriate cmdlets and parameters, command-line environments, such as PowerShell, can be efficient and usually faster than navigating a GUI. Obviously, the primary benefit of command-line interfaces is scripting. Admins could even generate their own name resolution troubleshooting scripts.
Several cmdlets help with DNS troubleshooting and reporting. It's particularly useful to display records from the zone, confirming that name resolution by the DNS server is possible for the queried name.
Here are a few examples of using PowerShell to troubleshoot configurations or retrieve information.
Clear the DNS resolver cache with the following cmdlet:
> Clear-DnsServerCache
Use the following cmdlet to retrieve resource records from servers, confirming the records exist:
> Get-DnsServerResourceRecord -ComputerName DC1 -ZoneName myzone.local
Retrieve A records from the specified DNS server by adding the -RRType A parameter:
> Get-DnsServerResourceRecord -ComputerName DC1 -ZoneName myzone.local -RRType A
4. Check the DNS configurations
From Server Manager, go to the Tools menu, and select DNS to open the DNS Manager console. Admins can expand nodes to display any DNS zones of which the server is aware. Here are some areas to check depending on the troubleshooting scenario:
- Confirm the correct zones are listed.
- Search for any typographical errors in static resource records.
- Verify the correct A and PTR resource records exist.
- Confirm that the firewall permits DNS traffic.
Admins can also use the DNS console to check zone properties, such as scavenging and forwarders. These settings affect how DNS handles name resolution queries.
Scavenging helps clean up the DNS records. In AD environments, Windows clients or DHCP servers dynamically create A and PTR resource records. Left unattended, the number of records continues to grow without older records being removed, which is why properties like aging and scavenging are available with DNS.
Aging identifies resource records of a specified age. These records are labeled as stale, and they're subject to scavenging (removal) after another specified time interval. Ensure that scavenging is enabled on one DNS server in the zone to keep the zone a manageable size.
Forwarding sends unresolved queries to another server. This configuration isolates internal DNS servers, which are likely colocated with AD domain controllers (DCs), from having direct internet access. Instead, a designated DNS server called a forwarder resides in the network's internet-facing screened subnet, or DMZ. Internal DNS servers forward queries for external internet resources to the forwarder.
Another setting to check is conditional forwarding. DNS conditional forwarding enables admins to associate specific domain names with known DNS servers. When a DNS server receives a query related to that domain name, the query is sent directly to the listed DNS server without resolving through multiple other servers. Ensure that any domain names identified are correct and that the appropriate DNS server IP addresses are provided.
5. Reload the zone
Next, attempt to reload the zone. Admins can also restart the DNS service. Be aware, however, that this also restarts AD DS and could affect client systems. It is assumed at least two AD DCs are at the site to mitigate the effect of one DC being unavailable at a time.
6. Check Event Viewer logs
Next, check the Event Viewer DNS logs. Admins may need to look at AD DS events and possibly even DHCP events, not just DNS entries. Watch for entries indicating problems with DNS starting. More importantly, check both DNS and AD DS for replication errors.
Windows provides several DNS service interfaces. Admins can manage the service via the Services console, though most DNS troubleshooting will probably occur in the DNS Manager console. This console enables zone management, displays resource records and modifies service settings, such as scavenging and forwarding. AD integrated zones improve the security and performance of DNS zone replication and enable for tighter integration between DNS and DHCP. So, don't forget to check AD replication and DHCP settings while troubleshooting DNS issues.
Wrap-up
DNS servers provide one of the most critical services on a network. Name resolution enables users to work with relatively easy-to-remember names. Under the hood, the systems relate these names to the IP addresses required by TCP/IP. Many services rely on DNS, including email, web browsing, file sharing, printer sharing and AD.
Begin troubleshooting by ensuring the service is installed, running and accessible. Confirm the zones needed to store resource records exist and are properly configured. Finally, verify that the resource records for the queried destinations exist and are accurate.
