Handling DNS in a Single Active Directory Domain Controller Environment
-
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
At this point, all internal services are down until AD is restored. Another variable that is difficult to account for. The most prevalent one of these would be printers. Impact will vary from business to business. If we say that of those 10 employees, 2 require (whether from felt personal need, or actual professional need it doesn't matter) a printer multiple times per day. How does 5 times sound? There are work arounds. Our enterprising technician goes to each machine to edit their hosts file to allow the users to print. Between getting all the information, figuring out the changes, coordinating with employees, and actually doing the work we'll say it takes an hour, so another $25.
How likely is it the single shared AD/DNS/DHCP/PRINT server VM is down for the 5-10 minutes it takes to restore at the same time both users need to print something? In that case, have them get a coffee. VM's just don't "go down" for no reason.
What all is "down"? How wide spread is it? Is it just the VM? The whole host? Power outage? Network switches okay? What all is the issue here?
-
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
At this point, all internal services are down until AD is restored. Another variable that is difficult to account for. The most prevalent one of these would be printers. Impact will vary from business to business. If we say that of those 10 employees, 2 require (whether from felt personal need, or actual professional need it doesn't matter) a printer multiple times per day. How does 5 times sound? There are work arounds. Our enterprising technician goes to each machine to edit their hosts file to allow the users to print. Between getting all the information, figuring out the changes, coordinating with employees, and actually doing the work we'll say it takes an hour, so another $25.
How likely is it the single shared AD/DNS/DHCP/PRINT server VM is down for the 5-10 minutes it takes to restore at the same time both users need to print something? In that case, have them get a coffee. VM's just don't "go down" for no reason.
What all is "down"? How wide spread is it? Is it just the VM? The whole host? Power outage? Network switches okay? What all is the issue here?
With Kelly's quoted post, I assumed he meant that the host was down for whatever reason.
I believe we are working from an expectation that power is good, and the network infrastructure is good - up to and including the firewalls are fine and the internet connection is good.
-
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
At this point, all internal services are down until AD is restored. Another variable that is difficult to account for. The most prevalent one of these would be printers. Impact will vary from business to business. If we say that of those 10 employees, 2 require (whether from felt personal need, or actual professional need it doesn't matter) a printer multiple times per day. How does 5 times sound? There are work arounds. Our enterprising technician goes to each machine to edit their hosts file to allow the users to print. Between getting all the information, figuring out the changes, coordinating with employees, and actually doing the work we'll say it takes an hour, so another $25.
How likely is it the single shared AD/DNS/DHCP/PRINT server VM is down for the 5-10 minutes it takes to restore at the same time both users need to print something? In that case, have them get a coffee. VM's just don't "go down" for no reason.
What all is "down"? How wide spread is it? Is it just the VM? The whole host? Power outage? Network switches okay? What all is the issue here?
With Kelly's quoted post, I assumed he meant that the host was down for whatever reason.
I believe we are working from an expectation that power is good, and the network infrastructure is good - up to and including the firewalls are fine and the internet connection is good.
I would agree. One host down, nothing else down assumed. Users are all functional.
-
It's anecdotal, but I just had this happen a few weeks ago. In my case I had a host go down that had my AD VM on it. It took me while to get it all resolved, but that is because I had to physically remove my server from the rack to get access to the usb drive where ESXi was installed (we will be getting a new rack soon). DNS was probably the biggest hit because a lot of our internal services use the DNS name.
-
@donahue said in Handling DNS in a Single Active Directory Domain Controller Environment:
It's anecdotal, but I just had this happen a few weeks ago. In my case I had a host go down that had my AD VM on it. It took me while to get it all resolved, but that is because I had to physically remove my server from the rack to get access to the usb drive where ESXi was installed (we will be getting a new rack soon). DNS was probably the biggest hit because a lot of our internal services use the DNS name.
Yeah, that was an odd one for sure.
-
@donahue said in Handling DNS in a Single Active Directory Domain Controller Environment:
It's anecdotal, but I just had this happen a few weeks ago. In my case I had a host go down that had my AD VM on it. It took me while to get it all resolved, but that is because I had to physically remove my server from the rack to get access to the usb drive where ESXi was installed (we will be getting a new rack soon). DNS was probably the biggest hit because a lot of our internal services use the DNS name.
I'm guessing you'll be like me and updating DHCP to include the router's IP as DNS (assuming yours supports DNS) and having the router point to internal DNS before external. I'm really loving this idea.
-
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@donahue said in Handling DNS in a Single Active Directory Domain Controller Environment:
It's anecdotal, but I just had this happen a few weeks ago. In my case I had a host go down that had my AD VM on it. It took me while to get it all resolved, but that is because I had to physically remove my server from the rack to get access to the usb drive where ESXi was installed (we will be getting a new rack soon). DNS was probably the biggest hit because a lot of our internal services use the DNS name.
I'm guessing you'll be like me and updating DHCP to include the router's IP as DNS (assuming yours supports DNS) and having the router point to internal DNS before external. I'm really loving this idea.
I am not sure. I am in the process of reevaluating my entire network and willing to take suggestions. I think that there is a lot of inefficiency in our current system due mostly to inexperience.
-
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@donahue said in Handling DNS in a Single Active Directory Domain Controller Environment:
It's anecdotal, but I just had this happen a few weeks ago. In my case I had a host go down that had my AD VM on it. It took me while to get it all resolved, but that is because I had to physically remove my server from the rack to get access to the usb drive where ESXi was installed (we will be getting a new rack soon). DNS was probably the biggest hit because a lot of our internal services use the DNS name.
I'm guessing you'll be like me and updating DHCP to include the router's IP as DNS (assuming yours supports DNS) and having the router point to internal DNS before external. I'm really loving this idea.
So using this example, If the DHCP server (mine is on the AD VM) points first to the router, outside DNS still works if AD goes out. If the router goes down though, internal DNS wont work unless the internal DNS was listed second under DHCP. Does this make sense?
-
@donahue said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@donahue said in Handling DNS in a Single Active Directory Domain Controller Environment:
It's anecdotal, but I just had this happen a few weeks ago. In my case I had a host go down that had my AD VM on it. It took me while to get it all resolved, but that is because I had to physically remove my server from the rack to get access to the usb drive where ESXi was installed (we will be getting a new rack soon). DNS was probably the biggest hit because a lot of our internal services use the DNS name.
I'm guessing you'll be like me and updating DHCP to include the router's IP as DNS (assuming yours supports DNS) and having the router point to internal DNS before external. I'm really loving this idea.
So using this example, If the DHCP server (mine is on the AD VM) points first to the router, outside DNS still works if AD goes out. If the router goes down though, internal DNS wont work unless the internal DNS was listed second under DHCP. Does this make sense?
You point to AD first, router second. If the router goes down, you are down either way.
Then the router points to AD first, public second.
-
@donahue said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@donahue said in Handling DNS in a Single Active Directory Domain Controller Environment:
It's anecdotal, but I just had this happen a few weeks ago. In my case I had a host go down that had my AD VM on it. It took me while to get it all resolved, but that is because I had to physically remove my server from the rack to get access to the usb drive where ESXi was installed (we will be getting a new rack soon). DNS was probably the biggest hit because a lot of our internal services use the DNS name.
I'm guessing you'll be like me and updating DHCP to include the router's IP as DNS (assuming yours supports DNS) and having the router point to internal DNS before external. I'm really loving this idea.
So using this example, If the DHCP server (mine is on the AD VM) points first to the router, outside DNS still works if AD goes out. If the router goes down though, internal DNS wont work unless the internal DNS was listed second under DHCP. Does this make sense?
Yes - but why point to your router first?
Personally - point to Windows DNS first, router second. The router DNS is configured to forward requests to Windows DNS first, and external (say Google) second.
So - AD is down, Windows DNS is down. The client will check with Windows DNS - fail, switch to secondary DNS on router, router will check Windows DNS - fail, Router will check secondary (external) DNS, success.
There will be some delay as the switching between what DNS is primary vs secondary happens, but for the user it shouldn't be more than one failure page load.
-
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
@donahue said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@donahue said in Handling DNS in a Single Active Directory Domain Controller Environment:
It's anecdotal, but I just had this happen a few weeks ago. In my case I had a host go down that had my AD VM on it. It took me while to get it all resolved, but that is because I had to physically remove my server from the rack to get access to the usb drive where ESXi was installed (we will be getting a new rack soon). DNS was probably the biggest hit because a lot of our internal services use the DNS name.
I'm guessing you'll be like me and updating DHCP to include the router's IP as DNS (assuming yours supports DNS) and having the router point to internal DNS before external. I'm really loving this idea.
So using this example, If the DHCP server (mine is on the AD VM) points first to the router, outside DNS still works if AD goes out. If the router goes down though, internal DNS wont work unless the internal DNS was listed second under DHCP. Does this make sense?
You point to AD first, router second. If the router goes down, you are down either way.
Then the router points to AD first, public second.
We recently had a router outage. I would still want internal DNS so we can still work from internal resources.
-
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
Given the premise of handling DNS failover scenarios it seems like having two DCs would be better, but I'm open to being convinced.
So there are a few scenarios here. But here are some general approaches to this that I've seen (thanks to @JaredBusch for the big one...)
- In really small AD environments, there might be zero internal DNS needs and Windows DNS is for AD only. In which case, point to the router's DNS or a public DNS and you are done, easy peasy. Free, simple, universal.
- In environments with internal DNS dependencies, much of the time the impact of losing that is trivial and you just have workers run in a reduced functionality mode until AD DC is fixed. Impact can be so small as to not measure. An option if you are very small and don't need external web access (super rare.)
- Jared's solution... point your router to your internal DNS first, then to public DNS. This handles failover and deals with any concerns of Windows DNS stack being flaky. When AD is up, internal DNS works, when it goes down, you transparently fail to public DNS.
- Use zone transfer to another DNS server. This could just be to your router. Have your router or some other "free or already included" system keep a copy of Windows' DNS and use this as your secondary. Full DNS redundancy (without active updates) while the AD DC is down. You could build a DNS server just for this, but nearly all networks have one already available. But a Raspberry Pi will do this easily if you really have no other hardware.
1: Nope. It's not a good idea to ever point DNS to an Internet based DNS server whether on the edge, DHCP, or DNS1 of a NIC (DNS0 being the local DC). Any kind of glitch will kick the clients over to a public DNS server that will respond to all internal queries with a, "Huh?" Then, Time To Live (TTL) means folks sit their doing nothing until someone either reboots, restarts DNS Client, or the TTL goes by.
2: If it's really that important there are two ways to deal with it: A: A good backup that's known good (fully restore tested). Or, B: an A series VM with site-to-site VPN in Azure with a fully prompted DC on the VM.
3: Nope. We've dealt with too many DNS questions/problems due to this to permit this on any network we manage.
4: See #2
-
@phlipelder said in Handling DNS in a Single Active Directory Domain Controller Environment:
3: Nope. We've dealt with too many DNS questions/problems due to this to permit this on any network we manage.
Jared's DNS solution could definitely fun afoul of the same Windows DNS flipping if the router's DNS forwarder won't always try the primary DNS server first, or at least retry it frequently.
Windows for example won't ever change back until the DNS server it's own has it's own glitch.
-
@scottalanmiller My printers all have static IP's as well. I manage that and keep track of all printers/IP's. We have around 200 users
-
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
Jared's DNS solution could definitely fun afoul of the same Windows DNS flipping if the router's DNS forwarder won't always try the primary DNS server first, or at least retry it frequently.
No normal router is going to do that. That's definitely not a real world concern.
-
@jmoore said in Handling DNS in a Single Active Directory Domain Controller Environment:
@scottalanmiller My printers all have static IP's as well. I manage that and keep track of all printers/IP's. We have around 200 users
We use DHCP Reservations for all printers being managed. If a printer gets moved from one site to another we don't have to muck about with it prior to the move or afterwards. All printers get deployed using a dedicated GPO linked to the Site/OU the printer will reside in.
-
This is a tangent, but can you tell a DHCP reservation to use a particular IP in the scope? Like if it comes in with something random, you can make a reservation for that mac and then change the IP to something else and restart the device?
-
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
At this point, all internal services are down until AD is restored. Another variable that is difficult to account for. The most prevalent one of these would be printers. Impact will vary from business to business. If we say that of those 10 employees, 2 require (whether from felt personal need, or actual professional need it doesn't matter) a printer multiple times per day. How does 5 times sound? There are work arounds. Our enterprising technician goes to each machine to edit their hosts file to allow the users to print. Between getting all the information, figuring out the changes, coordinating with employees, and actually doing the work we'll say it takes an hour, so another $25.
How likely is it the single shared AD/DNS/DHCP/PRINT server VM is down for the 5-10 minutes it takes to restore at the same time both users need to print something? In that case, have them get a coffee. VM's just don't "go down" for no reason.
What all is "down"? How wide spread is it? Is it just the VM? The whole host? Power outage? Network switches okay? What all is the issue here?
With Kelly's quoted post, I assumed he meant that the host was down for whatever reason.
I believe we are working from an expectation that power is good, and the network infrastructure is good - up to and including the firewalls are fine and the internet connection is good.
Okay, so the host is down. Still unsure if it's the only VM on the host or not, and whether or not the services that depend on AD are still available.
For the sake of argument, if every other service is running on it's own hardware, non-virtualized, and the only virtual host they have contains AD/DNS/DHCP/PRINT VM, but no other important services. That is going back to assuming that in a single-AD server environment, things are done incorrectly.... but I'll roll with that. Then yes, you'll need to fix the existing host first... perhaps a MOBO replacement from Dell within the next business day. Because of how important that VM is, they'd need to have active warranty services at least NBD service.
Or, maybe Hyper-V role could be enabled on another server, rebooted, and the VM restored to that. Is there a backup server? There's so many unknowns to account for. Why is it assumed that everything is set up incorrectly that you MUST have HA DC VM?
-
@donahue said in Handling DNS in a Single Active Directory Domain Controller Environment:
This is a tangent, but can you tell a DHCP reservation to use a particular IP in the scope? Like if it comes in with something random, you can make a reservation for that mac and then change the IP to something else and restart the device?
The reservation can be set by right clicking on the DHCP Lease and Add to Reservations to reserve the specific IP a device would pick-up when it first connects.
Or, I can set up the reservation using that device's MAC address ahead of time so that when the device gets connected it picks up the IP address I need it to have.
Does that answer the question?
-
@phlipelder yes, that is probably the last piece I would need before I would switch to using reservations more. I have just never looked it up to make sure it was doable. I like the idea of reservations, but I would also want similar devices in similar parts of the scope for organizational purposes.
