search

pi-hole / docker-pi-hole

Pi-hole in a docker container
https://pi-hole.net
Other
8.31k stars 1.11k forks source link

Pi-hole in Docker fails to connect to Encrypted Unbound DNS #1118

Closed AziaRae closed 2 years ago

AziaRae commented 2 years ago

This is a:

Details

I want to use Pi-hole with Unbound as Local DNS. Both Pi-hole and Encrypted Unbound seems to be working fine on their own. Pi-hole can block ads when Quad9 is used as Upstream DNS, and Unbound can dig websites without fail. When I try to set Unbound as Upstream DNS Server however, I no longer am able to connect to any website.

Related Issues

How to reproduce the issue

  1. Environment data

    • Operating System: Arch Linux x86_64
    • Hardware: VivoBook_ASUSLaptop X515EA_X515EA 1.0
    • Kernel Architecture: 5.18.3-arch1-1
    • Docker Install Info and version:
    • Software source: OS provided package (sudo pacman -Syu --needed docker docker-compose)
    • Hardware architecture: x86_64

  2. docker-compose.yml contents, docker run shell command, or paste a screenshot of any UI based configuration of containers here docker-compose.yml config

    
version: "3"

More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/

services: pihole: container_name: pihole image: pihole/pihole:latest

For DHCP it is recommended to remove these ports and instead add: network_mode: "host"

ports:
  - "127.0.0.1:53:53/tcp"
  - "127.0.0.1:53:53/udp"
  - "127.0.0.1:80:80/tcp"
environment:
  TZ: 'America/Chicago'
  # WEBPASSWORD: 'set a secure password here or it will be random'
# Volumes store your data between container upgrades
# privileged: true
volumes:
  - './etc-pihole:/etc/pihole'
  - './etc-dnsmasq.d:/etc/dnsmasq.d'    
#   https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
cap_add:
  - NET_ADMIN # Required if you are using Pi-hole as your DHCP server, else not needed
restart: unless-stopped
Then, I created Pi-hole using the `sudo docker-compose up -d pihole` command

3. Install Unbound via `sudo pacman -S --needed unbound`
4. Edit `/etc/unbound/unbound.conf `
This is my `/etc/unbound/unbound.conf `:

server:

If no logfile is specified, syslog is used

logfile: /var/log/unbound/unbound.log
verbosity: 0

interface: 127.0.0.1@5335
port: 5335
do-ip4: yes
do-udp: yes
do-tcp: yes

# Provide TLS on port 853
interface: 127.0.0.1@853
tls-port: 853

# May be set to yes if you have IPv6 connectivity
do-ip6: no

# You want to leave this to no unless you have *native* IPv6. With 6to4 and
# Terredo tunnels your web browser should favor IPv4 for the same reasons
prefer-ip6: no

# Use this only when you downloaded the list of primary root servers!
# If you use the default dns-root-data package, unbound will find it automatically
#root-hints: /var/lib/unbound/root.hints

# Trust glue only if it is within the server's authority
harden-glue: yes

# Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
harden-dnssec-stripped: yes

# Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
# see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
use-caps-for-id: no

# Reduce EDNS reassembly buffer size.
# IP fragmentation is unreliable on the Internet today, and can cause
# transmission failures when large DNS messages are sent via UDP. Even
# when fragmentation does work, it may not be secure; it is theoretically
# possible to spoof parts of a fragmented DNS message, without easy
# detection at the receiving end. Recently, there was an excellent study
# >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<<
# by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/)
# in collaboration with NLnet Labs explored DNS using real world data from the
# the RIPE Atlas probes and the researchers suggested different values for
# IPv4 and IPv6 and in different scenarios. They advise that servers should
# be configured to limit DNS messages sent over UDP to a size that will not
# trigger fragmentation on typical network links. DNS servers can switch
# from UDP to TCP when a DNS response is too big to fit in this limited
# buffer size. This value has also been suggested in DNS Flag Day 2020.
edns-buffer-size: 1232

# Perform prefetching of close to expired message cache entries
# This only applies to domains that have been frequently queried
prefetch: yes

# One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
num-threads: 1

# Ensure kernel buffer is large enough to not lose messages in traffic spikes
so-rcvbuf: 1m

# Ensure privacy of local IP ranges
private-address: 192.168.0.0/16
private-address: 169.254.0.0/16
private-address: 172.16.0.0/12
private-address: 10.0.0.0/8
private-address: fd00::/8
private-address: fe80::/10

do-not-query-localhost: no
tls-system-cert: yes
tls-cert-bundle: "/etc/ssl/cert.pem"

control which clients are allowed to make (recursive) queries

access-control: 127.0.0.1/32 allow_snoop access-control: ::1 allow_snoop access-control: 127.0.0.0/8 allow access-control: 192.168.1.0/24 allow

Upstream Servers

forward-zone: name: "." forward-tls-upstream: yes forward-addr: 9.9.9.9@853#dns.quad9.net forward-addr: 149.112.112.112@853#dns.quad9.net

5. Download root.hints
`wget https://www.internic.net/domain/named.root -qO- | sudo tee /var/lib/unbound/root.hints`
6. Enable unbound
`sudo systemctl enable --now unbound`
7. Test if unbound is working properly

╰─>$ dig sigfail.verteiltesysteme.net @127.0.0.1 -p 5335

; <<>> DiG 9.18.3 <<>> sigfail.verteiltesysteme.net @127.0.0.1 -p 5335 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 51854 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 2766 msec ;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP) ;; WHEN: Fri Jun 17 01:24:22 +08 2022 ;; MSG SIZE rcvd: 57

╰─>$ dig sigok.verteiltesysteme.net @127.0.0.1 -p 5335

; <<>> DiG 9.18.3 <<>> sigok.verteiltesysteme.net @127.0.0.1 -p 5335 ;; global options: +cmd ;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23492 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION: sigok.verteiltesysteme.net. 30 IN A 134.91.78.139

;; Query time: 2073 msec ;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP) ;; WHEN: Fri Jun 17 01:24:05 +08 2022 ;; MSG SIZE rcvd: 71

8. Change your DNS servers to `127.0.0.1` in `/etc/resolv.conf`

╰─>$ cat /etc/resolv.conf

Generated by resolvconf

nameserver 127.0.0.1 nameserver ::1 options trust-ad


9. Open Pi-hole in your browser, then add `127.0.0.1#5335` as a Custom Upstream DNS Server, then save it
![Screenshot 2022-06-16 at 17-39-38 Pi-hole - fd54d6c0a3fa](https://user-images.githubusercontent.com/78289561/174309223-0d6b72de-ef70-4e12-86d2-02ab01eff6b1.png)
10. Load any website you want

## These common fixes didn't work for my issue
<!-- IMPORTANT! Help me help you! Ordered with most common fixes first. -->
- [x] I have tried removing/destroying my container, and re-creating a new container
- [x] I have tried fresh volume data by backing up and moving/removing the old volume data
- [x] I have tried running the stock `docker run` example(s) in the readme (removing any customizations I added)
- [x] I have tried a newer or older version of Docker Pi-hole (depending what version the issue started in for me)
- [x] I have tried running without my volume data mounts to eliminate volumes as the cause
- [x] Adding the `--privileged` flag in the `docker-compose.yml`
rdwebdesign commented 2 years ago

Open Pi-hole in your browser, then add 127.0.0.1#5335 as a Custom Upstream DNS Server, then save it

You are pointing your "Custom DNS" to the container you are running Pi-hole. Try to use the host's IP.

github-actions[bot] commented 2 years ago

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.