Need help and techniques to debug DNS failure on Facebook and Instagram using Pihole with Unbound

pedz · May 22, 2021, 6:24pm

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

Expected Behaviour:

I set "Facebook.com" and "instagram.com" into my white list and I would expect "dig www.instagram.com" to return an IP address. Usually it does not but sometimes it does.

Also, a command such as "dig @127.0.0.1 -p 5335 www.instagram.com" which I assume is directly querying the Unbound DNS server returns the same answer. I suspect this isn't a Pihole problem but I have nowhere else to turn to.

Actual Behaviour:

One return (not always) is:

; <<>> DiG 9.10.6 <<>> www.instagram.com
;; global options: +cmd
;; connection timed out; no servers could be reached

Other returns are:

; <<>> DiG 9.10.6 <<>> www.instagram.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63492
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;www.instagram.com. IN A
;; Query time: 16 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat May 22 13:09:41 CDT 2021
;; MSG SIZE rcvd: 46

Also, FYI:

$ pihole -q www.instagram.com
[i] No results found for www.instagram.com within the block lists

$ pihole -q www.facebook.com
[i] No results found for www.facebook.com within the block lists

Debug Token:

(Moderator edit: Explicit debug log removed)

bigpcjunky · May 22, 2021, 9:40pm

I'm not a pihole expert so I don't have a clue about the debug token stuff... But I did finally get my unbound and pihole installation working right so I do have a couple of suggestions.

I'm assuming pihole was working fine before you installed unbound. If not you might consider uninstalling unbound and getting pihole to work first.

Run unbound-checkconf to verify your unbound conf file is error free. If you haven't already done it setup the unbound log file. Also enable the unbound-control features with 'control-enable: yes' in the conf file (I think it should be part of the pihole/unbound docs). It allows you to run unbound-control commands that help with debugging.

I set 'statistics-cumulative: yes' and 'extended-statistics: yes'. Honestly not sure if they were necessary but I wanted to do 'unbound-control stats_noreset' command to check the number of queries. In my case I don't think the number never got above 100 as I think the unbound service kept restarting so unbound wasn't caching things.

I think those few things should help you get started.

pedz · May 22, 2021, 11:15pm

Thank you. unbound-checkconf says its happy. Pihole was / is working ok except for these two domains. I can query instagram.com but not www.instagram.com for example. www.instagram.com is an aliases for something within facebook.com and that seems to be what is hit and miss.

My Pihole was working except I could not get archive.is. This page suggested installing unbound which solved that problem.

bigpcjunky · May 22, 2021, 11:59pm

Adding facebook and instagram to my white list doesn't change anything for me. They resolve for me with or w/o them being in the white list.

Are digs to other urls getting 'connection timed out; no servers could be reached' errors? I think I got that error when the dns on one of my devices wasn't setup but that wouldn't explain why it works for you sometimes.

I set 'listen on all interfaces' in the dns settings in pihole and that seemed to help me with all the random devices I have on my network.

Bucking_Horn · May 23, 2021, 5:10am

(We do not ask for the complete Debug Log, but just for the Debug Token.)

That assumption is correct.
As this is specific to a few domains only, Pi-hole could be involved by blocking access to those domains.
By default, Pi-hole would answer requests for blocked domains with status NOERROR and IP 0.0.0.0. SERVFAIL indicates one of Pi-hole's upstreams returned an error, and you also already explicitly verified (pihole-q) that Pi-hole isn't blocking those domains.

Intermittent SERVFAILs are not uncommon, but you'll hardly ever notice them.
If they persist over a longer period, a DNS server authoritative for that domain may be down, or something is interfering with DNS resolution (outside of your network) - see recent Pi-hole unbound servfail where an ISP was filtering DNS requests (also for further leads on troubleshooting).

pedz · May 23, 2021, 5:40pm

I created an unbound.conf within my home directory that was a copy of what is in /etc/unbound/unbound.conf.d. I changed the port as well as the service port. I added some debugging options and set verbosity to 4. Then I start it with "unbound -d -d -c ~/unbound.conf" Then I would do "dig" to the new port (5388) of www.instagram.com. After about 15 seconds, it would time out (as mentioned above). But a second dig would return with the correct answer. Watching the log as it spews to the screen, I could see the answer come a few seconds after the first request timed out.

One thing that is weird is this would also "fix" the other unbound so I guess the two must be sharing some resources. It's too bad I don't know what I'm doing

In the working case, unbound would eventually conclude "serviced query: EDNS works for ip4 185.89.218.11 port 53 (len 16)" but in the nonworking log, that would never happen. Then 185.89.218.11 would reply with the address that was requested.

Also, someone else in another forum suggested I remove unbound from the Pi-hole config and test using Google. This works fine and the return is very quick.

My conclusion is for some reason unbound normally isn't recognizing 185.89.218.11 as working with EDNS. I don't even know what that means or implies but I see it sending probes with timeouts. Perhaps with all of my hops, those requests are timing out too soon? Perhaps there is a timeout or a time to live that I need to adjust.

I'm starting to lean towards just having Google or someone else be my upstream resolver but I would like to understand what is happening.

Thank you all for the help.

deHakkelaar · May 24, 2021, 12:10pm

For diagnosing, configure something else in Pi-hole for upstream DNS resolution (not unbound).
You can do below to output verbose debug logging for unbound to screen (dont need to change port etc):

sudo service unbound stop

sudo /usr/sbin/unbound -ddd -vvv -c /etc/unbound/unbound.conf

Inspect for errors/warnings when started and see whats logged when you do below dig in another SSH session:

dig @localhost -p 5335 a www.instagram.com.

EDIT: Might want to compare with a dig for another domain that you know works.

When finished, you can break with CTRL-C and startup unbound again via init/systemd:

sudo service unbound start

And configure Pi-hole again to use unbound upstream when finished diagnosing.
Did you read below mentioned thread/link and tried some of those commands/queries for your troubled SERVFAIL domain?

pedz · May 24, 2021, 8:12pm

Thank you. This is easier testing now. I am getting the same basic results. A dig times out after 18 seconds with no answer. A second dig returns after a second with an answer and I can see that the answer is coming in the 5 to 10 seconds I pause between the two requests. Also, I did go through the other thread and picked up some tips. I'm also comparing the resolve of www.google.com (working) to www.instagram.com (not working) and www.facebook.com (also not working) but I don't really know what I'm looking for. An egrep of fail|warn|trust turns up very little.

I'm wondering if it is safe for me to post the log file to someplace like pastebin and ask someone to look through it.

deHakkelaar · May 24, 2021, 10:36pm

If large, yes Pastbin is fine.
And yes is safe, no sensitive date and you can oc review first.
One for just the starting of unbound.
And a second Pastbin with just the lines that appear when you query with the dig I posted.
Make sure you dont have unbound configured in Pi-hole for upstream so nothing else will be querying unbound while you capture the log entries.
You have to do it in one go, start unbound and run one dig afterwards bc unbound does caching!
I'll try and decipher

pedz · May 25, 2021, 12:27am

I have the time stamps so you can easily tell the start up from the query. I've also added comments.

Two pastebins. One is non-working
The other is working (dig of www.google.com)

Thank you very much for your time and effort

deHakkelaar · May 25, 2021, 3:57pm

[1621901688] unbound[27426:0] notice: Start of unbound 1.6.7.

Your unbound version is hopelessly outdated:

pi@ph5b:~ $ sudo /usr/sbin/unbound -ddd -vvv -c /etc/unbound/unbound.conf
[1621951618] unbound[16992:0] notice: Start of unbound 1.9.0.

May 24 19:14:48 unbound[27426:0] debug: Reading root hints from /var/lib/unbound/root.hints

Where does above root hints come from ?

dpkg -S root.hints

You dont have to separately download the root hints.
This will get installed automatically when installing unbound (with most current distros) and at a different location:

pi@ph5b:~ $ apt depends unbound
[..]
  Depends: dns-root-data
[..]

pi@ph5b:~ $ apt policy dns-root-data
[..]
  Installed: 2019031302
[..]

pi@ph5b:~ $ dpkg -L dns-root-data
[..]
/usr/share/dns/root.hints
[..]

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).
[..]

unbound will use this root.hints file default OOTB.

Your log output differs from mine maybe because your running an older version and/or
I'm guessing you've started unbound differently as I ~~requested~~ suggested because your logs show actual times instead of Unix epoch.
I tried to look where goes wrong but there is so much recursion going on into the different domains involved.
And with the differences in log output, its too difficult for me to trace where goes wrong.
Also that old unbound version could be bugged.
If you could get unbound to the current release v1.9, I'm willing to try investigate again.

pedz · May 25, 2021, 4:46pm

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.

deHakkelaar · May 25, 2021, 4:51pm

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).

pedz · May 25, 2021, 4:58pm

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.

deHakkelaar · May 25, 2021, 5:00pm

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.

pedz · May 26, 2021, 2:02am

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.

deHakkelaar · May 26, 2021, 6:25pm

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

deHakkelaar · May 26, 2021, 9:14pm

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.

pedz · May 26, 2021, 9:30pm

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

deHakkelaar · May 26, 2021, 9:39pm

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: