Unbound make requests to 53 port
-
I have my resolver set to forwarding mode to 1.1.1.1 and of course i did select Use SSL/TLS for outgoing DNS Queries to Forwarding Servers.
Today testing some dns servers i saw that i have queries using 53 udp.Most of my queries are for 853 tcp but i have also 53 udp.
Is this normal? Right now i made fast a floating rule to stop outbound traffic for port 53 and my dns is working.
screen -
Hi,
Some device in your LAN that likes to question directly 1.1.1.1:53 ?
-
Hello,
No i don't have(as far i know), but this request is made also to root servers if unbound will restart.
Now i set another forward dns server, is the same behavior.
Here is my config
-
What are the IP's what you masked out ?
Your LAN IP's ?
WAN IP ?@jimp, recently, created a bug tracker on pfSense redmine, where he mentions the resolver bypassing the forward servers.
edit : https://redmine.pfsense.org/issues/10931 ?
-
Is my wan , it is a pppoe connection.
I see no point to mask a rfc1918.
Thanks for the link, at least now i know that is not my fault. -
When you list anything in general settings pfsense can and would use those for its own lookups directly, so would not use tls to talk to those.
See the redmine linked to.
Also - having dnssec enable when you are forwarding is pointless. 1.1.1.1 already does dnssec, asking it for dnssec is pointless and just added queries for no reason.
If you were forwarding to something that didn't do dnssec, asking for it - again would be pointless.
When you forward, there is no point to leaving dnssec enabled. Where you forward will either be doing it or not. If it does it, great if it doesn't asking for it does nothing and is just wasted queries.
Also your doing dot to here ? doh-dot.applied-privacy.net
Forwarding to servers that could resolve stuff differently is bad idea.. If 1 filters traffic for say bad sites, and the other doesn't Or 1 does dnssec and the other doesn't you run into an issue where something should of been filtered is not, or something that fails dnssec is returned, etc.
If you want to point to multiple dns, you need to make sure they will resolve everything the same. if 1 filters bad stuff, and the other does not - or filters different sites.. You run into an issue where your not sure exactly what your going to get. And once its cached locally all your other clients will get that same info.
You need to be sure the NS you point to do things the same way.. If you trust 1.1.1.1, then use that - use their alternate IPs if you want to.. But its anycast anyway.. Do you honestly think they would go down. If so most of the planet would be down ;) You could always just point to something else if they had an extended outage.
It makes no sense to use different NS that are not resolving and returning the exact same info.. Based on filtering criteria and doing dnssec or not..
This isn't the days of pointing to a couple of boxes your ISP ran, and 1 might get overloaded or go down, and the other worked. These services like quad9, 1.1.1.1, googledns, etc. Are global anycast cdn deployments designed to be up! And work.. It makes no sense to point to more than 1 of them.. Since they all have their own take on what is filter, or what is not. And who you choose may or may not be doing dnssec.. Pick 1 and use only them.. Or you could have issues with what is returned or not returned depending on which NS unbound happens to use.. Which you never can be sure which one that will be.
edit: It seems a misread this a bit.. You were only using 1.1.1.1 and seeing queries to root, and then changed to this different dot-doh NS and still seeing queries to root.. What is the source of these queries? Why are you hiding them if they are rfc1918? Firewall would not log pfsense own queries, so those are devices from your network, external network?
-
@johnpoz said in Unbound make requests to 53 port:
When you list anything in general settings pfsense can and would use those for its own lookups directly, so would not use tls to talk to those.
See the redmine linked to.
Also - having dnssec enable when you are forwarding is pointless. 1.1.1.1 already does dnssec, asking it for dnssec is pointless and just added queries for no reason.
If you were forwarding to something that didn't do dnssec, asking for it - again would be pointless.
When you forward, there is no point to leaving dnssec enabled. Where you forward will either be doing it or not. If it does it, great if it doesn't asking for it does nothing and is just wasted queries.
Also your doing dot to here ? doh-dot.applied-privacy.net
Forwarding to servers that could resolve stuff differently is bad idea.. If 1 filters traffic for say bad sites, and the other doesn't Or 1 does dnssec and the other doesn't you run into an issue where something should of been filtered is not, or something that fails dnssec is returned, etc.
If you want to point to multiple dns, you need to make sure they will resolve everything the same. if 1 filters bad stuff, and the other does not - or filters different sites.. You run into an issue where your not sure exactly what your going to get. And once its cached locally all your other clients will get that same info.
You need to be sure the NS you point to do things the same way.. If you trust 1.1.1.1, then use that - use their alternate IPs if you want to.. But its anycast anyway.. Do you honestly think they would go down. If so most of the planet would be down ;) You could always just point to something else if they had an extended outage.
It makes no sense to use different NS that are not resolving and returning the exact same info.. Based on filtering criteria and doing dnssec or not..
This isn't the days of pointing to a couple of boxes your ISP ran, and 1 might get overloaded or go down, and the other worked. These services like quad9, 1.1.1.1, googledns, etc. Are global anycast cdn deployments designed to be up! And work.. It makes no sense to point to more than 1 of them.. Since they all have their own take on what is filter, or what is not. And who you choose may or may not be doing dnssec.. Pick 1 and use only them.. Or you could have issues with what is returned or not returned depending on which NS unbound happens to use.. Which you never can be sure which one that will be.
edit: It seems a misread this a bit.. You were only using 1.1.1.1 and seeing queries to root, and then changed to this different dot-doh NS and still seeing queries to root.. What is the source of these queries? Why are you hiding them if they are rfc1918? Firewall would not log pfsense own queries, so those are devices from your network, external network?
Thank you for your amazing explanation.
Dnssec was enabled because i was testing unbound alone and also different dns servers.I already saw your suggestion on different threads.
I won't use 1.1.1.1 , it was just use as example.
I was curious to understand how/who send the requests to port 53, because i have a nat rule catching all the dns requests and also unbound was set to tls mode. -
@lcbbcl said in Unbound make requests to 53 port:
I was curious to understand how/who send the requests to port 53
If you have servers listed in general other than loopback, pfsense can and will depending use those for its own lookups.. Which would not use dot, they would just be normal queries to 53.
There is currently a redmine to change this behavior if so desired.
https://redmine.pfsense.org/issues/10931If you only want pfsense, even for its own look ups - when it checks for updates, when you grab package list, if you click resolve some IP in the firewall log, etc. Anything that pfsense might try and resolve on its own. Aliases for example..
Then you would set the option to only put loopback (127.0.0.1) in resolv.conf
