Public DNS in DHCP Scope for domain joined machines?

Question

Hello,

I am trying to get some more information regarding best practices for DNS. I have done as much research as I can, however we have been hearing contradicting information from a contractor that has left me confused...

Everything I have found and learned says that domain joined machines should NOT be configured through the DHCP scope to use any public DNS servers, that Public DNS should only be configured using forwarders. The DHCP scope should only contain domain DNS servers because it can cause issues access internal resources if the client uses one of the public DNS servers. I have also seen a fair amount of reports from other's online about modern clients not respecting the "primary/secondary/tertiary/etc" structure and that any one of the servers listed in the client configuration can be used.

The contractor we have been using is saying otherwise and advised using our ISP's DNS servers as the tertiary and quaternary DNS servers in the DHCP scope AND using the forwarders. His argument was that in the event both of our Domain Controllers/DNS servers go down then the DHCP scope would still be configured to be able to use the ISP DNS for name resolution for public use. He stated that the clients will never use the tertiary or quaternary DNS server listed in the client configuration and that this is "best practice". He says he has configured it this way many times...

Can anyone provide more information this? I have pasted the only information I can find in the best practices guide below, but I cannot find any real information regarding the "tertiary/quaternary" argument. To me, the phrasing below would indicate that ISP DNS servers should not be configured at all, but I've never heard of using this as a "fail safe" of sorts for if the domain controllers go down by putting them further down the list.

Windows Server member servers

On Windows Server member servers, Microsoft recommends that you configure the DNS client settings according to these specifications:

• Configure the primary and secondary DNS client settings to point to local primary and secondary DNS servers (if local DNS servers are available) that host the DNS zone for the computer's Active Directory domain.
• If there are no local DNS servers available, point to a DNS server for that computer's Active Directory domain that can be reached through a reliable WAN link. Up-time and bandwidth determine reliability.
• Don't configure the client DNS settings to point to your ISP's DNS servers. If you do so, you may experience issues when you try to join the Windows Server-based server to the domain, or when you try to log on to the domain from that computer. Instead, the internal DNS server should configure forwarding to the ISP's DNS servers to resolve external names.

Best Practices Guide

Answer 1

Hello Friends

Hope you have a lovely day!

When configuring DNS for domain-joined machines, it is essential to adhere to best practices to ensure proper functionality and avoid potential issues with domain services. Here’s a detailed explanation based on the best practices and the points you’ve raised:

Best Practices for DNS Configuration

---

1. Internal DNS Servers Only in DHCP Scope:

• Primary and Secondary DNS: All domain-joined machines should be configured to use internal DNS servers exclusively. The primary and secondary DNS servers specified in the DHCP scope should point to your internal DNS servers that host the Active Directory (AD) DNS zones. This ensures that domain-joined machines can properly resolve domain names and locate domain controllers for authentication and other domain services.

2. No Public DNS in DHCP Scope:

• Avoid ISP/Public DNS: Configuring public DNS servers (including ISP's DNS servers) in the DHCP scope for domain-joined machines is generally discouraged. If a client queries an ISP's DNS server for a domain name that should be resolved by the internal DNS server, it can result in failed resolutions for domain resources, leading to authentication issues, difficulties accessing internal resources, and potential security risks.

3. DNS Forwarders:

• Use DNS Forwarders for External Resolution: Internal DNS servers should be configured to use DNS forwarders for resolving external domain names. This setup allows the internal DNS servers to handle all domain-specific queries while forwarding requests for non-domain names to an external DNS server (such as your ISP's DNS server or a public DNS server like Google's 8.8.8.8).

Addressing the Contractor's Argument

The contractor suggests configuring ISP DNS servers as tertiary and quaternary DNS servers in the DHCP scope to act as a fail-safe if both internal DNS servers go down. Here’s why this approach is problematic:

1. Modern DNS Client Behavior:

• Non-sequential DNS Querying: Modern DNS clients often do not strictly follow a primary/secondary/tertiary ordering. Instead, they might randomly select a DNS server from the list or use the one that responds fastest. This behavior means there is no guarantee that clients will only use the tertiary/quaternary DNS servers when the primary and secondary are unavailable. Consequently, clients may intermittently use ISP DNS servers even when internal DNS servers are operational, leading to the issues mentioned above.

---

2. Potential for Service Disruption:

• Inconsistent Name Resolution:If a domain-joined machine attempts to resolve a domain name using an ISP DNS server, it will fail to find the internal records necessary for domain operations. This failure can cause login issues, inability to locate domain controllers, and problems accessing internal resources.

3. Best Practices Guidance:

• Microsoft's Recommendation:According to Microsoft’s best practices, DNS client settings on domain-joined machines should exclusively point to internal DNS servers. This setup ensures all domain-related queries are handled correctly by internal DNS infrastructure.

Suggested Configuration

• DHCP Scope:
  • Primary DNS: Internal DNS Server 1
  • Secondary DNS: Internal DNS Server 2
• Internal DNS Servers:
  • Configure forwarders to public DNS servers (e.g., ISP DNS, Google DNS) for external name resolution.

Failover Considerations

To address the concern about both internal DNS servers going down:

• DNS Server Redundancy: Ensure high availability of your internal DNS servers by implementing redundancy and failover mechanisms (e.g., deploying multiple DNS servers in different locations, using DNS clustering or load balancing).
• Monitoring and Alerts: Implement robust monitoring and alerting systems to promptly address any issues with internal DNS servers before they result in downtime.

In summary, configuring domain-joined machines to use only internal DNS servers through DHCP and relying on forwarders for external resolution is the best practice. This setup maintains the integrity of domain operations and avoids potential issues related to using public DNS servers directly.

Best regards

rosy