PS: Mein Problem ist unabhängig von Docker!
Den Titel habe ich beim Verschieben direkt aus Deiner Beschreibung abgeleitet.
Es spricht nichts dagegen, Titel und die Kategorisierung anzupassen, wenn Du inzwischen neue Erkenntnisse zu Deiner Situation hast. Auch wenn ich Deinen Beitrag (und etliche Antworten) in ein neues Topic verschoben habe, gehört das natürlich Dir. 
Zum Problem selbst:
Was gibt denn hostname -I bei Dir zurück?
Basiert Deine Geisterjagd auschließlich auf einem Timeout bei diesem dig-Kommando?
Dann könnte es sein, dass die Anfrage schlicht an die falsche IP-Adresse geht, da -I alle Adressen aller Netzwerkadapter des Hosts in nicht vorhersehbarer Reihenfolge auflistet, bis auf link-lokale und Loopback.
Aus man hostname
-I, --all-ip-addresses
Display all network addresses of the host. This option enumerates all configured addresses on all network interfaces. The loopback interface and IPv6 link-local addresses are omitted.
Contrary to option-i, this option does not depend on name resolution. Do not make any assumptions about the order of the output.
Auch wenn ich dig direkt auf die IP meines produktiven Raspi 4 mache kommen timeouts solange ich DNSSEC aktiviert habe. Ich habe mittlerweile den Docker Container abgeschaltet und pihole direkt on the metal installiert.
Ich habe auf einem weiteren Raspi 3 ein frisches Buster und pihole installiert, selbes Bild wie auf dem Raspi 4.
Ich habe auf einem zweiten Raspi 3 ein Backup aus April aufgespielt selbes Bild.
Dann habe ich dieses Backup gelöscht und Stretch sowie pihole installiert, keine Probleme.
Ich habe auf einem weiteren Raspi 3 ein Backup mit Stretch aus Februar aufgespielt keine Probleme.
Ich habe final bei GCP Stretch und pihole installiert, keine Probleme.
Was mir auffällt, das conditional Forwarding hast du auf "fritz.box" konfiguriert, der Hostname deines macbook wird als "macbook.fritz.box" angezeigt, der Hostname deines raspi4 (pi-hole) wird allerdings als "raspi4.local" angezeigt.
DNS-Rebinf läuft mit den domains
raspi4.local
raspi4
raspi4.fritz.box
192.168.178.45
raspberrypi.local
raspberrypi
raspberrypi.fritz.box
raspi3.local
raspi3.fritz.box
192.168.178.34
EDIT:
Aber auch das lässt sich relativieren:
Raspi 3:
Raspi4:
Die Ausnahmen im DNS-Rebind Schutz der FritzBox sind nur relevant, wenn der Pi-hole in der FritzBox als Upstream DNS eingetragen ist, also unter Internet -> Zugangsdaten -> DNS Server, was bei dir ja nicht der Fall ist.
Hast du schon einmal im log unter /var/log/pihole.log nachgeschaut wohin der Query weitergeleitet wird und auch wie?
Und was gibt dig raspi4 @192.168.178.1 für eine Ausgabe.
Zeig auch bitte einmal hier die genaue Ausgabe.
**pi@raspi4** : **~ $** **dig raspi4 @192.168.178.1**
; <<>> DiG 9.11.5-P4-5.1-Raspbian <<>> raspi4 @192.168.178.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1117
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;raspi4. IN A
;; ANSWER SECTION:
raspi4. 9 IN A 192.168.178.45
;; AUTHORITY SECTION:
raspi4. 9 IN NS fritz.box.
;; ADDITIONAL SECTION:
fritz.box. 9 IN A 192.168.178.1
;; Query time: 0 msec
;; SERVER: 192.168.178.1#53(192.168.178.1)
;; WHEN: Di Apr 21 22:06:38 CEST 2020
;; MSG SIZE rcvd: 79
logs sagen (verkürzt):
Raspi3:
21:30:49 dnsmasq[682]: query[A] t.co from 127.0.0.1
21:30:49 dnsmasq[682]: forwarded t.co to 1.0.0.1
21:30:49 dnsmasq[682]: forwarded t.co to 1.1.1.1
21:30:49 dnsmasq[682]: dnssec-query[DS] co to 1.0.0.1
21:30:49 dnsmasq[682]: dnssec-query[DNSKEY] . to 1.0.0.1
21:30:49 dnsmasq[682]: reply . is DNSKEY keytag 48903, algo 8
21:30:49 dnsmasq[682]: reply . is DNSKEY keytag 20326, algo 8
21:30:49 dnsmasq[682]: reply co is DS keytag 10384, algo 8, digest 1
21:30:49 dnsmasq[682]: reply co is DS keytag 10384, algo 8, digest 2
21:30:49 dnsmasq[682]: reply co is DS keytag 21754, algo 8, digest 1
21:30:49 dnsmasq[682]: reply co is DS keytag 21754, algo 8, digest 2
21:30:49 dnsmasq[682]: dnssec-query[DS] t.co to 1.0.0.1
21:30:49 dnsmasq[682]: dnssec-query[DNSKEY] co to 1.0.0.1
21:30:49 dnsmasq[682]: reply t.co is 104.244.42.69
21:30:49 dnsmasq[2371]: query[A] t.co from 127.0.0.1
21:30:49 dnsmasq[2371]: forwarded t.co to 1.0.0.1
21:30:49 dnsmasq[2371]: dnssec-query[DS] t.co to 1.0.0.1
21:30:49 dnsmasq[2371]: dnssec-query[DNSKEY] co to 1.0.0.1
21:30:49 dnsmasq[2371]: reply co is DNSKEY keytag 64278, algo 8
21:30:49 dnsmasq[2371]: reply co is DNSKEY keytag 63993, algo 8
21:30:49 dnsmasq[2371]: reply co is DNSKEY keytag 10384, algo 8
21:30:49 dnsmasq[2371]: reply co is DNSKEY keytag 43834, algo 8
21:30:49 dnsmasq[2371]: reply t.co is no DS
21:30:49 dnsmasq[2371]: validation result is INSECURE
21:30:49 dnsmasq[2371]: reply t.co is 104.244.42.69
Raspi4:
22:25:57 dnsmasq[23132]: query[A] t.co from 127.0.0.1
22:25:57 dnsmasq[23132]: forwarded t.co to 192.168.178.1
22:25:57 dnsmasq[23132]: forwarded t.co to 1.0.0.1
22:25:57 dnsmasq[23132]: forwarded t.co to 1.1.1.1
22:25:57 dnsmasq[23132]: dnssec-query[DS] t.co to 192.168.178.1
22:25:57 dnsmasq[23132]: dnssec-query[DNSKEY] co to 192.168.178.1
22:25:57 dnsmasq[23132]: reply t.co is 104.244.42.133
22:25:57 dnsmasq[25532]: query[A] t.co from 127.0.0.1
22:25:57 dnsmasq[25532]: forwarded t.co to 192.168.178.1
22:26:07 dnsmasq[25534]: query[A] t.co from 127.0.0.1
22:26:07 dnsmasq[25534]: forwarded t.co to 192.168.178.1
22:26:12 dnsmasq[25532]: dnssec-query[DS] t.co to 192.168.178.1
22:26:17 dnsmasq[25535]: query[A] t.co from 127.0.0.1
22:26:17 dnsmasq[25535]: forwarded t.co to 192.168.178.1
22:26:22 dnsmasq[25534]: dnssec-query[DS] t.co to 192.168.178.1
22:26:27 dnsmasq[25532]: dnssec-query[DNSKEY] co to 192.168.178.1
22:26:27 dnsmasq[25532]: reply co is DNSKEY keytag 64278, algo 8
22:26:27 dnsmasq[25532]: reply co is DNSKEY keytag 63993, algo 8
22:26:27 dnsmasq[25532]: reply co is DNSKEY keytag 10384, algo 8
22:26:27 dnsmasq[25532]: reply co is DNSKEY keytag 43834, algo 8
22:26:27 dnsmasq[25532]: reply t.co is no DS
22:26:27 dnsmasq[25532]: validation result is INSECURE
22:26:27 dnsmasq[25532]: reply t.co is 104.244.42.133
22:26:32 dnsmasq[25535]: dnssec-query[DS] t.co to 192.168.178.1
22:26:37 dnsmasq[25534]: dnssec-query[DNSKEY] co to 192.168.178.1
22:26:37 dnsmasq[25534]: reply co is DNSKEY keytag 64278, algo 8
22:26:37 dnsmasq[25534]: reply co is DNSKEY keytag 63993, algo 8
22:26:37 dnsmasq[25534]: reply co is DNSKEY keytag 10384, algo 8
22:26:37 dnsmasq[25534]: reply co is DNSKEY keytag 43834, algo 8
22:26:37 dnsmasq[25534]: reply t.co is no DS
22:26:37 dnsmasq[25534]: validation result is INSECURE
22:26:37 dnsmasq[25534]: reply t.co is 104.244.42.133
22:26:47 dnsmasq[25535]: dnssec-query[DNSKEY] co to 192.168.178.1
22:26:47 dnsmasq[25535]: reply co is DNSKEY keytag 64278, algo 8
22:26:47 dnsmasq[25535]: reply co is DNSKEY keytag 63993, algo 8
22:26:47 dnsmasq[25535]: reply co is DNSKEY keytag 10384, algo 8
22:26:47 dnsmasq[25535]: reply co is DNSKEY keytag 43834, algo 8
22:26:47 dnsmasq[25535]: reply t.co is no DS
22:26:47 dnsmasq[25535]: validation result is INSECURE
22:26:47 dnsmasq[25535]: reply t.co is 104.244.42.133
Raspi4 fragt nochmal die FB:
22:25:57 dnsmasq[23132]: query[A] [t.co](http://t.co) from 127.0.0.1
22:25:57 dnsmasq[23132]: forwarded [t.co](http://t.co) to 192.168.178.1
22:25:57 dnsmasq[23132]: forwarded [t.co](http://t.co) to 1.0.0.1
22:25:57 dnsmasq[23132]: forwarded [t.co](http://t.co) to 1.1.1.1
Ohne DNSSEC Raspi 4 natürlich nur
22:44:53 dnsmasq[26070]: query[A] t.co from 127.0.0.1
22:44:53 dnsmasq[26070]: forwarded t.co to 192.168.178.1
22:44:53 dnsmasq[26070]: forwarded t.co to 1.0.0.1
22:44:53 dnsmasq[26070]: forwarded t.co to 1.1.1.1
22:44:53 dnsmasq[26070]: reply t.co is 104.244.42.5
Der fragt nicht nur zusätzlich noch die FritzBox, was er eigentlich nur tun sollte, wenn diese als Upstream DNS im Pi-hole konfiguriert ist, sondern der dnssec-query geht ausschließlich an die FritzBox. Wird aber von dieser auch beantwortet und es gibt auch einen reply auf den query für t.co.
Daher kann ich den "N/A" Reply hier nicht nachvollziehen