Handling DNS in a Single Active Directory Domain Controller Environment
-
@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.
-
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
just challenging the "most commonly correct approach" statement
It seems you are mistaking the "most common approach" with the "most common correct approach". I haven't been around the SMB as much as JB, but I'm assuming the most common approach to SMB DC implementations are incorrect. Meaning, 2+ DCs are being used when 1 should be used. Perhaps two DCs are used because so many other things are done incorrectly, it's thought 1 should't be used due to so many other things not properly in place, but that's besides the point in my reply 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:
just challenging the "most commonly correct approach" statement
It seems you are mistaking the "most common approach" with the "most common correct approach". I haven't been around the SMB as much as JB, but I'm assuming the most common approach to SMB DC implementations are incorrect. Meaning, 2+ DCs are being used when 1 should be used. Perhaps two DCs are used because so many other things are done incorrectly, it's thought 1 should't be used due to so many other things not properly in place, but that's besides the point in my reply here.
IMHO, SMB's use 2 DC's (me included) because it is drilled over and over in our heads by outside forces, including the application developers and the OS companies themselves. On top of that, we are completely stupid if we don't have a second DC if the hardware is available. So to follow "Best Practices," SMB's just do it. It doesn't necessarily mean that things are done incorrectly though. It mostly means, we (aka I) have an extra DC there sitting, waiting, getting monthly updates and then gather more dust for years on end all in the name of protection and risk reduction.
That is why coming here and having extensive discussions about general topics has helped me changed my own thoughts about system/network design in SMB's.
-
@pmoncho 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:
just challenging the "most commonly correct approach" statement
It seems you are mistaking the "most common approach" with the "most common correct approach". I haven't been around the SMB as much as JB, but I'm assuming the most common approach to SMB DC implementations are incorrect. Meaning, 2+ DCs are being used when 1 should be used. Perhaps two DCs are used because so many other things are done incorrectly, it's thought 1 should't be used due to so many other things not properly in place, but that's besides the point in my reply here.
IMHO, SMB's use 2 DC's (me included) because it is drilled over and over in our heads by outside forces, including the application developers and the OS companies themselves. On top of that, we are completely stupid if we don't have a second DC if the hardware is available. So to follow "Best Practices," SMB's just do it. It doesn't necessarily mean that things are done incorrectly though. It mostly means, we (aka I) have an extra DC there sitting, waiting, getting monthly updates and then gather more dust for years on end all in the name of protection and risk reduction.
That is why coming here and having extensive discussions about general topics has helped me changed my own thoughts about system/network design in SMB's.
Then I assume you have an extra everything if it costs less than $5k, correct? Especially if other things depend on it... such as redundant ISP, all redundant switches, definitely redundant LoB services, etc... if not, why choose only a DC over things that would be way more beneficial to have HA? If you have extra hardware, extra software, etc... that would go unused and be wasted otherwise, then sure, it could make more sense, but could still cause the same amount of benefits and negatives.
If the FSMO role holder goes down, it will take way longer ceasing those roles to DC2 and fixing all these troubles, than it would to simply restore a DC VM from backup. I understand IT may not be there, and some shops only have one IT employee, if any, but there are ways to become non-dependent on AD/DNS/DHCP etc so that an SMB can run for a while during the absence of someone coming to fix it.
-
I do also understand that all SMBs are not equal, some may be running software that absolutely requires 99.999 uptime of AD... I get it. Then on the other side I coudl question why something like that was chosen in the first place. There are great alternatives to Windows for SMBs.
-
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
@pmoncho 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:
just challenging the "most commonly correct approach" statement
It seems you are mistaking the "most common approach" with the "most common correct approach". I haven't been around the SMB as much as JB, but I'm assuming the most common approach to SMB DC implementations are incorrect. Meaning, 2+ DCs are being used when 1 should be used. Perhaps two DCs are used because so many other things are done incorrectly, it's thought 1 should't be used due to so many other things not properly in place, but that's besides the point in my reply here.
IMHO, SMB's use 2 DC's (me included) because it is drilled over and over in our heads by outside forces, including the application developers and the OS companies themselves. On top of that, we are completely stupid if we don't have a second DC if the hardware is available. So to follow "Best Practices," SMB's just do it. It doesn't necessarily mean that things are done incorrectly though. It mostly means, we (aka I) have an extra DC there sitting, waiting, getting monthly updates and then gather more dust for years on end all in the name of protection and risk reduction.
That is why coming here and having extensive discussions about general topics has helped me changed my own thoughts about system/network design in SMB's.
Then I assume you have an extra everything if it costs less than $5k, correct? Especially if other things depend on it... such as redundant ISP, all redundant switches, definitely redundant LoB services, etc... if not, why choose only a DC over things that would be way more beneficial to have HA? If you have extra hardware, extra software, etc... that would go unused and be wasted otherwise, then sure, it could make more sense, but could still cause the same amount of benefits and negatives.
If the FSMO role holder goes down, it will take way longer ceasing those roles to DC2 and fixing all these troubles, than it would to simply restore a DC VM from backup. I understand IT may not be there, and some shops only have one IT employee, if any, but there are ways to become non-dependent on AD/DNS/DHCP etc so that an SMB can run for a while during the absence of someone coming to fix it.
If the cost of the outage and the simplicity of bringing it back up again is worth the redundancy. Seizing roles takes almost no time. Certainly less than restoring a VM.
If cost were not in the equation an organization would be foolish not to have a second DC. If the cost of the outage compared to the cost of the second DC approach zero then it would be foolish not to have one. That is my point. Yes, vendors have pushed more software on companies that don't need it, but I was contesting that a single DC scenario is the most commonly correct deployment, and using math rather than anecdotal or speculation to look at the two costs.
-
@kelly 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:
@pmoncho 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:
just challenging the "most commonly correct approach" statement
It seems you are mistaking the "most common approach" with the "most common correct approach". I haven't been around the SMB as much as JB, but I'm assuming the most common approach to SMB DC implementations are incorrect. Meaning, 2+ DCs are being used when 1 should be used. Perhaps two DCs are used because so many other things are done incorrectly, it's thought 1 should't be used due to so many other things not properly in place, but that's besides the point in my reply here.
IMHO, SMB's use 2 DC's (me included) because it is drilled over and over in our heads by outside forces, including the application developers and the OS companies themselves. On top of that, we are completely stupid if we don't have a second DC if the hardware is available. So to follow "Best Practices," SMB's just do it. It doesn't necessarily mean that things are done incorrectly though. It mostly means, we (aka I) have an extra DC there sitting, waiting, getting monthly updates and then gather more dust for years on end all in the name of protection and risk reduction.
That is why coming here and having extensive discussions about general topics has helped me changed my own thoughts about system/network design in SMB's.
Then I assume you have an extra everything if it costs less than $5k, correct? Especially if other things depend on it... such as redundant ISP, all redundant switches, definitely redundant LoB services, etc... if not, why choose only a DC over things that would be way more beneficial to have HA? If you have extra hardware, extra software, etc... that would go unused and be wasted otherwise, then sure, it could make more sense, but could still cause the same amount of benefits and negatives.
If the FSMO role holder goes down, it will take way longer ceasing those roles to DC2 and fixing all these troubles, than it would to simply restore a DC VM from backup. I understand IT may not be there, and some shops only have one IT employee, if any, but there are ways to become non-dependent on AD/DNS/DHCP etc so that an SMB can run for a while during the absence of someone coming to fix it.
If the cost of the outage and the simplicity of bringing it back up again is worth the redundancy. Seizing roles takes almost no time. Certainly less than restoring a VM.
If cost were not in the equation an organization would be foolish not to have a second DC. If the cost of the outage compared to the cost of the second DC approach zero then it would be foolish not to have one. That is my point. Yes, vendors have pushed more software on companies that don't need it, but I was contesting that a single DC scenario is the most commonly correct deployment, and using math rather than anecdotal or speculation to look at the two costs.
It still depends.
Our LoB software uses AAD. So if all of our DCs go down, that will still work just fine. DHCP will not matter for a long time. DNS is covered. Printing doesn't require AD authentication. Etc etc etc... We only have multiple DCs because we have multiple geographic locations with unreliable WAN connections, a few are wireless only, and building to building outages are fairly frequent. We have several hundred users and like 1k devices. AD being down (it has in the past) doesn't hurt us.
I could hurt a 10-man shop, or it couldn't. But generally, setting things up correctly from the start, means a single DC implementation for an SMB is best practice, unless there are other factors requiring you to have two.
