Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    DNS Resolver Log Error sending queries to 1.1.1.1

    Scheduled Pinned Locked Moved DHCP and DNS
    49 Posts 16 Posters 11.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • chudakC
      chudak @bldnightowl
      last edited by

      @bldnightowl

      What's URL to this test page ?

      1 Reply Last reply Reply Quote 0
      • B
        bldnightowl
        last edited by

        "page" is a link in my post above.

        chudakC 2 Replies Last reply Reply Quote 0
        • chudakC
          chudak @bldnightowl
          last edited by

          @bldnightowl

          It was blocked by pfbNG for some reason

          I see that page work for me https://snag.gy/oNvPsI.jpg

          B 1 Reply Last reply Reply Quote 0
          • B
            bldnightowl
            last edited by

            Steve W. had me turn off "Enable DNSSEC" in the resolver, and it works for me now too. But that's not a solution. I'm perplexed -- because in my previous router, I was using DoH (through dnscrypt-proxy) and DNSSEC (through pihole), and that page looked fine. I certainly don't want to give up DNSSEC. If Cloudflare's page is just broken for some reason, ok -- I'd like to undertstand what's going on here. And also the proper way to verify DoT and DNSSEC are working. I can see traffic on port 853 to the external DNS servers, I suppose that's enough? But when I use "dig +dnssec" on a local client (with DNSSEC enabled on the resolver of course), I'm not seeing any of the DNSSEC parts of the response that I used to see.

            1 Reply Last reply Reply Quote 0
            • B
              bldnightowl
              last edited by

              Perplexing is that the following link indicates DNSSEC is working even when it's disabled in the resolver:

              https://dnssec.vs.uni-due.de/

              chudakC 1 Reply Last reply Reply Quote 0
              • GertjanG
                Gertjan
                last edited by

                If I shut down dnssec in the resolver :

                0_1550594166646_a38f524b-b3a0-493e-bfa6-bc444eff89ba-image.png

                the little guy isn't happy anymore :

                0_1550594145491_12a1524e-2b24-4d1c-b162-f45a9000727c-image.png

                Please note that I use the resolver as a resolver. I'm not forwarding anything to anybody.

                No "help me" PM's please. Use the forum, the community will thank you.
                Edit : and where are the logs ??

                B 1 Reply Last reply Reply Quote 0
                • chudakC
                  chudak @bldnightowl
                  last edited by

                  @bldnightowl

                  See comments from this thread https://forum.netgate.com/topic/140545/tcp-error-for-address-xxxx-port-853/4

                  "2nd you have dnssec enabled in forwarding mode - zero reason to do that.. whole thread about it recently where someone put together guide on setting up dns and tls.. When you forwarder to a resolver, if it supports dnssec its already doing it.. So you do not have to click that check box."

                  B 1 Reply Last reply Reply Quote 0
                  • B
                    bldnightowl @Gertjan
                    last edited by

                    @gertjan If you're not forwarding to anybody, I presume that means you're talking directly to the root servers for queries you can't resolve directly? And if so, how are you doing so securely, since "Use SSL/TLS for outgoing DNS Queries to Forwarding Servers" appears to only be for forwarding servers?

                    1 Reply Last reply Reply Quote 0
                    • B
                      bldnightowl @chudak
                      last edited by

                      @chudak Any pointers to the " guide on setting up dns and tls" that thread references?

                      1 Reply Last reply Reply Quote 0
                      • B
                        bldnightowl @chudak
                        last edited by

                        And while I'm seeing DoT working now, that Cloudflare page takes a long time to come back with answers for AS Name, AS Number and the Cloudflare Data Center -- and eventually indicates that it has no connectivity to Cloudflare's IPv6 resolver IP addresses.

                        0_1550596778551_Screen Shot 2019-02-19 at 9.17.01 AM.png

                        1 Reply Last reply Reply Quote 0
                        • chudakC
                          chudak @bldnightowl
                          last edited by

                          @bldnightowl said in DNS Resolver Log Error sending queries to 1.1.1.1:

                          "page" is a link in my post above.

                          Wonder if Quad9 has similar test page ?

                          DerelictD 1 Reply Last reply Reply Quote 0
                          • DerelictD
                            Derelict LAYER 8 Netgate @chudak
                            last edited by

                            @chudak said in DNS Resolver Log Error sending queries to 1.1.1.1:

                            @bldnightowl said in DNS Resolver Log Error sending queries to 1.1.1.1:

                            "page" is a link in my post above.

                            Wonder if Quad9 has similar test page ?

                            No.

                            https://www.quad9.net/faq/#Is_there_a_URL_we_can_check_to_see_if_a_given_domain_is_blocked,_and_what_a_user_might_get_if_they_go_to_a_blocked_site

                            Chattanooga, Tennessee, USA
                            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                            Do Not Chat For Help! NO_WAN_EGRESS(TM)

                            1 Reply Last reply Reply Quote 1
                            • First post
                              Last post
                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.