New Setup - DNS Resolver with Local DNS Server
-
@StormGate well then set your dhcp for to point to your AD dns.. Set your AD dns to forward to pfsense.. Do you not know how to change the nameserver in a dhcp scope on AD? Do you not know how to set it up to forward?
-
@StormGate Normally I'd set up a domain override for each Windows AD DNS server, so queries for it are forwarded to Windows.
If you really prefer to not do that, then as mentioned have the Windows network use Windows as DNS, and have other networks use pfSense as DNS.
@StormGate said in New Setup - DNS Resolver with Local DNS Server:
and a firewall rule that points DNS to this server's address as well?
Firewall rules block or allow. You might be thinking of https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html which uses NAT rules, and NAT rules can have a source. I don't think that's necessary though, unless blocking third party DNS is also a goal.
-
@johnpoz Thanks, so our DHCP is all handled by Pfsense but good call on the adding forwarding within AD. Yes under the properties on DNS are the Forwarders tab.
-
@StormGate at a loss to why an AD shop wouldn't leverage dhcp and dns of the AD.. It's deeply integrated into AD.
Are the user machines not actually members of the Domain?
-
@johnpoz We find that if IPv6 is enabled, devices get the router as IPv6 DNS server and that breaks AD. So we set the domain override for if/when that gets enabled by us or the ISP.
(We also find a lot of clients we onboard have set ISP/public DNS as "secondary" DNS which also breaks AD since Windows doesn't process in order)
-
@SteveITS said in New Setup - DNS Resolver with Local DNS Server:
ISP/public DNS as "secondary
Have seen this going back forever really.. Have seen some otherwise pretty good techs not really have a clue how dns works..
You can for sure hand over your AD dns in your RA.. So clients via IPv6 point to the right AD dns.
Same goes for IPv6 - techs in the biz for long time, not have a clue about IPv6 either..
-
@johnpoz said in New Setup - DNS Resolver with Local DNS Server:
Have seen this going back forever really.. Have seen some otherwise pretty good techs not really have a clue how dns works..
+1000 to this !!
The below response is directed at the general public who may drop by and read. It's not for @johnpoz because he absolutely already knows how DNS works
.
It seems to me there are two major DNS client myths (or at least major misconceptions) going around. I keep seeing examples of them in post after post here on the forums in the last couple of years.
MYTH 1: A client configured with multiple DNS servers will always try them in the order they are listed.
FALSE! The client may do that, or it more likely will randomly choose one of the servers you have listed. In that event, all the listed DNS servers better be able to resolve the same host to the same IP or you are going to have confusing issues! If one is a local DNS server and is authoritative for your internal IP space and the other is a public DNS server like 1.1.1.1 or 8.8.8.8, that's a disaster waiting to happen.
MYTH 2: A client configured with multiple DNS servers will try each one of them when looking up a host IP. If the first one fails to find the host IP, it will try the next one and so on until it either finds the host IP or runs out of configured DNS servers --
FALSE! The client will only try another configured DNS server if the first one it uses does not respond at all (as in totally fails to return any packet). If the server returns NXDOMAIN for the host (which means non-existent domain or host), then the client takes that as the "final answer" and will not ask another DNS server for a different answer. And back to Myth #1 above, since that server answered the client's query, the client will now continue to exclusively use that DNS server for any future queries.
Best Practice in Active Directory Shops
In Active Directory, DO NOT give your AD clients multiple DNS servers to choose from unless each listed DNS server is an authoritative DNS server for that Active Directory domain. Giving clients the AD DNS server as one DNS server and say Google or Cloudflare as the second DNS server is a recipe for confusion. When that client chooses to use the Google or Cloudflare server (because Windows will randomly do that), nothing in AD can then be resolved because Google and Cloudflare have no idea about your internal AD resources.The proper way to do this is give your AD clients only your AD DNS server to use. Then configure your AD DNS servers to either resolve external queries themselves (they are capable when the roots are loaded) or forward them to another DNS server such as the DNS Resolver on pfSense or a public DNS server. And on the pfSense side (if you use the DNS Resolver or DNS Forwarder), configure a domain override for your Active Directory domain that points back to your AD DNS server(s). That way pfSense can also resolve local AD hosts if necessary.
-
@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.
-
@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.
-
Just wanted to thank everyone so far with their expertise and suggestions, I wasn't expecting to have such quick responses so everyone's help is greatly appreciated.
-
@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.
Host override says, for one host (name), answer with a specific IP.
Domain override says, for *.example.com forward this request to that name server.
-
@SteveITS Thanks.
So what I have added:
- DHCP DNS - Domain DNS Server IP only (only on the AD network client DHCP)
- DNS Resolver - Added Domain Override to domain server
- Domain Server DNS Forward - Will be done once 8200 is on site
- Did not add and DNS explicit firewall rule yet to the active directory network.
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.
-
@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.
-
@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.).
-
@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.
-
@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".