Active Directory and DNS: Why you should not practice adding 8.8.8.8 in DNS forwarder?

Hi everyone and hope you are doing great today. A new day is a new start.

If you are the type of engineer that treat every DNS feature as it must add 8.8.8.8 or filling the DNS forwarder with values, then you must having trouble in understanding active directory and its DNS functionality.

Why mistakes happen?

When you are in a rush to rectify connectivity to the internet and the only idea is to point to 8.8.8.8 as the DNS. However, amending this into your DNS as your practice would impact the connectivity by an additional delay in DNS resolution and potentially adding a point of failure.

How DNS resolution works actually?

These are the basic order of resolution attempts. The first to reply wins either it’s right or wrong.

First phase: Local Windows Host File

Second phase: Computer’s DNS Server list

Third phase: Internal DNS Server

Fourth phase: Designated Conditional Forwarders

Fifth phase: DNS forwarders

Sixth phase: Root hints

What are the impacts?

Host file is static. It should only be used for troubleshooting and then immediately set back to it’s default after resolving the issue via internal DNS Servers.

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. Thus, will prevent your devices from communicating to Active Directory and devices won’t be able to grab policies, logins will be really slow and would cause intermittency with the domain.

Doing this would allow the local DNS queries will broadcasting your internal request to the internet. However, this is not recommended as its violating of your security policies.

DNS forwarders that points to 8.8.8.8 only are using your ISP connection to hop to 8.8.8.8 when resolving DNS. You have a local DNS resolution much closer that will speed up requests if used instead.

Moreover, if your DNS is set to 8.8.8.8, DNS failures may seem to be an ISP outage when your ISP connection if fine. If there is a 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 disabled root hints, one external DNS provider outage can stop external DNS resolution at your business.

Your Windows firewall internally would see you are on public network, which can cause it to start blocking network traffic. When 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 the same as well. Checking and unchecking IPv6 is a temporarily fix the public error, but it will continue 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.

References:

1. https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/best-practices-for-dns-client-settings
2. https://www.mirazon.com/stop-using-8-8-8-8-for-your-production-network/#:~:text=That%20is%20not%20recommended%20and,connection%20to%20hop%20to%208.8