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

    Major DNS Bug 23.01 with Quad9 on SSL

    Scheduled Pinned Locked Moved General pfSense Questions
    185 Posts 27 Posters 154.4k 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.
    • stephenw10S
      stephenw10 Netgate Administrator
      last edited by

      I would love to see anyone who was hitting this issue repeatedly confirm the ASLR workaround here.

      S J RobbieTTR 4 Replies Last reply Reply Quote 0
      • S
        SwissSteph @stephenw10
        last edited by

        @stephenw10
        I'm testing right now and for the moment it's "OK" .... I just put back my DNS settings like on my 22.05 version (which was working without any problem)

        5bd68f2f-86bd-4fa5-9835-b895cfebdfae-image.png

        I started with two "no-name" pfsense, one for use at home and the other as a backup in case of problems (which can happen when you're new to pfsense).
        ... And now I'm living with a Netgate 8200
        ... And sorry for my bad English...

        S 1 Reply Last reply Reply Quote 0
        • S
          SwissSteph @SwissSteph
          last edited by

          230b80ad-c87a-48f3-92b6-afa60040f2ed-image.png

          I started with two "no-name" pfsense, one for use at home and the other as a backup in case of problems (which can happen when you're new to pfsense).
          ... And now I'm living with a Netgate 8200
          ... And sorry for my bad English...

          GertjanG 1 Reply Last reply Reply Quote 1
          • GertjanG
            Gertjan @SwissSteph
            last edited by Gertjan

            @swisssteph

            Your are forwarding : ok
            and
            using TLS - port 853 ?

            Right ?

            edit :
            I am forwarding to these two over TLS - and most (not all) traffic goes actually over 2620:fe::fe and
            2620:fe::9, the IPv6 counterpart of 9.9.9.9 and 149.112.112.112.
            I did not do the ASLR patch .... I'm still waiting for it to fail 😢
            As sson as I see the fail, I'll go patch, so I'll know what I don't want to see any more.

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

            S 1 Reply Last reply Reply Quote 0
            • S
              SwissSteph @Gertjan
              last edited by

              @gertjan

              YES

              704a9b91-693f-4a84-a04a-73490fcc6c39-image.png

              I started with two "no-name" pfsense, one for use at home and the other as a backup in case of problems (which can happen when you're new to pfsense).
              ... And now I'm living with a Netgate 8200
              ... And sorry for my bad English...

              GertjanG 1 Reply Last reply Reply Quote 1
              • GertjanG
                Gertjan @SwissSteph
                last edited by

                @swisssteph

                Close.
                You mean :

                cc795123-915a-45fc-abd3-fe12b38a423c-image.png

                The "SSL/TLS Listen Port" (your image) is the port unbound uses on the LAN side, so it listens to that port for the DNS requests emitted by the pfSense LAN clients (if you have them, Windows 10 was not capable of doing DNS over TLS, I guess Windwos 11 can do it - didn't check).

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

                S N 2 Replies Last reply Reply Quote 0
                • S
                  SwissSteph @Gertjan
                  last edited by

                  @gertjan Sorry

                  16e4dc1b-336d-47fc-8d38-ac73fffdb0ad-image.png

                  I started with two "no-name" pfsense, one for use at home and the other as a backup in case of problems (which can happen when you're new to pfsense).
                  ... And now I'm living with a Netgate 8200
                  ... And sorry for my bad English...

                  1 Reply Last reply Reply Quote 0
                  • N
                    N0m0fud @Gertjan
                    last edited by

                    @gertjan Windows 11 after a certain version supports DOT and DOH

                    1 Reply Last reply Reply Quote 0
                    • J
                      JonH @stephenw10
                      last edited by

                      @stephenw10 The long waits to resolve have plagued me since upgrade to 23.01-Release with python mode & TLS. For the past week+ I've been using unbound/53 with no problems. I updated unbound as soon as I saw Chris's post. For past 2 days I've been back on python mode/853 and it's working well for me. Currently using localhost w/ fallback to dot1 & quad9. Hope this was the 'fix'.

                      1 Reply Last reply Reply Quote 1
                      • RobbieTTR
                        RobbieTT @stephenw10
                        last edited by RobbieTT

                        @stephenw10 said in Major DNS Bug 23.01 with Quad9 on SSL:

                        I would love to see anyone who was hitting this issue repeatedly confirm the ASLR workaround here.

                        I don't know the syntax to reverse the ASLR command - anyone?

                        I did a crude but repeatable test - hammered a load of name servers, including my pfSense resolver which is pointing at Quad9 using DoT:

                        Before the ASLR hack:

                        1684002538158-2023-05-13-at-19.08.59-before.png

                        After the ASLR hack:

                        1684002587941-2023-05-13-at-19.16.20-after.png

                        • Uncached minimums down from 34ms to 9ms
                        • Uncached maximums down from 663ms to 392ms
                        • Uncached average down from 103ms to 67ms
                        • Uncached SD down from 159ms to 90ms

                        What's not to like?

                        ☕️

                        [NB capturing the random 'pauses' and 'fail to loads' suffered (as described earlier) is much harder to represent]

                        jimpJ 1 Reply Last reply Reply Quote 0
                        • jimpJ
                          jimp Rebel Alliance Developer Netgate @RobbieTT
                          last edited by

                          @robbiett said in Major DNS Bug 23.01 with Quad9 on SSL:

                          @stephenw10 said in Major DNS Bug 23.01 with Quad9 on SSL:

                          I would love to see anyone who was hitting this issue repeatedly confirm the ASLR workaround here.

                          I don't know the syntax to reverse the ASLR command - anyone?

                          # elfctl /usr/local/sbin/unbound
                          File '/usr/local/sbin/unbound' features:
                          noaslr          'Disable ASLR' is unset.
                          [...]
                          # killall -9 unbound
                          # elfctl -e +noaslr /usr/local/sbin/unbound
                          # elfctl /usr/local/sbin/unbound
                          File '/usr/local/sbin/unbound' features:
                          noaslr          'Disable ASLR' is set.
                          [...]
                          # elfctl -e -noaslr /usr/local/sbin/unbound
                          # elfctl /usr/local/sbin/unbound
                          File '/usr/local/sbin/unbound' features:
                          noaslr          'Disable ASLR' is unset.
                          [...]
                          

                          Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                          Need help fast? Netgate Global Support!

                          Do not Chat/PM for help!

                          RobbieTTR 1 Reply Last reply Reply Quote 2
                          • RobbieTTR
                            RobbieTT @jimp
                            last edited by

                            @jimp
                            Thanks Jim 👍

                            1 Reply Last reply Reply Quote 0
                            • RobbieTTR
                              RobbieTT @stephenw10
                              last edited by RobbieTT

                              @stephenw10

                              I should probably add that even with the ASLR unset I still get weird looking results when I attempt an individual DNS Lookup on a domain name that I know hasn't been cached:

                               2023-05-14 at 10.43.36.png

                              If I understand the pfSense diagnostics screen, when the internal DNS resolver has to use forwarding to answer a query I would expect a similar time to answer the query as the fastest responding name server (2629:fe::fe at 7ms in this example) plus the almost negligible processing delay from checking the cache. Yet it actually takes a snooze-worthy 168ms.

                              Why does the DNS resolver take 168ms for a simple forwarded (uncached) query when the forwarder itself has an answer from an upstream provider in just 7ms or, in other words, around 24 times slower than expected?

                              ☕️

                              M 1 Reply Last reply Reply Quote 0
                              • S SteveITS referenced this topic on
                              • M
                                MoonKnight @RobbieTT
                                last edited by MoonKnight

                                @robbiett

                                Have been wondering about the same for some time now. It doesn't make sense

                                733a0b99-efe9-4aed-b945-26c89e5a7e89-image.png

                                And if you do the same lookup just seconds after the first time "The query time" is on 0.
                                Wait 1 minute then back to 60 msec.

                                I have been having this behavior since 23.01 and maybe on 22.05 also .

                                --- 24.11 ---
                                Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz
                                Kingston DDR4 2666MHz 16GB ECC
                                2 x HyperX Fury SSD 120GB (ZFS-mirror)
                                2 x Intel i210 (ports)
                                4 x Intel i350 (ports)

                                RobbieTTR johnpozJ 2 Replies Last reply Reply Quote 0
                                • RobbieTTR
                                  RobbieTT @MoonKnight
                                  last edited by

                                  @moonknight said in Major DNS Bug 23.01 with Quad9 on SSL:

                                  @robbiett
                                  And if you do the same lookup just seconds after first time "The query time" is on 0.
                                  Wait 1 minute then back to 60 msec.

                                  I don't suffer the second part of your observation. Once my query is cached it stays cached until it is removed or reset - it obeys the settings I have given it.

                                  If you stop the resolver for a moment and run the command:

                                  unbound-control -c /var/unbound/unbound.conf dump_cache

                                  ...you can poke around and see what is in your cache.

                                  ☕️

                                  M 1 Reply Last reply Reply Quote 1
                                  • M
                                    MoonKnight @RobbieTT
                                    last edited by

                                    @robbiett
                                    Thanks for the command, I'm going to test I later.
                                    But I did enable "Serve Expired" and now the lookup stays on 0 msec on 2nd lookup of the same domain.

                                    1111cd4b-74dd-446f-a40a-da221adcf7e0-image.png

                                    --- 24.11 ---
                                    Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz
                                    Kingston DDR4 2666MHz 16GB ECC
                                    2 x HyperX Fury SSD 120GB (ZFS-mirror)
                                    2 x Intel i210 (ports)
                                    4 x Intel i350 (ports)

                                    1 Reply Last reply Reply Quote 0
                                    • johnpozJ
                                      johnpoz LAYER 8 Global Moderator @MoonKnight
                                      last edited by

                                      @moonknight problem with cnn.com is they have the TTL set to 60 seconds..

                                      ;; QUESTION SECTION:
                                      ;cnn.com.                       IN      A
                                      
                                      ;; ANSWER SECTION:
                                      cnn.com.                60      IN      A       151.101.67.5
                                      cnn.com.                60      IN      A       151.101.195.5
                                      cnn.com.                60      IN      A       151.101.131.5
                                      cnn.com.                60      IN      A       151.101.3.5
                                      

                                      So if you forward to somewhere the ttl you can cache is going to be something shorter then 60 seconds, could be 59, could be 2..

                                      There is no sane reason for them to have the ttl set so freaking low - other than they want lots of queries.. They charge their customers maybe by queries - that is hosted on aws dns..

                                      ;; AUTHORITY SECTION:
                                      cnn.com.                3600    IN      NS      ns-1086.awsdns-07.org.
                                      cnn.com.                3600    IN      NS      ns-1630.awsdns-11.co.uk.
                                      cnn.com.                3600    IN      NS      ns-47.awsdns-05.com.
                                      cnn.com.                3600    IN      NS      ns-576.awsdns-08.net.
                                      

                                      So what you can do on your side is yeah allow for serving expired, and you could also set your min ttl.. I do both, have min ttl of 3600, and serve expired..

                                      An intelligent man is sometimes forced to be drunk to spend time with his fools
                                      If you get confused: Listen to the Music Play
                                      Please don't Chat/PM me for help, unless mod related
                                      SG-4860 24.11 | Lab VMs 2.7.2, 24.11

                                      M 1 Reply Last reply Reply Quote 2
                                      • M
                                        MoonKnight @johnpoz
                                        last edited by MoonKnight

                                        @johnpoz

                                        Thanks for the information :)
                                        I set "Minimum TTL for RRsets and Messages" to 3600 and seems to work :)

                                        --- 24.11 ---
                                        Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz
                                        Kingston DDR4 2666MHz 16GB ECC
                                        2 x HyperX Fury SSD 120GB (ZFS-mirror)
                                        2 x Intel i210 (ports)
                                        4 x Intel i350 (ports)

                                        RobbieTTR 1 Reply Last reply Reply Quote 0
                                        • RobbieTTR
                                          RobbieTT @MoonKnight
                                          last edited by

                                          @moonknight
                                          Yep, that is the one. I have mine set at 2400 for reasons I read in a technical paper that I have long since forgotten.

                                          M S 2 Replies Last reply Reply Quote 1
                                          • M
                                            MoonKnight @RobbieTT
                                            last edited by

                                            Thank you very much @robbiett :)

                                            --- 24.11 ---
                                            Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz
                                            Kingston DDR4 2666MHz 16GB ECC
                                            2 x HyperX Fury SSD 120GB (ZFS-mirror)
                                            2 x Intel i210 (ports)
                                            4 x Intel i350 (ports)

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