If you are experiencing a DNS server error, use the following command line to troubleshoot the IP address that the domain currently points to. The nslookup command enables Windows users to troubleshoot DNS issues through the command line.
Check IP configuration
- Open a command prompt and enter ipconfig/all to verify the IP address, subnet mask, and default gateway.
- Verify if the DNS server is authoritative for the specific name being searched.
- Enter the following commands:
nslookup <name> <IP address of the DNS server>
- To clear the resolver cache, enter the following commands in an administrative Command Prompt window:
dnscmd /clearcache
- Or, enter the following cmdlet in an administrative PowerShell window:
Clear-DnsServerCache
- Repeat step 3 once again.
Check DNS server problems
It is recommended to check the following logs for any recorded errors: Application, System, and DNS Server.
Verify using nslookup query
Run the following command to see if the DNS server is available from the client’s computer:
nslookup <client name> <server IP address>
- If the resolver returns the client’s IP address, then the server has no issues.
- If the resolver returns a “Server failure” or “Query refused” response, the zone must be paused, or the server may be overloaded. The General tab of the zone properties in the DNS console will notify you whether it is paused.
- And, if the resolver sends a “Request to server timed out” or “No response from server” response, the DNS service is likely not working. If so, you can try to restart the DNS Server service by entering the following:
net start DNS
If the problem arises while the service is active, the server is not listening to the IP address used in the nslookup query. The administrators can restrict a DNS server to listen to only specific addresses using the Interfaces tab of the server properties page in the DNS console. If the DNS server is set to limit service to a specific list of configured IP addresses, the IP address used to contact the DNS server may not be on the list. You can either try another IP address from the list or add the IP address to the list.
Rarely, the DNS server may possess an advanced security or firewall configuration. If the server is on another network and it can only be reached through an intermediate host like packet filtering router or proxy server, the DNS server will listen and receive client request on a non-standard port. By default, nslookup will send query to DNS servers via UDP port 53. As a result, if the DNS server use any different port, the nslookup queries will fails. If this is the problem, then check the intermediate filter is purposefully restrict traffic on known DNS ports. If not, modify the firewall’s packet filter or port rules to allow traffic on UDP/TCP port 53.
Check the problems with authoritative data
Verify whether the server that returns the incorrect response serves as the primary server or a server that hosts a secondary copy of the zone.
Primary Server – The source of the problem may be caused by the user error while entering the data into a zone or it might be due to an error with Active Directory Replication or Dynamic Updates.
A Server that hosts a Secondary Copy of the zone:
- Check the zone on the primary server. If the name does not match on the primary server, continue with step 4. (Note: Examining the properties of the secondary zone in the DNS console allows you to determine which server is the primary.)
- If the name matches on the primary server, check to see if its serial number is less than or equal to the secondary server’s serial number. If this is the case, change either the primary or secondary servers such that the primary server’s serial number is greater than the secondary server’s serial number.
- Force a zone transfer on the secondary server using either the DNS console or the following command: dnscmd /zonerefresh <zone name>
- Now, examine the secondary server again to ensure that the zone was transferred properly. If not, you have a zone transfer problem.
- If the zone was transferred properly, verify that the data is correct. In case it is not, then the primary zone’s data is incorrect.
Recursion problem check
For successful recursion, all the DNS servers in the path of a recursion query should respond and forward the correct data. If they are unable to do so, a recursive query may fail due to any of the following reasons:
- The query expired before it is completed.
- The server used in the query fails to respond.
- A server that is used during the query provides incorrect data.
Initiate troubleshooting on the server used in the original query. Check the Forwarders tab in the DNS console’s server properties to verify whether the server forwards queries to other servers. When the “Enable forwarders” checkbox is checked and one or more servers are specified, then this server will forward queries.
If the server is healthy and forwards queries, repeat the process and examine the server to which it forwards queries.
If the server does not forward queries to another server, check if the server can query a root server. To check, enter the following command:
nslookup
server <IP address of server being examined>
set q=NS
- If the resolver returns the IP address of a root server, then there is a broken delegation between the root server and the name or IP address. Follow the Verify a broken delegation process to find out where you have a broken delegation.
- If the resolver returns a “Request to server timed out”, ensure that the root hints refer to active root servers. To perform this, follow the View the current root hints process.
- In case if the root hints point to the active root server, you may have a network issue, or the server may have an advanced firewall configuration that stops the resolver from querying the server.
Verify a broken delegation
Let us begin the below verification process by querying an appropriate root server. This test will help you through the process of querying all DNS servers, from the root to the one that you are testing, for a broken delegation.
- Enter the following into the command prompt on the server you are testing: Note: The resource record type is the type of resource record that you were looking for in your original query.
- Repeat step 1, if the response contains a list of resource records “NS” or “A” for delegated servers and use the “A” resource records’ IP address as the server IP address.
- When there is no “NS” resource record in the response, then the delegation is broken. If the response contains “NS” resource records but no “A” resource records, use set recursion to query for “A” resource records of the servers listed in the “NS” records.
- If you are unable to find at least one valid IP address of an “A” resource record for each NS resource record in a zone, the delegation is broken.
3. To fix a broken delegation, create or update an “A” resource record in the parent zone with a valid IP address for the delegated zone’s DNS server.
View the current root hints
- Start with the DNS console.
- Add or connect the DNS server that failed a recursive query.
- Right-click on the server >> select Properties.
- Select Root hints.
Check the root server’s basic connectivity,
- If root hints are configured properly, then ensure that the DNS server used in a failed name resolution can ping the root servers by IP address.
- If the root servers do not respond to pinging by IP address, the IP addresses of the root servers may have been changed. However, re-configuring root servers is infrequent.
Check the Zone Transfer Problems
You need to run the following checks;
- Check the Event Viewer for both the primary and secondary DNS servers.
- Check the primary server and see if it is declining to send the transfer for security.
- In the DNS console, check the Zone Transfers tab from the zone properties. If the server limits zone transfers to a specific list of servers, as indicated on the Zone Properties’ Name Servers tab, verify that the secondary server is included. Confirm that the server is configured to send zone transfers.
- Follow the steps in the Check DNS server problems section to check for problems with the primary server. If you are prompted to do a task on the client, choose the secondary server instead.
- Verify that the secondary server is using another DNS server implementation, such as BIND. If so, the zone on the primary server contains incompatible resource records that Windows does not recognize or the error may be caused by one of the following:
- The Windows primary server is configured to send fast zone transfers, but the third-party secondary server may not. In that case, deactivate fast-zone transfers on the primary server using the DNS interface by clicking the Enable Bind secondaries on the Advanced tab of your server’s properties.
- If a forward lookup zone on the Windows server has a record type that the secondary server does not support, then the secondary server may have difficulty pulling the zone.
If the master or secondary server is running a different DNS server implementation, ensure that both servers support the same features. The Windows server can be checked in the DNS console, under the Advanced tab of the server’s properties page. Along with the Enable Bind secondaries box, this page has a Name-checking drop-down list. This allows you to specify strict RFC compliance for characters in DNS names.
Hope this has helped you to fix the DNS Server Error if you need any assistance feel free to Get assistance.
Also, check: Improve DNS Performance: Setup DNS to 8.8.8.8 in Linux
To get more updates you can follow us on Facebook, Twitter, LinkedIn
Subscribe to get free blog content to your Inbox
