Questions concerning [How To] Install Pi-Hole in Docker

  • Yes, I've seen your note about port 53 versus port 5353. I'm running OMV directly on an Orange Pi PC2. I just want to do some tests with Pihole/Unbound for eventually installing it to a separate machine afterwards. AFAIK a Docker Image under macvlan can only talk to its host doing something like this. Maybe I'm wrong but I couldn't get Docker-pihole talking to Unbound running on OMV host, so i installed a Docker Unbound image which also uses macvlan. After adjusting some things like interface and access-control in unbound.conf, it's running perfectly now.

    • Offizieller Beitrag

    The Pi-hole docker, with a MacVlan interface, works with an OMV host on Arm64 architectures. And I know that with unbound direct installed on OMV running on a X64 host, with Pi-hole in a Docker (w/MacVlan) works as well.


    What I haven't tested is Pi-hole in a Docker, using a MacVlan interface, with unbound direct installed on OMV running an ARM64 platform. While they're close to X64 builds, SBC images have tweaks for running OMV/Debian on ARM64.


    But you're up and running so, as they say, "all's well that ends well".

  • Yes, I've seen your note about port 53 versus port 5353. I'm running OMV directly on an Orange Pi PC2. I just want to do some tests with Pihole/Unbound for eventually installing it to a separate machine afterwards. AFAIK a Docker Image under macvlan can only talk to its host doing something like this. Maybe I'm wrong but I couldn't get Docker-pihole talking to Unbound running on OMV host, so i installed a Docker Unbound image which also uses macvlan. After adjusting some things like interface and access-control in unbou, it's running perfectly now.

    For what it is worth, I also have both Pi-Hole and Unbound running in separate Docker containers, both with macvlan. Except for finding an Unbound image which would run on a Raspberry Pi, I had no problems whatsoever.

  • klutchell/unbound has images for arm and arm64.
    I'm using this image on my Orange Pi PC2.


    Did the wget -O root.hints https://www.internic.net/domain/named.root
    in the mounted config directory and created unbound.conf with the values
    from the pi-hole howto with the following changes:
    changed port: 5353 to port: 53 and
    root-hints: "/var/lib/unbound/root.hints" to
    root-hints: "/opt/unbound/etc/unbound/root.hints"
    added:
    interface: <my unbound docker macvlan IP>
    access-control: <my pihole docker macvlan IP> allow
    auto-trust-anchor-file: "/opt/unbound/etc/unbound/var/root.key"
    qname-minimisation: yes


    Option so-rcvbuf: 1m in the config needs Docker extra argument --cap-add=NET_ADMIN

    • Offizieller Beitrag

    @flmaxey with the two dig tests, you change the port numbers. Do you not also change the address? Shouldn't it be the address of the omv server?:


    dig sigfail.verteiltesysteme.net @127.0.0.1 -p 53
    dig sigok.verteiltesysteme.net @127.0.0.1 -p 53


    When I run the tests as above, they each return as described in the how-to. I have tried it substituting my server's address and the tests time out.


    With regard to the configuration section, I am assuming the /etc/unbound/unbound.conf.d/pi-hole.conf in the configure section means for me to nano /etc/unbound/unbound.conf.d/pi-hole.conf and copy/paste the contents of the next section and save. I'm sorry to be such a doubting Thomas but when I got pihole up and running I saw immediate results with vanishing ads. With unbound I don't know what I'm looking for.


    Another aspect of what troubles me is that both LAN and WIFI devices worked with just pihole, but when I implemented unbound with the custom upstream server everything on WIFI couldn't access the internet. When I go back and select one of the listed upstream servers everything works fine again. I have also noticed that since I started pihole yesterday, the blocked percentage has crept down to below 3% from an initial 10% or more. Is that normal? I wondered if unbound had anything to do with that.

    • Offizieller Beitrag

    @flmaxey with the two dig tests, you change the port numbers. Do you not also change the address? Shouldn't it be the address of the omv server?:

    If installed by the How-To, (which is a direct install of unbound to the OMV host) 127.0.0.1 "is" the OMV server.


    dig sigfail.verteiltesysteme.net @127.0.0.1 -p 53
    dig sigok.verteiltesysteme.net @127.0.0.1 -p 53

    If you read the pi-hole doc's install procedure for unbound:
    The first command, above, is intended to fail.
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4683


    The second command works.
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60166


    The above are the expected results. If you're getting something else, something is wrong with unbound.

    With regard to the configuration section, I am assuming the /etc/unbound/unbound.conf.d/pi-hole.conf in the configure section means for me to nano /etc/unbound/unbound.conf.d/pi-hole.conf and copy/paste the contents of the next section and save.

    Your assumptions are correct. Nano is a bit more difficult than WinSCP, but any editor can used. (One that supports copy and paste is preferred.) If the configuration from here is saved to a file under /etc/unbound/unbound.conf.d/ that ends with .conf ( pi-hole.conf from the doc ) it will be merged when unbound starts.


    Another aspect of what troubles me is that both LAN and WIFI devices worked with just pihole, but when I implemented unbound with the custom upstream server everything on WIFI couldn't access the internet. When I go back and select one of the listed upstream servers everything works fine again.

    I don't know what "everything" on wifi is but, did you mentioned I-phones? (I'm not sure if that was you or someone else.) The configuration supplied for unbound kills IPv6 (do-ip6: no). It might have something to do with that.
    There's a configuration option for pi-hole that kills IPv6, in the How-To, if you added it. ( /dockerparms/pihole/pihole-FTL.conf . After the file is created, add the line AAAA_QUERY_ANALYSIS=no)

    If IPv6 is enabled in pi-hole and not enabled in unbound, that might be an indicator. For ease of configuration, I would go through all my devices (to include your router) and force them to IPv4 (conservative and safe). Alternately, setup unbound and pi-hole for IPv6.


    I have also noticed that since I started pihole yesterday, the blocked percentage has crept down to below 3% from an initial 10% or more. Is that normal?

    Define "normal". :) Frankly, I don't know. My block rate is 70%, but I have pi-hole blocking all IPv6 and I do surf venues outside of gardening. :)
    In pi-hole, under settings, blocklists, I have the default 7 lists active with no custom add-on's.


    You might have a problem with an alternate DNS address configured somewhere, that's bypassing pi-hole. I'd check your router and set ANY DNS address setting (even on the WAN side of your router) to pi-holes IP. The same goes for your clients and devices.
    I point all statically addressed LAN clients to the router, for DNS. (DHCP clients get their DNS address from the DHCP server, which is the router.) The router is pointed to pi-hole. Pi-hole is pointed to unbound. There are no alternates. (BTW: unbound has nothing to do with "blocking".)


    I'm sorry to be such a doubting Thomas

    Romans 14:1 applies

    • Offizieller Beitrag

    I did run the tests as shown above and did get those results. I was just uncertain because of the problem with the iPhones/iPad/laptop (yes, it was I).


    I guess I misinterpreted when you wrote in your how-to:


    Zitat von @flmaxey

    At the end of the installation:



    To configure Pi-hole (which is running in a Docker with a separate IP
    address) to look at OMV/unbound as it's up-stream DNS server; 127.0.0.1#5353 cannot be used.

    I don't understand what you mean when you said above "127.0.0.1 "is" the OMV server" but I will accept that. I thought my pihole-dedicated rpi3 was known by the ip address I set in the "network" tab.


    This is just how much I know about networking and the internet. I am aware of the creation of a new naming scheme because the old one is running out of available addresses (that is how I understand it) but I don't know why it is blocked in the unbound config file, and I certainly did not know that it had anything to do with my iPhone. I did not add the extra IPv6 file in your how-to, but I did kill IPv6 in the unbound config. Is there any security reason I should leave that as "no"?


    Thank you for your gracious help.

    • Offizieller Beitrag
    Zitat von @flmaxey

    At the end of the installation:


    To configure Pi-hole (which is running in a Docker with a separate IP
    address) to look at OMV/unbound as it's up-stream DNS server; 127.0.0.1#5353 cannot be used.

    This applies when configuring a Pi-hole install, that's running in a Docker, with a separate IP address. If you used 127.0.0.1 in pi-hole, as described in the unbound document, you'd be sending all DNS queries to the Docker container itself which has no mechanism for dealing with them.


    I don't understand what you mean when you said above "127.0.0.1 "is" the OMV server" but I will accept that. I thought my pihole-dedicated rpi3 was known by the ip address I set in the "network" tab.

    There is no place like 127.0.0.1 AKA, "home" or the local host.
    If you're on your OMV server's command line, you can ping the server's IP address, or 127.0.0.1, interchangeably. (They are the same thing.)


    The thing to note in both instances above is, the OMV server is not the same as pi-hole running in a Docker container. (Pi-hole, running in a Docker, is a type of Virtual Machine.) They are two completely different hosts, using two different IP addresses. Once a name query passes through Pi-hole, it must be forwarded to a DNS server. If you use 127.0.0.1, in pi-hole, name queries would not leave the the pi-hole Docker-container. They won't go anywhere. If you use OMV's IP address, where unbound is installed, unbound (a DNS server itself) knows what to do with the name query and begins a resolution process with it's list of root DNS servers.


    Similarly, (from the HOW-TO) if you execute this command on the OMV server's command line:
    dig pi-hole.net @127.0.0.1 -p 53
    The answer will not come from the local host (127.0.0.1) which is the intended purpose of this particular test. This works only when pi-hole is direct installed on the local host - not in a Docker. (When using the standard DNS port 53, in this command, an answer may come from pi-hole.net which are up-line servers on the internet. Again, not the intended purpose of thid test.)


    This is just how much I know about networking and the internet. I am aware of the creation of a new naming scheme because the old one is running out of available addresses

    From a pure networking stand point, as of the introduction of CIDR and with the private networks considered, IPv4 still has plenty of address space if managed reasonably well. For example, the 10.X.X.X is reserved for private use. The "10" network has over 16 million possible addresses. Even the largest corporations would have trouble using that many addresses but, if they did, there's a few class B private networks as well. For these reasons the adoption of IPv6 has been, and will be, slow.


    Manufactures want IPv6 for one basic reason; they want the ability to give all devices it's own unique address (cars, refrigerators, heating/ac systems, a thermostat, really anything with an embedded CPU and networking ability). This would solve a lot of support problems for them, to include device identification, serialization, remote diagnostics, etc. With IPv6 using a 128 bit address structure, something in the neighborhood of 2128 addresses are possible. Saying "that's a BIG number" doesn't do it justice.


    I don't know why it is blocked in the unbound config file, and I certainly did not know that it had anything to do with my iPhone. I did not add the extra IPv6 file in your how-to, but I did kill IPv6 in the unbound config. Is there any security reason I should leave that as "no"?

    I really don't know about issues with "I-things". (Do you have an Apple AirPort router as well?)
    Unbound doesn't block anything but IPv6 because, as previously noted, it's configured to do so. If you want unbound to pass IPV6 as a test, edit the unbound config file - specifically set;
    ip6: yes.
    It won't hurt anything as a test.
    Another change you might consider, just as a test, is;
    harden-dnssec-stripped: no
    Changes to the above should be followed by:
    service unbound stop


    service unbound start


    IPv6 and security:
    The address structure is fine. It's the implementation of the address structure in software, and potentially in the network stack, where the hacks will find holes. For this reason, I will not adopt IPv6 until it's much more widely used. (But I don't have devices that require it.)

    • Offizieller Beitrag

    @flmaxey Yes I did run an AirPort Extreme until I bought a Netgear R7000 (Tomato firmware). It had about four settings and couldn't handle port forwarding (or I couldn't figure out how). The Tomato router has about four hundred settings and I have figured out about fifteen of them. I still use the AirPort (two of them, actually) in bridge mode to extend the network/wifi to the outer reaches around the house.


    What an education! I have wondered why if we are running out of addresses there doesn't appear to be much evidence of it.


    Thanks for the stop/start command. I figured there must be something like that. I will give those two settings a try, each separately, and check back.


    At the bottom of pihole's Settings/DNS there are some check boxes. One is to "Use DNSSEC". Should that be checked?
    Thanks again.

    • Offizieller Beitrag

    DNSSEC is a very good idea, and a good reason for using pi-hole and unbound. With the use of the three together, DNSSEC is enforced so a "man in the middle" DNS attack is unlikely. Check the DNSSEC box in pi-hole and, if at all possible, run unbound with the setting in the unbound config - harden-dnssec-stripped: yes

    • Offizieller Beitrag

    I'm beginning to think there is something with my router settings preventing unbound. There is a check box in basic network settings to enable DNSSEC. Under Advanced Settings there is an area for Custom Configuration of Dnsmasq. Notes at the bottom of that page read "Custom configuration - Extra options to be added to the Dnsmasq configuration file." and "The contents of file /etc/dnsmasq.custom are also added to the end of Dnsmasq's configuration file (if it exists)." Associated with anything Dnsmasq I cannot find any check box to disable it. I noticed at the very first of the section of your how-to on unbound where you say that unbound doesn't work if dnsmasq plugin installed with OMV. Maybe I have a similar situation with my router.


    I'm headed to bed. Thanks for your help. Let me know if you have anything. Don't forget to change your clocks.

    • Offizieller Beitrag

    I noticed at the very first of the section of your how-to on unbound where you say that unbound doesn't work if dnsmasq plugin installed with OMV. Maybe I have a similar situation with my router.

    This doesn't apply to your router. This is about having two different DNS functions (dnsmasq and unbound) running on the same host at the same time.
    __________________________________________


    The dnsmasq function, on the router, handles DHCP. If you disabled it, somehow, you'd have to transfer the DHCP function to pi-hole. That's probably not a good idea. If your server crashed and burned, with DHCP handled by the router, all you'd need to do to recover is add a DNS server IP at the router and your clients would be back up.


    I can't think of a reason "why" a router would block unbound only. Have you tried disabling IPv6 at the router, in pi-hole (add the file), and unbound (the default config)?


    (Or) Do you have a spare R-PI?

    • Offizieller Beitrag

    No but I do have an Odroid XU4, and it just happens to have pihole already on it, but not unbound. I set both machines up with a fresh omv a few days ago and ran the pihole docker on both of them but didn’t get to unbound on the XU4 because the R-Pi was doing so well.


    I can’t try it out till later today, probably this evening. Thanks for the clarification. I’m pretty sure IPv6 is already disabled at the router. I just looked at your section on adding that file to pihole and it looks clear enough.


    I am going to have to step back and say that it wasn’t just the WiFi devices that lost internet connection when I changed to unbound as upstream dns resolver. It was everything on the network. I don’t know why I didn’t see that, or if maybe it was working for a while on my main computer. So sorry.

    • Offizieller Beitrag

    Ok, here's an alternative that may get you past potential limitations with pi-hole running in a Docker and/or OMV:


    Using one of your XU4's, set aside the SD-card that has OMV on it, . Get another SD-card and load up Diet-PI (the XU4 is supported). Then load pi-hole onto the Diet-PI. Note that pi-hole is directly supported by the Diet-PI software installer. The menu's might be a little confusing at first, but you'll figure it out.
    ((**When prompted by the pi-hole install, set a static IP address. It may be easiest to set the DHCP address, as the static address, and set a permanent lease for the Diet-Pi on the router. If the address used is different from the DHCP address, you'll have to SSH back in.**))


    Once pi-hole is working, SSH in and install unbound directly to the Diet-PI host, on the command line, and test it exactly as the pi-hole doc lays it out.
    (You won't have to do the sudo thing because you'll be on the CLI as root, but use the custom port 5353 as the doc lays it out in the configuration.)


    Both packages (pi-hole and unbound) are designed to work when installed this way. If this doesn't work, it stands to reason that potential causes may be your router or some requirement of WIFI devices themselves. In either case, you might want to back out of unbound altogether and just use pi-hole in a docker.


    (BTW: This is how I'm set up, with an R-PI. I maintain pi-hole in a Docker and unbound on OMV, as a backup and to maintain the How-To's)

    • Offizieller Beitrag

    I have experimented with Diet-Pi a while back. I’ll give it a try. Thanks.

    • Offizieller Beitrag

    I flashed a SD card with diet pi and played with it last evening but ran into a snag. Setting a static ip and switching dns server to 1.1.1.1 was easy enough. I also set time zone, region, keyboard and then ran an upgrade. When I went to the dietpi-software section it showed pihole starred as if it were already installed but I could not figure how to access it to configure it. I finally uninstalled it and then reinstalled it. I was then allowed to go in and configure but then proceeded to lock myself out when I set a password. By then it was past bedtime. I will resume this evening or tomorrow. Right now I need to do some outdoor work before showers set in this evening/tomorrow.

    • Offizieller Beitrag

    When I went to the dietpi-software section it showed pihole starred as if it were already installed but I could not figure how to access it to configure it.

    ipaddress/admin 192.168.X.X/admin


    Diet-PI is a bit odd. It seems like an extended process to get pi-hole running (in and out of menu's, setting a static IP, etc.).


    While the password is set on the CLI, my preference is to get pi-holes preliminary config set so the admin web page comes up, then wrap up the details it in the web page. (Test pi-hole with at least one client, first, before adding unbound.)

    • Offizieller Beitrag

    Test pi-hole with at least one client, first, before adding unbound.

    Thanks. Will do. Should I shut down my pihole/omv server, or just switch the dns settings in my router when pihole/dietpie is ready?

    • Offizieller Beitrag

    I would statically address one client, just the DNS setting, to the Diet-PI/pihole IP address. There's no point in upsetting the entire LAN for a test.


    (Two DNS servers or, more accurately, DNS "proxies" can be together in the same network, at the same time. This is NOT true where DHCP servers are concerned.)

    • Offizieller Beitrag

    I noticed this morning that pi-hole.net removed their test page from there site. I wonder what is with that.


    When I get close on the diet-pi install I will remove the other reference from my router.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!