Using non MS DHCP in MS AD
-
I'm not ready to get rid of AD just yet, but I'm looking for ways to keep my environment more resilient when AD is down.
I'm the typical SMB, AD VM that also has DNS/DHCP on the same VM. If this VM goes down today, I lose internet access because DNS is gone. (it's amazing how quick windows clients give up the DNS cache for a site they are still using)
I have an Ubiquiti USG firewall.
Goal: not have internet access go down when AD/DNS/DHCP go down.
As most of us know - when Windows client fail to their secondary DNS, they do not fall back to the primary until there is a failure on the secondary. This prevents us from having the clients being directly aware of an external DNS provider like CloudFlare, because if the primary DNS has a blip, now those clients can't utilize any internal resources until the machine is forced back to the primary DNS.
-
As a current stop gap I've made the following changes:
DHCP/DNS are still on the AD server
DHCP provides DNS Primary (AD Server) secondary (USG)
USG's DNS is configured Primary (AD Server) secondary (1.1.1.1)
The expectation here is that the USG will fall back to the priamry as soon as it comes back online, no user intervention required. (need to test to confirm)
Without testing AD DNS failure situation itself, I have confirmed that a device using the USG as it's DNS will pull DNS from the AD DNS sever as desired.
This leaves solving DHCP being down on the AD box. My current DHCP lease time is 12 hours. I could easily make this 24 or 48, etc - but let's just plan for the worst, a long outage, so I want to move DHCP as well.
Does anyone see any issue in moving DHCP to the USG, still having DHCP provide DNS Primary (AD Server) Secondary (USG)? My question is about clients registering themselves with AD DNS. Assuming normal working conditions, I want them registering themselves with DNS.
-
Problem: One network blip and the intranet clients will lose their ability to resolve internal DNS A records for whatever the TTL setting is for them. BTDT
Public DNS servers do not belong anywhere near your intranet setup.
I.E. don't have DNS0 192.168.33.5 DC/DNS and DNS1 8.8.8.8 or whatever public DNS server. Bad. Just. Bad.
There are two ways to solve this that won't cause you grief:
- Set up as you are but leave DHCP off on the secondary device
- Set up DHCP Failover via a second DC
The second option can be licensed via your favourite SPLA provider for very little cost per month over purchasing a full license.
-
@Dashrender Vyatta (thus USG/EdgeRouter) handles this simply.
You simply add a DNS forwarding option to your setup.
I have multiple VPN mesh networks setup like this to prevent a VPN outage from killing all internet.First DNS setup (note this is from EdgeRouter, USG will be someplace in the GUI):
set service dns forwarding cache-size 150 set service dns forwarding listen-on eth3 set service dns forwarding name-server 10.204.20.2 <--- Local Pi-hole but could simply be router set service dns forwarding name-server 1.1.1.1 <--- Cloudflare set service dns forwarding options server=/domain.local/10.1.1.4 <-- AD across VPN set service dns forwarding options server=/domain/10.1.1.4 <-- AD across VPN
Second the DHCP setup:
set service dhcp-server shared-network-name SiteB authoritative disable set service dhcp-server shared-network-name SiteB subnet 10.204.20.0/24 default-router 10.204.20.1 set service dhcp-server shared-network-name SiteB subnet 10.204.20.0/24 dns-server 10.204.20.1 <-- clients look to router not Pi-Hole set service dhcp-server shared-network-name SiteB subnet 10.204.20.0/24 domain-name domain.local <-- ensures clients have the AD domain suffix in use. set service dhcp-server shared-network-name SiteB subnet 10.204.20.0/24 lease 86400
-
@PhlipElder said in Using non MS DHCP in MS AD:
Problem: One network blip and the intranet clients will lose their ability to resolve internal DNS A records for whatever the TTL setting is for them. BTDT
Completely misguided.
With the correct design, you can easily have non-windows DHCP and DNS and have zero issues. -
Stupid question perhaps but are the clients really registering themselves with the DNS? I thought the clients got their IP from the DHCP server and it's the DHCP server that registers the DHCP hostname in DNS.
-
@JaredBusch said in Using non MS DHCP in MS AD:
@Dashrender Vyatta (thus USG/EdgeRouter) handles this simply.
You simply add a DNS forwarding option to your setup.
I have multiple VPN mesh networks setup like this to prevent a VPN outage from killing all internet.First DNS setup (note this is from EdgeRouter, USG will be someplace in the GUI):
set service dns forwarding cache-size 150 set service dns forwarding listen-on eth3 set service dns forwarding name-server 10.204.20.2 <--- Local Pi-hole but could simply be router set service dns forwarding name-server 1.1.1.1 <--- Cloudflare set service dns forwarding options server=/domain.local/10.1.1.4 <-- AD across VPN set service dns forwarding options server=/domain/10.1.1.4 <-- AD across VPN
Second the DHCP setup:
set service dhcp-server shared-network-name SiteB authoritative disable set service dhcp-server shared-network-name SiteB subnet 10.204.20.0/24 default-router 10.204.20.1 set service dhcp-server shared-network-name SiteB subnet 10.204.20.0/24 dns-server 10.204.20.1 <-- clients look to router not Pi-Hole set service dhcp-server shared-network-name SiteB subnet 10.204.20.0/24 domain-name domain.local <-- ensures clients have the AD domain suffix in use. set service dhcp-server shared-network-name SiteB subnet 10.204.20.0/24 lease 86400
yeah, this is close to what I do, except I have my clients talk to my AD DNS first, and the firewall second... the firewall then talks to the AD DNS first, and CloudFlare second...
Jared's example gives the clients only one DNS entry - the firewall itself, and it handles all routing to whatever DNS server is actually handling stuff. -
@Pete-S said in Using non MS DHCP in MS AD:
Stupid question perhaps but are the clients really registering themselves with the DNS? I thought the clients got their IP from the DHCP server and it's the DHCP server that registers the DHCP hostname in DNS.
This is the real root of the question - if you'll notice the title is about DHCP, not DNS... but I wanted to cover all bases here.
But onto registering in DNS - It's my understanding that Windows clients will register on their own, they understand dynamic DNS, so they don't need DHCP to do it for them.
Other devices apparently don't understand/care about dynamic DNS, so DHCP can then help those devices register into DNS.
Assuming all the above is correct, then my setup where my primary is my AD DNS, then my Windows clients should register without issue - this is also why I need AD's DNS needs to be primary.
-
Setup the way I show, Windows DNS still gets updated form workstations.
-
@JaredBusch said in Using non MS DHCP in MS AD:
Setup the way I show, Windows DNS still gets updated form workstations.
Good to know Windows is doing what it's supposed to do!
Thanks Jared