Home / server / Questions / 907003
Accepted
shodanshok
Asked: 2018-04-11 10:32:07 +0800 CST

Public DNS on domain-joined PCs

  • 772

I have a two-controllers AD domain, and all domain-joined PCs have their addresses as primary and secondary DNS servers.

I wonder if I should configure a tertiary public DNS. The reasoning is that many PCs are located in smaller remote networks and they reach both domain controllers via a central VPN tunnel. If the VPN tunnel goes down, both DCs would be unavailable and the remote PCs will be unable to resolve any addresses, preventing them for surfing the internet/checking email/etc.

Adding a DC in each network is out of question (they are of 5/10 PCs), and the same can be said about creating a direct VPN tunnel from the remote network to the secondary DC site (due to hardware capacity).

A tertiary, public DNS server would prevent this, but I wonder if it can cause problems (ie: if it is, for some reason, selected as the preferred DNS, the PC would be "disconnected" from the domain).

So: it is ok to use a tertiary public DNS on a domain-joined PC, or it will cause problems? Anything to be aware of?

domain-name-system

3 Answers

  1. Best Answer

    For proper domain functionality Windows computers need to be able to perform lookups against the DNS zone being used for AD.

    If clients are pointed at a server that doesn't provide correct answers for that AD zone, those systems will probably break at some point.

    It is important to understand, that if a client made a DNS lookup for a record like _gc._tcp.yourdomain.example.org or some other internal-only record against that third external server, that server will respond with a not found error. Your client will not retry that query against your domain controllers. A not found answer is perfectly valid.

    If you want some more redundancy for DNS at your external sites, I would look at whatever device that is running that VPN, or the device acting as the router/firewall. See if one of those devices can act as a caching DNS server. Possibly you can get it to forward the internal DNS requests to the DCs, and non-internal requests out to the world. Or perhaps run a DNS server in the cloud somewhere that will forward all internal requests to your DCs, and use whatever method of recursion for other requests.

    • 4

  2. What I do on our network (many tiny offices, all linked in a star formation to our central DCs) is to have a pair of small cheap Raspberry Pi servers in each office. I use two for resilience. These secondary our AD DNS domain from the primary DNS/AD servers, but also know how to reach the rest of the world's DNS without going via the DCs at all.

    If an office VPN drops, the Pi servers continue serving DNS, and only our internal systems across the VPN become temporarily inaccessible. Everything else continues unaffected.

    • 3

  3. A caching DNS using DCs as a primary source and public DNS as secondary may not be enough, as it would still use the public DNS for all recursion, replying with NXDOMAIN for non-cached internal addresses when there's no connection between the sites. That's why @roaima's solution, whether it's Raspberry Pi, any workstation converted to a BIND server or a built-in DNS server on your VPN router, would be ideal: I'd recommend having full zones transferred to all sites. For this server a public DNS can be a forwarder for the rest, but I'd never push it directly to the clients.

    There's more to this than just the local DNS as a resolver for the AD domain.

    • If your site-to-site VPN has to work on both directions, a split may temporarily brake dynamic DNS updates. Is the local DHCP capable of caching those or how is this arranged, because the client computer doesn't automatically re-registers its DNS name when the split is over.

    • The correct Windows Firewall profile (domain / private / public) is based on the ability to authenticate with the domain controller. If a client is started during a split, it may have a wrong profile until the next reconnect or reboot, which may be worse than the NXDOMAIN problem.

    • If the remote site has pretty unlimited connectivity to the main site, split tunneling in general might make your network vulnerable, unless your VPN router is also an advanced firewall / UTM. Having the router chosen wisely may actually make configuring your DNS easier, as this kind of solutions are more likely to have a fully functional DNS server built-in. Furthermore, the settings are easier to deploy across the sites compared to a setup built from scratch.

    • 1