Having DNS issues since switching from Forwarder to Resolver - Will Squid3 help?
-
I have a situation that I'm not exactly sure how best to resolve. Should I use Squid3, Apache with mod_security-dev or other? Are subdomains best practice?
Client's bought domain packages including .com, .us and .net. I set them up using the .net domains internally for Active Directory and remote access. They recently asked me for a new LAMP server and unknown to me they had plans to build and host a website for their .net domain. During that process, (because they own the domains) they changed the nameservers and pointed them to their hosting provider (GoDaddy). The second they did that it somewhat blew up my internal DNS that I was using for pfSense, etc.
I'm not even sure if it's possible to use a reverse proxy or to have an internal/LAN AD server on a FQDN with an externally hosted website. Is there a package that will help with this or should I use subdomains?
The only other choice I can think of would be to go out and use subdomains off of either mydomain.com/.net or theirdomain.net.
What is the best way to handle a situation like this? They also want development web servers but I can do .local's for those.
I feel like when I was using DNS Forwarder it was straight forward and absolute whereas I don't exactly understand the differences between Forwarder and Resolver and what Resolver does. Would a reverse proxy such as Squid3 work better?
Open to suggestions. Thank you.
-
Best practice, I believe, is to use a subdomain of the FQDN for their AD domain. So, if they own customer.com then you would use something like lan.customer.com or corp.customer.com. I must admit that I've read your post a few times now and I'm not sure what the actual problem is.
-
Users of a AD should not be using pfsense for dns or dhcp - that should come from AD.
So why it blew up pfsense I have no idea what you were doing..
As to using domain.tld as AD and as public - BAD BAD BAD idea.. While using domain.com as public and domain.net as your AD would be fine.. If your going to host something on the public with domain.net ok.. Then your outside dns points to where its hosted. Internally in AD dns you will need to create a record for the name your using.. lets call it www.domain.net – so on public it resolves to 1.2.3.4 that is hosted on go daddy servers.
Then in your AD create A record under your domain.net for www that points to 1.2.3.4 done.
If your hosting it inside your network.. You would point public to your public IP lets call it 5.6.7.8, you forward that in at pfsense to the server hosting it lets call it 192.168.1.8.. In your AD dns you make sure you point to 192.168.1.8 vs the public IP.
Trying to use pfsense for Active Directory dns or even for dhcp is not good idea. In AD setup all members of AD point to AD for their dns.. This is the ONLY dns they should point to.. IF you want to then have AD forward to pfsense ok that works.. but might as well remove the hop and forward them to your isp dns or public dns like google or open. And or have them directly resolve from roots. But members of domain should ONLY point to AD for dns!!!
-
Thank you for the help. So if I use AD for DNS for the members of that AD server, what do I do for members of other AD servers on different domains but behind the same pfSense machine.
-
You have multiple Active directories on the same network? Running on the same address space? Do they trust each other, are they members of the same forest? They would use their own AD dns if they are different ADs
Why would you have 2 different ADs on the same network??
-
Regarding the original question, have yet to hear about Squid helping anywhere (as opposed to being a royal PITA breaking things and slowing everything down). For the rest, it exactly does not matter how many AD domains you have behind pfSense. They all should still use AD DNS servers only for clients.
-
I should be using AD for DHCP as well as DNS? Meaning the AD server should be issuing the DHCP addresses vs. pfSense?
I have (me personally) a public .com domain and I also own the associated .net. I have been using mydomain.net as the primary AD server behind pfSense. From there I initially set the network up as follows:
mydomain.net
client1.mydomain.net
client2.mydomain.net
client3.mydomain.net
client4.mydomain.net
client5.mydomain.netEach sub-domain using its own AD server for each client and on different VLANs & subnets, while still being a member of the same forest. That was fine while they were pre-revenue startup companies but now that a few of them have gotten investment funding they have started to complain that their internet connection (Windows) shows mydomain.net, not clientdomain.net.
So I started changing things over from client1.mydomain.net to client1.net. At the same time, they registered client1.net with a hosting provider and started building a public website for it.
I would much rather go back to the way I listed above (client#.mydomain.net) because it worked and I think its best practice. I'm still not exactly clear on how to setup the DHCP server on pfSense for each interface and wondering if I can just change the domain name entry on the DHCP tab to fix all of this.
-
Meaning the AD server should be issuing the DHCP addresses vs. pfSense?
Yes. If AD, don't use pfSense for DNS or DHCP.
I'm still not exactly clear on how to setup the DHCP server on pfSense for each interface
Well, don't do that. But if you were to, it's not hard. For each interface, you need to specify the IP address range for the DHCP pool for that interface, and other network details like DNS, domain suffix, search order, etc.
-
So all of these clients are on their own AD.. and on their own segment and vlan so why would you need or want pfsense to run dhcp? DHCP is helpful AD in maintaining its dns entries for its clients for clients that can or do not register themselves.
If you have AD, there is no point in leveraging pfsense for dns or dhcp - your just making your setup more complicated when AD by design wants to own and leverage dhcp and dns. The dns and dhcp services in pfsense for sites that don't have AD or other dns and dhcp.. But if you have AD running then clients need to point to it for dns and dhcp.
You should really be telling your clients that it a bad idea to use the same domain on the public as you don for your AD domain. Your idea of using .com for public and .net for your AD works and used quite often. As to what they want to call their AD be it clientx.domain.tld vs clientx.tld ok but if they are using clientx.tld on the public then for their AD they should really use clientx.someothertld
-
Thank you for the replies. I am truly grateful. I have not had any issues for years and the last few weeks have been embarrassing as it seems I have gotten caught with my pants down (not knowing or understanding best practices).
@KOM:
Yes. If AD, don't use pfSense for DNS or DHCP.
I'm running a bunch of VLANs. Each on its own subnet, each for a different client. VLANS/subnets are isolated with rules and each has its own AD server that is client.mydomain.net.
Are you saying that I should turn off the pfSense DHCP server for those subnets and use only the AD server for DHCP and DNS?
@KOM:
I'm still not exactly clear on how to setup the DHCP server on pfSense for each interface
Well, don't do that. But if you were to, it's not hard. For each interface, you need to specify the IP address range for the DHCP pool for that interface, and other network details like DNS, domain suffix, search order, etc.
I can and currently do have pfSense running as the main/primary DHCP server for each interface and subnet. I've not messed around with Windows DHCP & DNS but I assume its fairly straight forward. Should I be completely turning off DHCP on pfSense within those subnets such that I assign a static IP to the AD server within the subnet of the interface its attached to and then the AD server will push IPs out via DHCP to all of the members of its domain? Or is it even more complicated than that whereby the main AD server (mydomain.net) acts as DHCP server and assigns IPs out to all of the client.mydomain.net as well as any machines attached to the client.mydomain.net domain?
So all of these clients are on their own AD.. and on their own segment and vlan so why would you need or want pfsense to run dhcp? DHCP is helpful AD in maintaining its dns entries for its clients for clients that can or do not register themselves.
Yes, each client is on its own VLAN (in some cases 2-3 VLANs) which each have their own subnets which are separated out and isolated from each other with rules. Typically each client has only one VLAN with one subnet and its own dedicated AD server named client.mydomain.net. The client.mydomain.net AD server is a member of mydomain.net and currently, pfSense is doing ALL of the DHCP and DNS work.
Its not that I needed pfSense to run DHCP, I thought it would make things less complicated and simpler by having one central DHCP server that manages all subnets vs. having to log into each AD server to manage the clients attached to its domain.
If you have AD, there is no point in leveraging pfsense for dns or dhcp - your just making your setup more complicated when AD by design wants to own and leverage dhcp and dns. The dns and dhcp services in pfsense for sites that don't have AD or other dns and dhcp.. But if you have AD running then clients need to point to it for dns and dhcp.
Thank you. Will start making those changes ASAP. This is going to be fun… considering there are quite a few Mac, Linux and BSD machines in each domain.
You should really be telling your clients that it a bad idea to use the same domain on the public as you don for your AD domain. Your idea of using .com for public and .net for your AD works and used quite often. As to what they want to call their AD be it clientx.domain.tld vs clientx.tld ok but if they are using clientx.tld on the public then for their AD they should really use clientx.someothertld
Thank you again. That was what my gut was telling me but I just wanted to make sure. I'm self-taught so while it feels good to know that what my gut told me was correct, I still question everything because I have no formal training to fall back on.
-
Formal training – where would you get that? ;)
You pick up stuff after 30 years doing this.. What works, what doesn't work - Read, Read, Read... Understand how the protocols actually work.. You'll get there someday yourself.
-
Wow, lots of info here, but no completely definitive answers.
Here you go…
You can have pfSense as your DNS/DHCP in an AD environment no problem as long as you follow a couple of rules:
- pfSense DHCP needs to do its own name registration in the pfSense DNS service, e.g. BIND (configured for that domain and not exposed to the outside world)
- pfSense DHCP needs to hand out the AD DNS server(s) in the DHCP response, not itself (very important, otherwise AD will bork in many nasty ways)
- AD DNS server(s) should have the pfSense as their primary forwarder(s) (not actually necessary but it simplifies things)
Now, on to using the TLD internally. Yes, it was a dumb idea, never do that, for a number of reasons, but it's there now and changing would be a giant pain and it's actually not hard to make it work.
For the most part everything will actually "just work". The only catch is that you'll need to add manual entries in either the pfSense DNS Forwarder service or in AD, (your preference, but if you use pfSense entries then make sure AD has pfSense as primary forwarder).
(ETA - and don't use .local for anything either!)
