How to Fix DNS Server Error

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 this problem occurs while the service is active, the server might not listen to the IP address used in the nslookup query. Administrators can configure a DNS server to listen only to specific addresses through the Interfaces tab on the server properties page in the DNS console. When the DNS server limits service to certain configured IP addresses, the IP address you use to contact it may fall outside that list. In that case, try another IP address from the allowed list or add your current IP address to it.

In rare cases, the DNS server may have an advanced security or firewall configuration. If the server resides on another network and is accessible only through an intermediate host such as a packet-filtering router or proxy server, it might listen for client requests on a non-standard port. By default, nslookup sends queries to DNS servers using UDP port 53. Therefore, if the DNS server uses a different port, nslookup queries will fail. To fix this issue, verify whether the intermediate filter intentionally restricts traffic on standard DNS ports. If it doesn’t, update the firewall’s packet filtering or port rules to allow traffic on UDP and 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:

1. 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.)
2. 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.
3. Force a zone transfer on the secondary server using either the DNS console or the following command: dnscmd /zonerefresh <zone name>
4. Now, examine the secondary server again to ensure that the zone was transferred properly. If not, you have a zone transfer problem.
5. 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, a broken delegation exists between the root server and the specified domain name or IP address. To identify the issue, follow the Verify a Broken Delegation process to locate where the delegation failure occurs.
• If the resolver displays a “Request to server timed out” message, verify that the root hints point to active root servers. To do this, follow the View the Current Root Hints process to confirm that each listed root server is active and reachable.
• If the root hints already point to active root servers, the issue may lie in the network connection or an advanced firewall configuration blocking the resolver’s queries. Check the network settings and firewall rules to ensure the resolver can communicate with the DNS server without restriction.

Verify a broken delegation

Begin the verification process by querying an appropriate root server. This test walks you through querying each DNS server, starting from the root server and continuing to the target server, to identify any broken delegation within the DNS hierarchy.

1. Enter the following command in the Command Prompt on the server you are testing.
   Note: Replace the resource record type with the specific type you used in your original DNS query.
2. Repeat Step 1 if the response includes a list of NS or A resource records for delegated servers. Use the IP address from the A records as the server IP address for your next query.

• If the response does not include any NS resource records, the delegation is broken. However, if the response includes NS records but lacks corresponding A records, enable recursion to query the A resource records of the servers listed in the NS records.

  If you cannot find at least one valid A record IP address for each NS record in the zone, the delegation remains 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

1. Start with the DNS console.
2. Add or connect the DNS server that failed a recursive query.
3. Right-click on the server >> select Properties.
4. 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 on both the primary and secondary DNS servers.
• Check the primary DNS server to see whether it’s refusing the zone transfer for security.
• In the DNS console, open the zone properties and check the Zone Transfers tab. If zone transfers are restricted to specific servers listed on the Name Servers tab, make sure the secondary server is included. Also, confirm that the primary server is configured to send zone transfers.
• Follow the steps in the Check DNS Server Problems section to troubleshoot the primary server. If any task requires action on a client, perform it on the secondary server instead.
• Verify whether the secondary server runs a different DNS implementation, such as BIND. If it does, the primary server’s zone may include resource records that Windows DNS cannot recognize, or the issue may result from one of the following causes
• The Windows primary server may use fast zone transfers, but the third-party secondary server might not support them. In that case, disable fast zone transfers on the primary server. To do this, open the DNS console, go to your server’s properties, select the Advanced tab, and click Enable BIND secondaries.
• 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 DNS server uses a different implementation, ensure both servers support the same features. On a Windows DNS server, open the DNS Console and navigate to the Advanced tab in the server’s Properties page. In this section, enable BIND secondaries and review the Name Checking drop-down list. These settings help you enforce 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

Name

Email