Cloudflare new DNS 1.1.1.1 issues



  • Hi guys.

    For some reason my network appliance running pfsense 2.4.3 refuses to access 1.1.1.1. Trying directly from my modem works fine however. I have tried toggling bogon network blocking off on the wan interface with no luck.

    My attempts to reach 1.1.1.1 were also initiated directly from pfsense on the WAN interface. Any help or ideas would be appreciated.




  • Netgate Administrator

    What actual error do you see when you try to ping it?

    Steve



  • nslookup google.com 1.1.1.1 from your PC
    From cmd or ssh in case of *nix OS

    Do you get IP addresses back?
    If you do

    Do the same from pfsense ssh
    Do you get IP addresses back?

    No?


  • Netgate Administrator

    Given there is a known issue with pfBlocker if you're running DNS-BL that's the first place to check. See KOM's link above.

    If it is that just set the list action to disabled in 'DNSBL IP Firewall Rule Settings' until a package update is available.

    Steve




  • So, I had the pfblocker package installed, but had never used it.

    Removing the package did not fix the issue. I am going to try re-installing it and disabling the list in question as KOM linked to.

    As per another comment from jaspras:
    From desktop-

    nslookup google.com 1.1.1.1
    DNS request timed out.
        timeout was 2 seconds.
    Server:  UnKnown
    Address:  1.1.1.1

    DNS request timed out.
        timeout was 2 seconds.
    DNS request timed out.
        timeout was 2 seconds.
    DNS request timed out.
        timeout was 2 seconds.
    DNS request timed out.
        timeout was 2 seconds.
    *** Request to UnKnown timed-out

    from pfsense shell-

    nslookup google.com 1.1.1.1
    ;; connection timed out; no servers could be reached


  • Netgate Administrator

    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 tables

    Internet:
    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        lo0

    Internet6:
    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.


  • Netgate Administrator

    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.com

    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.



  • @ddg00101:

    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.



  • @Tantamount:

    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).