New Setup - DNS Resolver with Local DNS Server
-
@StormGate said in New Setup - DNS Resolver with Local DNS Server:
I see mention of iPv6, we don't use this addressing at all should i be disabling, I know on the 6100 I actually had blocking rules in place iPv6.
That's up to you. IPv6 basically self configures, it's just that if DNS isn't set up to work then AD lookups break. You can leave it enabled on WAN and disable it on LAN, or there's a checkbox to disable it completely. Like IPv4, inbound connections are blocked by default.
-
@StormGate said in New Setup - DNS Resolver with Local DNS Server:
@bmeeks So how exactly would I make such a change, I would turn off DHCP on the Pfsense for the active directory network. Pfsense is new to me to begin with so this type of split DNS/DHCP setup must have a few moving parts.
It would be a little tricky in a production network. You just have to think carefully through the process and then work through it methodically. You don't want two DHCP servers both "active" at the same time on the same network. So, get the new one configured and all ready to go, verify all the information one more time, then shutdown the DHCP server on pfSense and then immediately bring up the DHCP server on Windows.
First, you would configure the DHCP server in Active Directory but not start the service immediately. You should carefully duplicate the DHCP scopes from pfSense into the Windows DHCP server configuration. I would have the Windows DHCP MMC snap-in panel open and then a browser window open to pfSense on the same machine making sure to duplicate the DHCP pool information (starting and ending IP address ranges, scope options, etc.). The only change would be to put in your Windows AD DNS server as the "DNS Server" to be assigned in the configuration of your Windows DHCP server. Remember that AD clients need to only ever use an AD DNS server. Never given them any other choice. The default choices in the "Add Role/Feature" wizard on the Windows server should be fine. DHCP is not computationally intensive and you can run the DHCP service just fine on a domain controller. Unless your network is huge with tons of clients, you can run the AD DNS and AD DHCP services on the domain controller just fine.
Once you are confident you have the Windows DHCP server ready to go, stop the DHCP server on pfSense and then immediately start the DHCP server on Windows. Your clients should never really know anything happened. They will find the new Windows DHCP server and life will be good. The only time things would get confused or go haywire is if the DHCP scopes and/or any reservations were configured differently on the two DHCP servers. That would be bad! That's why you want to take your time and carefully review the settings to be sure everything is matched up except telling DHCP clients which DNS server to use. Remember the AD clients need to have the AD DNS server handed out to them by DHCP.
-
Windows DHCP server has a setting for conflict detection attempts, to help avoid it handing out an IP a device is already using.
-
@SteveITS said in New Setup - DNS Resolver with Local DNS Server:
Windows DHCP server has a setting for conflict detection attempts, to help avoid it handing out an IP a device is already using.
Yep! I was impressed by Windows DHCP. I would still be using it, but I was on Windows 2012 R2 from an old MSDN subscription that has long since expired and didn't want to pay Microsoft the full cost of a new Windows server installation. Could not justify that for a small home network. So as soon as Kea in pfSense Plus obtained the ability to dynamically update DNS, I retired my Active Directory setup and moved to plain vanilla DHCP via Kea on pfSense Plus and use the DNS Resolver.
Back when I did have my AD setup, I used a domain override in the pfSense DNS Resolver that pointed any queries for hosts in my local AD domain to my AD DNS server (which ran on my domain controller virtual machine).
-
@SteveITS said in New Setup - DNS Resolver with Local DNS Server:
Windows DHCP server has a setting for conflict detection attempts, to help avoid it handing out an IP a device is already using.
I'm pretty sure this statement is also valid :
WindowsAny DHCP server has a setting for conflict detection attempts, to help avoid it handing out an IP a device is already using.
For example : Kea & ISC for example ^^edit : I didn't device into the Kea documentation, as it is just to huge and every time I look up a thing, it's suddenly 'hours later', but I wouldn't be surprised that it isn't an option. It's default behavior.
There could be an option to disable this functionality, as disabling it would pretty much break the network. Maybe there are special case exceptions ...After all, before deciding to give a IP (lease) to a requesting device, the DHCP server throws out a arp request that will ask : who uses 192.168.1.10 and wait a bit for the answer, before it hands over 192.168.1.10 to the DHCP requester.
If some device was using already using 192.168.1.10 then "He should speak up now - or stay silent forever". -
@Gertjan said in New Setup - DNS Resolver with Local DNS Server:
@SteveITS said in New Setup - DNS Resolver with Local DNS Server:
Windows DHCP server has a setting for conflict detection attempts, to help avoid it handing out an IP a device is already using.
I'm pretty sure this statement is also valid :
WindowsAny DHCP server has a setting for conflict detection attempts, to help avoid it handing out an IP a device is already using.
For example : Kea & ISC for example ^^I agree, liklely true for most if not all DHCP servers. The one thing I really like about Microsoft's implementation is you can create a DHCP reservation anywhere even smack in the middle of a defined DHCP scope. The server will then not try to hand out that IP to any other client (whose MAC does not match the reservation). Kea does not permit that. If you try to create a reservation "in place", Kea will reject it if the IP falls within a defined DHCP scope.
Granted it's bad practice to stick reservations in the middle of a scope, but sometimes it dang sure was a handy short cut
-- bad practice notwithstanding.
-
@bmeeks I think with not being to be on site and no help on the other end, I am not going to be able to perform this type of configuration, especially for my first time and cross my fingers it just works. That might be something to entertain down the road if I was ever to have a visit, unfortunately I don't think this is something to attempt while not there. Overall the 6100 has been working fine for their basic needs but I would like to implement this in the future.