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

    Unbound/DNS resolver with IPv6 unreliable finally solved

    Scheduled Pinned Locked Moved IPv6
    21 Posts 4 Posters 2.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.
    • GertjanG
      Gertjan @strandte
      last edited by

      @strandte

      allow_ or allow_snoop, thats one thing.
      But what does is mean :

      access-control: ::1 allow_snoop
      access-control: ::1/128 allow

      as ::1 and ::1/128 are the same for me.
      So, allow_snoop gets set on ::1 and then overridden by 'allow' ?

      Here you can see how the access_lists.conf file gets created :
      /etc/inc/unbound.inc

      First, "127.0.0.1/32 allow_snoop" gets thrown in and then "::1 allow_snoop".
      You and I don't chose the 'allowed_snoop' from the GUI here, it's hard coded.

      Then, all your local known interfaces, and this includes
      127.0.0.0/8 allow
      and
      ::1/128 allow

      and as said : these are the same for me.

      Note that the 'allow' here is the one I set up here :

      f98bcfaf-53c5-4af3-8011-0db92ef32d97-image.png

      I wonder what happens if I delete these two lines :

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

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

      tinfoilmattT 1 Reply Last reply Reply Quote 0
      • S
        strandte
        last edited by

        It is possible to configure manually the "Allow_snoop", by choosing "Allow_snoop" under "Action" in the web gui of unbound under "Access Lists". The sequence of rules shown in the lower part of that web page are the same as the sequence of the rules in the access_lists.conf file. I'm currently testing to see if putting the snoop rule first or last has any influence on the end result, but so far I can't say that it seems to have any effect.
        What I see is that after doing a change in the configuration the resolver will work for some minutes more, then be unresponsive for some minutes and then come back. I wonder if it is pfBlockers large DNSBL lists which need to be loaded before unbound can take care of resolving again?
        After this down period of some minutes it again seems to be stable no matter if the snoop is first or last. The only thing I'm not able to reproduce is to make the rule in access_lists.conf 100% similar to the auto created rule:

        Auto created it looks like this:

        access-control: ::1 allow_snoop

        but when I manually create it I can't make it in any other way than this (mask needs to be selected, and if you do not select it will be auto created):

        access-control: ::1/128 allow_snoop

        I guess that should be the same, if it isn't a bug which makes trouble for the auto rule?

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

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

          It is possible to configure manually the "Allow_snoop", by choosing "Allow_snoop" u

          Noop.

          I selected some random "Refuse Nonlocal" :

          f5c02c50-025e-4dd8-97e2-b2ed86b11634-image.png

          this creates :

          access-control: 127.0.0.1/32 allow_snoop
          access-control: ::1 allow_snoop
          access-control: 127.0.0.0/8 allow 
          access-control: 192.168.1.0/24 allow 
          access-control: 192.168.2.0/24 allow 
          access-control: 192.168.3.0/24 allow 
          access-control: 192.168.100.0/24 allow 
          access-control: 2a01:dead:beef:a6e2::/64 allow 
          access-control: ::1/128 allow 
          #Local
          access-control: fc00::/7 refuse_non_local
          access-control: fe80::/64 refuse_non_local
          access-control: 10.0.0.0/24 refuse_non_local
          access-control: ::ffff:0:0/96 refuse_non_local
          access-control: 192.168.4.0/24 refuse_non_local
          access-control: 192.168.3.0/24 refuse_non_local
          access-control: 2a01:dead:beef:a6e2::/64 refuse_non_local
          

          so everything before
          #Local
          didn't change.

          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

            Are you sure you have disabled the auto rules?
            Services_ DNS Resolver_ Advanced Settings.png
            The access_lists.conf does not look like that in my case with auto rules disabled.

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

              @strandte

              When I check this :

              7f6060c6-b713-4733-8fd0-66da303b4378-image.png

              ( which I don't have checked right now )

              I have to create my own access list .... so more chances to f##k up.
              I'm a "leave it to default" guy 😊

              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
              • tinfoilmattT
                tinfoilmatt @Gertjan
                last edited by tinfoilmatt

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

                GertjanG 1 Reply Last reply Reply Quote 0
                • S
                  strandte
                  last edited by

                  This post is deleted!
                  1 Reply Last reply Reply Quote 0
                  • GertjanG
                    Gertjan @tinfoilmatt
                    last edited by

                    @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 ??

                    tinfoilmattT 1 Reply Last reply Reply Quote 0
                    • S
                      strandte
                      last edited by

                      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

                        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?

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

                          @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

                            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.

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

                              @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
                              • w0wW
                                w0w
                                last edited by w0w

                                @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
                                • tinfoilmattT
                                  tinfoilmatt @Gertjan
                                  last edited by

                                  @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
                                  • First post
                                    Last post
                                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.