I’m not a fan of running as --net=host. It can be a security risk in some situations. There should be a more elegant solution.

I think the issue may be with having the interface set to 127.0.0.1. With Docker networking, that’s probably not doing what you think/want. Try this instead:

    # The  port  number,  default  53, on which the server responds to queries.
    port: 5335
    # Listen to for queries from clients and answer from this network interface
    # and port.
    interface: 0.0.0.0@5335

Is there a reason you need it to be on port 5335? I know you want to avoid a conflict with Pi-hole, but you should be able to change the public port and keep the container port on 53 if you like (i.e., publish=5335:53/tcp --publish=5335:53/udp). It may be worth trying since the issue seems somewhat port related. If you do, just swap out 5335 with 53 in the port and interface settings.

You may also want to add the following to your config (by default only localhost is allowed and the rest are refused):

    access-control: 127.0.0.1/32 allow
    access-control: 192.168.1.1/24 allow
    access-control: 172.16.0.0/12 allow
    access-control: 10.0.0.0/8 allow

One other issue I see appears to be related to the log file location. The specified path (/opt/unbound/etc/unbound/unbound.log) does not exist by default within the container which is likely why it’s giving a permission denied error (that and it’s in the default chroot location and root privileges are dropped after the port is bound). I don’t think that’s causing your problem, but may still be worth resolving.

I don’t currently run Pi-hole with Unbound so the others on here may be of more help than me. If you haven’t already, you might also look over https://github.com/MatthewVance/unbound-docker/issues/35.

Please report future issues related to the unbound-rpi image at https://github.com/MatthewVance/unbound-docker-rpi.

You should remove so-rcvbuf: 1m from your config to use the default (the default inherits the underlying system value). Your config should no longer cause a conflict because it will match whatever value used by the base OS image (i.e., the FROM debian:stretch in the Dockerfile).

so-rcvbuf is for performance, not Pi-hole functionality (see Unbound documentation included below for reference). I doubt your Raspberry Pi will experience enough load to worry about such optimizations (if extra Unbound optimization is needed beyond the defaults, you probably shouldn’t be running on a Pi).

While you could spend the time to optimize the image to support a higher value, it wouldn’t be worth the trouble. If you want some increased performance custom tuned to your Pi, look at how the shell script that builds the default conf file dynamically calculates values based on OS support.

Also keep in mind that Docker is a container, not a full VM. One way this difference comes into play is with permissions. While the Docker service may be run as a root user and a container often runs as root user by default, the root user in a running container does not have full rights to change the underlying Docker host. By default, Docker uses the Linux capabilities support to limit the rights of the “root” user within the container. See https://docs.docker.com/engine/security/security/#linux-kernel-capabilities.

It’s also worth noting this particular Unbound image runs Unbound within the container as the user _unbound, not as the “root” user by default. However, your config doesn’t appear to set username: "_unbound", meaning you’re missing out on the improved security from dropping user privileges.

From Howto Optimise:

Set so-rcvbuf to a larger value (4m or 8m) for a busy server. This sets 
the kernel buffer larger so that no messages are lost in spikes in the 
traffic...The OS caps it at a maximum, on linux unbound needs root 
permission to bypass the limit, or the admin can use 
sysctl net.core.rmem_max.
...
    # Larger socket buffer.  OS may need config.
    so-rcvbuf: 4m

From Unbound documentation:

so-rcvbuf: <number>
              If not 0, then set the SO_RCVBUF socket option to get more  buf-
              fer space on UDP port 53 incoming queries.  So that short spikes
              on busy servers do not drop  packets  (see  counter  in  netstat
              -su).   Default  is 0 (use system value).  Otherwise, the number
              of bytes to ask for, try "4m" on a busy server.  The OS caps  it
              at  a  maximum, on linux unbound needs root permission to bypass
              the limit, or the admin can use  sysctl  net.core.rmem_max.   On
              BSD  change kern.ipc.maxsockbuf in /etc/sysctl.conf.  On OpenBSD
              change header and recompile kernel. On Solaris ndd -set /dev/udp
              udp_max_buf 8388608.

If it helps, the unbound.conf file I use on my Pi currently is:

server:
    verbosity: 1
    num-threads: 3
    interface: 0.0.0.0@53
    so-reuseport: yes
    edns-buffer-size: 1472
    delay-close: 10000
    cache-min-ttl: 60
    cache-max-ttl: 86400
    do-daemonize: no
    username: "_unbound"
    log-queries: no
    hide-version: yes
    hide-identity: yes
    identity: "DNS"
    harden-algo-downgrade: yes
    harden-short-bufsize: yes
    harden-large-queries: yes
    harden-glue: yes
    harden-dnssec-stripped: yes
    harden-below-nxdomain: yes
    harden-referral-path: no
    do-not-query-localhost: no
    prefetch: yes
    prefetch-key: yes
    qname-minimisation: yes
    aggressive-nsec: yes
    ratelimit: 1000
    rrset-roundrobin: yes
    minimal-responses: yes
    chroot: "/opt/unbound/etc/unbound"
    directory: "/opt/unbound/etc/unbound"
    auto-trust-anchor-file: "var/root.key"
    num-queries-per-thread: 4096
    outgoing-range: 8192
    msg-cache-size: 260991658
    rrset-cache-size: 260991658
    neg-cache-size: 4M
    serve-expired: yes
    unwanted-reply-threshold: 10000
    use-caps-for-id: yes
    val-clean-additional: yes
    tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
    private-address: 10.0.0.0/8
    private-address: 172.16.0.0/12
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: fd00::/8
    private-address: fe80::/10
    private-address: ::ffff:0:0/96
    access-control: 127.0.0.1/32 allow
    access-control: 192.168.1.1/24 allow
    access-control: 172.16.0.0/12 allow
    access-control: 10.0.0.0/8 allow
    include: /opt/unbound/etc/unbound/a-records.conf
    forward-zone:
        name: "."
        forward-addr: 1.1.1.1@853#cloudflare-dns.com
        forward-addr: 1.0.0.1@853#cloudflare-dns.com
        forward-addr: 2606:4700:4700::1111@853#cloudflare-dns.com
        forward-addr: 2606:4700:4700::1001@853#cloudflare-dns.com
        forward-tls-upstream: yes
    remote-control:
        control-enable: no

Excellent. Everything else working now?

On Sat, Jul 13, 2019, 8:54 PM nlt6444 notifications@github.com wrote:

Thank you I added the additional options from your script.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/MatthewVance/unbound-docker/issues/21?email_source=notifications&email_token=AAUMHOX6YC2EAVH3I3HCDD3P7KBNVA5CNFSM4H4LYPE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ34QXQ#issuecomment-511166558, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUMHOW46FQZIP276NDCT7TP7KBNVANCNFSM4H4LYPEQ .

You should also consider adding more of the config options I provided in the example config file. While the Unbound guide on the Pi-hole site applies a few security and privacy tricks, I took quite a bit of care to take advantage of several more such features.

The main ones Unbound supports that are not currently taken advantage of are related to running Unbound as a recursive server. Those are things like the root.hints you added and some TLS server related settings (see https://github.com/MatthewVance/unbound-docker/issues/13 and https://github.com/MatthewVance/unbound-docker/issues/14).