Loop in setup. How to remove it?

Please follow the below template, it will help us to help you!

If you are Experiencing issues with a Pi-hole install that has non-standard elements (e.g you are using nginx instead of lighttpd, or there is some other aspect of your install that is customised) - please use the Community Help category.

Expected Behaviour:

I have my pi hole generating excess queries from *.0.0.0.10.in-addr.arpa , app-measurement.com/sdk-exp. I googled, of course. Disabled DNSSEC, Conditional forwarding, but I still get hit over by rate limited. In a normal enough network, it should never have happened.
Screen Shot 2022-03-07 at 7.03.41 AM

Apple devices on network : Macbook, 2 ipads. No printers or other bonjour devices.
-Raspbian 32-bit lite
-unbound, pretty much vanilla config file.
-Raspberry Pi 2 v1.1

Actual Behaviour:

As above, those query numbers are in 3-4 days. I get that based on number of devices, either I have to increase rate limit or there is a loop in resolving DNS requests. I followed this post and got to know pi hole is forwarding DNS again to my router, which I assume is forwarding again to pi hole. Known from running this: grep -n "New upstream" /var/log/pihole-FTL.log
output:

 98:[2022-03-07 06:47:28.679 12365M] New upstream server: 127.0.0.1:5335 (0/256)
99:[2022-03-07 06:47:28.682 12365M] New upstream server: 10.0.0.1:53 (1/256)
250:[2022-03-07 06:50:39.299 12595M] New upstream server: 127.0.0.1:5335 (0/256)
251:[2022-03-07 06:50:39.302 12595M] New upstream server: 10.0.0.1:53 (1/256)
402:[2022-03-07 06:56:43.485 552M] New upstream server: 127.0.0.1:5335 (0/256)
403:[2022-03-07 06:56:43.487 552M] New upstream server: 10.0.0.1:53 (1/256)

Its been a year old, don't know if its still valid. Of course I restarted DNS resolver and rebooted pi too.

Debug Token:

https://tricorder.pi-hole.net/0VeLsGPJ/

Yes, I need to know how to remove the loop.

Your router is distributing its own IP for DNS, and not the IP of Pi-hole:

** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   Timeout: 10 seconds
   
   * Received 300 bytes from eth0:10.0.0.1
     Offered IP address: 10.0.0.100
     Server IP address: N/A
     Relay-agent IP address: N/A
     BOOTP server: (empty)
     BOOTP file: (empty)
     DHCP options:
      Message type: DHCPOFFER (2)
      server-identifier: 10.0.0.1
      lease-time: 86400 ( 1d )
      netmask: 255.255.255.0
      router: 10.0.0.1
      dns-server: 10.0.0.1
      --- end of options ---
    
   DHCP packets received on interface eth0: 1
   DHCP packets received on interface wlan0: 0
   DHCP packets received on interface lo: 0

Pi-hole is at this IP, and this should be in the DHCP settings on the router:

*** [ DIAGNOSING ]: Setup variables
    PIHOLE_INTERFACE=eth0
    IPV4_ADDRESS=10.0.0.100/24

I am sure I set up my router correctly. I even rebooted router and got another debug log, it still shows 10.0.0.1.
I understand router is doing that, but not why. Is this router specific problem? Should I try with another device? The current one is pretty old, Netgear JWNR2010v5.


That would suggest that your screenshot refers to your router's upstream DNS server, while your router continues to distribute its own IP as local DNS server to its clients. Your router may or may not support explicit configuration of the lattter.

Those lines would suggest that your Pi-hole would use your router's IP as its upstream, besides a same-device unbound.

If that would be the case, together with your router using Pi-hole as upstream, that would close the loop.
However, your debug log shows unbound as Pi-hole's only upstream:

*** [ DIAGNOSING ]: Setup variables
    PIHOLE_DNS_1=127.0.0.1#5335
*** [ DIAGNOSING ]: contents of /etc/dnsmasq.d
-rw-r--r-- 1 root root 1.4K Mar  7 06:47 /etc/dnsmasq.d/01-pihole.conf

   server=127.0.0.1#5335

Did you perhaps change your configuration recently, before uploading the log?

No, I didn't change anything. I just rebooted devices to see if solves the problem. And restarted pi-hole's DNS resolver. But here's latest logs. https://tricorder.pi-hole.net/YswLfciP/
I removed all logs just a bit after my last reply, I thought the requests are growing exponentially or something.

Pi-hole using router's IP as upstream DNS other than unbound on same device, Is there no way to stop this from happening? Is this normal and expected behavior? Even after I set it to just use unbound? Should I see if other pi-hole setup with third party DNS providers like openDNS or GoogleDNS behaves similarly? I have a Pi 4 lying around.

I am not against using DNS from given choices, I just wanted to try unbound and think its interesting.

I'm new to all this:
Why is there an asterisk? (*.0.0.0.10.) and why is there a period after 10 and before 0?
Did you put those in the cfg, or is that the output unedited and you are just copying and pasting?

Asterisk as in wild card, as shown in screenshot. There are multiple domains ending with 0.0.0.10.in-addr.arpa. I put this in because this thread may be helpful for others who have similar problems as mine.

I don't understand

a period after 10 and before 0?

Whatever I though was pertinent, I put them in post. And it was mostly template settings anyway.
I copy pasted the raw unedited output. I don't know how people post output otherwise, not sarcastic.

As you are using Bullseye, you may be affected by WARNING: Raspbian October 2021 release bullseye + unbound.
I've only seen this to effect a loop between unbound and Pi-hole so far, but let's check for this nevertheless.

Run from your Pi-hole host machine, what's the output of:

sudo grep -v '#\|^$' -R /etc/unbound/unbound.conf*

Note that Pi-hole's dashboard operates on a rolling time-frame of the last 24 hours.

You defintely have a loop, and that needs to be sorted first.

Depending on the number and chattiness of your devices, you should consider doing something about the rate limit also, either by adjusting it via RATE_LIMIT in pihole-FTL.conf, or by configuring your router to distribute Pi-hole's IPv4 via DHCP instead of using it as your router's upstream (provided your router would support that). If possible, I'd prefer the latter.

From what I have gathered, the problem in that post points out to some kind of conflict between openresolv and resolvconf making functionality of unbound a mess. In this case, forwarding unbound requests to pihole-FTL.

I don't know how the poster looks up number of status 14 - Already forwarded, not forwarding again.
But a loop is present, and I think something similar is happening under the hood.

Here's my /etc/resolvconf.conf file(unchanged).

# Configuration for resolvconf(8)
# See resolvconf.conf(5) for details

resolv_conf=/etc/resolv.conf
# If you run a local name server, you should uncomment the below line and
# configure your subscribers configuration files below.
#name_servers=127.0.0.1


# Mirror the Debian package defaults for the below resolvers
# so that resolvconf integrates seemlessly.
dnsmasq_resolv=/var/run/dnsmasq/resolv.conf
pdnsd_conf=/etc/pdnsd.conf
unbound_conf=/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf

From the unbound documentation unbound - Pi-hole documentation, I haven't changed anything in optional part. I am not as savvy and reading it now I didn't think I touched /etc/dhcpcd.conf. Here's tail end of that file(unchanged).

interface eth0
        static ip_address=10.0.0.100/24
        static routers=10.0.0.1
        static domain_name_servers=

I am sorry I haven't looked deep enough for problems similar to mine. I haven't tried any of the solutions advised on the post WARNING: Raspbian October 2021 release bullseye + unbound. If you don't need any more data, I want to try applying the solution - removing that one conf file and purging openresolv and installing resolvconf. (This is the gist of the thread, right?)

sudo grep -v '#\|^$' -R /etc/unbound/unbound.conf*

/etc/unbound/unbound.conf:include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf:server:
/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf:    auto-trust-anchor-file: "/var/lib/unbound/root.key"
/etc/unbound/unbound.conf.d/pi-hole.conf:server:
/etc/unbound/unbound.conf.d/pi-hole.conf:    verbosity: 0
/etc/unbound/unbound.conf.d/pi-hole.conf:    interface: 127.0.0.1
/etc/unbound/unbound.conf.d/pi-hole.conf:    port: 5335
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-ip4: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-udp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-tcp: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    do-ip6: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    prefer-ip6: no
/etc/unbound/unbound.conf.d/pi-hole.conf:    root-hints: "/var/lib/unbound/root.hints"
/etc/unbound/unbound.conf.d/pi-hole.conf:    harden-glue: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    harden-dnssec-stripped: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    use-caps-for-id: no
/etc/unbound/unbound.conf.d/pi-hole.conf:    edns-buffer-size: 1232
/etc/unbound/unbound.conf.d/pi-hole.conf:    prefetch: yes
/etc/unbound/unbound.conf.d/pi-hole.conf:    num-threads: 1
/etc/unbound/unbound.conf.d/pi-hole.conf:    so-rcvbuf: 1m
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 192.168.0.0/16
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 169.254.0.0/16
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 172.16.0.0/12
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: 10.0.0.0/8
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: fd00::/8
/etc/unbound/unbound.conf.d/pi-hole.conf:    private-address: fe80::/10

I don't think I can config router to distribute pi-hole's IPv4 via DHCP. Its simply too old and feature lacking.

  1. Edit file /etc/resolvconf.conf and comment out the last line which should read:

unbound_conf=/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf

  1. Delete the unwanted unbound configuration file:

sudo rm /etc/unbound/unbound.conf.d/resolvconf_resolvers.conf

  1. Restart unbound:

sudo service unbound restart

At a glance it looked like it worked. But pretty soon, my router's IP was included in DNS list.

78:[2022-03-09 07:43:21.316 526M] New upstream server: 127.0.0.1:5335 (0/256)
190:[2022-03-09 07:42:57.163 543M] New upstream server: 127.0.0.1:5335 (0/256)
313:[2022-03-09 07:51:23.353 3617M] New upstream server: 127.0.0.1:5335 (0/256)
366:[2022-03-09 07:51:30.391 3619M] New upstream server: 10.0.0.1:53 (1/256)
476:[2022-03-09 14:17:18.751 543M] New upstream server: 127.0.0.1:5335 (0/256)
497:[2022-03-09 14:17:22.101 543M] New upstream server: 10.0.0.1:53 (1/256)
642:[2022-03-09 15:17:16.444 543M] New upstream server: 127.0.0.1:5335 (0/256)
662:[2022-03-09 15:17:19.922 543M] New upstream server: 10.0.0.1:53 (1/256)
839:[2022-03-09 17:18:07.933 548M] New upstream server: 127.0.0.1:5335 (0/256)
857:[2022-03-09 17:18:10.916 548M] New upstream server: 10.0.0.1:53 (1/256)
1054:[2022-03-09 17:22:39.345 604M] New upstream server: 127.0.0.1:5335 (0/256)
1072:[2022-03-09 17:22:42.359 604M] New upstream server: 10.0.0.1:53 (1/256)

The 800s was when I edited /etc/resolveconf.conf uncommenting name_servers=127.0.0.1. The 1000s was when I edited /etc/dhcpcd.conf adding static domain_name_servers=127.0.0.1::5335.
Neither solved it.

I installed a fresh copy of raspbian 32 bit lite , installed pihole, and installed unbound. On side note; looks like installing unbound installs dns-root-data always, but not root.hints. I had to config that bit manually. This time, I followed the optional part and disabled unbound-resolvconf.service. This looks like its fine now, but the DNS I used while setting up(openDNS) IPs, still show up.

60:[2022-03-09 21:55:51.124 688M] New upstream server: 208.67.220.220:53 (0/256)
61:[2022-03-09 21:55:51.126 688M] New upstream server: 208.67.222.222:53 (1/256)
62:[2022-03-09 21:55:51.147 688M] New upstream server: 127.0.0.1:5335 (2/256)
172:[2022-03-09 22:17:17.257 15254M] New upstream server: 208.67.220.220:53 (0/256)
173:[2022-03-09 22:17:17.258 15254M] New upstream server: 208.67.222.222:53 (1/256)
174:[2022-03-09 22:17:17.275 15254M] New upstream server: 127.0.0.1:5335 (2/256)
269:[2022-03-09 22:19:15.331 16923M] New upstream server: 208.67.220.220:53 (0/256)
270:[2022-03-09 22:19:15.331 16923M] New upstream server: 208.67.222.222:53 (1/256)
271:[2022-03-09 22:19:15.342 16923M] New upstream server: 127.0.0.1:5335 (2/256)
362:[2022-03-09 22:20:32.819 18456M] New upstream server: 208.67.220.220:53 (0/256)
363:[2022-03-09 22:20:32.820 18456M] New upstream server: 208.67.222.222:53 (1/256)
364:[2022-03-09 22:20:32.831 18456M] New upstream server: 127.0.0.1:5335 (2/256)

I tried to recreate the problem, but I never bothered with optional part. But now it looks like it works. I have to wait a while to rack up query count. I'll update in 12-16 hours to see if I get RATE_LIMIT again.

Update: Looks like problems solved with disabling unbound-resolvconf.service. As I thought, the openDNS IPs went away after a while. After deleting all the queries, I no longer see those IPs under upstream servers in dashboard.

62:[2022-03-10 02:17:14.656 698M] New upstream server: 208.67.220.220:53 (0/256)
63:[2022-03-10 02:17:14.657 698M] New upstream server: 208.67.222.222:53 (1/256)
64:[2022-03-10 02:17:14.668 698M] New upstream server: 127.0.0.1:5335 (2/256)
192:[2022-03-10 04:55:52.725 18463M] New upstream server: 127.0.0.1:5335 (0/256)
271:[2022-03-10 09:53:34.113 13636M] New upstream server: 127.0.0.1:5335 (0/256)

While I think the suggestion of making the optional part in post install steps of unbound mandatory makes sense, I am not developer, nor savvy enough to understand under the hood unbound works with resolvconf.

Problem recreating steps:

  1. Fresh install of 32bit raspbian lite(64bit too?). Update, upgrade.
  2. One line install of pihole. Vanilla config. choose one of available DNS providers for now.
  3. Change upstream DNS on router.
  4. Install unbound. look for root.hints, vanilla config template. yes for IPv6.
  5. Change DNS in web interface.
    wait a while to blow up queries.

debug token: https://tricorder.pi-hole.net/Vizat2AY/

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.