DNS Server - not resolving external references while able to resolve internal references
This document (7011258) is provided subject to the disclaimer at the end of this document.
Restarting the DNS service may or may not help.
Looking at the named.run file, or messages file, you see a lot of error messages like the following:
23-Oct-2012 11:14:09.613 lame-servers: dns/resolver: info: unexpected RCODE (SERVFAIL) resolving '126.96.36.199.in-addr.arpa/PTR/IN': 188.8.131.52#53
23-Oct-2012 11:14:10.005 lame-servers: dns/resolver: info: unexpected RCODE (REFUSED) resolving 'something.com/A/IN': 184.108.40.206#53
23-Oct-2012 11:22:27.223 client: query: warning: client 10.1.1.5#50067: no more recursive clients: quota reached
In the logs this appears to start out as a flood of in-addr.arpa queries for PTR records in in-addr.arpa zones that the local DNS server is not authoritative for.
By default recursive queries are enabled on the DNS server so these requests cause the local DNS server to send those PTR requests on to the upstream configured DNS forwarder, or to the Root Servers if no forwarders are defined.
Since there is a large flood of these requests, and the local DNS server and the upstream DNS servers are not able to resolve them quickly if at all, eventually the local DNS server and possibly even the upstream DNS server will run out of resources to handle the flood of the bogus recursive queries.
The upstream servers may even stop resolving anything for the local DNS server and you will get the lame-servers, SERVFAIL, and REFUSED errors.
On the local server you may see the recursive quota reached errors.
In any case there will be a lot of all of these errors in the local DNS server logs.
After you have done that restart the DNS server.
At this point all recursive resources will be available.
If it still fails to resolve externally look at the log files again to make sure the previous errors are not longer being written. If they are still being logged take more LAN traces to see if the flood of bogus in-addr.arpa requests have stopped. If not, identify the new devices and stop those.
When you have stopped all devices making bogus requests and restarted the DNS server it will no longer be logging the errors and running out of resources and will forward on to the upstream foraders properly.
At this point it shoulsd be working again. If not then the upstrema servers may no longer be answering queries forthe local DNS server. You can point to different upstream forwarders and restart DNS to test this theory or take LAN traces to verify.
Once the local DNS server is resolving external references again find out what was causing those devices to flood the network and the DNS server with bogus PTR requests and address that issue on those devices before bringing them back up on your network.
This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.
- Document ID:7011258
- Creation Date: 25-Oct-2012
- Modified Date:03-Mar-2020
- SUSE Linux Enterprise Server
For questions or concerns with the SUSE Knowledgebase please contact: firstname.lastname@example.org