New Setup - DNS Resolver with Local DNS Server

[bmeeks]

@StormGate said in New Setup - DNS Resolver with Local DNS Server:

@bmeeks Thanks what confuses is me is when to use a Host override or Domain override, on paper they seem to do the same thing, I'm obviously missing the interpretation.

A host override returns the specific IP you want returned when the DNS server is queried for a specific fully qualified hostname. So, for example, if you want your DNS server to return some specific internal IP of your choosing when a client queries for "www.cnn.com" instead of resolving that via the DNS root servers or forwarding to any forwarder you have configured, then that's a host override. Only that specific FQDN (fully qualified domain name, or specific hostname if you prefer) will be treated specially. In the case of a host override for "www.cnn.com", if your client asked for just "cnn.com", then that query would get resolved to the real public IP of "cnn.com" because the host override is only for "www.cnn.com" and thus does not completely match "cnn.com".

A domain override tells the DNS Resolver (or DNS Forwarder, if configured instead) to refer all queries for the specified domain to a specific DNS server. Don't try to resolve it, just immediately forward it to the DNS server listed in the domain override. So, as an example, if I put in a domain override for "myAD.net" (for my local Active Directory domain name) I would list my internal AD DNS server as the target for any queries for a host in the "myAD.net" domain. So, if pfSense wanted to perform a lookup of say the IP of one of your AD servers by fully-qualified domain name, it would ask the DNS Resolver on pfSense. The Resolver would see that the host being queried resides in your AD domain and the domain override tells the Resolver to go ask your AD DNS server for the IP of the host. Without the domain override, the DNS Resolver in pfSense would either try to resolve the hostname on its own via the root servers or it would forward the request to say 8.8.8.8 or 1.1.1.1 if you had those configured as forwarders (or whatever IP you had configured for forwarding). Obviously 8.8.8.8 will have no idea about your local AD domain and it would return NXDOMAIN for the result.

In practice I could create individual host overrides for every single host in my AD domain and put those in pfSense, but that's a lot of work. Much easier in the case of AD to use a domain override. That tells the pfSense DNS Resolver to go ask the target DNS server listed with the domain override when querying any host from that domain name.

[bmeeks]

@StormGate said in New Setup - DNS Resolver with Local DNS Server:

@StormGate Well the network I am on that is how we setup DHCP but when the original 6100 was setup there was no DC , this was added a year ago and I am in another country so without physically being there and no IT staff, it isn't something I wanted to do since it most likely would break my connection in some form trying to make these changes. The main network clients, yes are domain connected clients. All the other networks are independent.

I understand your trepidation of making a DHCP change if you are remote, but I would eventually plan to make the trip to the necessary site or sites and get it done. With Active Directory, everything is much more seamless with DHCP provided by Windows. The Windows DHCP server can seamlessly update AD DNS with hostname IPs. If you use pfSense for DHCP, then the AD DNS server does not get updated and host lookups within AD can fail (or worse, resolve to the wrong "old" IP).

Microsoft is almost like Apple when it comes to Active Directory. You are sort of locked into using all things Windows when doing AD. And to be honest, it works pretty darn well! In an AD shop, let Windows do DCHP and DNS. You can choose to let AD DNS either resolve external hosts on its own, or you can have it forward queries for external hosts to another DNS server (maybe Pi-Hole for ad blocking/filtering, maybe Cloudflare or another filtering DNS, etc.).

[StormGate]

@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.

[SteveITS]

@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.

[bmeeks]

@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.

[SteveITS]

Windows DHCP server has a setting for conflict detection attempts, to help avoid it handing out an IP a device is already using.

[bmeeks]

@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).

[Gertjan]

@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 :
Windows Any 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".

[bmeeks]

@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 :
Windows Any 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.

[StormGate]

@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.