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

Unbound/DNS resolver with IPv6 unreliable finally solved

IPv6
4
21
1.3k
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.
  • T
    tinfoilmatt @Gertjan
    last edited by tinfoilmatt 30 days ago Apr 11, 2025, 5:22 PM

    @Gertjan said in Unbound/DNS resolver with IPv6 unreliable finally solved:

    I wonder what happens if I delete these two lines :

    a9c12224-4af3-4fde-8015-2265b6b91de5-image.png

    I would delete ::1/128 allow, and add the /128 CIDR notation to the ::1 allow_snoop entry manually—and leave 127.0.0.1/32 allow_snoop as is.

    But I agree that neither may be necessary as my auto-generated /var/unbound/access_lists.conf contains only the ACLs I've defined via the webGUI. No loopback addresses are present.

    G 1 Reply Last reply Apr 14, 2025, 6:53 AM Reply Quote 0
    • S
      strandte
      last edited by Apr 14, 2025, 6:48 AM

      This post is deleted!
      1 Reply Last reply Reply Quote 0
      • G
        Gertjan @tinfoilmatt
        last edited by Apr 14, 2025, 6:53 AM

        @tinfoilmatt said in Unbound/DNS resolver with IPv6 unreliable finally solved:

        127.0.0.1/128

        Isn't that a 'syntax error' ?
        127.0.0.1/32 is as far as it goes.

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

        T 1 Reply Last reply 30 days ago Reply Quote 0
        • S
          strandte
          last edited by Apr 14, 2025, 6:57 AM

          I tried to add the:

          access-control: ::1/128 allow_snoop

          to my manual access list over the weekend. The result was that both the primary and the secondary firewall had a unresponcive unbond service on sunday. Today I have removed the access rule above. We will see how this goes.

          Does anybody know what this rule is for?

          1 Reply Last reply Reply Quote 0
          • S
            strandte
            last edited by Apr 14, 2025, 7:04 AM

            Yes, 127.0.0.1/128 is wrong, and 127.0.0.1/32 is correct, but I see that the auto rule allow 127.0.0.0/8. Is that necessary? In case it is which other IP addresses in the 127.0.0.0/8 are in use?

            G 1 Reply Last reply Apr 14, 2025, 7:17 AM Reply Quote 0
            • G
              Gertjan @strandte
              last edited by Apr 14, 2025, 7:17 AM

              @strandte said in Unbound/DNS resolver with IPv6 unreliable finally solved:

              but I see that the auto rule allow 127.0.0.0/8. Is that necessary? In case it is which other IP addresses in the 127.0.0.0/8 are in use?

              127.0.0/8 is a bit large, true.

              Execute for example

              sockstat -4 | grep '127'
              

              to see who is using 127.a.b.c

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

              1 Reply Last reply Reply Quote 0
              • S
                strandte
                last edited by Apr 14, 2025, 9:20 AM

                I can't see any othe address in the 127.0.0.0/8 used other than 127.0.0.1, so I would assume it would be ok to change out 127.0.0.0/8 with 127.0.0.1/32.

                G 1 Reply Last reply Apr 14, 2025, 9:37 AM Reply Quote 0
                • G
                  Gertjan @strandte
                  last edited by Apr 14, 2025, 9:37 AM

                  @strandte

                  Sure.
                  Will it make any difference ?
                  Not sure.

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

                  1 Reply Last reply Reply Quote 0
                  • W
                    w0w
                    last edited by w0w Apr 14, 2025, 12:20 PM Apr 14, 2025, 10:14 AM

                    @strandte said in Unbound/DNS resolver with IPv6 unreliable finally solved:

                    After I setup monitoring I found out that the DNS resolver on the pfSense boxes often stopped for a while and then automatically started to respond to queries again, and that the problem seemed to be more pronounced for resolving via the IPv6 addresses of the pfSense boxes. Often the unbound stopped responding to queries done via the IPv6 address, but still responded to queries done via the IPv4 address. After a while both became unresponsive. When this was the case restarting the service made it respond to queries again, but I think it might also would have started again at some time if I had not done anything. When the service had stopped this would not be the case of cause.

                    I honestly don't think that the unbound control settings are related to this issue. Unless access control for unbound simply prevents its endless restarts and refreshes, which, in turn, solves one problem but clearly causes a thousand others. In fact, unbound was rock-stable for me on 24.11 and earlier. But it "broke" on the 23.05 beta because pfSense suddenly decided that now, every time it receives configuration packets (RA info) from the ISP, it needs to refresh and update all related settings, including unbound, even if no changes are detected in those settings received. When I started digging into this issue, I was surprised to see just how many requests there were to stop and restart the service — sometimes ending with it stopping and not starting again. Ideally, with proper Python module integration, everything should be much more stable, but sometimes it is not.

                    1 Reply Last reply Reply Quote 0
                    • T
                      tinfoilmatt @Gertjan
                      last edited by 30 days ago

                      @Gertjan said in Unbound/DNS resolver with IPv6 unreliable finally solved:

                      Isn't that a 'syntax error' ?

                      Yes, typo. Post edited. Thanks for pointing out.

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