DNS-resolver forwarding local domain to rootservers!??
-
Hello,
By accident I noticed in a wireshark capture that the resolver is forwarding what IMHO should be a strictly local query towards the dns rootservers. So something seems wrong there.
Formally I would have used .local form my network, but nowadays the situation is a bit more complex.
For my internal network I use ^.lan^ where the vlan's have a subnet value attached like
vlan a = domain *.a.lan
vlan b = domain *.b.lan
I do not use .local any longer due to mdns etc/In system/general setup I defined the pfSense domain as ^lan^.
Next to that strictly local lan I also have a redzone running e.g. an Apache web server for some public domains. That vlan has as internal domain rz.lan.
For my public domains I use an external DNS provider and to make the servers for ipv4 internally accessible I use host override in the local resolver.
Further on I redirect all dns calls regardless of the opriginal destination towards the pfSense internal resolver. That allows me to block things and to log things
So far so good ..... however now the strange / NOK thing
when is when I start a ping towards ape.pc.lan (which does not exist) that query is forwarded to the DNS-root servers,
something which should not happen IMHO.So what is going on here and how should I solve this!?
Louis
-
@louis2 said in DNS-resolver forwarding local domain to rootservers!??:
So what is going on here and how should I solve this!?
How does unbound know that is not a public tld? The default zone type setting in pfsense is transparent.. Meaning if asked for something in the local domain, and there is no local resource - try and resolve it normally.
If you do not want that to happen, then set the zone type to static.
https://nlnetlabs.nl/documentation/unbound/unbound.conf/
static If there is a match from local data, the query is answered. Otherwise, the query is answered with nodata or nxdomain. For a negative answer a SOA is included in the answer if present as local-data for the zone apex domain. transparent If there is a match from local data, the query is answered. Otherwise if the query has a different name, the query is re- solved normally. If the query is for a name given in local- data but no such type of data is given in localdata, then a noerror nodata answer is returned. If no local-zone is given local-data causes a transparent zone to be created by de-fault
I personally think static should be the default, but maybe that is just me.
-
John IMHO you are completely right if you say that the default should be static.
Apart from that, I did also try with redirect, since the behavoir descriptions are IMHO rather vague and I do have subdomains (facilitated by this pfSense system / resolver)
That option did not work, however there are bugs in the pfSense code.
- my redirects are not accepted when trying to switch to redirect mode
- and switching back from that try to transparent or static is not possible any more. The errors displayed when trying redirect do not disappear any more
I had to restore a recent config file !!
I also noticed another unexpected behavoir. When issuing a
ping ape.rz.lan when the option is e.g. static, there is a DNS check related to A-records and not AAAA-records. Which is IMHO a bit strange. Where in other modes there is a DNS query for both A and AAAA. If I explicit ask for a ping -6 there is an DNS-request for AAAA only.So apart from the discribed issues, NOK but you will probably hardly ever notice, changing the setting to static is the solution for this IMHO faulty behavoir.
I say faulty because domains formally specified as local domains (.local, .lan etc.) should in my opinion never be forwarded from the local resolver ...
-
@louis2 said in DNS-resolver forwarding local domain to rootservers!??:
should in my opinion never be forwarded from the local resolver ...
While agree with you, users love to think its ok to use a public domain internally as well as externally at the same time.
Hey have publicdomain.tld and use that internally.. This is bad idea no matter how you look at it imho.
your duplicate local zone pfsense.lan and localhost.lan - what are you doing there, your creating custom zones in the custom box? And you also have a redirect setup in the custom box?
-
I need access to my websites from/via my own lan, no way around that. If you have a better solution for that
be my guest / I would appreciate!
In the actual config (static) www.mysite.nl ipv4 is forwarded to the internal ip-address and not the external as provided via the external DNS.Related to the "duplicate local zone pfsense.lan and localhost.lan ..... I really have no idea where it is coming from.
As written I gave every vlan its own subdomain. However pfsense itself is a strange thing. In a couple of regards:- it is above the vlans so as domain I use .lan
- as far as I no, and that is not ok, I can not define an pfsense listening address (explicit managment address) :(
- it is listening to SSH-port 22 which is conflicting with other SSH-servers (I changed the port number)
Then we have localhost.lan ....... no idea. I opened the configfile and searched for localhost ..... it is not there
I use fixed IP's for my servers etc. To make them accessible via a FQDN, I put them in the Host Override list
No idea what is mend with "local-data in redirect zone must reside at top of zone"
No idea why all this is an issue when using the redirect setting and no problem when using transparent or static
Further on I have some domain overrides, for domains I do not like, I forward them to ^dev0^(not existing ip)
-
@louis2 said in DNS-resolver forwarding local domain to rootservers!??:
I need access to my websites from/via my own lan, no way around that. If you have a better solution for that
be my guest / I would appreciate!So? Your websites are external or internal? Don't understand how that has anything to do with running the same domain in a LAN then in the wild.
It has a reason, why a new install of pfSense comes with .home.arpa as default domain as that is per IETF/RFCs a safe and internal TLD/domain to use. But yeah, you can't have certificates and stuff with that, so if already having a real domain, why not using lan.<yourdomain> for internal use instead of dummy TLDs or stuff?In the actual config (static) www.mysite.nl ipv4 is forwarded to the internal ip-address and not the external as provided via the external DNS.
Host override can do that, no problem. No reason to adjust pfSense' default domain to mysite.nl for that.
Related to the "duplicate local zone pfsense.lan and localhost.lan ..... I really have no idea where it is coming from.
As written I gave every vlan its own subdomain. However pfsense itself is a strange thing. In a couple of regards:
What's in your advanced config box? Those entries don't come from nowhere. You have to configure that by hand to pop up such errors. So what did you put in the resolver advanced config?
it is above the vlans so as domain I use .lan
as far as I no, and that is not ok, I can not define an pfsense listening address (explicit managment address) :(Don't understand what that is supposed to mean?
it is listening to SSH-port 22 which is conflicting with other SSH-servers (I changed the port number)
Huh? Of course it does if you enable SSH, why shouldn't it? If you don't use it, then disable it in System / Advanced Settings but sorry, I don't understand how that is weird, not working correctly or somehow strange that a system listens to a port is services.
I use fixed IP's for my servers etc. To make them accessible via a FQDN, I put them in the Host Override list
Why? If you have a clean setup of "System / General" (Domain) and the DNS Resolver (push static DHCP mappings to DNS) that's simply unnecessary.
If you only configure them via static IP directly, OK that I can understand, but it also helps mitigate errors, that's why I recommend to create static DHCP mappings for servers so in case you reset/reinstall them they also come up with the same IP you otherwise would statically assign anyway. Plus - DNS is already done that way.No idea what is mend with "local-data in redirect zone must reside at top of zone"
you broke unbound's config file with your own modifications and pushed data into a zone that was already created automatically by unbound because (I'd guess) it's the default zone of pfSense (default domain in System/General) and thus created before the advanced config field of unbound comes into play. So you can't push a zone again and write any entries in it if it already exists. No duplication is allowed in unbound's config.
Further on I have some domain overrides, for domains I do not like, I forward them to ^dev0^(not existing ip)
That's more pfBlockerNG's job to do, but if you do that, please route them to 0.0.0.0 - that's what sensible DNS blocking is like. Nullblocking. Not any nonsense IP that would result in unnecessary DNS resolution attempts and timeouts.
But consider using pfBlockerNG's DNSBL section for that - that's what it does (or pihole, adguard, etc.)Cheers mate
-
Thanks for your thoughts. I will try to answer / explain.
My websites are inside my own lan, that is causing the problem, other wise there would not have been any problem at all.
And yep my servers are using domain name related certificates.
And those servers are in use for multiple domains, so your idea to use the external domain for internal purposes as well is not possible.
The problem is mainly an IPV4 problem. My server is using multiple private 192.168.a.b addresses. And I only have one public IPV4 address.
The external DNS-servers are translating my FQDN's towards the one public IPV4. And pfSense is forwarding the incoming traffic using NAT.
If I would not override the DNS-querys in the resolver, queries started from my local PC's towards my own websites would be answered by the external DNS with my public IP. Which does not work from within my local network.
Than related to DHCP <> DNS. I always have some doubt if it is yes or no a good idea to share DHCP addresses to the resolver. Perhaps it is. However that does not change the problem. My Server, NAS etc have all machine defined fixed IP addresses. Only laptops etc have DHCP assigned addresses often using MAC banded addresses.
The default zone I use is "lan" and for the vlan's "<vlanname>.lan"
I do not understand the paragraph starting with "you broke"Related to I can not define an pfsense listening address (explicit managment address) What I would like to see is that:
The pfSense gateway addresses are not at the same time addresses used as management addresses !! For example: Accessing pfSense gui from the management vlan is a good idea, where accessing the GUI form the guest vlan is definitively not!!The same type of problem with SSH. That pfSense is listening on all interfaces to SSH is simply not OK! From the security point of view. And next to that in this case also because it is conflicting with my SSH server to be accessible from the internet (fixed that by choosing a different port)
I am not using pfBlockerNG e.g. because it will slowdown the system. And I am only blocking a small number of sites, and I think that that can be perfectly done by an override and I also assume that would cost far less performance
-
@louis2 said in DNS-resolver forwarding local domain to rootservers!??:
My websites are inside my own lan, that is causing the problem, other wise there would not have been any problem at all.
And yep my servers are using domain name related certificates.Understood! :)
And those servers are in use for multiple domains, so your idea to use the external domain for internal purposes as well is not possible.
Why exactly? Multiple domains won't make that "impossible". That you have to explain.
The problem is mainly an IPV4 problem. My server is using multiple private 192.168.a.b addresses. And I only have one public IPV4 address.
Again: unclear about why that should be a problem?
The external DNS-servers are translating my FQDN's towards the one public IPV4. And pfSense is forwarding the incoming traffic using NAT.
So far so good...
@louis2 said in DNS-resolver forwarding local domain to rootservers!??:
If I would not override the DNS-querys in the resolver, queries started from my local PC's towards my own websites would be answered by the external DNS with my public IP. Which does not work from within my local network.
But it does. You just would have to add either a port forwarding rule on your internal LAN or enable NAT reflection to do the same automagically.
Otherwise a Host Override will do better as it won't have traffic go to your firewall to be reflected to the internal host unnecessary but directly connect your client with your host without involving the firewall (besides DNS of course).Than related to DHCP <> DNS. I always have some doubt if it is yes or no a good idea to share DHCP addresses to the resolver. Perhaps it is. However that does not change the problem. My Server, NAS etc have all machine defined fixed IP addresses. Only laptops etc have DHCP assigned addresses often using MAC banded addresses.
Dynamic ones - no. Statically assigned ones are no problem AFAIK as those get imported when starting/restarting the resolver and won't be refreshed that often as the problem is with dynamic ones of clients. With low lease times and many clients the resolver would get swarmed with updates and reloads for those, that's why dynamic ones are mostly a "no" for unbound/the resolver.
@louis2 said in DNS-resolver forwarding local domain to rootservers!??:
The default zone I use is "lan" and for the vlan's "<vlanname>.lan"
To check: What do you mean by "default zone"? Do you have "lan" set as domain in System/General like this?
That could be a problem as a "tld only" might trouble a few clients. I'd use something like the default (xy.home.arpa or only home.arpa) or at least a domain, not a TLD only (sth like home.lan). The TLD should be valid (home.arpa, .test) or at least a half-way safe TLD like ".lan" (that is not really a valid TLD but currently agreed upon to not be handed out as a gTLD for domains to be sold).
A domain per DHCP should also be no problem, I do essentially the same thing with <domain.tld> being my normal (externally visible) domain and <lan.domain.tld>, iot..., work..., lab... or <guest.domain.tld> being the DHCP domains per VLAN.
The part about "broke" was putting options in the Custom option field. You can't simply copy/paste anything you find on blogs or the docs of unbound straight into it as pfSense itself creates entries in the config and adds those from this textbox at the bottom of the config. So if you set up things that pfSense already inserted above with its default settings, you can't overwrite them - unbound doesn't support that. So what do you have in that box?
That is most certainly causing your posted (red box) errors from the DNS resolver page.The pfSense gateway addresses are not at the same time addresses used as management addresses !! For example: Accessing pfSense gui from the management vlan is a good idea, where accessing the GUI form the guest vlan is definitively not!!
Yes, you can't select to unbind the webserver from different LAN/VLANs currently. So if you don't want access simply block it or don't allow it in your ruleset. Dito for SSH. The
this firewall
alias is perfect for that.That pfSense is listening on all interfaces to SSH is simply not OK!
I disagree. That depends heavily on your use case and your setup. I might agree that having it available to configure would be nice but a general "don't" is your opinion, my usecase is different than that.
@louis2 said in DNS-resolver forwarding local domain to rootservers!??:
And next to that in this case also because it is conflicting with my SSH server to be accessible from the internet (fixed that by choosing a different port)
Again that is specific to your setup. I'm running various datacenter installations with a multitude of IPs and pfSense isn't disturbing them at all. It also is completely fine to forward tcp/22 from your WAN to another server inside and "use" port 22 for your own without having to reconfigure pfSense although I would generally recommend using another port instead of 22 when exposing SSH to the general internet (and not only to various sources defined in an alias) to reduce impact from simple scans and bots that try password-guessing-games.
So perhaps you didn't know, but you can use the ports of SSH/Web and forward them to another host from your WAN without doing anything in pfSense. Just because it is listening on :: or 0.0.0.0 (any IP) isn't automatically bad or makes ports unusable. That is what redirect/forwarding rules are for (and even if it's not listening on those ports you would have to use forwards anyway to reach hosts on your LANs). So nothing per se to fix, but configuring other ports is a general recommendation (of me or other consultants) anyway.@louis2 said in DNS-resolver forwarding local domain to rootservers!??:
I am not using pfBlockerNG e.g. because it will slowdown the system. And I am only blocking a small number of sites, and I think that that can be perfectly done by an override and I also assume that would cost far less performance
I don't know your system or HW specs but again - generally - that is not correct. It slows down nothing with us. Even my home backup box with a Atom C2558 has no problems at all running pfBlocker every hour. Sorry but that is nonsense or a problem with your install/setup/usage. We do several setups with customers using either IP blocklists or both IP and DNS blocklisting (you don't have to do both!) with pfBlockerNG-devel and it doesn't slow down their systems either. So that would be a topic for the pfBNG subforum if you want but it's not a given in general.
Hope that helps you further!
Cheers -
Why exactly? Multiple domains won't make that "impossible". That you have to explain.
My impression was that you suggest to use one of those domain names also for internal use. Since I have multiple that seems impossible to me, apart from the fact that i do not like the idea.Otherwise a Host Override will do better as it won't have traffic go to your firewall to be reflected
The traffic from my internal systems are passing directly to the also ^publicly accessible systems^. However in opposite to what you suggest, they do pass the firewall, since the public servers are in the redzone and for example the pc's are in the pc-zone.However I do not understand the NAT reflection idea. I had a look on https://docs.netgate.com/pfsense/en/latest/nat/reflection.html And do not get the impressing that there is a better solution. But perhaps I am wrong.
Dynamic ones - no. Statically assigned ones are no problem AFAIK as those get imported when starting/restarting the resolver and won't be refreshed that often.
I did not ever released that, I do not like it, however since the things which should have a stable address have either a machine internal fixed address(es) or have one statically assigned by the dhcp server based on MAC and DUID that will probably not be a big problem.DNS-resolver forwarding local domain to rootservers!??
That issue have been solved recently by changing DNS resolver type to static. Which should IMHO be the default.To check: What do you mean by "default zone"?
Yep exactly there. That is my toplevel. All the clients are in vlans having <vlanshortname>.lan as subdomain.Note that .lan and its subdomains are of course not visible from the outside.
Related to DNS options, I have the following options in that field
server:
log-queries: yes
#log-replies: yes
#log-tag-queryreply: yes
local-zone: "use-application-dns.net" always_nxdomain
Not so sure about the final lineRelated to blocking SSH from e.g. my guest vlan. I am not sure about the pfSense behavoir (I should test some time).
I have two issues here:- the gateway is inside each vlan (?), and from that you could expect that there is no rule which could block access to that gateway. Never the less I think that you can block the functions provided by the gateway.
- Second is that you have to add rules for that. Best way there is probably two rules in the floating rule set.
First defining what is allowed
Second refusing the rest
I would prefer an option where you could define the listening addresses for the pfSense GUI.
So perhaps you didn't know, but you can use the ports of SSH/Web and forward them to another host from your WAN without doing anything in pfSense
I do not understand this, however I have only one publicly reachable SSH-/SHTP-server and that one is reachable via port forwarding. pfSense itself is on port 2222 and the pfSense management is not reachable from the wan, not by any port/means.I don't know your system or HW specs
Related to the hardware specs
Intel(R) Core(TM) i5-6600K CPU @ 3.50GHz
Current: 2099 MHz, Max: 3500 MHz
4 CPUs: 1 package(s) x 4 core(s)
SSD 16 GB-ramSo reasonable powerfull, however I have 10gbit lan's internally, and transferring data from the NAS (greenzone) to the PC-zone is passing the FW.
I also assume that applications like pfBlocker are only checking the WAN, which of course has a much lower speed. But why should I add that complexity If I only want to block a minimal number of domains!?
Note that I not only use the firewall to block incoming traffic, but also try to block some outgoing traffic (using DNS). Not so easy