DNS Settings For Active Directory at a remote site

McMurphy

Hi,

I have a client with a main site and a remote site connected by OpenVPN

The main site has the Windows active directory server and I am unsure of how best to configure the DNS at the remote site?

Presently I have pfSense operating as a DHCP server at the remote site and this works well. My initial thought is to specify three dns servers in the remote site's DHCP server settings:

Windows AD DC IP (at the main site)
8.8.8.8
8.8.4.4

I have been told this is incorrect as clients do not search these DNS servers in order but rather select one randomly which would be a problem.

How should I configure the DNS server settings at the remote site so that Windows clients can connect to the main site and connect to AD?

Thanks in advance...

bmeeks

@McMurphy said in DNS Settings For Active Directory at a remote site:

Hi,

I have a client with a main site and a remote site connected by OpenVPN

The main site has the Windows active directory server and I am unsure of how best to configure the DNS at the remote site?

Presently I have pfSense operating as a DHCP server at the remote site and this works well. My initial thought is to specify three dns servers in the remote site's DHCP server settings:

Windows AD DC IP (at the main site)

8.8.8.8

8.8.4.4

I have been told this is incorrect as clients do not search these DNS servers in order but rather select one randomly which would be a problem.

How should I configure the DNS server settings at the remote site so that Windows clients can connect to the main site and connect to AD?

Thanks in advance...

For Windows AD you should NEVER configure any client DNS server other than the domain controller (which is typically also the DNS server for the AD domain)!

You were told correctly that Windows can randomly choose a DNS server from the list when configured with multiple DNS server IP addresses, and it will continue to use that DNS server until it fails to answer at all. And by "fail to answer" I mean the server simply does not reply. If the server replies with NXDOMAN (meaning I can't find that name), then that's not a failure of the server so the Windows client will keep using it but will be unable to resolve any internal required DNS records if that DNS server is say Google's 8.8.8.8 server.

External DNS servers such as Google have no idea what the IP address of critical internal hosts might be nor do they know about required Windows AD service records. In short, using an external DNS for Windows AD clients will lead to all kinds of random failures.

Here is what you should do.

Configure your Windows AD clients to use ONLY the local (or remote, if using a VPN) AD controller for DNS.
Configure your DNS server on the AD controller to either resolve or forward domain lookups for which it is not authoritative.
Never put any DNS server IPs in your Windows AD clients except the Windows AD controller (or where you are running DNS for the Active Directory domain).

bmeeks

@McMurphy:

P.S. - a common misconception among new network admins is that when they put multiple DNS servers in a list the client will try each server in turn when looking for a hostname. Or they believe the client will randomly choose a server from the list for each individual DNS query thus spreading out the load.

Neither of those assumptions is correct. The client will only try another server in the list if the server it tries first fails to respond at all. If the server it tries replies at all, then it will use that server forever (or until it fails to reply). As an analogy, consider the client to be "pinging the server" to see if it is alive. If the server says "yes, I'm here", the client will continue using it. Only if the server fails to reply with "yes, I'm here", will the client try another server from the list.

When the client first boots, it will randomly choose a server from the list provided, and then it will continue to use only that server per the process described in the previous paragraph.

So, you can see if you examine the process above how Active Directory could be totally dysfunctional for a local Windows client if that client randomly chooses from a configured list to use Google's 8.8.8.8 server for all of its DNS lookups. Everything related to the local AD domain would fail to resolve because Google doesn't know anything about your local domain. But Google's server will continue to reply to any query, thus the client will not mark the Google server as "down" because it is returning replies (albeit, they will be NXDOMAIN replies for Active Directory stuff). The client will happily take NXDOMAIN as a valid reply, but the client will not be able to find and talk to any local AD assets (and thus will be functionally broken in terms of Active Directory).

McMurphy

@bmeeks
Thank you for the thorough reply which makes perfect sense.

To ensure I have understood.

If my AD DC at the main site was 192.168.1.10 then at the remote site the pfSense DHCP should only include this single DNS IP?

This means that all DNS queries at the remote site will use the AD DC at the main sit, over the VPN?

bmeeks

@McMurphy said in DNS Settings For Active Directory at a remote site:

@bmeeks
Thank you for the thorough reply which makes perfect sense.

To ensure I have understood.

If my AD DC at the main site was 192.168.1.10 then at the remote site the pfSense DHCP should only include this single DNS IP?

This means that all DNS queries at the remote site will use the AD DC at the main sit, over the VPN?

Yes, that is correct. Luckily, DNS traffic is not very taxing and should not adversely impact overall throughput on the VPN. Now, if you happen to have an AD DC at the remote site, then you could point them there.

I also happen to favor letting the AD DC do DHCP as well, because Windows DHCP server can easily send dynamic DNS updates to the DC DNS server. If you run DHCP on pfSense, that can't happen. It is usually advantageous for the Windows clients in an Active Directory network to have their hostnames registered in DNS. You can do this either by static IP assignment (via DHCP reservations or actual static IP at the client), or you can take advantage of the dynamic DNS updates that a Windows DHCP server can send to a Windows DC DNS server.

To do the above with DHCP at the remote site over VPN (if your DC is located at the main site) you would need to configure a DHCP relay agent on pfSense at the remote site.

To summarize this long response, in an Active Directory environment it is best to let Windows do everything. That includes using Microsoft's DHCP and DNS server features (usually just deployed on the DC in smaller networks).

McMurphy

@bmeeks
Thanks again

So what is the difference/use of the DNS settings under System => General Setup?

Currently there I have:

127.0.0.1
8.8.8.8
8.8.4.4

bmeeks

@McMurphy said in DNS Settings For Active Directory at a remote site:

@bmeeks
Thanks again

So what is the difference/use of the DNS settings under System => General Setup?

Currently there I have:

127.0.0.1

8.8.8.8

8.8.4.4

Those are the DNS servers that pfSense will use for its own DNS queries when NOT using the default resolver mode for unbound. For example, to find the Netgate package update repo server. Here is the official doc: https://docs.netgate.com/pfsense/en/latest/config/general.html#dns-server-settings.

I don't know your familiarity with DNS, but it is very critical for you to completely understand the important distinction between a "resolver" and a "forwarder" when it comes to DNS. They are not the same! If you are not initimately familiar with these terms, spend some time on Google learning what each is. Your questions in this thread lead me to suspect you may not be familiar with those terms and how each impacts how you should configure DNS. A resolver is the preferred mode of operation most of the time in present day setups.

For the vast majority of pfSense setups, you should leave those lines blank on the GENERAL SETTINGS page. Don't type anything in those boxes. That will automatically configure unbound (the DNS Resolver on pfSense) to use its resolver mode. Don't try to "out think" the defaults on pfSense when it comes to the DNS setup. There is a bunch of outright totally incorrect info out there on YouTube and elsewhere about DNS setups on pfSense. A lot of those are actually referring to the very old and now out of date pfSense releases. The current out-of-the-box defaults will work in nearly all situations. When used with an Active Directory setup, you might consider entering a domain overrride in the pfSense DNS Resolver that points it to your Microsoft DNS server for name resolutions within your Active Directory domain. Here are the official docs on domain overrides in pfSense: https://docs.netgate.com/pfsense/en/latest/services/dns/resolver-domain-overrides.html.

McMurphy

@bmeeks
Again, thank you for your excellent response and this helps greatly.
I have:
a) removed the DNS servers from System => General Setup and now the only DNS server listed on the dashboard is 127.0.0.1
b) added a domain override that associates the AD DC with the domain
c) restated pfsense

I am still unable to perform DNS lookups over the VPN.

12.03.2024_16.35.38_REC.png

12.03.2024_16.38.39_REC.png

12.03.2024_16.39.48_REC.png

bmeeks

@McMurphy said in DNS Settings For Active Directory at a remote site:

@bmeeks
Again, thank you for your excellent response and this helps greatly.
I have:
a) removed the DNS servers from System => General Setup and now the only DNS server listed on the dashboard is 127.0.0.1
b) added a domain override that associates the AD DC with the domain
c) restated pfsense

I am still unable to perform DNS lookups over the VPN.

Ah- I forgot to tell you about one important tidbit regarding the unbound config on pfSense.

The resolver has an ACL (access control list) that restricts what IP addresses can query the service. By default, pfSense will include all of the locally-attached interface subnets that unbound is listening on. Since your remote site is not a directly attached local network, you will need to let unbound know about it. Here's how to do that: https://docs.netgate.com/pfsense/en/latest/services/dns/resolver-acls.html. You will need to add the remote site's subnet (and any additional ones that may exist there) to the DNS Resolver ACL in pfSense.

Scratch the above as I forgot you were using your DC for DNS instead of pfSense now. The problem is likely the Windows firewall on your DC. By default, Windows will enable a firewall on the servers that will block inbound traffic from external subnets (meaning any IP subnet that is NOT the same as the subnet where the server is addressed). You will need to enable a Window firewall rule to allow inbound DNS traffic to the DC from the remote site's subnet (both UDP and TCP in the event a larger packet is occasionally needed). So, because your DC is on the 192.168.1.0/24 subnet, but your remote clients are on the 192.168.2.0/24 subnet, the local Windows firewall on the DC will block unsolicited inbound traffic (such as DNS query requests from your remote site) outside the DC's subnet.

I assume the 192.168.1.11 address in your screen shots is the main site DC (and DNS server).

McMurphy

@bmeeks

Thank you very much for all your help and everything is working well now.

One final question if I may. If the DC is unable to resolve a request internally and needs to use an external DNS server is this what is specified under forwarders in the DNS server properties?

bmeeks

@McMurphy said in DNS Settings For Active Directory at a remote site:

One final question if I may. If the DC is unable to resolve a request internally and needs to use an external DNS server is this what is specified under forwarders in the DNS server properties?

It can be. It depends on whether you have the DNS server configured to "resolve" or "forward". Here is the difference.

Forwarding
For any domain name that the local DNS server has no record of (meaning it is not "authoritative" for that domain record), it will send the query along to the configured forwarder's IP address. The "forwarder" server will then either serve the record from its cache if the record is present and the TTL (time-to-live) for the record has not expired, or the "forwarder" can go resolve the record as described below for a resolver and then return the result.

Resolving
There are 13 official DNS root servers for the entire world. Details are described here: https://www.iana.org/domains/root/servers. Those DNS root servers each have the hostname and address for all of the authoritative root servers for each possible top-level domain (TLD) such as ".com, .org, .edu, .gov, etc.). Then each of those TLD root servers will have the authoritative DNS server for the sub-domains in that TLD. For example, google.com, microsoft.com, etc.

So, a client wanting the address of say analytics.google.com will send a query to its local DNS server. Assume that server is your DC DNS and that DNS is configured to resolve. The DC DNS server will realize that analytics.google.com is not a domain it is authoritative for, so it needs to go look it up elsewhere. That's really what resolving is. That lookup works like this:

Ask one of the 13 DNS root servers who is authoritative for .com domains. The root server will respond with the IP address of the TLD root server family that knows about all the .com domains.
Your DC DNS server then sends a query to the authoritative TLD server for .com domains asking for the IP address of the authoritative server for google.com. The .com DNS root server responds with 8.8.8.8 because that is the server IP Google has registered with IANA as being "authoritative" for their specific domain.
Finally, your DC DNS sends a query to 8.8.8.8 asking for the IP address for analytics.google.com. Google's 8.8.8.8 server would respond with 216.239.34.181 (one of several possible IPs for analytics.google.com) and the query is complete.
The returned IP record from Google's server will contain a TTL (time-to-live) value. Your DC DNS knows that it can cache that response for at least the TTL value and won't have to go resolve again should another client ask for the same domain name within the TTL.

To summarize the resolving steps, your DC DNS server would execute up to three distinct DNS queries in order to find the IP address for analytics.google.com. In plain language, here are the steps:

Ask one of the DNS root servers who should I ask about .com stuff? The root server says to go ask the TLD server at IP x.x.x.x for anything about .com. So, your server sends a query to the TLD server at IP x.x.x.x asking who should I ask for google.com stuff? The TLD responds with "oh, that would be the server at 8.8.8.8 because it is authoritative for google.com stuff". Finally, your DC DNS server sends the query to 8.8.8.8 asking what is the IP address for analytics.google.com? And Google's 8.8.8.8 server replies with "that is IP address 216.239.34.181".

McMurphy

@bmeeks
Fantastic, thank you!

McMurphy

@bmeeks

As I am no longer specifying DNS servers in pfSense and using the resolver however can I see what DNS servers pfSense is using?

bmeeks

@McMurphy said in DNS Settings For Active Directory at a remote site:

As I am no longer specifying DNS servers in pfSense and using the resolver however can I see what DNS servers pfSense is using?

@McMurphy, you don't seem to understand how resolving works. There is no specifically set or configured server pfSense will use other than itself (technically, the unbound service which is called DNS Resolver in the menus). When you leave all the DNS settings in the GENERAL SETTINGS tab blank, that automatically tells pfSense to use its internal resolver process, unbound.

Go back and read my post above that describes both Forwarding and Resolving. Read the Resolving section very carefully and be sure you understand what's happening there. Don't try to skim it, and don't assume you know how it works already .

Once you fully understand what Resolving is, you will see that your question is moot. Out of the box pfSense will operate in the resolve mode using the built-in unbound DNS resolver service.

McMurphy

@bmeeks

ok ok ok... I did skim a it :)

I understand that the resolver uses a predefined list of root DNS servers:
https://docs.netgate.com/pfsense/en/latest/services/dns/resolver-modes.html

I think I am getting my wires crossed here so please correct me if I am wrong:

pfSense will disregard the ISP DNS servers unless checked in System => General Setup
pfSense itself will us the resolver function for internal purposes, such as checking for updates.
clients will only use the pfSense resolver if they are set to use the pfSense IP for DNS (DHCP or manual)
AD server is it's own DNS server
AD server has it's own DNS forwarders so it will totally disregard pfSense's resolver

How does that sound?

bmeeks

@McMurphy said in DNS Settings For Active Directory at a remote site:

@bmeeks

ok ok ok... I did skim a it :)

I understand that the resolver uses a predefined list of root DNS servers:
https://docs.netgate.com/pfsense/en/latest/services/dns/resolver-modes.html

I think I am getting my wires crossed here so please correct me if I am wrong:

pfSense will disregard the ISP DNS servers unless checked in System => General Setup

pfSense itself will us the resolver function for internal purposes, such as checking for updates.

clients will only use the pfSense resolver if they are set to use the pfSense IP for DNS (DHCP or manual)

AD server is it's own DNS server

AD server has it's own DNS forwarders so it will totally disregard pfSense's resolver

How does that sound?

All of the above is correct. The only small clarification is that the DNS server on a Windows AD DC can be configured to forward or to resolve. You can tick a box in the DNS server properties to change that behavior. In recent Windows Server versions the root hints servers are automatically populated, so the DNS server would resolve unless you explicitly provided a forwarder IP address. By default, your AD DNS server will not have a forwarder configured, so it would resolve. Only if you manually add the IP address for a forwarding server would it use one.

And to muddy the waters a bit more, you could configure the Windows AD DNS server to forward to pfSense any domains it is not authoritative for. And then use the default pfSense DNS Resolver configuration which would resolve the query and send it back to the Windows AD DNS server. Why would someone do it this way? For say ad blocking using the DNSBL features of pfBlockerNG. The AD DNS server would do all the local Active Directory lookups, but anything external to the local AD domain would be forwarded to the DNS Resolver in pfSense. And if you were to configure the DNSBL option in pfBlockerNG, then the DNS Resolver would not go "resolve" domain names for ads and thus block them.

And just to close the loop in this long discussion -- ultimately the only way to look up an IP address for a hostname is to "resolve" using the resolver process I described earlier. Even a forwarder will actually go resolve the request, then send it back to the client that sent it originally to the "forwarder". While inefficient, a forwarder server could in turn forward to some other server and so on, but at some point in the chain a DNS server would have to actually resolve the request starting by querying the root servers to get the server for the TLD, then working down to the final authoritative DNS server for the domain being looked up.

In the old and early days of the Internet, there was no collection of DNS resolver applications you could install on clients. So, the only option was to point the DNS client on your Windows or Mac machine to a DNS forwarder typically provided by your ISP. The ISP wanted you to use their forwarder, so that's the DNS server IP they gave you. They wanted this originally to minimize DNS traffic on their external links. Their internal server could go do the resolving for something once, then cache the returned IP locally and then quickly serve it to the ISP's customers until the TTL on the record expired. But over time lots of DNS resolver apps have become available, and the need to rely on the ISP's DNS servers has waned.

McMurphy

@bmeeks

Does this mean the settings below only apply to DNS Forwarder mode and are totally ignored by DNS Resolver mode?

System => General Setup => DNS Server Settings

https://docs.netgate.com/pfsense/en/latest/services/dns/resolver-modes.html

McMurphy

@bmeeks

p.s. And just when I thought understood what a resolver was I found this...
14.03.2024_21.03.02_REC.png

bmeeks

@McMurphy:

There are DNS clients and DNS servers. Let's examine the difference between them.

DNS clients are small applications that have existed as mostly an embedded part of an operating system. For example, Windows, Linux, and MacOS all ship with a DNS client. The only thing a DNS client does is ask a DNS server to tell it what IP address it should go connect to in order to access a given hostname. DNS clients only talk to a DNS server. So, when a Windows client workstation or server wants to connect to www.microsoft.com, it will use its DNS client app to query a configured DNS server to find the IP address for that domain or hostname. A DNS client can only ask a DNS server for that info. The DNS client itself cannot resolve. You could sort of say it "forwards", but not exactly using the same process as a DNS server would use for forwarding.

A DNS server is an application that can either resolve the query on its own by starting with those 13 DNS root servers and working its way up the chain until it finds the server that is authoritative for the domain being queried. There it obtains the IP for the queried hostname and then returns it to the DNS client that asked for it. A DNS server can also be configured to simply forward requests to another DNS server and let that other DNS server do the footwork of resolving.

pfSense is a full FreeBSD operating system install. It has a built-in DNS client just like every other operating system has had forever (at least since networking was a standard component of operating systems). The settings on the GENERAL SETTINGS tab for DNS servers are telling the DNS client in pfSense what it should do. It has two choices, it can ask the DNS Resolver component that now ships as part of pfSense to find the IP, or if the admin has configured external DNS servers it will go ask them and ignore the local DNS Resolver component. When you put 127.0.0.1 (local host) in the box, that tells the client to use the local resolver component (the unbound daemon). If you put Google's or Cloudfare's DNS server IP addresses in there, the DNS client will use those instead. But the DNS client is only used to find an IP address for pfSense itself. Nothing the DNS client on pfSense does ever gets sent to some other device on the network. There is a drop-down selector in that section that has some other choices about how the DNS client should behave regarding looking up IP addresses for pfSense itself.

The only time the DNS client on pfSense will get used is when pfSense is looking for something just for local use such as how to find the Netgate package/firmware update servers, or how to find the IP for some NTP server's hostname you enter under the NTP Settings tab, or when you click the option under DIAGNOSTICS to view the ARP table, or when you click one of the little icons in the firewall log view to display the hostname for a logged IP address.

Several years back pfSense began including the unbound package as part of the core install. That package is a limited DNS server. It can resolve hostnames using the DNS root servers, it can be configured to simply forward queries to an external DNS server (a forwarder) and let that external server do the work, and it can on a very limited basis store CNAME, A, and AAAA host records and behave similar to a full-blown DNS server. The DNS Resolver part of pfSense is the unbound daemon.

That last screenshot you provided with the Enable Forwarding Mode option is used should you wish to switch the unbound daemon (the DNS Resolver) from its default resolver mode of operation over to forwarding mode. There is really no good reason for doing this, but a few admins seem passionate about switching over to TLS and using that protocol along with this option to send all their queries to Cloudfare or someone similar for resolution instead of letting the pfSense DNS Resolver do the resolving. Several of us old guys on here really do not see the need for that. But it's an option that is available. The default for that checkbox is "not checked", which means the unbound service (the built-in DNS Resolver on pfSense) will behave as a resolver. One use case for that forwarding mode option is if you want to take advantage of a large DNS provider's filtering option. An example would be using Cloudfare's option to filter adult/porn sites.

So, why I would configure my network to have clients ask pfSense's DNS Resolver for IP lookups, but then configure the pfSense DNS Resolver to just turn around and forward that query to an external DNS server? One reason is that the DNS Resolver on pfSense cannot natively filter results. It can't block adult/porn sites from resolving (without use of an aditional third-party package such as pfBlockerNG and its DNSBL option). If I forward to a service like Cloudfare, they do offer such filtering if I send my queries to a particular DNS server (1.1.1.1, for example). In my mind, that's really the only good reason to enable the forwarding mode of the pfSense DNS Resolver. Of course you could just as easily configure your clients to go straight to Cloudfare and take out the pfSense middle man, and that is another valid configuration option. One reason to leave the pfSense middle man in place would be if you needed to make use of domain overrides such that lookups for certain domains go to a specific DNS server for resolution. You can't do that at the DNS client level, so you would have to utilize the pfSense middle man to do that.

Last remark -- prior to the inclusion of the unbound core package, pfSense offered no way to resolve. It could only forward using a package called dnsmasq. That package is still available and can be configured under the DNS Forwarder menu under the SERVICES section of pfSense. It is considered a legacy and deprecated package. If you enable it, you must NOT enable the DNS Resolver under SERVICES. Those two cannot co-exist because they want to listen on the same port. If you enable the DNS Forwarder component under the SERVICES menu, then you must provide it with the IP addresses of the DNS servers it should send the queries to. Do not confuse the DNS Forwarder component in pfSense with the DNS forwarder option available in the DNS Resolver configuration. In the DNS Resolver component, "forwarding" is an optional mode of operation for the resolver.

bmeeks

@McMurphy said in DNS Settings For Active Directory at a remote site:

@bmeeks

Does this mean the settings below only apply to DNS Forwarder mode and are totally ignored by DNS Resolver mode?

System => General Setup => DNS Server Settings

https://docs.netgate.com/pfsense/en/latest/services/dns/resolver-modes.html

Yes, except these do impact how the DNS client component of pfSense operates. See my long post describing clients and servers for DNS.