Issues with WAN failover configuration on Unifi

pschloten · March 27, 2022, 10:13am

Hi,

I am using the latest piHole version in combination with unbound. My network is a Unifi setup with a Unifi LTE failover.

When the USG fails over to the LTE connection I can still ping servers via their IP address (also from the raspi piHole is running on). But unbound does not seem to be able to resolve domains any longer.

Would anybody have an idea what might be causing this? Or how to narrow down the issue? Thanks a lot.

Best
Peter

Bucking_Horn · March 28, 2022, 10:39am

unbound should be indifferent towards those connection details.

Just a guess:
Either your router is not allowing DNS in the same way for wired and LTE, or maybe your LTE provider redirects DNS traffic to its own servers, which would cripple unbound's attempts to recurse through the root servers.

pschloten · March 28, 2022, 5:34pm

Hi, and thanks a lot for the suggestion. Being new to the topic, could you help me with how to test/identify if either of these might be the case?

Thanks a lot
Peter

Bucking_Horn · March 29, 2022, 8:30am

I am not familiar with Unifi equipment, so I can't provdie any guidance for that.

As far as redirection is concerned, that could only be deduced indirectly, e.g. you could verify whether the following nslookup would return 0.0.0.0 when using your LTE connection:

nslookup flurry.com 80.241.218.68

If it does return a set of IP addresses instead, that would mean that the intended DNS server at 80.241.218.68 did not handle the request, suggesting your LTE provider (or something else) redirects DNS traffic to its own DNS servers (this would be common for VPN providers, by the way).

pschloten · April 2, 2022, 10:29am

Thanks a lot for your feedback. I am still in touch with the unifi support as well to see if I can find a solution. I will update this thread once I have some news.

Peter

pschloten · April 15, 2022, 10:49am

After some back and forth with Ubiquity support on this now we came to the point that if I am simply using the Google DNS on my client it all works - both for the main connection and the failover.

If I am using piHole/unbound (which I need for local resolution as well as for filtering) I am running into the issues with the failover. And even after the main connection is restored it typically takes some time for piHole/unbound to properly work again.

Would anybody have any further ideas on this?

Thanks a lot
Peter

Bucking_Horn · April 15, 2022, 10:56am

Could you provide us with a pointer to your discussion in Ubiquity's support forums, so we could know how and what they've already checked for?

Also, what where the results from the command I've suggested in one of my previous posts?

pschloten · April 15, 2022, 11:49am

Hi, and thanks a lot for the swift response.

Regarding the UI support exchange that happened via e-mail. Is there a way to share a file here on the forum? If not I will paste the text here.

Regarding the command from your previous post I need to check that again. I need to come back to that on Sunday.

Thanks a lot again for your help!

Peter

pschloten · April 15, 2022, 11:56am

Here is the exchange with the UI Support:

From: Ubiquiti Inc support@ui.com
Subject: Re: (H) Failover not working to LTE Pro
Date: 15. April 2022 at 11:50:09 CEST
Reply-To: Ubiquiti Inc support@ui.com
UI Support (Ubiquiti Help Center)
Apr 15, 2022, 3:50 MDT
Hi,

If the connection works with the Google DNS but not with your own DNS server, then the issue is related to the Pi-hole. Unfortunately, we will not be able to help with issues arising because of Pi Hole. Please let us know if you have any further questions. Have a great day ahead!

Thanks!
Best,
UI Support Ubiquiti Inc.

UI Support (Ubiquiti Help Center)
Apr 14, 2022, 6:01 MDT
Hi,

Thanks for the update. We are looking into this issue and we will get back to you with further updates soon.

Thanks!
Best,
UI Support Ubiquiti Inc.

Peter Schloten
Apr 14, 2022, 5:53 MDT
Hi,

Yes, I am still facing the issue. I am using a local piHole/unbound DNS that I need for filtering and local server resolution. Any idea what I can do to have this working with the failover? It does not work to simply use the Google DNS.

Thanks
Peter

UI Support (Ubiquiti Help Center)
Apr 14, 2022, 3:51 MDT
Hi,

I am sorry for the delay. As per the packet capture, it looks like everything is working, as you are able to access google.com using the browser. I suspect that the issue was caused by the DNS server.

Please let us know here if you are still facing any issues.

Thanks!
Best,
UI Support Ubiquiti Inc.

UI Support (Ubiquiti Help Center)
Apr 4, 2022, 4:51 MDT
Hi,

Thanks for the logs. We are looking into this issue and we will get back to you with further updates soon.

Thanks!
Best,
UI Support Ubiquiti Inc.

Peter Schloten
Apr 2, 2022, 4:27 MDT
Hi,

All of that worked. Please find attached the TCP Dump logs. Please let me know how to proceed.

Thanks
Peter

Attachment(s) Archive.zip

UI Support (Ubiquiti Help Center)
Apr 1, 2022, 13:23 MDT
Hi,

Try setting the DNS server on the clients to 8.8.8.8 (either manually or by modifying the DHCP settings). Afterwards, ping 8.8.8.8 from a client and run a tcpdump on the U-LTE-Pro's WAN (wwan0) and LAN (gre1) ports (two SSH sessions). If the ping works, switch to pinging google.com. If that works, visit google.com using a browser.

Thanks!
Best,
UI Support Ubiquiti Inc.

UI Support (Ubiquiti Help Center)
Mar 31, 2022, 15:12 MDT
Hi,

Thanks for the logs. We appreciate your efforts. We are looking into this issue and we will get back to you with further updates soon.

Thanks!
Best,
UI Support Ubiquiti Inc.

Peter Schloten
Mar 29, 2022, 14:41 MDT
Hi,

I just followed the below instructions. Please find the output of the command attached. The PC from which I tried to access the website is 192.168.1.175. Looking at the output, though, I cannot see that IP address in there. I could, however, access the USG and the network application from that PC.

Is there anything I need to do differently?

Thanks
Peter

Attachment(s) TCP Dump.txt

UI Support (Ubiquiti Help Center)
Mar 28, 2022, 11:48 MDT
Hi,

Thanks for the logs. When the WAN1 is down on the USG, please SSH into the USG and run the below command:-
sudo tcpdump -i tun900 -n
Once the command is running, try to access any website on a lan client a few times. Wait for a few minutes, and then copy the output generated for the above command in a text file and share the file here with us along with the IP address on the lan client on which the website was accessed.

Thanks!
Best,
UI Support Ubiquiti Inc.

Peter Schloten
Mar 26, 2022, 11:14 MDT
Hi,

Thanks a lot for your note. I checked the “LTE Backup” option. It was already enabled for all LANs.

I once more disconnected the primary WAN and ran the command below. Please find attached the two files as requested. Please let me know how to proceed.

Thanks a lot
Peter

Attachment(s) Load balancing.txt unifi-20220326-1751.supp

UI Support (Ubiquiti Help Center)
Mar 25, 2022, 14:40 MDT
Hi,

Thanks for the logs. Can you please check whether the "LTE backup" option is enabled inside the LAN network settings? If not enabled yet, then please enable the option and monitor whether the same issue persists.

If the issue is still there, then when the issue occurs again, share the output of the below command from the USG along with a new copy of the Unifi Network support file.

show load-balance status && show interfaces && show ip route && show load-balance watchdog

Thanks!
Best,
UI Support Ubiquiti Inc.

Peter Schloten
Mar 24, 2022, 13:18 MDT
Hi,

Thanks a lot for your note. And please find attached the output from the commands. I had to find some time when I could take down my primary internet connection. Please let me know how to proceed from here.

Thanks
Peter

Attachment(s) Commands.txt

UI Support (Ubiquiti Help Center)
Mar 21, 2022, 11:57 MDT
Hi,

Thanks for the logs. As per the output, the failover to ULTE is taking place, so it looks like the issue is with Internet access on the ULTE. Please SSH into the ULTE when the WAN1 is down and share the output of these commands:

ping www.google.com
ping www.ui.com
ping 8.8.8.8
ifconfig
cat /etc/resolv.conf
netstat -nr

Thanks!
Best,
UI Support Ubiquiti Inc.

Peter Schloten
Mar 18, 2022, 14:05 MDT
Hi,

Thanks a lot for your note. Please find attached the files as requested.

Thanks a lot
Peter

Attachment(s) TechSupport.txt ifconfig.txt Log.txt MCA Dump.txt

UI Support (Ubiquiti Help Center)
Mar 16, 2022, 11:50 MDT
Hi,

I am from the Tier2 team!

Thank you for reaching out! I apologize for the delay in getting back to you.

Please share the tech support file from the USG and the Unifi Network support file when the WAN1 connection is down on the USG but the failover does not occurs to the ULTE-Pro:-

Tech support file from the UniFi Security Gateway (USG):-

SSH to the USG.
Input the following command:
show tech-support | no-more
Copy the full output and paste it into a text editor.
Save and name the file while using the .txt extension.

The network support file can be downloaded from the system settings of the unifi network application.

Also, SSH into the LTE pro (when WAN1 on the USG is down) and share the output of these commands:-

mca-dump | grep lte
cat /var/log/messages
ifconfig

Accessing a UniFi device via SSH:-
To access a UniFi device via SSH, you will first need to set up Device SSH Authentication. These same credentials apply to all UniFi devices managed by the Network application.
To locate or change your device authentication credentials, launch UniFi Network and go to Settings > System > Device SSH Authentication.

Note: You can also use these credentials when locally accessing a UniFi Security Gateway (USG) by typing its IP address into a web browser.
To SSH into your device, run the following command in your terminal of choice (PowerShell or PuTTY on Windows, Terminal on Linux/mac):
ssh @
Thanks!
Best,
UI Support Ubiquiti Inc.

Peter Schloten
Mar 15, 2022, 15:47 MDT
I just installed, adopted and updated a Unifi LTE Pro EU. It shows in the dashboard as „LTE Failover Ready“ with a „Good“ connection. When I unplug the cable for the primary internet connection from the USG-Pro-4, however, I get the message on the dashboard that the primary internet connection has failed. But it does not failover to LTE and I also cannot see an alert in my messages.
This email is a service from Ubiquiti Help Center.
[LYPW7Q-EX75X]

Bucking_Horn · April 15, 2022, 1:03pm

If Ubiquiti support's claim of the fallback hand-over itself to be operational is correct, then that would support my suspicion that somehing interfere's with DNS traffic upstream of unbound,...

In addition to running that aforementioned nslookup, you could try to point Pi-hole to a public DNS server when connected to your fallback LTE network and see if that works.

If it does, that would again support that something specific to your fallback LTE connection would impair unbound.

pschloten · April 15, 2022, 2:20pm

Thanks again for the feedback. Let me check that Sunday/Monday and come back here.

Peter

pschloten · April 18, 2022, 3:07pm

Hi, I have done a few more tests now in failover mode. Please see the console outputs below. Please let me know if those help to narrow down the issue.

When I switch the pihole to an external DNS server there seem to be no issues. I also tested enabling/disabling DNSSEC. That does not seem to make a difference either way.

Thanks
Peter

Console outputs:

admin-raspberrypi-2:~ $ dig www.heise.de @127.0.0.1 -p 5335

; <<>> DiG 9.16.27-Raspbian <<>> www.heise.de @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 19746
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.heise.de.			IN	A

;; Query time: 3 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Mon Apr 18 16:44:48 CEST 2022
;; MSG SIZE  rcvd: 41

admin-raspberrypi-2:~ $ nslookup heise.de 80.241.218.68
Server:		80.241.218.68
Address:	80.241.218.68#53

Non-authoritative answer:
Name:	heise.de
Address: 193.99.144.80
Name:	heise.de
Address: 2a02:2e0:3fe:1001:302::

admin-raspberrypi-2:~ $ nslookup flurry.com 80.241.218.68
Server:		80.241.218.68
Address:	80.241.218.68#53

Name:	flurry.com
Address: 0.0.0.0

Bucking_Horn · April 19, 2022, 8:13am

At least, your LTE provider is not forcibly redirecting DNS traffic to its own DNS servers (as flurry.com got resolved to 0.0.0.0 as expected).

But:

It would seem that unbound's full recursion isn't possible with your LTE connection.

Which ISP is providing your LTE connection?

I guess you did disable DNSSEC via Pi-hole's UI?
Note that unbound would still employ DNSSEC if you didn't adjust its configuration files.

With DNSSEC enabled, you could try to see where DNSSEC validation fails.
Retrieve and store the DNS root servers DNSKEYs:

dig . DNSKEY | grep -Ev '^($|;)' > root.dnskeys

Then use those DNSKEYs to validate a domain lookup, e.g.:

dig +sigchase +trusted-key=./root.dnskeys heise.de

If that doesn't reveal anything (trouble-shooting SERVFAILs is an arduous process), you could further analyse your issue, e.g. by trying deHakkelaar's suggestions following my remark in SERVFAIL with deutsche-glasfaser.de - #12 by Bucking_Horn.

pschloten · April 21, 2022, 5:13am

My LTE provider is Vodafone Germany.

Regarding DNSSEC you are right. I only tried it in the piHole UI. How would I disable it temporarily for unbound? Is it simply commenting out the reference to the key files?

I also tried the dig commands in failover mode and got the below result. Does that point anywhere?

admin@raspberrypi-3:~ $ dig +sigchase +trusted-key=./root.dnskeys heise.de
;; +sigchase option is deprecated;; +trusted-key option is deprecated
; <<>> DiG 9.16.27-Raspbian <<>> +sigchase +trusted-key heise.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4222
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;heise.de.			IN	A

;; Query time: 0 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Thu Apr 21 07:09:47 CEST 2022
;; MSG SIZE  rcvd: 37

Thanks a lot!

Bucking_Horn · April 21, 2022, 6:37am

Unfortunately, that would suggest a SERVFAIL has occured before DNSSEC validation even began, so DNSSEC likely isn't (yet) involved here.

Before you engage in the steps as layed out by the linked posts above, let's try to directly send a query to an IPv4 and IPv6 root server address each (over your LTE connection), similar to what unbound would start with for resolving heise.de:

dig +norecurse @192.5.5.241 de.

dig +norecurse @2001:500:2f::f de.

Both of those should produce the same result (click for sample output)

~ $ dig +norecurse @2001:500:2f::f de.

; <<>> DiG 9.11.5-P4-5.1+deb10u5-Raspbian <<>> +norecurse @2001:500:2f::f de.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21304
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 13

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;de.                            IN      A

;; AUTHORITY SECTION:
de.                     172800  IN      NS      a.nic.de.
de.                     172800  IN      NS      f.nic.de.
de.                     172800  IN      NS      l.de.net.
de.                     172800  IN      NS      n.de.net.
de.                     172800  IN      NS      s.de.net.
de.                     172800  IN      NS      z.nic.de.

;; ADDITIONAL SECTION:
a.nic.de.               172800  IN      A       194.0.0.53
a.nic.de.               172800  IN      AAAA    2001:678:2::53
f.nic.de.               172800  IN      A       81.91.164.5
f.nic.de.               172800  IN      AAAA    2a02:568:0:2::53
l.de.net.               172800  IN      A       77.67.63.105
l.de.net.               172800  IN      AAAA    2001:668:1f:11::105
n.de.net.               172800  IN      A       194.146.107.6
n.de.net.               172800  IN      AAAA    2001:67c:1011:1::53
s.de.net.               172800  IN      A       195.243.137.26
s.de.net.               172800  IN      AAAA    2003:8:14::53
z.nic.de.               172800  IN      A       194.246.96.1
z.nic.de.               172800  IN      AAAA    2a02:568:fe02::de

;; Query time: 14 msec
;; SERVER: 2001:500:2f::f#53(2001:500:2f::f)
;; WHEN: Thu Apr 21 08:31:22 CEST 2022
;; MSG SIZE  rcvd: 401

pschloten · April 21, 2022, 4:15pm

Hi, I am getting the below results:

admin@raspberrypi-2:~ $ dig +norecurse @192.5.5.241 de.

; <<>> DiG 9.16.27-Raspbian <<>> +norecurse @192.5.5.241 de.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13746
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 13

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;de.				IN	A

;; AUTHORITY SECTION:
de.			172800	IN	NS	a.nic.de.
de.			172800	IN	NS	f.nic.de.
de.			172800	IN	NS	l.de.net.
de.			172800	IN	NS	n.de.net.
de.			172800	IN	NS	s.de.net.
de.			172800	IN	NS	z.nic.de.

;; ADDITIONAL SECTION:
a.nic.de.		172800	IN	A	194.0.0.53
a.nic.de.		172800	IN	AAAA	2001:678:2::53
f.nic.de.		172800	IN	A	81.91.164.5
f.nic.de.		172800	IN	AAAA	2a02:568:0:2::53
l.de.net.		172800	IN	A	77.67.63.105
l.de.net.		172800	IN	AAAA	2001:668:1f:11::105
n.de.net.		172800	IN	A	194.146.107.6
n.de.net.		172800	IN	AAAA	2001:67c:1011:1::53
s.de.net.		172800	IN	A	195.243.137.26
s.de.net.		172800	IN	AAAA	2003:8:14::53
z.nic.de.		172800	IN	A	194.246.96.1
z.nic.de.		172800	IN	AAAA	2a02:568:fe02::de

;; Query time: 35 msec
;; SERVER: 192.5.5.241#53(192.5.5.241)
;; WHEN: Thu Apr 21 18:13:05 CEST 2022
;; MSG SIZE  rcvd: 401

admin@raspberrypi-2:~ $ dig +norecurse @2001:500:2f::f de.

; <<>> DiG 9.16.27-Raspbian <<>> +norecurse @2001:500:2f::f de.
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Bucking_Horn · April 21, 2022, 8:47pm

So that query to the IPv6 server address timed out.

The next dig commands in the resolution chain would be:

dig +norecurse @194.0.0.53 heise.de.

dig +norecurse @193.99.145.37 heise.de.

and

dig +norecurse @2001:678:2::53 heise.de.

dig +norecurse @2a00:e68:14:800::d1ce heise.de.

The respective second commands should return an A record with an IPv4 address in its ANSWER section.

pschloten · April 22, 2022, 5:23am

Thanks again. Please see below the results:

admin@raspberrypi-2:~ $ dig +norecurse @194.0.0.53 heise.de.

; <<>> DiG 9.16.27-Raspbian <<>> +norecurse @194.0.0.53 heise.de.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39250
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 8

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
; COOKIE: 103b1700feba927a2bebc9fc62623b766fb6745f219d44ac (good)
;; QUESTION SECTION:
;heise.de.			IN	A

;; AUTHORITY SECTION:
heise.de.		86400	IN	NS	ns.s.plusline.de.
heise.de.		86400	IN	NS	ns.plusline.de.
heise.de.		86400	IN	NS	ns.pop-hannover.de.
heise.de.		86400	IN	NS	ns2.pop-hannover.net.
heise.de.		86400	IN	NS	ns.heise.de.

;; ADDITIONAL SECTION:
ns.pop-hannover.de.	86400	IN	A	193.98.1.200
ns.plusline.de.		86400	IN	A	212.19.48.14
ns.heise.de.		86400	IN	A	193.99.145.37
ns.s.plusline.de.	86400	IN	A	212.19.40.14
ns.plusline.de.		86400	IN	AAAA	2a02:2e0:1:2:3:4:5:6
ns.heise.de.		86400	IN	AAAA	2a00:e68:14:800::d1ce
ns.s.plusline.de.	86400	IN	AAAA	2a02:2e0:a:b:c:d:e:f

;; Query time: 39 msec
;; SERVER: 194.0.0.53#53(194.0.0.53)
;; WHEN: Fri Apr 22 07:21:58 CEST 2022
;; MSG SIZE  rcvd: 354

admin@raspberrypi-2:~ $ dig +norecurse @193.99.145.37 heise.de.

; <<>> DiG 9.16.27-Raspbian <<>> +norecurse @193.99.145.37 heise.de.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44420
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;heise.de.			IN	A

;; ANSWER SECTION:
heise.de.		86400	IN	A	193.99.144.80

;; Query time: 35 msec
;; SERVER: 193.99.145.37#53(193.99.145.37)
;; WHEN: Fri Apr 22 07:22:05 CEST 2022
;; MSG SIZE  rcvd: 53

admin@raspberrypi-2:~ $ dig +norecurse @2001:678:2::53 heise.de.

; <<>> DiG 9.16.27-Raspbian <<>> +norecurse @2001:678:2::53 heise.de.
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

admin@raspberrypi-2:~ $ dig +norecurse @2a00:e68:14:800::d1ce heise.de.

; <<>> DiG 9.16.27-Raspbian <<>> +norecurse @2a00:e68:14:800::d1ce heise.de.
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Bucking_Horn · April 22, 2022, 6:45am

IPv4 looks OK, and IPv6 is timing out again.
That's probably because Vodafone does not support IPv6 for your mobile data, but shoudn't have an impact on resolution, since IPv4 is available.

Does your unbound try to make use of IPv6?
What's the output of:

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

From our findings, I'm at a loss of explaining why unbound would return SERVFAIL.

unbound may have picked other authoritative DNS servers from the answer sets, but by running those lookups, we've manually walked the recursion, similar to what unbound would have done, apart from the initial root zone lookup.
This would be e.g.

dig +norecurse @192.203.230.10 . NS

For furher analysis, you'd have to follow the steps from the link I've posted above to examine unbound's actual log output.

pschloten · April 22, 2022, 4:11pm

Thanks a lot for your help so far once more. And please see below the outputs of the two commands. Does that give any further pointers? If not I will have a look into the other thread you pointed me to.

admin@raspberrypi-2:~ $ sudo grep -v '#\|^$' -R /etc/unbound/unbound.conf*
[sudo] password for admin: 
/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/resolvconf_resolvers.conf:forward-zone:
/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf:	name: "."
/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf:	forward-addr: 80.69.96.12
/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf:	forward-addr: 81.210.129.4
/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:    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: 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
admin@raspberrypi-2:~ $ dig +norecurse @192.203.230.10 . NS

; <<>> DiG 9.16.27-Raspbian <<>> +norecurse @192.203.230.10 . NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 356
;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.				IN	NS

;; ANSWER SECTION:
.			518400	IN	NS	a.root-servers.net.
.			518400	IN	NS	b.root-servers.net.
.			518400	IN	NS	c.root-servers.net.
.			518400	IN	NS	d.root-servers.net.
.			518400	IN	NS	e.root-servers.net.
.			518400	IN	NS	f.root-servers.net.
.			518400	IN	NS	g.root-servers.net.
.			518400	IN	NS	h.root-servers.net.
.			518400	IN	NS	i.root-servers.net.
.			518400	IN	NS	j.root-servers.net.
.			518400	IN	NS	k.root-servers.net.
.			518400	IN	NS	l.root-servers.net.
.			518400	IN	NS	m.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.	518400	IN	A	198.41.0.4
b.root-servers.net.	518400	IN	A	199.9.14.201
c.root-servers.net.	518400	IN	A	192.33.4.12
d.root-servers.net.	518400	IN	A	199.7.91.13
e.root-servers.net.	518400	IN	A	192.203.230.10
f.root-servers.net.	518400	IN	A	192.5.5.241
g.root-servers.net.	518400	IN	A	192.112.36.4
h.root-servers.net.	518400	IN	A	198.97.190.53
i.root-servers.net.	518400	IN	A	192.36.148.17
j.root-servers.net.	518400	IN	A	192.58.128.30
k.root-servers.net.	518400	IN	A	193.0.14.129
l.root-servers.net.	518400	IN	A	199.7.83.42
m.root-servers.net.	518400	IN	A	202.12.27.33
a.root-servers.net.	518400	IN	AAAA	2001:503:ba3e::2:30
b.root-servers.net.	518400	IN	AAAA	2001:500:200::b
c.root-servers.net.	518400	IN	AAAA	2001:500:2::c
d.root-servers.net.	518400	IN	AAAA	2001:500:2d::d
e.root-servers.net.	518400	IN	AAAA	2001:500:a8::e
f.root-servers.net.	518400	IN	AAAA	2001:500:2f::f
g.root-servers.net.	518400	IN	AAAA	2001:500:12::d0d
h.root-servers.net.	518400	IN	AAAA	2001:500:1::53
i.root-servers.net.	518400	IN	AAAA	2001:7fe::53
j.root-servers.net.	518400	IN	AAAA	2001:503:c27::2:30
k.root-servers.net.	518400	IN	AAAA	2001:7fd::1
l.root-servers.net.	518400	IN	AAAA	2001:500:9f::42
m.root-servers.net.	518400	IN	AAAA	2001:dc3::35

;; Query time: 47 msec
;; SERVER: 192.203.230.10#53(192.203.230.10)
;; WHEN: Fri Apr 22 18:09:23 CEST 2022
;; MSG SIZE  rcvd: 811