Thank you. I'm at Ubuntu 18.04 and I thought about updating it a month or so ago but it was "working" so I didn't. I will figure out how to get up to the latest and report back. It's always a little scary for me doing a big update. I feel very weak with Linux. I'm Mac or AIX type.
Have you checked wat updates are available?
sudo apt-get update
apt-cache policy unbound
If no v1.9, I guess you'll need to upgrade your distro (am unfamiliar with Ubuntus releases).
odroid@crystal:~$ apt-cache policy unbound
unbound:
Installed: 1.6.7-1ubuntu2.3
Candidate: 1.6.7-1ubuntu2.4
Version table:
1.6.7-1ubuntu2.4 500
500 http://ports.ubuntu.com/ubuntu-ports bionic-updates/universe armhf Packages
500 http://ports.ubuntu.com/ubuntu-ports bionic-security/universe armhf Packages
*** 1.6.7-1ubuntu2.3 100
100 /var/lib/dpkg/status
1.6.7-1ubuntu2 500
500 http://ports.ubuntu.com/ubuntu-ports bionic/universe armhf Packages
I have one or two other Odroids somewhere. I'm going to find one of them, update it, and then migrate to it. Probably take me most of today if not more.
Thank you very much again.
1 Like
Odroid is bit overkill 
I run mine on a:
pi@ph5a:~ $ cat /proc/cpuinfo
[..]
Model : Raspberry Pi Model B Rev 1
EDIT: Just noticed they are on release v1.13 already:
So depends what major release your distro is on and what version they push.
New Odroid, up at Ubuntu 20.04, unbound at 1.9.4. New Pi-hole installed using Google (not unbound). unbound has the same problem. Weird. I figured something would change.
New pastebin is here.
Edit: If there is something I can change that would make your analysis easier, please let me know. Also, perhaps if you pasted your working log file somewhere of the same setup and request, then I would have a good sample to work from and compare much like you are doing but we both could look for similarities and differences.
Thank you again.
Yeah sure, below is from starting unbound after removing upstream in Pi-hole settings:
pi@ph5b:~ $ sudo service unbound stop
pi@ph5b:~ $
pi@ph5b:~ $ sudo /usr/sbin/unbound -ddd -vvv -c /etc/unbound/unbound.conf
[1622048033] unbound[883:0] notice: Start of unbound 1.9.0.
[1622048033] unbound[883:0] debug: chdir to /etc/unbound
[1622048033] unbound[883:0] debug: drop user privileges, run as unbound
[1622048033] unbound[883:0] debug: switching log to stderr
[1622048033] unbound[883:0] debug: module config: "subnetcache validator iterator"
[1622048033] unbound[883:0] notice: init module 0: subnet
[1622048033] unbound[883:0] debug: subnet: option registered (8)
[1622048033] unbound[883:0] notice: init module 1: validator
[1622048033] unbound[883:0] notice: init module 2: iterator
[1622048033] unbound[883:0] debug: target fetch policy for level 0 is 3
[1622048033] unbound[883:0] debug: target fetch policy for level 1 is 2
[1622048033] unbound[883:0] debug: target fetch policy for level 2 is 1
[1622048033] unbound[883:0] debug: target fetch policy for level 3 is 0
[1622048033] unbound[883:0] debug: target fetch policy for level 4 is 0
[1622048034] unbound[883:0] debug: cache memory msg=33040 rrset=33040 infra=3916 val=33196 subnet=41372
[1622048034] unbound[883:0] info: start of service (unbound 1.9.0).
Results for the one dig only (successive queries are pulled from unbound cache!):
pi@ph5b:~ $ dig @localhost -p 5335 a www.instagram.com.
; <<>> DiG 9.11.5-P4-5.1+deb10u5-Raspbian <<>> @localhost -p 5335 a www.instagram.com.
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58754
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;www.instagram.com. IN A
;; ANSWER SECTION:
www.instagram.com. 3600 IN CNAME z-p42-instagram.c10r.facebook.com.
z-p42-instagram.c10r.facebook.com. 60 IN A 69.171.250.174
;; Query time: 351 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1)
;; WHEN: Wed May 26 18:54:58 CEST 2021
;; MSG SIZE rcvd: 106
Below the logs that resulted from that one dig query:
I suspect that one of the authoritative name servers isn't cooperating or some filtering/mangling going on upstream.
The way it works, unbound will ask the root servers first who is authoritative for the net. domain.
The root servers/hints are stored in that file I mentioned earlier and are loaded into unbound cache at startup:
pi@ph5b:~ $ cat /usr/share/dns/root.hints
; This file holds the information on root name servers needed to
; initialize cache of Internet domain name servers
; (e.g. reference this file in the "cache . <file>"
; configuration file of BIND domain name servers).
;
; This file is made available by InterNIC
; under anonymous FTP as
; file /domain/named.cache
; on server FTP.INTERNIC.NET
; -OR- RS.INTERNIC.NET
;
; last update: March 13, 2019
; related version of root zone: 2019031302
;
; FORMERLY NS.INTERNIC.NET
;
. 3600000 NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
A.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:ba3e::2:30
;
; FORMERLY NS1.ISI.EDU
;
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 199.9.14.201
B.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:200::b
;
; FORMERLY C.PSI.NET
;
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
C.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2::c
;
; FORMERLY TERP.UMD.EDU
;
. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000 A 199.7.91.13
D.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2d::d
;
; FORMERLY NS.NASA.GOV
;
. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
E.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:a8::e
;
; FORMERLY NS.ISC.ORG
;
. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241
F.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:2f::f
;
; FORMERLY NS.NIC.DDN.MIL
;
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
G.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:12::d0d
;
; FORMERLY AOS.ARL.ARMY.MIL
;
. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000 A 198.97.190.53
H.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:1::53
;
; FORMERLY NIC.NORDU.NET
;
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
I.ROOT-SERVERS.NET. 3600000 AAAA 2001:7fe::53
;
; OPERATED BY VERISIGN, INC.
;
. 3600000 NS J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30
J.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:c27::2:30
;
; OPERATED BY RIPE NCC
;
. 3600000 NS K.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129
K.ROOT-SERVERS.NET. 3600000 AAAA 2001:7fd::1
;
; OPERATED BY ICANN
;
. 3600000 NS L.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET. 3600000 A 199.7.83.42
L.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:9f::42
;
; OPERATED BY WIDE
;
. 3600000 NS M.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33
M.ROOT-SERVERS.NET. 3600000 AAAA 2001:dc3::35
You can see in my logs, the first query "sending query: . NS IN"
is sent to "sending to target: <.> 192.203.230.10#53"
which is the E.ROOT-SERVERS.NET. server listed in the root.hints file above.
This translates with dig into below:
pi@ph5b:~ $ dig +norecurse @192.203.230.10 ns .
; <<>> DiG 9.11.5-P4-5.1+deb10u5-Raspbian <<>> +norecurse @192.203.230.10 ns .
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55983
;; 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: 16 msec
;; SERVER: 192.203.230.10#53(192.203.230.10)
;; WHEN: Wed May 26 19:26:41 CEST 2021
;; MSG SIZE rcvd: 811
These root-servers are from now on used every time (until TTL expires) to look up records for TLD domains like for example the com. TLD.
The next query unbound does "sending query: com. A IN" to "sending to target: <.> 199.9.14.201#53", which is the b.root-servers.net. server from above query, is to ask who is authoritative for the com. domain:
pi@ph5b:~ $ dig +norecurse @199.9.14.201 a com.
;; BADCOOKIE, retrying.
; <<>> DiG 9.11.5-P4-5.1+deb10u5-Raspbian <<>> +norecurse @199.9.14.201 a com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35662
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: cd34f7efbe1ad48b0100000060ae8679c376b4bffb33117a (good)
;; QUESTION SECTION:
;com. IN A
;; AUTHORITY SECTION:
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800 IN A 192.5.6.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
b.gtld-servers.net. 172800 IN A 192.33.14.30
b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30
c.gtld-servers.net. 172800 IN A 192.26.92.30
c.gtld-servers.net. 172800 IN AAAA 2001:503:83eb::30
d.gtld-servers.net. 172800 IN A 192.31.80.30
d.gtld-servers.net. 172800 IN AAAA 2001:500:856e::30
e.gtld-servers.net. 172800 IN A 192.12.94.30
e.gtld-servers.net. 172800 IN AAAA 2001:502:1ca1::30
f.gtld-servers.net. 172800 IN A 192.35.51.30
f.gtld-servers.net. 172800 IN AAAA 2001:503:d414::30
g.gtld-servers.net. 172800 IN A 192.42.93.30
g.gtld-servers.net. 172800 IN AAAA 2001:503:eea3::30
h.gtld-servers.net. 172800 IN A 192.54.112.30
h.gtld-servers.net. 172800 IN AAAA 2001:502:8cc::30
i.gtld-servers.net. 172800 IN A 192.43.172.30
i.gtld-servers.net. 172800 IN AAAA 2001:503:39c1::30
j.gtld-servers.net. 172800 IN A 192.48.79.30
j.gtld-servers.net. 172800 IN AAAA 2001:502:7094::30
k.gtld-servers.net. 172800 IN A 192.52.178.30
k.gtld-servers.net. 172800 IN AAAA 2001:503:d2d::30
l.gtld-servers.net. 172800 IN A 192.41.162.30
l.gtld-servers.net. 172800 IN AAAA 2001:500:d937::30
m.gtld-servers.net. 172800 IN A 192.55.83.30
m.gtld-servers.net. 172800 IN AAAA 2001:501:b1f9::30
;; Query time: 12 msec
;; SERVER: 199.9.14.201#53(199.9.14.201)
;; WHEN: Wed May 26 19:33:46 CEST 2021
;; MSG SIZE rcvd: 856
The next query "sending query: instagram.com. A IN" to "sending to target: <com.> 192.54.112.30#53" (one of the IP's from above query) is to ask who is authoritative for instagram.com.:
pi@ph5b:~ $ dig +norecurse @192.54.112.30 a instagram.com.
; <<>> DiG 9.11.5-P4-5.1+deb10u5-Raspbian <<>> +norecurse @192.54.112.30 a instagram.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57896
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;instagram.com. IN A
;; AUTHORITY SECTION:
instagram.com. 172800 IN NS ns-384.awsdns-48.com.
instagram.com. 172800 IN NS ns-868.awsdns-44.net.
instagram.com. 172800 IN NS ns-1349.awsdns-40.org.
instagram.com. 172800 IN NS ns-2016.awsdns-60.co.uk.
;; ADDITIONAL SECTION:
ns-384.awsdns-48.com. 172800 IN A 205.251.193.128
;; Query time: 17 msec
;; SERVER: 192.54.112.30#53(192.54.112.30)
;; WHEN: Wed May 26 19:37:40 CEST 2021
;; MSG SIZE rcvd: 195
Next, you would expect to get an answer with "sending query: www.instagram.com. A IN" to "sending to target: <instagram.com.> 205.251.193.128#53" (IP from above query):
pi@ph5b:~ $ dig +norecurse @205.251.193.128 a www.instagram.com.
; <<>> DiG 9.11.5-P4-5.1+deb10u5-Raspbian <<>> +norecurse @205.251.193.128 a www.instagram.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29610
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.instagram.com. IN A
;; ANSWER SECTION:
www.instagram.com. 3600 IN CNAME z-p42-instagram.c10r.facebook.com.
;; AUTHORITY SECTION:
instagram.com. 172800 IN NS ns-1349.awsdns-40.org.
instagram.com. 172800 IN NS ns-2016.awsdns-60.co.uk.
instagram.com. 172800 IN NS ns-384.awsdns-48.com.
instagram.com. 172800 IN NS ns-868.awsdns-44.net.
;; Query time: 43 msec
;; SERVER: 205.251.193.128#53(205.251.193.128)
;; WHEN: Wed May 26 19:41:48 CEST 2021
;; MSG SIZE rcvd: 227
But no, the bloody answer is a CNAME record "z-p42-instagram.c10r.facebook.com." that needs to be iterated/recursed into the same way as the www.instagram.com. domain.
Meaning start all over again and ask the root servers for the com. domain, next for facebook.com., next c10r.facebook.com. etc).
Same for follow up queries for authoritative name servers with only a name and no A records included.
Tedious to say the least 
I'll follow up once I have a little bit more time to investigate.
Also I need to figure out what REFERRAL means in the logs.
Until then, good luck exploring your recursive DNS server
Ps. you can circumvent those troubled domains being forwarded to unbound upstream with pihole-FTL:
sudo nano /etc/dnsmasq.d/99-forward-zone.conf
Containing:
server=/instagram.com/www.instagram.com/1.1.1.1
server=/instagram.com/www.instagram.com/8.8.8.8
server=/instagram.com/www.instagram.com/9.9.9.9
Check syntax:
pihole-FTL --test
And apply:
sudo service pihole-FTL reload
If you check the Pi-hole logs, you'll see those servers will be addressed instead of unbound (if configured unbound upstream):
pihole -t
Could you post output for below ones?
dig +norecurse @185.89.218.12 a z-p42-instagram.c10r.facebook.com.
dig +norecurse @185.89.218.12 a c10r.facebook.com.
The clr.facebook.com is the one that never works.
odroid@brandy:~$ dig +norecurse @185.89.218.12 a z-p42-instagram.c10r.facebook.com.
; <<>> DiG 9.16.1-Ubuntu <<>> +norecurse @185.89.218.12 a z-p42-instagram.c10r.facebook.com.
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
odroid@brandy:~$ dig +norecurse @185.89.218.12 a c10r.facebook.com.
; <<>> DiG 9.16.1-Ubuntu <<>> +norecurse @185.89.218.12 a c10r.facebook.com.
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
That means something upstream is blocking/filtering traffic with IP 185.89.218.12:
pi@ph5b:~ $ dig +norecurse @185.89.218.12 a z-p42-instagram.c10r.facebook.com.
[..]
;; AUTHORITY SECTION:
c10r.facebook.com. 3600 IN NS a.ns.c10r.facebook.com.
c10r.facebook.com. 3600 IN NS c.ns.c10r.facebook.com.
c10r.facebook.com. 3600 IN NS b.ns.c10r.facebook.com.
c10r.facebook.com. 3600 IN NS d.ns.c10r.facebook.com.
;; ADDITIONAL SECTION:
a.ns.c10r.facebook.com. 3600 IN AAAA 2a03:2880:f0fc:b:face:b00c:0:99
a.ns.c10r.facebook.com. 3600 IN A 129.134.30.11
c.ns.c10r.facebook.com. 3600 IN AAAA 2a03:2880:f1fc:b:face:b00c:0:99
c.ns.c10r.facebook.com. 3600 IN A 185.89.218.11
b.ns.c10r.facebook.com. 3600 IN AAAA 2a03:2880:f0fd:b:face:b00c:0:99
b.ns.c10r.facebook.com. 3600 IN A 129.134.31.11
d.ns.c10r.facebook.com. 3600 IN AAAA 2a03:2880:f1fd:b:face:b00c:0:99
d.ns.c10r.facebook.com. 3600 IN A 185.89.219.11
Not related to unbound or Pi-hole.
Someone else experienced similar:
EDIT: Or maybe routes upstream are wrong somehow.
EDIT2: Below did the trick seeing something wrong with the repeated attempts and no answer:
grep 'sending query\|sending to target\|response was\|reply from\|operate: query' unbound.log | less
I guess I got myself confused or things have changed. I thought I could resolve www.facebook.com ... so I thought I could resolve some Facebook subdomains but not all. But now today (with the 1.9 unbound) I can't resolve any.
I have my gateway, my 4G LTE modem, and then the AT&T network between me and reality. I'll check the first two again for some type of filtering.
It's interesting (from your previous post) that I can add special cases for particular domains.
The other question is if doing encrypted queries would help. Any idea if it would?
Thank you again for your help. It's been very educational for me.
1 Like
No I dont think so.
Something is realy wrong upstream somewhere and encrypting wont fix that.
You cant encrypt if you cant even connect.
EDIT: Ow sorry, you cant establish a DNSSEC connection with the servers unbound uses recursively , they dont have encryption.
EDIT2: One encrypted solution is to run everything through a public VPN.
That way the IP cant be blocked.
This somewhat implies that it is outside of my house:
% traceroute 185.89.218.12
traceroute to 185.89.218.12 (185.89.218.12), 64 hops max, 52 byte packets
1 gateway (192.168.1.1) 12.378 ms 3.499 ms 3.426 ms
2 192.168.10.1 (192.168.10.1) 4.177 ms 4.033 ms 3.660 ms
3 * * *
4 * * *
#2 is the AT&T 4G LTE modem.
Dont mind the last hops not showing:
pi@ph5b:~ $ traceroute -n 185.89.218.12
traceroute to 185.89.218.12 (185.89.218.12), 30 hops max, 60 byte packets
1 10.0.0.1 0.713 ms 0.704 ms 0.817 ms
2 192.168.1.1 1.096 ms 0.901 ms 0.905 ms
3 62.58.240.1 7.562 ms 7.320 ms 7.845 ms
4 212.53.25.201 10.555 ms 11.000 ms 26.897 ms
5 212.53.25.193 10.782 ms 10.578 ms 10.714 ms
6 212.151.190.0 11.419 ms 11.210 ms 11.102 ms
7 130.244.82.55 8.042 ms 8.037 ms 8.983 ms
8 130.244.200.46 10.774 ms 11.048 ms 10.959 ms
9 195.219.194.78 218.731 ms 195.219.156.61 204.850 ms 195.219.194.146 203.320 ms
10 195.219.156.133 211.872 ms 195.219.156.151 214.576 ms 80.231.217.5 206.166 ms
11 195.219.87.209 202.499 ms 195.219.87.169 213.530 ms 180.87.12.2 205.479 ms
12 180.87.12.226 216.651 ms 80.231.217.1 199.245 ms 199.079 ms
13 116.0.93.168 202.783 ms 80.231.217.91 203.732 ms 116.0.93.152 197.990 ms
14 180.87.12.2 202.581 ms 116.0.93.147 206.972 ms 180.87.12.2 202.714 ms
15 180.87.12.226 215.920 ms * 116.0.82.62 211.895 ms
16 116.0.82.62 198.831 ms 203.942 ms 116.0.93.147 200.938 ms
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
(Unrelated to the issue, just to clarify:
DNSSEC is not about encrypting DNS traffic - it is about digitally signing DNS records so you can be sure they are authentic and haven't been manipulated.
It is correct that the root servers don't do encryption, but they (as well as the majority of TLD domain servers) do support DNSSEC (the root zone has been completely signed since 2010).
Since the root servers do not support encryption, that also means you cannot run unbound (nor any other DNS server) as a fully recursive resolver and encrypt DNS traffic at the same time.)
1 Like
Yeah I was confusing DNSSEC with DoT and DoH.
The DNSSEC validation is clearly seen in the logs:
[1622048098] unbound[883:0] info: iterator operate: query com. DNSKEY IN
[1622048098] unbound[883:0] info: response for com. DNSKEY IN
[1622048098] unbound[883:0] info: reply from <com.> 192.52.178.30#53
[1622048098] unbound[883:0] info: query response was ANSWER
[1622048098] unbound[883:0] info: finishing processing for com. DNSKEY IN
[1622048098] unbound[883:0] debug: validator[module 1] operate: extstate:module_wait_module event:module_event_moddone
[1622048098] unbound[883:0] info: validator operate: query com. DNSKEY IN
[1622048098] unbound[883:0] debug: subnet[module 0] operate: extstate:module_wait_module event:module_event_moddone
[1622048098] unbound[883:0] info: subnet operate: query com. DNSKEY IN
[1622048098] unbound[883:0] info: validated DNSKEY com. DNSKEY IN
Thanks for the correction!
Last week my kids were complaining that some sites including Instagram weren't connecting. After some investigation it transpired that it was down to the Adlists that were pulled in overnight. Trimming the Adlists to the default 4 brought them all back. Bonus was that it brought down the memory usage of the Pi as well.
YMMV.
Cheers
I sent an email to the support of my 4G provider. If they say anything interesting, I'll report back.
1 Like
I created a little bash script to analyse those debug logs and generate a list of dig queries that unbound performs.
Next time we can compare outcome for those queries between a good and bad setup.
I know its not perfect but does the job:
pi@ph5b:~ $ nano unbound_check.sh
#!/bin/bash
while read LINE; do
if [[ "$LINE" =~ "sending query" ]]; then
QUERY=$(sed 's/^.*sending query: //' <<< $LINE )
fi
if [[ "$LINE" =~ "sending to target" ]]; then
TARGET=$(sed 's/^.*sending to target.*> //; s/#.*$//' <<< $LINE )
fi
if [[ "$QUERY" != "" ]] && [[ "$TARGET" != "" ]]; then
echo "dig +norecurse @$TARGET $QUERY"
QUERY=""
TARGET=""
fi
done < $1
pi@ph5b:~ $ chmod +x unbound_check.sh
pi@ph5b:~ $
Below my good logs:
pi@ph5b:~ $ ./unbound_check.sh unbound.good.log | column -t
dig +norecurse @192.203.230.10 . NS IN
dig +norecurse @199.9.14.201 com. A IN
dig +norecurse @192.54.112.30 instagram.com. A IN
dig +norecurse @205.251.193.128 www.instagram.com. A IN
dig +norecurse @192.112.36.4 org. A IN
dig +norecurse @192.36.148.17 uk. A IN
dig +norecurse @202.12.27.33 net. A IN
dig +norecurse @199.19.53.1 awsdns-40.org. A IN
dig +norecurse @192.35.51.30 facebook.com. A IN
dig +norecurse @192.54.112.30 awsdns-44.net. A IN
dig +norecurse @205.251.196.43 ns-1349.awsdns-40.org. A IN
dig +norecurse @129.134.31.12 c10r.facebook.com. A IN
dig +norecurse @205.251.195.46 ns-868.awsdns-44.net. A IN
dig +norecurse @129.134.30.11 z-p42-instagram.c10r.facebook.com. A IN
dig +norecurse @43.230.48.1 co.uk. A IN
dig +norecurse @156.154.102.3 awsdns-60.co.uk. A IN
dig +norecurse @192.36.148.17 . DNSKEY IN
dig +norecurse @192.33.4.12 _ta-4f66. A IN
dig +norecurse @192.52.178.30 com. DNSKEY IN
dig +norecurse @205.251.198.1 ns-2016.awsdns-60.co.uk. A IN
Below the bad logs:
pi@ph5b:~ $ ./unbound_check.sh unbound.bad.log | column -t
dig +norecurse @192.5.5.241 . NS IN
dig +norecurse @198.97.190.53 com. A IN
dig +norecurse @192.31.80.30 instagram.com. A IN
dig +norecurse @205.251.193.128 www.instagram.com. A IN
dig +norecurse @192.5.5.241 org. A IN
dig +norecurse @192.5.5.241 uk. A IN
dig +norecurse @192.112.36.4 net. A IN
dig +norecurse @192.43.172.30 facebook.com. A IN
dig +norecurse @199.19.56.1 awsdns-40.org. A IN
dig +norecurse @192.12.94.30 awsdns-44.net. A IN
dig +norecurse @185.89.218.12 c10r.facebook.com. A IN
dig +norecurse @205.251.199.172 ns-868.awsdns-44.net. A IN
dig +norecurse @205.251.194.234 ns-1349.awsdns-40.org. A IN
dig +norecurse @156.154.103.3 co.uk. A IN
dig +norecurse @156.154.103.3 awsdns-60.co.uk. A IN
dig +norecurse @205.251.198.1 ns-2016.awsdns-60.co.uk. A IN
dig +norecurse @129.134.30.12 c10r.facebook.com. A IN
dig +norecurse @129.134.30.12 c10r.facebook.com. A IN
dig +norecurse @185.89.218.12 z-p42-instagram.c10r.facebook.com. A IN
dig +norecurse @129.134.31.12 z-p42-instagram.c10r.facebook.com. A IN
dig +norecurse @129.134.31.12 z-p42-instagram.c10r.facebook.com. A IN
dig +norecurse @185.89.219.12 c10r.facebook.com. A IN
dig +norecurse @185.89.219.12 c10r.facebook.com. A IN
dig +norecurse @185.89.219.12 z-p42-instagram.c10r.facebook.com. A IN
dig +norecurse @185.89.218.12 c10r.facebook.com. A IN
dig +norecurse @185.89.218.12 z-p42-instagram.c10r.facebook.com. A IN
dig +norecurse @185.89.219.12 z-p42-instagram.c10r.facebook.com. A IN
dig +norecurse @185.89.219.12 z-p42-instagram.c10r.facebook.com. A IN
dig +norecurse @129.134.31.12 c10r.facebook.com. A IN
dig +norecurse @129.134.31.12 z-p42-instagram.c10r.facebook.com. A IN
dig +norecurse @129.134.31.12 z-p42-instagram.c10r.facebook.com. A IN
dig +norecurse @129.134.30.12 c10r.facebook.com. A IN
dig +norecurse @129.134.30.12 c10r.facebook.com. A IN
dig +norecurse @185.89.219.12 z-p42-instagram.c10r.facebook.com. A IN
dig +norecurse @129.134.30.12 z-p42-instagram.c10r.facebook.com. A IN
dig +norecurse @185.89.219.12 z-p42-instagram.c10r.facebook.com. A IN
dig +norecurse @185.89.218.12 z-p42-instagram.c10r.facebook.com. A IN
dig +norecurse @185.89.218.12 z-p42-instagram.c10r.facebook.com. A IN
dig +norecurse @185.89.218.12 z-p42-instagram.c10r.facebook.com. A IN
dig +norecurse @185.89.219.12 z-p42-instagram.c10r.facebook.com. A IN
dig +norecurse @185.89.218.12 z-p42-instagram.c10r.facebook.com. A IN
dig +norecurse @185.89.218.12 z-p42-instagram.c10r.facebook.com. A IN
dig +norecurse @185.89.218.12 z-p42-instagram.c10r.facebook.com. A IN
dig +norecurse @129.134.30.12 z-p42-instagram.c10r.facebook.com. A IN
dig +norecurse @129.134.30.12 z-p42-instagram.c10r.facebook.com. A IN
dig +norecurse @129.134.30.12 z-p42-instagram.c10r.facebook.com. A IN
EDIT: added good/bad
One more
I noticed below event indicates no answer/reply:
pi@ph5b:~ $ grep -B3 module_event_noreply unbound.bad.log
[..]
[1621993999] unbound[4963:0] info: sending query: c10r.facebook.com. A IN
[1621993999] unbound[4963:0] debug: sending to target: <facebook.com.> 129.134.30.12#53
[1621993999] unbound[4963:0] debug: cache memory msg=34898 rrset=60588 infra=7225 val=35039 subnet=41372
[1621994000] unbound[4963:0] debug: iterator[module 2] operate: extstate:module_wait_reply event:module_event_noreply
--
[1621994000] unbound[4963:0] info: sending query: c10r.facebook.com. A IN
[1621994000] unbound[4963:0] debug: sending to target: <facebook.com.> 129.134.30.12#53
[1621994000] unbound[4963:0] debug: cache memory msg=34898 rrset=60588 infra=7225 val=35039 subnet=41372
[1621994002] unbound[4963:0] debug: iterator[module 2] operate: extstate:module_wait_reply event:module_event_noreply
--
[1621994002] unbound[4963:0] info: sending query: z-p42-instagram.c10r.facebook.com. A IN
[1621994002] unbound[4963:0] debug: sending to target: <facebook.com.> 185.89.218.12#53
[1621994002] unbound[4963:0] debug: cache memory msg=34898 rrset=60588 infra=7225 val=35039 subnet=41372
[1621994003] unbound[4963:0] debug: iterator[module 2] operate: extstate:module_wait_reply event:module_event_noreply
--
[1621994003] unbound[4963:0] info: sending query: z-p42-instagram.c10r.facebook.com. A IN
[1621994003] unbound[4963:0] debug: sending to target: <facebook.com.> 129.134.31.12#53
[1621994003] unbound[4963:0] debug: cache memory msg=34898 rrset=60588 infra=7467 val=35039 subnet=41372
[1621994004] unbound[4963:0] debug: iterator[module 2] operate: extstate:module_wait_reply event:module_event_noreply
[..]
pi@ph5b:~ $ grep -B3 module_event_noreply unbound.good.log
pi@ph5b:~ $
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.