# Two Pi-hole instances, One with "failed to send..."

**URL:** <https://discourse.pi-hole.net/t/two-pi-hole-instances-one-with-failed-to-send/75057>\
**Category:** Beta 6.0\
**Created:** [January 9, 2025, 10:49am UTC](https://discourse.pi-hole.net/t/two-pi-hole-instances-one-with-failed-to-send/75057 "2025-01-09T10:49:59Z")\
**Posts on this page:** 11\
**Page:** 3

<div class="post-metadata">

**Author:** ![Bucking\_Horn](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/bucking_horn/32/18719_2.png) [@Bucking\_Horn](https://discourse.pi-hole.net/u/Bucking_Horn)\
**Post date:** [February 7, 2025, 11:25am UTC](https://discourse.pi-hole.net/t/two-pi-hole-instances-one-with-failed-to-send/75057/41 "2025-02-07T11:25:35Z")

</div>

Yes, cleaning the logs seems like a good idea.

```auto
sudo systemctl stop unbound
sudo rm /var/log/unbound/unbound.log
sudo touch /var/log/unbound/unbound.log
sudo chown unbound /var/log/unbound/unbound.log
sudo unbound-checkconf /etc/unbound/unbound.conf.d/pi-hole.conf
sudo systemctl start unbound

```

---

<div class="post-metadata">

**Author:** ![seh2000](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/seh2000/32/45392_2.png) [@seh2000](https://discourse.pi-hole.net/u/seh2000)\
**Post date:** [February 7, 2025, 12:40pm UTC](https://discourse.pi-hole.net/t/two-pi-hole-instances-one-with-failed-to-send/75057/42 "2025-02-07T12:40:31Z")

</div>

Thanks 🙂 and done...

---

<div class="post-metadata">

**Author:** ![seh2000](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/seh2000/32/45392_2.png) [@seh2000](https://discourse.pi-hole.net/u/seh2000)\
**Post date:** [February 7, 2025, 4:41pm UTC](https://discourse.pi-hole.net/t/two-pi-hole-instances-one-with-failed-to-send/75057/43 "2025-02-07T16:41:11Z")

</div>

Hi again...

Had a go again 🙂

Deleted and created a new Unbound.log file as Bucking\_Horn suggested.

Three log files and one pcap file uploaded to same location as yesterday.

There are several incidents in pihole.log and FTL.log, I tried to use same time stamps in the unbound.log, but as before I am not sure what to look for. Each request in the unbound.log got many many entries with same time stamp like thousands...

Hope the pcap file is ok, got the message `The capture file appears to have been cut short in the middle of a packet` and for some reason the capturing is only between 15:19 and 16:25. However, there are incidents inside that timeframe so I hope it is OK.  
Warm Regards - Steen

---

<div class="post-metadata">

**Author:** ![DL6ER](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/dl6er/32/281_2.png) [@DL6ER](https://discourse.pi-hole.net/u/DL6ER)\
**Post date:** [February 7, 2025, 6:48pm UTC](https://discourse.pi-hole.net/t/two-pi-hole-instances-one-with-failed-to-send/75057/44 "2025-02-07T18:48:59Z")

</div>

Okay, we got something now.

```auto
Feb 7 13:14:46 dnsmasq[3013]: query[A] sync.opera.com from 192.168.1.40
Feb 7 13:14:46 dnsmasq[3013]: cached-stale sync.opera.com is <CNAME>
Feb 7 13:14:46 dnsmasq[3014]: query[HTTPS] sync.opera.com from 192.168.1.40
Feb 7 13:14:46 dnsmasq[3013]: cached-stale nl.sync.opera.com is 185.26.182.111
Feb 7 13:14:46 dnsmasq[3014]: cached-stale sync.opera.com is <CNAME>
Feb 7 13:14:46 dnsmasq[3013]: cached-stale nl.sync.opera.com is 185.26.182.112
Feb 7 13:14:46 dnsmasq[3014]: cached nl.sync.opera.com is NODATA
Feb 7 13:14:47 dnsmasq[3014]: forwarded sync.opera.com to 127.0.0.1#5335
Feb 7 13:14:47 dnsmasq[3014]: dnssec-query[DS] opera.com to 127.0.0.1#5335
Feb 7 13:14:47 dnsmasq[3014]: reply opera.com is no DS
Feb 7 13:14:47 dnsmasq[3014]: validation result is INSECURE
Feb 7 13:14:47 dnsmasq[3014]: reply sync.opera.com is <CNAME>
Feb 7 13:14:47 dnsmasq[3014]: reply sync.geo.opera.com is <CNAME>
Feb 7 13:14:47 dnsmasq[3014]: reply nl.sync.opera.com is NODATA
Feb 7 13:14:47 dnsmasq[3013]: Failed at receiving length, data_sent: true
Feb 7 13:14:47 dnsmasq[3013]: failed to send TCP(read_write) packet: Connection prematurely closed by remote server

```

and, indeed `unbound` never sent the reply to the `A` query downstream:

```auto
Feb 07 13:14:46 unbound[1989:0] info: 127.0.0.1 sync.opera.com. HTTPS IN

...

Feb 07 13:14:46 unbound[1989:0] info: 127.0.0.1 sync.opera.com. A IN

...

Feb 07 13:14:47 unbound[1989:0] info: subnetcache operate: query sync.opera.com. HTTPS IN
Feb 07 13:14:47 unbound[1989:0] debug: reply has edns subnet (null)
Feb 07 13:14:47 unbound[1989:0] debug: mesh_run: subnetcache module exit state is module_finished
Feb 07 13:14:47 unbound[1989:0] debug: comm point stop listening 12
Feb 07 13:14:47 unbound[1989:0] debug: comm point start listening 12 (200 msec)
Feb 07 13:14:47 unbound[1989:0] debug: startlistening 12 mode w
Feb 07 13:14:47 unbound[1989:0] debug: query took 0.165177 sec
Feb 07 13:14:47 unbound[1989:0] info: 127.0.0.1 sync.opera.com. HTTPS IN NOERROR 0.165177 0 135
Feb 07 13:14:47 unbound[1989:0] info: mesh_run: end 1 recursion states (1 with reply, 0 detached), 1 waiting replies, 1240 recursion replies sent, 0 replies dropped, 0 states jostled out

...

Feb 07 13:14:47 unbound[1989:0] info: subnetcache operate: query sync.opera.com. A IN
Feb 07 13:14:47 unbound[1989:0] debug: reply has edns subnet (null)
Feb 07 13:14:47 unbound[1989:0] debug: mesh_run: subnetcache module exit state is module_finished
Feb 07 13:14:47 unbound[1989:0] info: mesh_run: end 0 recursion states (0 with reply, 0 detached), 0 waiting replies, 1241 recursion replies sent, 0 replies dropped, 0 states jostled out

```

just before the last four lines, we see that the cache is populated with

```auto
Feb 07 13:14:47 unbound[1989:0] info: chased extract ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
;; flags: qr ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
sync.opera.com.	IN	A

;; ANSWER SECTION:
sync.opera.com.	60	IN	CNAME	sync.geo.opera.com.

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:
;; MSG SIZE rcvd: 55

Feb 07 13:14:47 unbound[1989:0] info: chased extract ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
;; flags: qr ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
sync.geo.opera.com.	IN	A

;; ANSWER SECTION:
sync.geo.opera.com.	120	IN	CNAME	nl.sync.opera.com.

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:
;; MSG SIZE rcvd: 58

Feb 07 13:14:47 unbound[1989:0] info: chased extract ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
;; flags: qr ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
nl.sync.opera.com.	IN	A

;; ANSWER SECTION:
nl.sync.opera.com.	60	IN	A	185.26.182.112
nl.sync.opera.com.	60	IN	A	185.26.182.111

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:
;; MSG SIZE rcvd: 67

```

so `unbound` indeed **has** the necessary data to respond to your query.

This brings me to the final conclusion that is really an `unbound` bug. Despite being asked to resolve `query sync.opera.com. A IN` and having performed all the necessary steps and recursions, it falsely concludes the chain with "0 waiting replies", and, hence, does not think it has to reply.

Case closed, I'd say. This bug would need to be reported to `unbound` but I am not familiar with their forums/procedures. I guess everything they'd need can be found in this message I am just writing.

---

<div class="post-metadata">

**Author:** ![seh2000](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/seh2000/32/45392_2.png) [@seh2000](https://discourse.pi-hole.net/u/seh2000)\
**Post date:** [February 7, 2025, 7:12pm UTC](https://discourse.pi-hole.net/t/two-pi-hole-instances-one-with-failed-to-send/75057/45 "2025-02-07T19:12:16Z")

</div>

Hi DL6ER,  
Many thanks for all your efforts, investigations, very good explanations and suggestions!!!  
I'll - just for the "fun" - start to use a couple of other browsers just to see if same would pop-up or I have tell the house not to use Opera 🙂  
I am also not sure how to report to Unbound, might poke a bit around their forum...  
You have a great Friday and a lovely weekend!  
Steen

---

<div class="post-metadata">

**Author:** ![chrislph](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/chrislph/32/32723_2.png) [@chrislph](https://discourse.pi-hole.net/u/chrislph)\
**Post date:** [February 8, 2025, 4:16am UTC](https://discourse.pi-hole.net/t/two-pi-hole-instances-one-with-failed-to-send/75057/46 "2025-02-08T04:16:12Z")

</div>

It looks like you [open an Issue](https://github.com/NLnetLabs/unbound/issues) on their GitHub, and I guess include background and link back to DL6ER's post here for details.

---

<div class="post-metadata">

**Author:** ![seh2000](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/seh2000/32/45392_2.png) [@seh2000](https://discourse.pi-hole.net/u/seh2000)\
**Post date:** [February 8, 2025, 11:43am UTC](https://discourse.pi-hole.net/t/two-pi-hole-instances-one-with-failed-to-send/75057/47 "2025-02-08T11:43:13Z")

</div>

Hi,  
I might not be the best to do, but I'll try.  
Thanks for the hint!

---

<div class="post-metadata">

**Author:** ![DL6ER](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/dl6er/32/281_2.png) [@DL6ER](https://discourse.pi-hole.net/u/DL6ER)\
**Post date:** [February 8, 2025, 7:47pm UTC](https://discourse.pi-hole.net/t/two-pi-hole-instances-one-with-failed-to-send/75057/48 "2025-02-08T19:47:48Z")

</div>

> <https://github.com/NLnetLabs/unbound/issues/1237>
>
> Hi,
> My first try to report an issue here.
> I am having a couple of Raspberry Pi r…unning Pi-hole and is using Unbound as a recursive DNS server.
> 
> I and others have seen this message \`WARNING Connection error (127.0.0.1#5335): failed to send TCP(read\_write) packet (Connection prematurely closed by remote server)\` in the Pi-holes FTL.log, but often just disregarded this. 
> However, a few weeks ago I started a discussion around this at Pi-holes Beta 6 forum. Which lead to a deeper investigation by the people behind Pi-hole and my self (let me just say that I am not a software/developer person).
> 
> Yesterday one of the developer concluded this must most likely be an Unbound bug, here the link to the message https://discourse.pi-hole.net/t/two-pi-hole-instances-one-with-failed-to-send/75057/44?u=seh2000.
> 
> Unfortunately the log files especial the unbound.log are rather large, however in the link above there are extracts from different log files. 
> 
> Kind regards - Steen
> 
> \*\*System:\*\*
> - Unbound version: 1.17.1
> 
> - OS: 
> Distributor ID: Debian
> Description: Debian GNU/Linux 12 (bookworm)
> Release: 12
> Codename: bookworm
> Kernel: Linux 6.6.74+rpt-rpi-v8
> Architecture: arm64
> - HW: Raspberry Pi 4 Model B Rev 1.5
>  
> - \`unbound -V\` output:
> Version 1.17.1
> Configure line: --build=aarch64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=${prefix}/lib/aarch64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --with-pythonmodule --with-pyunbound --enable-subnet --enable-dnstap --enable-systemd --with-libnghttp2 --with-chroot-dir= --with-dnstap-socket-path=/run/dnstap.sock --disable-rpath --with-pidfile=/run/unbound.pid --with-libevent --enable-tfo-client --with-rootkey-file=/usr/share/dns/root.key --disable-flto --enable-tfo-server
> Linked libs: libevent 2.1.12-stable (it uses epoll), OpenSSL 3.0.15 3 Sep 2024
> Linked modules: dns64 python subnetcache respip validator iterator
> TCP Fastopen feature available
> BSD licensed, see LICENSE in source package for details.
> Report bugs to unbound-bugs@nlnetlabs.nl or https://github.com/NLnetLabs/unbound/issues
> 
> \- unbound conf:
> admin@Pi4-1:~ $ 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/remote-control.conf:remote-control:
> /etc/unbound/unbound.conf.d/remote-control.conf: control-enable: yes
> /etc/unbound/unbound.conf.d/remote-control.conf: control-interface: /run/unbound.ctl
> /etc/unbound/unbound.conf.d/pi-hole.conf:server:
> /etc/unbound/unbound.conf.d/pi-hole.conf: logfile: "/var/log/unbound/unbound.log"
> /etc/unbound/unbound.conf.d/pi-hole.conf: log-time-ascii: yes
> /etc/unbound/unbound.conf.d/pi-hole.conf: log-queries: yes
> /etc/unbound/unbound.conf.d/pi-hole.conf: log-replies: yes
> /etc/unbound/unbound.conf.d/pi-hole.conf: verbosity: 5
> /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: no
> /etc/unbound/unbound.conf.d/pi-hole.conf: prefer-ip6: no
> /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
> 
> 
> \*\*Additional information\*\*

---

<div class="post-metadata">

**Author:** ![seh2000](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/seh2000/32/45392_2.png) [@seh2000](https://discourse.pi-hole.net/u/seh2000)\
**Post date:** [February 8, 2025, 7:52pm UTC](https://discourse.pi-hole.net/t/two-pi-hole-instances-one-with-failed-to-send/75057/49 "2025-02-08T19:52:54Z")

</div>

please update anything I wrote as it is most likely not the best bug report.

---

<div class="post-metadata">

**Author:** ![seh2000](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/seh2000/32/45392_2.png) [@seh2000](https://discourse.pi-hole.net/u/seh2000)\
**Post date:** [February 10, 2025, 3:41pm UTC](https://discourse.pi-hole.net/t/two-pi-hole-instances-one-with-failed-to-send/75057/50 "2025-02-10T15:41:48Z")

</div>

Hi,  
I got a long response at the Unbound forum. Unfortunately several of the questions - I can't with my limited knowledge - answer.  
Perhaps if you or one of the others could assist me with answers?

```auto
I dont have the complete log to see what is happening but my initial thoughts is why does Unbound get TCP queries in the first place?

If this is not the environments configuration (everything over TCP), maybe only select queries are strictly over TCP, like the one from opera I see in the forum? But then the amount of said TCP traffic still pushes Unbound near its configured limits?

Also, I see that this is mostly dnsmasq talking to Unbound?

Maybe dnsmasq can be configured to send multiple queries over a single TCP connection?

```

They also suggest to bump `incoming-number-tcp` and see how it goes.

> <https://github.com/NLnetLabs/unbound/issues/1237#issuecomment-2648162871>
>
> Hi,
> My first try to report an issue here.
> I am having a couple of Raspberry Pi r…unning Pi-hole and is using Unbound as a recursive DNS server.
> 
> I and others have seen this message \`WARNING Connection error (127.0.0.1#5335): failed to send TCP(read\_write) packet (Connection prematurely closed by remote server)\` in the Pi-holes FTL.log, but often just disregarded this. 
> However, a few weeks ago I started a discussion around this at Pi-holes Beta 6 forum. Which lead to a deeper investigation by the people behind Pi-hole and my self (let me just say that I am not a software/developer person).
> 
> Yesterday one of the developer concluded this must most likely be an Unbound bug, here the link to the message https://discourse.pi-hole.net/t/two-pi-hole-instances-one-with-failed-to-send/75057/44?u=seh2000.
> 
> Unfortunately the log files especial the unbound.log are rather large, however in the link above there are extracts from different log files. 
> 
> Kind regards - Steen
> 
> \*\*System:\*\*
> - Unbound version: 1.17.1
> 
> - OS: 
> Distributor ID: Debian
> Description: Debian GNU/Linux 12 (bookworm)
> Release: 12
> Codename: bookworm
> Kernel: Linux 6.6.74+rpt-rpi-v8
> Architecture: arm64
> - HW: Raspberry Pi 4 Model B Rev 1.5
>  
> - \`unbound -V\` output:
> Version 1.17.1
> Configure line: --build=aarch64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=${prefix}/lib/aarch64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --with-pythonmodule --with-pyunbound --enable-subnet --enable-dnstap --enable-systemd --with-libnghttp2 --with-chroot-dir= --with-dnstap-socket-path=/run/dnstap.sock --disable-rpath --with-pidfile=/run/unbound.pid --with-libevent --enable-tfo-client --with-rootkey-file=/usr/share/dns/root.key --disable-flto --enable-tfo-server
> Linked libs: libevent 2.1.12-stable (it uses epoll), OpenSSL 3.0.15 3 Sep 2024
> Linked modules: dns64 python subnetcache respip validator iterator
> TCP Fastopen feature available
> BSD licensed, see LICENSE in source package for details.
> Report bugs to unbound-bugs@nlnetlabs.nl or https://github.com/NLnetLabs/unbound/issues
> 
> \- unbound conf:
> admin@Pi4-1:~ $ 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/remote-control.conf:remote-control:
> /etc/unbound/unbound.conf.d/remote-control.conf: control-enable: yes
> /etc/unbound/unbound.conf.d/remote-control.conf: control-interface: /run/unbound.ctl
> /etc/unbound/unbound.conf.d/pi-hole.conf:server:
> /etc/unbound/unbound.conf.d/pi-hole.conf: logfile: "/var/log/unbound/unbound.log"
> /etc/unbound/unbound.conf.d/pi-hole.conf: log-time-ascii: yes
> /etc/unbound/unbound.conf.d/pi-hole.conf: log-queries: yes
> /etc/unbound/unbound.conf.d/pi-hole.conf: log-replies: yes
> /etc/unbound/unbound.conf.d/pi-hole.conf: verbosity: 5
> /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: no
> /etc/unbound/unbound.conf.d/pi-hole.conf: prefer-ip6: no
> /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
> 
> 
> \*\*Additional information\*\*

---

<div class="post-metadata">

**Author:** ![DL6ER](https://discourse-cdn.pi-hole.net/user_avatar/discourse.pi-hole.net/dl6er/32/281_2.png) [@DL6ER](https://discourse.pi-hole.net/u/DL6ER)\
**Post date:** [February 11, 2025, 4:58pm UTC](https://discourse.pi-hole.net/t/two-pi-hole-instances-one-with-failed-to-send/75057/51 "2025-02-11T16:58:53Z")

</div>

Sorry, I haven't been able to answer before but I see you are already quite well discussing (and progressing?) with them.

[Previous page](https://discourse.pi-hole.net/t/two-pi-hole-instances-one-with-failed-to-send/75057.md?page=2)