You've come to this page because you've asked a question similar to the following:
I am running a proxy DNS server of my own, listening on the IP address 10.53.0.1. My ISP provides proxy DNS to customers such as me on the IP address 62.140.76.16, and Google provides promiscuous proxy DNS service on the IP address 8.8.8.8. I've configured my DNS Clients to use my own proxy DNS server as the preferred proxy DNS server, and to fall back to using my ISP's proxy DNS server and Google's proxy DNS server as alternates. Now sometimes my machines are unable to see or to use services on my LAN. Why?
This is the Frequently Given Answer to that question.
You've configured your DNS Clients incorrectly. All of the proxy DNS servers whose IP addresses are used by DNS Clients must provide identical views of the DNS namespace. Yours do not. Remove 62.140.76.16 and 8.8.8.8 from the list of proxy DNS servers that you are configuring your DNS Clients with, leaving just 10.53.0.1.
The primary point of configuring a DNS Client with a list of several proxy DNS servers is for fallback in the event of a server outage or a partial loss of network connectivity. If a DNS Client cannot obtain responses from the principal proxy DNS server, it falls back to attempting to communicate with the alternate proxy DNS servers.
One common misconception is to think that the purpose of the list of proxy DNS servers configured in one's DNS Client is to provide fallback in the event of the receipt of a negative answer, thinking that if a "no such name" answer is received by the DNS Client from one proxy DNS server it will consequently fall back to querying the next. This misconception is false. The fallback mechanism is not there for the provision of some hypothetical mechanism for somehow admixing multiple different proxy DNS services. If a DNS Client receives a response containing a negative answer, it will use that answer. As far as it is concerned, it has an answer. It will not continue to look for another one, and it will not attempt to mix in the service of a different proxy DNS service. Fallback occurs in the event of a lack of response, within the DNS Client's timeout period, not in the event that a response is actually received.
You've configured "split horizon" DNS service. You may not think that you have done this. However, you may have done so entirely unawares.
For example: Ifthen you have, effectively, set up "split horizon" DNS service with separate content servers, with the DNS database content for the "internal" view being provided by your own DNS server and the DNS database content for the "external" view being provided by your domain hosting company.
your Internet domain is "hosted" by a domain hosting company, not by you; and
you are using Microsoft's DNS server and your Active Directory domain name is the same as your Internet domain name
In "split horizon" DNS service, your own proxy DNS server provides a view of the DNS namespace that is different to the view provided by your ISP's proxy DNS server and Google's promiscuous proxy DNS server.
Arranging for DNS Clients to fall back from a proxy DNS server that provides an "internal" view to a proxy DNS server that provides an "external" view is a simple recipe for disaster:
Fallback from the one proxy DNS server to the other can happen at any time, and can (for example) be triggered by simple network congestion. The result is that one cannot predict what view of the DNS namespace will be presented to a DNS Client from moment to moment.
(Just to make things worse: There is also a known bug in the DNS Client fallback algorithm used by Microsoft Windows NT 4/2000/XP machines such that if they fall back to using an alternate proxy DNS server, they will not resume using the principal proxy DNS server until the DNS Client service is stopped and then restarted.)
The DNS database content in the "internal" view are different to the DNS database content in the "external" view, and the correct operation of the machines on one's LAN relies upon always seeing the "internal" view.
For example: Microsoft Windows NT 2000 and Windows NT XP machines use the DNS database to locate Windows Domain Controllers, LDAP servers, and suchlike. None of the information for doing so will of course be in the "external" view of the DNS database that the rest of Internet sees. It will only be in the "internal" view.
For another example: One might be employing "dual-homed" servers, of various kinds. The "external" view of the DNS database will list the publically reachable IP addresses of those servers, on which is provided the service that one gives to the public at large; whereas the "internal" view of DNS database will list the LAN-reachable IP addresses to be used by machines on one's own LAN, on which is provided the service that is used by one's own organization.
For example: They might attempt to look up the Windows Domain Controllers, LDAP servers, and whatnot, and intermittently be unable to find them because they end up asking your ISP's or Google's proxy DNS server about them instead of your own proxy DNS server. (One symptom of this is that Microsoft Windows NT 2000 and Windows NT XP machines are either partially or completely unable to use "Domain" resources, such as contacting a Windows Domain Controller to change passwords or to log in.)
For another example: They might intermittently try to use the publically reachable IP addresses of one's "dual-homed" servers instead of the LAN-reachable IP addresses. At minimum, this will result in their being unable to see "intranet" resources.
If you wish to have redundancy, in order to provide proxy DNS service even in the event of a single server outage, you should have more than just the one proxy DNS server of your own, therefore. Set up a second proxy DNS server, providing a view of the DNS namespace identical to the one provided by your first, and listening on an IP address such as 10.53.1.1; and add that IP address to the list of proxy DNS servers that you are giving to your DNS Clients.