We have all done it. You don’t know your ISP’s DNS off the top of your head or your ISP has recently changed. You are in a hurry to verify connectivity to the internet and the easy way out is entering 8.8.8.8 as the DNS. But once you were done testing, did you change the DNS back to the correct DNS? If not, you are introducing an additional delay in DNS resolution and potentially adding a point of failure.
How DNS Resolution Works
DNS will go through a basic order of resolution attempts. The first reply wins whether it’s right or wrong.
- Local Windows Host File (This is recommended for troubleshooting only)
- PC DNS Server list
- Internal DNS server
- Designated Conditional Forwarders
- DNS forwarders
- Root hints (only if they are enabled)
The Problems of Using 8.8.8.8 or Any Other Non-ISP DNS
The Host file is static. It should only be used for troubleshooting and then immediately set back to its default after resolving the issue via internal DNS Servers. Many people will use this to troubleshoot and once the issue is Band-Aided they forget to fix it properly and do not set the Host File back to its default.
If your DNS is only pointing to 8.8.8.8, it will reach out externally for DNS resolution. This means it will give you internet access, but it will not resolve local DNS. It may also prevent your machines from talking to Active Directory. Computers won’t be able to pull policies, logins will be really slow and they could lose relationship with the domain.
The Local DNS queries will be broadcasting your internal requests to the internet. That is not recommended and may even be a violation of your security policies, depending on the level of security required in your organization or by any governing agency.
DNS forwarders that only point to 8.8.8.8 are using your ISP connection to hop to 8.8.8.8 when resolving DNS. You have a local DNS resolution solution much closer that will speed up requests if used instead.
Additionally, if your DNS is set to 8.8.8.8, DNS failures may seem to be an ISP outage when your ISP connection is fine. If you have failover rules set in place that are NOT using your ISP’s DNS, your system may failover when there is not an outage.
If you have root hints disabled, one external DNS provider outage can stop external DNS resolution at your business. Why take the chance of Google’s issue directly affecting your production network?
Your Windows firewall internally may also see you are on a “public” network, which can cause it to start blocking network traffic. If you have a domain controller in your environment with its primary or secondary DNS pointing to an external address like 8.8.8.8, it can cause this as well. Checking and unchecking IPv6 may temporarily fix the “public” error, but it will keep happening until you remove 8.8.8.8.
It’s recommended that any domain controller/DNS servers local network interface should always point to another domain controller/DNS interface then itself, never to an external IP.
DNS Forwarders should be configured in the DNS management console to point to external DNS servers of your ISP. Doing this should resolve external DNS resolution.
If you are using a third-party DNS filtering service such as OpenDNS, it is configured completely different so please consult the product’s documentation. In most third-party DNS filtering cases, any external DNS resolution such as 8.8.8.8 or having root hints enabled may bypass the protection that those services offer.