Resolver with Forwarding enabled Having Difficulty with Some URLs
-
2.3.2_1-RELEASE (amd64)
OpenVPN - Site-To-Site link. Tunnel: 172.16.4.0/30.The overall problem is, with DNS assigned from DHCP, users are unable to resolve (some) web site URLs. If I specify DNS1 as 10.10.10.150 on the Windows PC, all is OK. But I really don't want to ever manually assign IP or DNS values to a general workstation. I want each Windows PC to have a DNS setting of the local pfSense and then pfSense will query itself for DHCP addresses and if not found, then query the AD server. Lastly if the DNS still fails to then query external OpenDNS servers.
Location A: pfSense. Single, virtual Windows 2012 R2 server running only ActiveDirectory and DNS - 10.10.10.150/32. DNS has reverse zones, too, for both sites (10.10.10.150, 192.168.252.0)
Location B: User network. pfSense running DHCP, DNS. 192.168.252.0/24Within pfSense at Location B, am I supposed to use DNS Forwarder or DNS Resolver with forwarding enabled? From what I've read, DNS Resolver (with forwarding) is the preferred method. Ok, so in System >> General Setup I configure DNS server #1 as my AD/DNS server 10.10.10.150. As DNS servers 2 and 3 I add my OpenDNS severs 208.67.222.222 and 208.67.220.220 respectively. I allow 127.0.0.1 by not enabling Disable DNS Forwarder.
Within DNS Resolver at Location B I have check marks enabling the following features:
-
Enabled
-
Network Interfaces: All
-
Outgoing Network Interfaces: All
-
System Domain Local Zone Type: Transparent
-
DNSSEC
-
DNS Query Forwarding
-
DHCP Registration
-
Static DHCP
and I can't resolve the host name of my server at 10.10.10.150. So then I also add "Domain Overrides" such as:
-
domain.local - 10.10.10.150
-
10.10.10.in-addr.arpa - 10.10.10.150
-
252.168.192.in-addr.arpa - 10.10.10.150
Even that fails some web page URL lookups.
If I Diagnostic >> DNS Lookup my server by host name (should return 10.10.10.150) I get Host "server1" could not be resolved. So then I try server host name+domain (server1.domain.local) and I get the same result. If I do the same lookup via IP address, it correctly resolves back to server1.domain.local
What am I missing?
EDIT: I reviewed the system log and I'm seeing this:
Time Process PID Message
Nov 14 14:58:55 dhcpleases Could not deliver signal HUP to process because its pidfile (/var/run/unbound.pid) does not exist, No such process.
Nov 14 14:58:57 php-fpm 66221 /services_unbound.php: The command '/usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid re1 re2 re3' returned exit code '1', the output was 'Internet Systems Consortium DHCP Server 4.3.3-P1 Copyright 2004-2016 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Config file: /etc/dhcpd.conf Database file: /var/db/dhcpd.leases PID file: /var/run/dhcpd.pid Wrote 0 deleted host decls to leases file. Wrote 0 new dynamic host decls to leases file. Wrote 3 leases to leases file. Listening on BPF/re3/00:30:18:c8:0d:27/192.168.254.0/24 Sending on BPF/re3/00:30:18:c8:0d:27/192.168.254.0/24 Listening on BPF/re2/00:30:18:c8:0d:26/192.168.253.0/24 Sending on BPF/re2/00:30:18:c8:0d:26/192.168.253.0/24 Listening on BPF/re1/00:30:18:cc:99:97/192.168.252.0/24 Sending on BPF/re1/00:30:18:cc:99:97/192.168.252.0/24 Can't bind to dhcp address: Address already in use Please make
Nov 14 14:58:57 dhcpleases Could not deliver signal HUP to process because its pidfile (/var/run/unbound.pid) does not exist, No such process. -
-
Is there a way to see which of the DNS servers are responding back with the IP of <whatever -="" whether="" it's="" a="" local="" ip="" or="" web="" server="">?
I'm using 127.0.0.1, 10.10.10.150, 208.67.222.222, 208.67.220.220 I'm curious to see which defined DNS server is returning the result.
?
Thanks</whatever>
-
"From what I've read, DNS Resolver (with forwarding) is the preferred method. "
Read where? The preferred and default setup is unbound in resolver mode - just like it is when you turn of pfsense.
"DNS setting of the local pfSense and then pfSense will query itself for DHCP addresses and if not found, then query the AD server."
This is just BORKED!!! All your members of your AD should only point to your AD.. Nothing else!! If you set it up this way all your problems with will go away. You can then have your AD forward to pfsense, or it could look up from roots directly or forward to some other public dns if you want.
If you forward to pfsense. You could then have pfsense resolve.. Or it too could just forward - but that would be just asking a hop for no reason.
So you have a vpn between 2 sites.. Does this other site have their own AD or DC that are members of the same AD? If you have multiple locations in AD, the dns in your AD will share information and any member in any site would be able to resolve AD just fine.. If they are pointing as they should to ONLY AD DNS…
If you are a microsoft AD shop.. This should also be your dhcp server.. There is zero reason to have pfsense do that for you..
Out of the box unbound would have rebinding protection on.. So for example if you forwarded to your AD to look up something that would return a rfc1918 address. Unbound would not hand that back to the client. Because that would be normally a rebinding sort of attack. If you have your little heart set on doing it the borked up way then you would have to turn off rebinding protection, or atleast turn it off for your AD domains.
But let me state this again - if you have AD, and you have members of this AD, they should only point to your AD for dns!! And your AD should also be your dhcp.. If you want your AD to forward to Pfsense to lookup public stuff for you sure ok.. But its kind of pointless, might as well just let your AD dns do that as well.
-
Thx for the reply.
At "location A" all they have is a single AD domain server and a pfSense.
At "location B" they have all of their other normal network stuff (a pfsense, a few Windows computers - joined to the AD domain at location A, wireless access point, NAS, printer)I originally wanted "location B" pfSense to handle DHCP/DNS since DHCP forwarding is broken. (?) If it's not then that would cure a lot of issues. I'd prefer to have the AD server do it all but if it can't get DHCP requests then… ? No member servers at location B. Is it bad practice to run a DHCP server remotely from the devices what need it?
thx again.
-
" Is it bad practice to run a DHCP server remotely from the devices what need it?"
No.. where would you get that idea?
Again you have AD, why would pfsense at either location be handling anything?? Let your AD do dhcp and dns..
-
thanks again for your reply.
I really do want the AD server to do it all. I'm not trying to make it more difficult. :)
I enabled the DHCP Relay on Location B pfSense. If it wasn't for my fat finger mistake in setting the router IP for the scope it would have gone un-noticed. So at this time the AD server is doing DHCP, DNS.
" Is it bad practice to run a DHCP server remotely from the devices what need it?"
No.. where would you get that idea?
if the link should drop and all of you networking services are no longer available to the devices on the LAN then everything at that remote site/branch office/etc will be offline. If the local pfSense can do DHCP/DNS then at least that site can get to the Internet (assuming that the site uses some sort of hosted app/website as a primary line of business) and carry on some (if not most) functions and use cached creds until the AD sever link is re-established. That was my thinking and how I was taught.
-
The preferred and default setup is unbound in resolver mode - just like it is when you turn of pfsense.
Why is that?
-
Why is what, why is it default or why is a resolver better than a forwarder?
As to why its default, ask the developers. But a resolver with dnssec enabled is better from a security point of view because as long as the domain your asking for a record from is using dnssec you are assured that the answer you get back is legit and what the authoritative server wants to hand out. Not some record in a cache, its quite possible the stuff in a cache has been poisoned, etc. Or maybe your cache entry ttl has not expired, or maybe the ones running the cache don't adhere to the authoritative servers ttls settings? To reduce their traffic?
If your asking the authoritative server you getting the answer right from the horses mouth, not some cache. To me this would always be the preferred method. Be it they sign it with dnssec or not. But in a perfect world all dns would be using dnssec..
Look at it like this, if the developers of pfsense thought it was better or a preferred setup to use unbound in forwarder mode - why and the F is out of the box in resolver mode ;) That would make zero sense. So its logical that pfsense using unbound in resolver mode is the preferred method..
You could debate that since some users have problem with resolver mode because they on some bad isp that blocks dns to anything other then their servers, or they intercept dns traffic and do something odd with it. Or maybe the user is just on a bad connection where talking to the authoritative servers for a domain on the other side of the planet takes too long. So in that case the forwarder to the users local isp dns would answer queries better. That really should be one offs to typical connection, and those users should make the decision to either bring up the issue to their isp, or get a better connection or use the forwarder.
I think its better to deal with the few users that have issues, and put most of the users than don't really know any better on a better security footing then leaving the default at forward mode and hoping the users read and figure out on their own that resolver is better and more secure.