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

    DNS Resolver

    Scheduled Pinned Locked Moved General pfSense Questions
    5 Posts 2 Posters 778 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.
    • G
      Gblenn
      last edited by

      I have set up an Elastic dashboard (pfelk) to visualize pfsense logs for unbound, suricata, firewall and dhcp.
      In the unbound dashboard I end up with a large chunk (22-30%) of all DNS flows being listed as "n.n.n.n.in-addr.arpa". Most of them single IP addresses, but as much as 13% directed towards my failover WAN IP!
      (127.0.0.1>10.3.168.192.in-addr.arpa)

      Where 192.168.3.10 is my "external IP" on the that interface which connected to a 4G router. As it is for failover only, it's defined as Tier 2 and there should not be any traffic going in that direction, except I guess dpinger checking availability ever so often.

      I have pfsense set up as DNS resolver, and what I believe is pretty much default for that part, although for Outgoing NW interfaces only WAN is currently marked (not WAN2).

      First of all, is it normal to have such a high percentage of in-addr.arpa requests?
      And what are all those directed towards the IP-address on failover interface?

      If I change the settings for DNS Resolution behavior under System-General to "Use remote DNS servers, ignore local DNS", I stop getting all these in-addr.arpa. Any benefit/drawback in doing this? Is there some other setting I might have missed?

      Thoughts? Comments?

      stephenw10S 1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator @Gblenn
        last edited by

        @gblenn said in DNS Resolver:

        First of all, is it normal to have such a high percentage of in-addr.arpa requests?

        Likely just IPs with no reverse look up.

        @gblenn said in DNS Resolver:

        And what are all those directed towards the IP-address on failover interface?

        Those look like outbound connections from localhost. So something configured to use a load-balance-gateway group maybe. If those are all DNS queries it could be the firewall itself.
        Do you have DNS servers configured against WAN2 in System > General Setup?
        If you set 'Use remote DNS servers, ignore local DNS' it will only use the servers configured there for the firewall itself.

        Check what is configured and what is responding in Diag > DNS Lookup.

        Steve

        G 1 Reply Last reply Reply Quote 0
        • G
          Gblenn @stephenw10
          last edited by Gblenn

          @stephenw10 said in DNS Resolver:

          @gblenn said in DNS Resolver:

          First of all, is it normal to have such a high percentage of in-addr.arpa requests?

          Likely just IPs with no reverse look up.

          Ok, so you mean that most or all of those requests are triggered by localhost trying to resolve the domain name for each of those IP's? BTW, it's the same 127.0.0.1->n.n.n.n.in-addr.arpa as for the WAN2 requests, and it is quite a large number of IP's though...

          So what are the steps involved here? Is localhost (DNS resolver) showing because something, a device/PC/phone, is making a request as a step one? And under "System > General" I have set default (Use local DNS, fall back to DNS Servers)?
          But what happens if an IP actually does resolve, will this in-addr.arpa still be logged, as the first step perhaps. And then (again) with the resolved domain name but in the form of source of the request and resolved DN, like : 192.168.1.100->www.office.com ??

          I do see a large chunk of the in-addr.arpa requests relating to the company I work for, which will resolve. And there are also a number of internal (LAN) IP's, which also resolve as I have set both DHCP and Static mappings to be registered in the resolver. I would have thought these wouldn't show up like this?

          BTW, when I set up pfelk, I did add the custom option "server: log-queries: yes" under DNS Resolver/General. Is there perhaps a command option that I could use that would allow me to NOT log any in-addr.arpa requests?

          @gblenn said in DNS Resolver:

          And what are all those directed towards the IP-address on failover interface?

          Those look like outbound connections from localhost. So something configured to use a load-balance-gateway group maybe. If those are all DNS queries it could be the firewall itself.
          Do you have DNS servers configured against WAN2 in System > General Setup?
          If you set 'Use remote DNS servers, ignore local DNS' it will only use the servers configured there for the firewall itself.

          Check what is configured and what is responding in Diag > DNS Lookup.

          Steve

          I do have OpenDNS servers listed there, but not specified towards any Gateway (none). And as mentioned I use the resolver, not the forwarder, I thought the settings there didn't matter in that case??
          However, doing a DNS Lookup under diagnostics I do get 127.0.0.1 as the first item, and then the 208.67.222.220 / 222 IP's.
          Here I thought the idea was that in resolver mode, it would contact the authoritative servers and not the one's listed under general... I do not have Forwarding Mode activated.

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            It looks like you have something set that means it's to do a reverse lookup on all IPs. Anything that doesn't resolve is shown in that form which is why you're seeing a whole bunch of 'in-addr.arpa' logs. Yes, if an address has a PTR record then I'd expect it to show a domain there.
            That all seems like its probably a setting in the analyser though and nothing to do with pfSense.

            The output of Diag > DNS Lookup shows all configured DNS servers not just those in use by the system or by clients. That's expected.

            Steve

            G 1 Reply Last reply Reply Quote 0
            • G
              Gblenn @stephenw10
              last edited by

              @stephenw10 said in DNS Resolver:

              It looks like you have something set that means it's to do a reverse lookup on all IPs. Anything that doesn't resolve is shown in that form which is why you're seeing a whole bunch of 'in-addr.arpa' logs.

              I think you are on to something here, "all the IP's"... which do seem to be spread across the world, and made me think of pfBlocker...
              Which in fact seems to be what is behind most of it (could Suricata be the other??). Anyway, I quickly found that two of the IP's which came up 4-5 times in the last 15 minutes, and do not resolve, are on pfBlocker lists, like "pfB_Top_v4"...

              Yes, if an address has a PTR record then I'd expect it to show a domain there.
              Steve

              Interestingly it seems the issue with internal IP's and/or my employers site are no longer there. Not sure what I did but I was going through the settings earlier today and I think had "ignore remote DNS servers" active (under system > general). For sure it's at the default setting now, and I have to go back several hours in the logs to find those IP's in the list as in-addr.arpa...
              Could that setting change have made this difference?

              Anyhow, seem the problem is solved, or at least I have a better understanding now. I do still have to look for a simple way to skip those items in the analyzer...

              The output of Diag > DNS Lookup shows all configured DNS servers not just those in use by the system or by clients. That's expected.

              So I guess I shouldn't worry then... In fact I can of course remove those servers completely on that page and things still work.

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