Handling DNS in a Single Active Directory Domain Controller Environment
-
@donahue said in Handling DNS in a Single Active Directory Domain Controller Environment:
@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.
That is a managerial issue and has nothing to do with the technology.
If you want it there, design it there.
-
@jaredbusch We always set up the full subnet in DHCP then configure exclusions for the parts of the subnet that would be divvied up to printers, servers, and other services/systems we assign addresses to.
-
@phlipelder said in Handling DNS in a Single Active Directory Domain Controller Environment:
@jaredbusch We always set up the full subnet in DHCP then configure exclusions for the parts of the subnet that would be divvied up to printers, servers, and other services/systems we assign addresses to.
Exactly the best way to do it, in my experience. And exactly what I just shown in the example above.
-
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
Printers are a big case that @Kelly mentioned, Those are often overlooked. Mostly because we all hate them.
Something I'm seeing more and more is people printing directly to printers and not going through a print server. I think more and more in the smaller SMBs (those most likely to not have dual AD DCs) this is increasingly common and likely the strongest protection there.
Print servers used to be pretty critical, and large shops with loads of printing still need them. But for smaller companies, how often is this seen in new deployments? I know here it rarely crosses our mind to put in a print server. Just extra complexity. All the printers we deal with typically have built in print servers and it is rare that we need printer security until the shops get pretty big.
Along this line, I no longer use a print server ever. Plenty of legacy networks still have them, but going forward, it is a powershell script to set the printers up.
I will still use a GPO to execute the script depending on the network, but it is jsut direct IP printing from now on for me.Note: Typical SMB obviously. Larger businesses bring new dynamics to change things like this.
I posted a sample script someplace on here a few weeks back.
Still working out some kinks, but it will end up on github or gitlab.
-
@scottalanmiller Ok you do keep the physical lan but you don't use the lan for your security. You instead use whatever application that you are using for your work to control that. That would mean applications have to be built to do this and we would also have to trust they were built in a secure manner. We are still a long ways from this being universal. Is that kind of what you meant?
-
@jmoore said in Handling DNS in a Single Active Directory Domain Controller Environment:
@scottalanmiller Ok you do keep the physical lan but you don't use the lan for your security.
The physical LAN can't go away, whatever device you have, that's on "a LAN". But traditionally people used that LAN as a security safe area and treated anything on it as special. This creates both network management problems (like needing internal DNS) and security problems (LAN breaches are the majority of attacks.)
If you start thinking of your own LAN as foreign and risky, LANless design allows for better security, and way more flexibility. Since real world companies are no longer bound by the physical LAN connections.
-
@jmoore said in Handling DNS in a Single Active Directory Domain Controller Environment:
That would mean applications have to be built to do this and we would also have to trust they were built in a secure manner.
You have to do this regardless. If you don't, you aren't secure.
LAN thinking isn't secure, it's just ignoring risk. LANless embraces reality that blindly trusting the LAN is dangerous. You can't assume that anything that plugs in is safe to use.
-
@jmoore said in Handling DNS in a Single Active Directory Domain Controller Environment:
We are still a long ways from this being universal. Is that kind of what you meant?
Good design will never be universal. Most networks, most admins, most software will always be bad. Nothing good becomes the norm, not how the world works.
-
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
@jmoore said in Handling DNS in a Single Active Directory Domain Controller Environment:
We are still a long ways from this being universal. Is that kind of what you meant?
Good design will never be universal. Most networks, most admins, most software will always be bad. Nothing good becomes the norm, not how the world works.
the law of averages apply.
-
@donahue 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:
@jmoore said in Handling DNS in a Single Active Directory Domain Controller Environment:
We are still a long ways from this being universal. Is that kind of what you meant?
Good design will never be universal. Most networks, most admins, most software will always be bad. Nothing good becomes the norm, not how the world works.
the law of averages apply.
Exactly.
-
@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.)
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?
I'm not sure you ever addressed my contentions to your opening statement. There was a lot of discussion that went back and forth, but I was responding to your initial statement that a single AD DC is "most commonly correct approach" based on cost and lack of value. My long post was showing that the cost of it disappears very quickly in an outage in the typical SMB. If things are properly configured and laid out those costs can be mitigated, but also at a cost. I don't buy the "most commonly correct approach" statement based on common implementations. Maybe common ML IT pro implementations, but not generally. Not so I would want to recommend it as a best practice which the language of your statement appears to assert.
-
@kelly 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:
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?
I'm not sure you ever addressed my contentions to your opening statement. There was a lot of discussion that went back and forth, but I was responding to your initial statement that a single AD DC is "most commonly correct approach" based on cost and lack of value. My long post was showing that the cost of it disappears very quickly in an outage in the typical SMB. If things are properly configured and laid out those costs can be mitigated, but also at a cost. I don't buy the "most commonly correct approach" statement based on common implementations. Maybe common ML IT pro implementations, but not generally. Not so I would want to recommend it as a best practice which the language of your statement appears to assert.
Sure - but you can't include bad "common" implementations in a conversation like this.
-
@dashrender 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:
@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.)
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?
I'm not sure you ever addressed my contentions to your opening statement. There was a lot of discussion that went back and forth, but I was responding to your initial statement that a single AD DC is "most commonly correct approach" based on cost and lack of value. My long post was showing that the cost of it disappears very quickly in an outage in the typical SMB. If things are properly configured and laid out those costs can be mitigated, but also at a cost. I don't buy the "most commonly correct approach" statement based on common implementations. Maybe common ML IT pro implementations, but not generally. Not so I would want to recommend it as a best practice which the language of your statement appears to assert.
Sure - but you can't include bad "common" implementations in a conversation like this.
Not sure what you're getting at. Scott is stating that a single AD DC is the "most commonly correct approach" based on costs vs risks. My postulation is that this not necessarily correct in the majority of implementations. Even a perfect implementation that mitigates entirely the risks of not having a failover DC carries costs that can remove any benefits gained.
-
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
Maybe common ML IT pro implementations, but not generally.
I've been doing it since Server 2003 days.
This was the entire point of the Windows SBS model from 2003 through 2011.
So I think you have blinders on to claim it is only Scott or only ML.
-
@jaredbusch 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:
Maybe common ML IT pro implementations, but not generally.
I've been doing it since Server 2003 days.
This was the entire point of the Windows SBS model from 2003 through 2011.
So I think you have blinders on to claim it is only Scott or only ML.
Either I'm not communicating well, or I'm misunderstanding what y'all are getting at. Can you clarify what you mean?
-
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
@jaredbusch 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:
Maybe common ML IT pro implementations, but not generally.
I've been doing it since Server 2003 days.
This was the entire point of the Windows SBS model from 2003 through 2011.
So I think you have blinders on to claim it is only Scott or only ML.
Either I'm not communicating well, or I'm misunderstanding what y'all are getting at. Can you clarify what you mean?
I’ve been implementing single AD DC stacks for years in the methods described here.
I have been using various techniques for handling failure of the services on them for all of that time. The router based strategy I posted above for DNS is something I first used in 2007. It included disabled, but configured, DHCP also.
Is that more clear? Or am I misunderstanding you completely?
-
@kelly 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:
@kelly 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:
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?
I'm not sure you ever addressed my contentions to your opening statement. There was a lot of discussion that went back and forth, but I was responding to your initial statement that a single AD DC is "most commonly correct approach" based on cost and lack of value. My long post was showing that the cost of it disappears very quickly in an outage in the typical SMB. If things are properly configured and laid out those costs can be mitigated, but also at a cost. I don't buy the "most commonly correct approach" statement based on common implementations. Maybe common ML IT pro implementations, but not generally. Not so I would want to recommend it as a best practice which the language of your statement appears to assert.
Sure - but you can't include bad "common" implementations in a conversation like this.
Not sure what you're getting at. Scott is stating that a single AD DC is the "most commonly correct approach" based on costs vs risks. My postulation is that this not necessarily correct in the majority of implementations. Even a perfect implementation that mitigates entirely the risks of not having a failover DC carries costs that can remove any benefits gained.
What expenses are you going to have, in a SMB, that are generally going to outweigh the costs of that DC?
If we limit ourselves only to a DC with AD, DNS and DHCP on it, we've show how easy it is to mitigate those specific situations. Now if you have other things tied to AD, that's when you have a possible point where a second DC makes sense.
-
@jaredbusch 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:
@jaredbusch 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:
Maybe common ML IT pro implementations, but not generally.
I've been doing it since Server 2003 days.
This was the entire point of the Windows SBS model from 2003 through 2011.
So I think you have blinders on to claim it is only Scott or only ML.
Either I'm not communicating well, or I'm misunderstanding what y'all are getting at. Can you clarify what you mean?
I’ve been implementing single AD DC stacks for years in the methods described here.
I have been using various techniques for handling failure of the services on them for all of that time. The router based strategy I posted above for DNS is something I first used in 2007. It included disabled, but configured, DHCP also.
Is that more clear? Or am I misunderstanding you completely?
It seems like my point is being missed by specifying in response to my generalities. I entered the discussion to address a generality made by @scottalanmiller, because frequently the things he states as definites become rules of thumb for the less experienced. They are frequently nuanced in later posts, but sometimes only after being challenged.
Anyhow, I am open to having my assumptions and math challenged in the generalities, but the responses have all been specific. My point was that making a rule of thumb out of the single AD DC design is dangerous because of how quickly the costs of downtime and configuration can make it cost effective. Not that single AD DC is not a good solution, or that it can be done well, just challenging the "most commonly correct approach" statement with a framework of assumptions so that we could establish common ground on where we were each drawing our conclusions.
-
@dashrender 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:
@dashrender 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:
@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.)
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?
I'm not sure you ever addressed my contentions to your opening statement. There was a lot of discussion that went back and forth, but I was responding to your initial statement that a single AD DC is "most commonly correct approach" based on cost and lack of value. My long post was showing that the cost of it disappears very quickly in an outage in the typical SMB. If things are properly configured and laid out those costs can be mitigated, but also at a cost. I don't buy the "most commonly correct approach" statement based on common implementations. Maybe common ML IT pro implementations, but not generally. Not so I would want to recommend it as a best practice which the language of your statement appears to assert.
Sure - but you can't include bad "common" implementations in a conversation like this.
Not sure what you're getting at. Scott is stating that a single AD DC is the "most commonly correct approach" based on costs vs risks. My postulation is that this not necessarily correct in the majority of implementations. Even a perfect implementation that mitigates entirely the risks of not having a failover DC carries costs that can remove any benefits gained.
What expenses are you going to have, in a SMB, that are generally going to outweigh the costs of that DC?
If we limit ourselves only to a DC with AD, DNS and DHCP on it, we've show how easy it is to mitigate those specific situations. Now if you have other things tied to AD, that's when you have a possible point where a second DC makes sense.
And that is my point. Not that single DC AD is wrong, but that making it into a rule of thumb is insufficient. I was attempting to point out, using my assumptions laid out as clearly as I could, that when you factor in all of the costs of each scenario a second DC can be a cost effective strategy. My goal was to point out that @scottalanmiller's basic statement of "most commonly correct approach" is lacking all the nuance that he thinks about in his head, but would not be in the basic analysis of a significant portion of IT pros.
-
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
@jaredbusch 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:
@jaredbusch 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:
Maybe common ML IT pro implementations, but not generally.
I've been doing it since Server 2003 days.
This was the entire point of the Windows SBS model from 2003 through 2011.
So I think you have blinders on to claim it is only Scott or only ML.
Either I'm not communicating well, or I'm misunderstanding what y'all are getting at. Can you clarify what you mean?
I’ve been implementing single AD DC stacks for years in the methods described here.
I have been using various techniques for handling failure of the services on them for all of that time. The router based strategy I posted above for DNS is something I first used in 2007. It included disabled, but configured, DHCP also.
Is that more clear? Or am I misunderstanding you completely?
It seems like my point is being missed by specifying in response to my generalities. I entered the discussion to address a generality made by @scottalanmiller, because frequently the things he states as definites become rules of thumb for the less experienced. They are frequently nuanced in later posts, but sometimes only after being challenged.
Now I follow, and generally agree. I argue with him consistently on certain issues.
But I do believe it is the most common approach, because Enterprise is certainly not the most common, SMB is.
I neglected the full statement you quoted.
