Cloudflare new DNS 1.1.1.1 issues
-
Well something is preventing that then. Do you have anything odd in your routing table?
If you run a pcap on WAN and filter for 1.1.1.1 do you actually see packets leaving why you try to nslookup against it from the command line.
Steve
-
I don't see anything odd in the routes unless someone else does:
Sanitized output of course….. assume valid address for the Xs
netstat -rn
Routing tablesInternet:
Destination Gateway Flags Netif Expire
default 99.74.X.X UGS em0
8.8.8.8 99.74.X.X UGHS em0
10.0.2.0/24 10.0.2.2 UGS ovpns1
10.0.2.1 link#7 UHS lo0
10.0.2.2 link#7 UH ovpns1
10.0.3.0/24 10.0.3.2 UGS ovpns2
10.0.3.1 link#8 UHS lo0
10.0.3.2 link#8 UH ovpns2
99.74.X.0/22 link#1 U em0
99.74.X.X link#1 UHS lo0
127.0.0.1 link#3 UH lo0
192.168.1.0/24 link#2 U em1
192.168.1.1 link#2 UHS lo0Internet6:
Destination Gateway Flags Netif Expire
default fe80::e222:4ff:fe16:4915%em0 UGS em0
::1 link#3 UH lo0
2001:4860:4860::8888 fe80::e222:4ff:fe16:4915 UGHS em0
2600:1700:2d60:XXXX::/64 link#1 U em0
2600:1700:2d60:XXXX::469 link#1 UHS lo0
2600:1700:2d60:XXXX:215:17ff:fea9:XXXX link#1 UHS lo0
2600:1700:2d60:XXXX::/64 link#2 U em1
2600:1700:2d60:XXXX:215:17ff:fea9:XXXX link#2 UHS lo0
fe80::e222:4ff:fe16:4915 fe80::e222:4ff:fe16:4915%em0 UGHS em0
fe80::%em0/64 link#1 U em0
fe80::215:17ff:fea9:ff54%em0 link#1 UHS lo0
fe80::%em1/64 link#2 U em1
fe80::1:1%em1 link#2 UHS lo0
fe80::%lo0/64 link#3 U lo0
fe80::1%lo0 link#3 UHS lo0
fe80::%ovpns1/64 link#7 U ovpns1
fe80::215:17ff:fea9:XXXX%ovpns1 link#7 UHS lo0
fe80::%ovpns2/64 link#8 U ovpns2
fe80::215:17ff:fea9:XXXX%ovpns2 link#8 UHS lo0 -
I can ping and use nslookup with 1.1.1.1. I have pfBlocker with DNSBL, snort, and squidguard running. So it seems to be an isolated issue.
-
Mmm, something odd. Try the pcap whilst nslookup-ing. Or least check for states to 1.1.1.1 open on WAN. Maybe the upstream device is blocking it although it can connect itself.
Steve
-
Here is the relevant pcap:
no. time source dest proto length info
1702 6.019781 99.74.X.X 1.1.1.1 DNS 80 Standard query 0x0001 PTR 1.1.1.1.in-addr.arpa
2695 12.024627 99.74.X.X 1.1.1.1 DNS 70 Standard query 0x0004 A google.com
2915 14.026166 99.74.X.X 1.1.1.1 DNS 70 Standard query 0x0005 AAAA google.comIt is a stupid ATT gateway that is in DMZ mode, though I may have to dig into it and see if it is doing something screwy too.
-
It is a stupid ATT gateway that is in DMZ mode, though I may have to dig into it and see if it is doing something screwy too.
At Least 2 AT&T Gateways use 1.1.1.1 and/or 1.0.0.1 or the blocks they are in for themselves, thus break routing to them.
5268ac Breaks connectivity to 1.1.1.1, though 1.0.0.1 is fine.
BGW210 apparently breaks both. -
Oh FFS, 1.0.0.1 does work, so is very likely what you just mentioned. No idea why I didn't think to try the backup address. I really loath ATT, but only fiber option here. I think that just explained everything and fixes my issue.
Thanks so much.
-
Is it even worth switching anyway?
8.8.8.8 or 1.1.1.1 – it's all still clear text, so there are very little privacy differences between the two. This only takes away information from Google -- a company that can use these queries to know which sites are more relevant than others -- i.e. give you better search results.
There's also the problem introduced by using these "proxy" DNS servers. By running your own DNS server, when you do a query, the DNS servers it queries can respond based on your IP address -- this means the other DNS servers have the potential to return IP addresses that are closer to you. When you query using these hosted DNS servers, you have the potential to get cached results that someone before you made that may not be ideal for your location. This means gaming and other services where you want the lowest latency possible may suffer.
I ran into an issue using blacklists for spam filtering a while back --- it wasn't working reliably. I found out that the blacklisting mechanism works by performing DNS queries -- and that the blacklisting service limits the number of queries based on the DNS server doing the asking. So if you use these DNS hosting servers, you're much more likely to reach their cap because a LOT of people use them. Once I started using my own DNS server, that problem vanished.
-
Is it even worth switching anyway?
8.8.8.8 or 1.1.1.1 – it's all still clear text, so there are very little privacy differences between the two. This only takes away information from Google -- a company that can use these queries to know which sites are more relevant than others -- i.e. give you better search results.
There's also the problem introduced by using these "proxy" DNS servers. By running your own DNS server, when you do a query, the DNS servers it queries can respond based on your IP address -- this means the other DNS servers have the potential to return IP addresses that are closer to you. When you query using these hosted DNS servers, you have the potential to get cached results that someone before you made that may not be ideal for your location. This means gaming and other services where you want the lowest latency possible may suffer.
I ran into an issue using blacklists for spam filtering a while back --- it wasn't working reliably. I found out that the blacklisting mechanism works by performing DNS queries -- and that the blacklisting service limits the number of queries based on the DNS server doing the asking. So if you use these DNS hosting servers, you're much more likely to reach their cap because a LOT of people use them. Once I started using my own DNS server, that problem vanished.
1.1.1.1 offers DNS over TLS and DNS over HTTPs
8.8.8.8 only offers DNS over HTTPs,So not necessarily plain text, and DNS over TLS is easy to do on pfSense wifh BIND and sTunnel
Also EDNS Client Subnet solves the issue of DNS based geolocation, wich i believe both support.
-
In case you haven't figured it out yet, firmware 1.5.11 (1.5.12?) breaks access to 1.1.1.1. This ip is now some sort of internal ip within the gateway (bgw210).
