Network Project - Mutliple DNS Servers IP addresses to change - Clarification
-
I am thinking about utilizing Cisco Umbrella Port53 technologies for cloud content-filtering and advanced Internet threat management for our domain security, and as such I must point our DNS servers to them.
But, I am unsure which to change since there are multiple locations for this within pfSense and I am confused about where the 127.0.0.0 comes from as well as why when I use ipconfig from my endpoint within our LAN shows DNS servers IPs that are not the same as what is in pfSense...
Just want to make sure I have a better understanding of this subject before I go ahead and modify our DNS servers.
Thanks
-
Out of the box, pfsense will "resolve" needs NO dns server.. But it will also add ns that are handed to it via dhcp, unless you tell it not too. Or what you put in then general section... But it will not actually use them, unless for whatever reason unbound wasn't running.
the loopback 127.0.0.1 is pfsense asking "itself" unbound when it needs to lookup something - which unbound "resolves" not forwards.
What your clients use for dns is what dhcp server handed it, or what the client has set locally. Is the dhcp server (pfsense 10.235.17.1) if so then you setup dhcp server in pfsense to hand those out - or the client added them.. Out of the box pfsense will only hand out its own IP on that network for the dhcp server.
If you want to use some external dns and not resolve. Then change unbound into forward mode and it will use the server you list in the general section. Or don't use unbound and use the forwarder (dnsmasq) on pfsense.
And have your clients ONLY Point to pfsense for dns.. And prob make sure you block all other dns queries so clients HAVE to use pfsense.
-
@johnpoz
Thanks John, but I am still slightly confused and I should be set after a little more details..Confirmed that DNS resolver(Unbound) is active and running and pFSense and it is what we use as our DHCP server for our LAN
The DNS Servers listed after ipconfig command on client device are IPs provided by the pfSense DHCP server - (68.xx.xxx.x)
And the 12.127.xx.xx dns servers IPs in my general setup section are most likely from pfSense dhcp and thus are the NameServers, or could they be At&t provided DNS servers ? Since our firewall gateway appliance is physically preceded by and connected to the att modem/router .
So there are WAN(Internet) DNS servers and LAN dns servers (DHCP)?
-
Pfsense will not hand clients anything other than its own IP on that interface that dhcp is running on, UNLESS you modify the dhcp scope directly... You could have 10 dns servers listed in general.. pfsense will only hand out its own IP..
Leave blank to use the system default DNS servers: this interface's IP if DNS Forwarder or Resolver is enabled, otherwise the servers configured on the System / General Setup page.
unless unbound or forwarder are not running, then dhcpd would hand out what it had on the general tab for dns to clients vs its own ip.
-
Yep...
-
Well then dhcp clients would get handed those IP..
And is going to run in issues if 68.94 are the blocking NS you want to use, because 8.8.8.8 and 4.2.2.2 do not block.. So how are you sure client won't ask them for p0rndomain.tld vs one of the blocking ones, etc.
You can not have clients use different NS that would return different things without issue, since you can never be sure which ns a client has listed will be asked.
If you want to make sure ALL clients only can ask your blocking NS is point them either directly to there ONLY!!! Or only point them to pfsense, and set pfsense to only ask the NS you want to ask.. And then block client from asking any other ns.
if you point clients to only external NS, then they wouldn't be able to resolve anything locally.. Which is why its better to have them ONLY use pfsense, and pfsense forward to whatever blocking ns you want your client to get their public dns from.
-
Hey John,
So come to find out the 4 DNS servers IP addresses that are not the pfSense loopback IP are retired - as in they have not been used for awhile.
So how I understand it is that we are solely utilizing the pfSense Loopback 127.xx.xx.x dns server for WAN upstream data traffic and goolge 8.8.8.8 and the 4.2.2.2 public dns resolvers for LAN DHCP DNS?
Is this correct?
I am about to delete the other 4 that were owned by Att corp.
-
Dude why would you have your clients use 8.8.8.8 or 4.2.2.2 how are they going to resolving any local assets? That would be fine if these were just say guest wifi clients.
And btw 4.2.2.2 is only meant for L3 customers, if your not L3 or now Century link your not even really suppose to be using 4.2.2.2 ;) Check out this info
https://www.tummy.com/articles/famous-dns-server/That you wanted to use blocking dns? If so all clients behind pfsense would ONLY Point to pfsense for dns... Then they could resolve local assets, and pfsense would forward to your blocking NS.
-
@johnpoz Then this does not make sense to me.... the Att dns agent told me that the 68.xx IPs are not up and running...so then how are we resolving local assets as you mentioned if the only other two are the 8. and the 4.?
-
Dude your local clients would not be able to resolve LOCAL assets.. if your not pointing at a local dns server. Your prob broadcasting for them..
But I can tell you for fact that 8.8.8.8 doesn't have a clue about some host your running on local.lan Nor would of 68.something..
Not sure why this is confusing you? Only a your own NS is going to know about host.local.lan or pfsense.local.lan or nas.local.lan, etc.
Are you redirecting all dns at pfsense, so I could ask 9.9.9.9 and your redirecting it to pfsense.. If so that would also explain how your resolving local assets.
-
@johnpoz What I am confused about is I do not know if all dns is being redirected to pfSense or not..I was not in charge of the network when all of this was initially configured and all IP numberings were set...so this is why I am seeking clarity from expertise.
All my screenshots at the beginning of this post indicate, I think, that the 127. dns server is a loopback within the LAN, so that means that 8. and 4. dns DHCP servers are not even being actively utilized, so does this mean we are redirecting dns to pfsense to resolve local assets ? Because if the att dns tech is correct, it means the two 12. and two 68. are not being utilized.
I ask because I do not know since I am simply analyzing the best I can what I was already set up before me and all I want to do is point DNS servers to cisco for content-filtering.
-
You did not show the section what would tell me if being redirected... This would be on the port forwards sections, and you would see a firewall rule on the lan if that was the case.
@VirtuousMight said in Network Project - Mutliple DNS Servers IP addresses to change - Clarification:
DHCP servers are not even being actively utilized,
What? Dude that setting is what pfsense will use to resolve what pfsense needs to resolve.. Ie check if there is updates, the PTR for an IP it blocked in a firewall rule if you click the resolve this button, etc.
You clearly are handing out 8.8.8.8 and 4.2.2.2 to your clients via dhcp setup in pfsense...
-
Hey John, sorry about the misstatement regarding DHCP - I was referring to it within the context of local assets based on how I understood it, which is not a complete understanding yet - but I now have the screenshots about firewall NAT and Rules:
Does the first screenshot show evidence of pfsense dns redirecting?
And in the second screenshot of firewall rules for lan shows an Anti-lockout rule, and default allow for IPv4 and IPv6 - which I understand is not firewall security best practice (default deny it should be set up as).
-
That is outbound nat, not port forwarding tab.
But your lan rules show no rule for redirection of dns... And those rdp rules on both lan and wan make zero sense to be honest.
Wan is port forward to rdp but without seeing the port forward specific not sure how your differentiating between the 2.. What I will say is having rdp open to the public is a very BAD idea.
Without redirection of dns and clients asking google and 4.2.2.2 the only way they could possible resolve local resources would be with just simple broadcasting for them..
Here is what I would suggest.. Your clients should point to pfsense for dns, this is the DEFAULT out of the box configuration for when you enable dhcp server on pfsense. Then pfsense will resolve - out of the box, or you can set it up to forward if you want to use some outside dns for blocking stuff, etc.
-
I agree the WAN- MS RDP port forward is flawed (the actual set up differentiates the two by separate custom destination ports, 33389 and 33390) and therefore I have discontinued its use some time ago ( again this was another instance of faulty config before I started working here) so thanks for stating that definitively.
Where would the previous personnel set up dns broadcasting for LAN nodes in pfSense so I can disable it?
I did not include the port forward tab because all it has is this...
-
its not dns broadcasting... It would be the client doing a netbios broadcast for the hostname... Hey who is called somehost..
So your clearly not doing dns redirection.
So you want to set it up correctly.. Point your clients to pfsense, or some other local NS that will resolve all your local resources, and will then forward or resolve all your public dns needs.
Pointing clients to outside NS is not going to allow you to actually resolve any local resources, nor will it give you the ability to block bad stuff.. You have no control over the dns at all when you tell client to use 8.8.8.8 for their dns..
But if you have them point to something local for dns, say pfsense - you then can control stuff by blocking stuff you don't want them to get to.. You can resolve say www.whatever.com to the local IP its hosted off of, vs getting the public IP for this fqdn and having to use nat reflection.
Also pointing clients locally allow you save some bandwidth, because if client A looks up www.something.com, and then client B asks for it its already cached at your local dns, and doesn't have to be looked up again, etc.
So fix it already - not really sure why we are stilling having this discussion ;)
