DNS Resolver Log Error sending queries to 1.1.1.1
-
Hello All,
I pointed my DNS Resolver to the CLOUDFLARE DNS Server for queries and I am getting the following error in the logs:
Apr 4 00:02:24 unbound 8198:3 debug: tcp error for address 1.1.1.1 port 853
Apr 4 00:02:24 unbound 8198:3 debug: outnettcp got tcp error -1
Apr 4 00:02:24 unbound 8198:3 debug: cache memory msg=99133 rrset=121685 infra=5722 val=78919
Apr 4 00:02:24 unbound 8198:3 debug: sending to target: <.> 1.1.1.1#853It seems that all my queries are resolved by the the secondary server(1.0.0.1) and not the primary. Any ideas why this would be?
Thank you!
-
I'm having the same issue to both the ipv4 and ipv6 resolvers on 853.
Everything is fine over port 53.
Log excerpt…
Apr 4 01:09:56 edi unbound: [51210:0] info: iterator operate: query ps-667.pubnub.com. A IN Apr 4 01:09:56 edi unbound: [51210:0] info: processQueryTargets: ps-667.pubnub.com. A IN Apr 4 01:09:56 edi unbound: [51210:0] info: sending query: ps-667.pubnub.com. A IN Apr 4 01:09:56 edi unbound: [51210:0] debug: sending to target: <.> 1.0.0.1#853 Apr 4 01:09:56 edi unbound: [51210:0] debug: cache memory msg=37518 rrset=33048 infra=4193 val=33248 Apr 4 01:09:56 edi unbound: [51210:0] debug: outnettcp got tcp error -1 Apr 4 01:09:56 edi unbound: [51210:0] debug: tcp error for address 1.0.0.1 port 853 Apr 4 01:09:56 edi unbound: [51210:0] debug: iterator[module 1] operate: extstate:module_wait_reply event:module_event_noreply
Pcap on igb0 for port 853 show traffic going out and coming back.
Running 'openssl s_client -connect 1.1.1.1:853' also works, so I know it's not an ISP block upstream.
-
Seeing similar issues on my end when trying to set up tcp forwarding:
Apr 4 04:35:48 pfsense.home unbound: [33395:0] info: iterator operate: query ps-275.pubnub.com. A IN
Apr 4 04:35:48 pfsense.home unbound: [33395:0] info: processQueryTargets: ps-275.pubnub.com. A IN
Apr 4 04:35:48 pfsense.home unbound: [33395:0] info: sending query: ps-275.pubnub.com. A IN
Apr 4 04:35:48 pfsense.home unbound: [33395:0] debug: sending to target: <.> 1.1.1.1#853
Apr 4 04:35:48 pfsense.home unbound: [33395:0] debug: cache memory msg=52480 rrset=33048 infra=4193 val=33248
Apr 4 04:35:49 pfsense.home unbound: [33395:0] debug: outnettcp got tcp error -1
Apr 4 04:35:49 pfsense.home unbound: [33395:0] debug: tcp error for address 1.1.1.1 port 853
Apr 4 04:35:49 pfsense.home unbound: [33395:0] debug: iterator[module 1] operate: extstate:module_wait_reply event:module_event_noreplyI do see active states for port 853 on 1.1.1.1, so not sure why it isn't able to communicate. Not seeing anything like firewall blocking connections or anything like that… Note that I did not include the 1.0.0.1 server in my config while trying to debug this.
I see the same results if I try Quad9's servers, too (9.9.9.9).edit: looks like switching to quad9 9.9.9.9 does work as expected. Must be something up with 1.1.1.1.
-
We're seeing it as well. While we're investigating this issue, it seems to work with quad9 so I suggest you try it.
-
UPDATE: This morning I was not able to resolve any DNS Queries until I removed the CLOUDFLARE Config. My pfsense router cannot connect to either CLOUDFLARE Name Server over TLS.
-
We're seeing it as well. While we're investigating this issue, it seems to work with quad9 so I suggest you try it.
Yep, I switched to Quad9, and so far no issues working with them over 853.
If it makes any difference, I'm using a SG-2220 appliance.
EDIT:
It occurs to me the above is probably not that helpful overall, so…
System Netgate SG-2220 BIOS Vendor: coreboot Version: ADI_DFF2-01.00.00.17-nodebug Release Date: Mon Sep 18 2017 Version 2.4.3-RELEASE (amd64) built on Wed Mar 28 16:32:48 CDT 2018 FreeBSD 11.1-RELEASE-p7 CPU Type Intel(R) Atom(TM) CPU C2338 @ 1.74GHz 2 CPUs: 1 package(s) x 2 core(s) AES-NI CPU Crypto: Yes (active) Hardware crypto AES-CBC,AES-XTS,AES-GCM,AES-ICM Kernel PTI Enabled
-
Thank you! I will try the QUAD9 Server.
-
We have updated the blog post with Quad9 settings https://www.netgate.com/blog/dns-over-tls-with-pfsense.html
-
The Quad9 IPV4 and IPV6 resolvers are all working for me over TLS/853 with the same settings I was trying to use for CloudFlare.
¯_(ツ)_/¯
-
I'm also getting the following error once i switch to using cloudflare
There were error(s) loading the rules: /tmp/rules.debug:19: cannot define table bogonsv6: Cannot allocate memory - The line in question reads [19]: table <bogonsv6> persist file "/etc/bogonsv6"
@ 2018-04-04 19:21:23This is using 2.4.3 w/8gb of mem.
I'm pretty sure I saw this was being looked at in 2.4.4
-
Do we have to wait for an update for this to be fixed? Was anybody successful in getting the Cloudflare config to work?
Thanks!
-
Do we have to wait for an update for this to be fixed? Was anybody successful in getting the Cloudflare config to work?
Thanks!
It worked until this morning so I left the config in place and added entries for Quad9 as well. If they both provide the DNS TLS might as well have both in the list.
-
Do we have to wait for an update for this to be fixed? Was anybody successful in getting the Cloudflare config to work?
Thanks!
It worked until this morning so I left the config in place and added entries for Quad9 as well. If they both provide the DNS TLS might as well have both in the list.
The point is to be able to use Cloudflare as the primary DNS since their service is faster.
-
Do we have to wait for an update for this to be fixed? Was anybody successful in getting the Cloudflare config to work?
Thanks!
It worked until this morning so I left the config in place and added entries for Quad9 as well. If they both provide the DNS TLS might as well have both in the list.
The point is to be able to use Cloudflare as the primary DNS since their service is faster.
Agree but it does not work for me. If I only have Cloudflare in my config I cannot resolve.
Apr 5 09:08:16 unbound 70814:1 error: SSL_read syscall: Connection reset by peer
Quad9 works though.
-
The Cloudflare settings still are not working and Cloudflare is reporting that they are not experiencing any service problems. Perhaps they have made some change that either inadvertently or deliberately blocks this? Regardless, it seems that it isn’t likely to work “as is”.
Hope I’m wrong.
-
The Cloudflare settings still are not working and Cloudflare is reporting that they are not experiencing any service problems. Perhaps they have made some change that either inadvertently or deliberately blocks this? Regardless, it seems that it isn’t likely to work “as is”.
Hope I’m wrong.
I was reading a post on one of the forums and some there seems to think this is a pfsense issue with the Cloudflare certificate.
-
The Cloudflare settings still are not working and Cloudflare is reporting that they are not experiencing any service problems. Perhaps they have made some change that either inadvertently or deliberately blocks this? Regardless, it seems that it isn’t likely to work “as is”.
Hope I’m wrong.
I was reading a post on one of the forums and some there seems to think this is a pfsense issue with the Cloudflare certificate.
Stange thing is, it worked for two days before it stopped at @ Midnight local two nights ago.
-
https://tech.slashdot.org/story/18/04/05/0420247/1111-cloudflares-new-dns-attracting-gigabits-per-second-of-rubbish
If they can't handle the bogus traffic, maybe they should move to a host that specializes in DDoS protections… ;D ;D
-
^ exactly… Why anyone would even want to point their dns to this is beyond me....
-
^ exactly… Why anyone would even want to point their dns to this is beyond me....
Do you use QUAD9?