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.
Basically, other than for your router and DHCP server, you never need static.
-
The whole DNS and DHCP thing wouldn't be an issue if a small SMB went LANless like they should.
-
@obsolesce 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:
@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?
Can't do any assuming that things are done incorrectly. Once done incorrectly, no solution will fix it. You only get working results in a correctly configured environment.
-
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
The whole DNS and DHCP thing wouldn't be an issue if a small SMB went LANless like they should.
Boom. Yet another solution, but I hesitate to mention it because people think I'm crazy
-
@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:
@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.
Basically, other than for your router and DHCP server, you never need static.
that's basically how I feel now. Now I've just got to change the 40 or so static that I currently have.
-
@scottalanmiller What do you mean by lanless here?
-
@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.
