Handling DNS in a Single Active Directory Domain Controller Environment
-
@jmoore said in Handling DNS in a Single Active Directory Domain Controller Environment:
@scottalanmiller What do you mean by lanless here?
No LAN based network dependencies.
https://mangolassi.it/topic/15325/lanless-explained
Basically thinking of your resources as being public (whether or not they are) rather than using your LAN for security and management.
-
@phlipelder said in Handling DNS in a Single Active Directory Domain Controller Environment:
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.
Never, ever, do this.
@phlipelder said in Handling DNS in a Single Active Directory Domain Controller Environment:
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.
Always do this. Whether ahead of time or after it is online and you can see the existing lease.
You should always design your network with a range of addresses in the scope of the DHCP server, but blocked from being handed out to anything that gets plugged in to the network.
How you do it varies by system. On Windows, you set the DHCP scope for your entire CIDR (/24, /23, etc), then you "Exclude" ranges of IP addresses from being handed out.
You can still set reservations in those excluded areas as they are part of the scope.
Example network:
CIDR: 10.202.0.0/23 DHCP Scope: 10.202.0.0/23 Excluded Range: 10.202.0.1 - 10.202.0.99How it is used:
Gateway: 10.202.0.1 Switches: 10.202.0.2 - 10.202.0.10 Hypervisors: 10.202.0.11 - 10.202.0.20 Random IT stuff (NAS, etc): 10.202.0.21 - 10.202.0.29 Servers (DC, SQL, Nextcloud, etc): 10.202.0.30 - 10.202.0.49 Random Empty space in case something comes up: 10.202.0.50 - 10.202.0.59 Printers: 10.202.0.60 10.202.0.99 DHCP Lease range: 10.202.0.100 - 10.202.1.254 -
@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.
