Handling DNS in a Single Active Directory Domain Controller Environment
-
By now, hopefully everyone knows that in the SMB having only a single Active Directory Domain Controller, for those companies that truly need AD in the first place, isn't just acceptable but is the most commonly correct approach, since AD failover often has almost no value, but a second DC generally is expensive (there are exceptions to both cases, of course.)
But this brings up (and brought up in an offline discussion) a concern around when your AD server is also your DNS server, how do you handle DNS failover, rather than AD failover, when they are tied together?
-
Let's say someone knew they probably don't need AD, but they have never heard that only 1 server is fine. Hypothetically, where would they look to read more into this idea?
-
@s-hackleman said in Handling DNS in a Single Active Directory Domain Controller Environment:
Let's say someone knew they probably don't need AD, but they have never heard that only 1 server is fine. Hypothetically, where would they look to read more into this idea?
One DNS server?
-
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
By now, hopefully everyone knows that in the SMB having only a single Active Directory Domain Controller, for those companies that truly need AD in the first place, isn't just acceptable but is the most commonly correct approach, since AD failover often has almost no value, but a second DC generally is expensive (there are exceptions to both cases, of course.)
Do you have a reference for your "most commonly correct approach" statement aside from something you've written? Running a second AD server isn't all that expensive. You have a server license and (potentially) hardware, so $1,500 to $2,000 USD if you don't already have a second set of hardware you can run it on. If you run it in core configuration it requires very little in the way of resources. Given the premise of handling DNS failover scenarios it seems like having two DCs would be better, but I'm open to being convinced.
Edit: The $1,500 to $2,000 might seem like quite a bit, but those costs are pretty minimal compared to down time and repair costs if you do suffer a catastrophic failure.
-
@s-hackleman said in Handling DNS in a Single Active Directory Domain Controller Environment:
Let's say someone knew they probably don't need AD, but they have never heard that only 1 server is fine. Hypothetically, where would they look to read more into this idea?
Reverse it. There isn't really anything special to read, it's really about applying standard IT practices to AD and not treating it as a special, magical black box case. No workload in IT is ever "always redundant", never. It always comes down to analyzing the risk (cost and likeliness of downtime), understanding the recovery model, and looking at the cost of redundancy and analyzing what risk that mitigates (and what extra risk is creates.)
There is nothing special about AD to read about. The problem is, if you read vendor resources their job is to sell more licenses so claim a false "best practice" to have two which clearly violates the most basic IT best practices (of always evaluating your own needs) and loads of places that just repeat that without ever looking at how wrong it is. So it gets this feeling that there is actually a reason you need two, which doesn't really exist.
However, there is this one resource...
-
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
Do you have a reference for your "most commonly correct approach" statement aside from something you've written?
It's not something that needs to be sought out. It's simply applying baseline IT practices to AD. It's no different than any other service on your network - on average nothing needs to be redundant, the cost is higher than the risk. So you don't need, and won't find, things specific to AD as that doesn't really make sense. I've only bothered to do it because so many communities promote it as if AD is magic and standard IT best practices are to be ignored with it.
-
How passwords are stored and reset is a critical aspect of GDPR compliance. Clients and staff members may legitimately forget or need to reset passwords for a number of reasons. GDPR requirements mean that companies must be able to demonstrate that their password reset processes and procedures are secure. Systems must be in place, for example, to prevent help desk employees that may be involved in resets from directly accessing passwords.
-
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
Running a second AD server isn't all that expensive. You have a server license and (potentially) hardware, so $1,500 to $2,000 USD if you don't already have a second set of hardware you can run it on. If you run it in core configuration it requires very little in the way of resources.
In the SMB market, $1,500 - $2,500 is anything but small. To most businesses, that's a lot of money. And don't forget that adding a second DC means your IT has to know a lot more about how things work, it's not just double the software and possibly double the hardware, it's also more effort and expertise needed. The system is less "simple."
Compare that to the risk of not having a second AD DC. For the average business, the impact of losing AD temporarily is tiny to zero. Many can have AD down and not even know! As the CEO... how much money is it worth to protect again a "zero impact" outage. I guarantee the answer is... zero. Even if you risk losing $5,000 from an AD outage, that's not half as much as you'd need to justify investing $2,500 up front to protect against a maybe outage someday in the future that small.
Also, in real world terms, if you lose your only AD DC, it means you've likely lost some, most, or even all other AD linked (and even non-AD linked) services. When AD is down, most typically businesses are having issues not because of AD, but because other things running on the same server are down. AD would be the least of their worries.
-
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
Edit: The $1,500 to $2,000 might seem like quite a bit, but those costs are pretty minimal compared to down time and repair costs if you do suffer a catastrophic failure.
One of the problems with this specific discussion is that AD varies wildly from a cost of roughly $0 for one company to close to $3,000 for another. Comes down heavily to the hardware needs, virtualization requirements, how the licensing is handled, etc. For one company, there might already be a spare server, a spare license, and no other use case for them, so the second DC is "free" and they should probably do it without question. But for another, it might be buying a dedicated server and a dedicated Windows license for that one thing, making it rather pricey.
So no way to say what a general case cost will be.
-
@stuartjordan said in Handling DNS in a Single Active Directory Domain Controller Environment:
How passwords are stored and reset is a critical aspect of GDPR compliance. Clients and staff members may legitimately forget or need to reset passwords for a number of reasons. GDPR requirements mean that companies must be able to demonstrate that their password reset processes and procedures are secure. Systems must be in place, for example, to prevent help desk employees that may be involved in resets from directly accessing passwords.
I responded in the GDPR Password thread.
-
@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.
-
To be clear, no one is suggesting that two AD DCs is bad. Only that in many cases, only having one is appropriate and when you do have only one, DNS is often a cascaded dependency that might need to be addressed, and that's what we are looking at here - when you have only one AD DC (we are already assuming that you fit that profile) how do you deal with DNS needs.
-
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
- 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.
Here is how I handle it in EdgeOS
set service dns forwarding cache-size 150 set service dns forwarding listen-on eth1 set service dns forwarding name-server 10.1.1.show 4 set service dns forwarding name-server 1.1.1.1 set service dns forwarding name-server 8.8.8.8 set service dns forwarding options server=/domain.local/10.1.1.4 set service dns forwarding options server=/domain/10.1.1.4 set system domain-name domain.local set system name-server 127.0.0.1And the few absolute core items that I need to 100% resolve get a static host mapping in EdgeOS.
set system static-host-mapping host-name dc02 inet 10.1.1.4 set system static-host-mapping host-name dc02.domain.local inet 10.1.1.4 set system static-host-mapping host-name domain.local inet 10.1.1.4 set system static-host-mapping host-name pbx.domain.com inet 10.1.1.30 -
@jaredbusch said in Handling DNS in a Single Active Directory Domain Controller Environment:
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
- 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.
Here is how I handle it in EdgeOS
set service dns forwarding cache-size 150 set service dns forwarding listen-on eth1 set service dns forwarding name-server 10.1.1.show 4 set service dns forwarding name-server 1.1.1.1 set service dns forwarding name-server 8.8.8.8 set service dns forwarding options server=/domain.local/10.1.1.4 set service dns forwarding options server=/domain/10.1.1.4 set system domain-name domain.local set system name-server 127.0.0.1And the few absolute core items that I need to 100% resolve get a static host mapping in EdgeOS.
set system static-host-mapping host-name dc02 inet 10.1.1.4 set system static-host-mapping host-name dc02.domain.local inet 10.1.1.4 set system static-host-mapping host-name domain.local inet 10.1.1.4 set system static-host-mapping host-name pbx.domain.com inet 10.1.1.30That's smart thinking if you have an on prem PBX. They can still use the phones even if the DC (and primary DNS) is down.
-
@mike-davis said in Handling DNS in a Single Active Directory Domain Controller Environment:
That's smart thinking if you have an on prem PBX. They can still use the phones even if the DC (and primary DNS) is down.
Exactly. And that's exactly why we do something similar. We want our PCs and phones online even when other things are down.
And honestly, for things like PBX that is off prem, we never use the in house DNS for the phones at all. Point them straight to CloudFlare or Google and if AD fails, no one knows (from a phone perspective.)
-
In our DHCP settings (hosted by the same DC) I currently have 5 DNS servers defined. My two DC's, then the two public DNS from our ISP, then finally 8.8.8.8. But in my experience, if my DC is down, I've got larger issues than just DNS. But when this has happened, I just start up the DHCP server on the router and define 8.8.8.8 as the DNS for everyone while I fix this issue with the DC. I am not sure we have it configured correctly though, because it never seems to actually fail over to the other DC. It could be because its in another subnet at a different location, not sure.
-
I have a number of clients where they need a server, but Server Essentials on a small server is enough. Veeam for backup and if the box fails, they are down for an hour or two while we restore to something else. The licensing to go to a second AD server would more than double the cost of the project. (and isn't worth it for them)
-
@mike-davis said in Handling DNS in a Single Active Directory Domain Controller Environment:
I have a number of clients where they need a server, but Server Essentials on a small server is enough. Veeam for backup and if the box fails, they are down for an hour or two while we restore to something else. The licensing to go to a second AD server would more than double the cost of the project. (and isn't worth it for them)
Great example, that's what we see a lot, even with "larger than Essentials" shops. The downtime is still short, getting new hardware is trivial (a big desktop could do it), a single server restore is simple, and the cost to avoid that pain is huge compared to the cost of the downtime.
-
@donahue said in Handling DNS in a Single Active Directory Domain Controller Environment:
In our DHCP settings (hosted by the same DC) I currently have 5 DNS servers defined. My two DC's, then the two public DNS from our ISP, then finally 8.8.8.8. But in my experience, if my DC is down, I've got larger issues than just DNS. But when this has happened, I just start up the DHCP server on the router and define 8.8.8.8 as the DNS for everyone while I fix this issue with the DC. I am not sure we have it configured correctly though, because it never seems to actually fail over to the other DC. It could be because its in another subnet at a different location, not sure.
That might be the cause. Do you have them set up as different sites?
I would avoid using the ISP DNS, that's generally slow and risky. Use Google and CloudFlare for your "other" DNSs on the outside. Fast and secure. And each provides two, so more than enough to replace what you have.
-
@donahue said in Handling DNS in a Single Active Directory Domain Controller Environment:
In our DHCP settings (hosted by the same DC) I currently have 5 DNS servers defined. My two DC's, then the two public DNS from our ISP, then finally 8.8.8.8. But in my experience, if my DC is down, I've got larger issues than just DNS.
I would never put public DNS entries in anything related to a client system running a Windows Desktop OS. I have had too much direct experience with Windows' network stack flipping to the secondary DNS server and not flipping back to ever want to deal with that crap. It could be better with Windows 10, but I am not going to change now to find out.
@donahue said in Handling DNS in a Single Active Directory Domain Controller Environment:
But when this has happened, I just start up the DHCP server on the router and define 8.8.8.8 as the DNS for everyone while I fix this issue with the DC. I am not sure we have it configured correctly though, because it never seems to actually fail over to the other DC. It could be because its in another subnet at a different location, not sure.
DHCP is a different but related issue.
