Support hostnames and domains in PIHOLE_DNS_

networkException · October 23, 2021, 8:37pm

This is a follow up to Start: Support hostnames and domains in PIHOLE_DNS_ by networkException · Pull Request #816 · pi-hole/docker-pi-hole · GitHub #docker

Currently the docker configuration does not allow for a hostname or domain in the pihole dns configuration. Technically DNS servers are never domains but in some cases the ip of a domain might want to be used as the DNS server. In particular a docker-compose stack would benefit from this feature:

services:
    pihole:
        image: pihole/pihole
        hostname: pihole        
        depends_on:
            - dnscrypt        
        ports:
            - 53:53/udp
        environment:
            PIHOLE_DNS_: dnscrypt

    dnscrypt:
        image: #...

By resolving the ip of "dnscrypt" on startup, pihole could now use the dnscrypt container as a DNS server.

DL6ER · October 24, 2021, 7:44am

@PromoFaux Could you check this out?

system · April 22, 2022, 7:45am

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.

yubiuser · May 31, 2022, 9:19pm

There is an upstream PR to dnsmasq which would implement this feature

github.com/pi-hole/dnsmasq

Extend server to accept hostnames for upstream resolver

pi-hole:master ← pi-hole:new/resolve_server

opened 03:22PM - 03 Feb 22 UTC

DL6ER

+75 -1

In docker swarm and compose configurations, other containers are only reachable …via hostnames. It is not possible to assign IP addresses beforehand. Hence, the upstream server IP is not known at `dnsmasq` start when the upstream is part of the deployed configuration, e.g., a local `cloudflared` or `unbound` container. So far, getting `dnsmasq` to run in such a case requires hacks that somehow try to determine the IP address before starting dnsmasq. An example for such a hack: https://github.com/tschaffter/docker-dnsmasq/blob/54b5d5d551746b6f1708fbf4a705e2de66c2eaee/docker-entrypoint.sh#L14-L23 This patch implements name resolution functionality for `server=...` by querying the system resolver for a hostname. It is only used when a user supplied something that is not a valid IP address (`dnsmasq` currently fails hard in this case) and can be omitted by a compile time flag (I think it's worthwhile to have it). I know my proposal does sound somewhat strange (resolving a DNS server name) but this is something that is somewhat frequently needed and currently only possible through external hacks.

yubiuser · November 14, 2022, 10:09pm

This has been part of

github.com/pi-hole/FTL

Update embedded dnsmasq to v2.88test3

pi-hole:development ← pi-hole:update/dnsmasq

opened 01:19PM - 07 Nov 22 UTC

DL6ER

+1331 -392

**By submitting this pull request, I confirm the following:** - [X] I have re…ad and understood the [contributors guide](https://github.com/pi-hole/pi-hole/blob/master/CONTRIBUTING.md). - [X] I have checked that [another pull request](https://github.com/pi-hole/FTL/pulls) for this purpose does not exist. - [X] I have considered, and confirmed that this submission will be valuable to others. - [X] I accept that this submission may not be used, and the pull request closed at the will of the maintainer. - [X] I give this submission freely, and claim no ownership to its content. **How familiar are you with the codebase?:** ## 10 --- Updates the embedded `dnsmasq` to the next tagged version of `dnsmasq`. Highlights compared to the most recent version of `dnsmasq` (v2.87) released in FTL v5.18: **New options/features** - **Allow domain names as well is IP addresses in `server` options** - this will be especially helpful in situations where upstream destinations are primarily reachable by hostname (think of DHCP networks and `docker compose`, etc.) (***Pi-hole patch***) - `use-stale-cache` - when set, **if a DNS name exists in the cache, but its time-to-live has expired, `dnsmasq` will return the data anyway** and attempts itself to refresh the data with an upstream query after returning the stale data. Advantages: - This can improve speed as we can always reply immediately to known queries, even when cached content has expired, instead of having to wait for upstream replies to arrive. Disadvantages: - In certain edge-cases, these out-of-data replies can lead to (intermittent) incorrect behavior on websites. - There is no way to inform a downstream client that an answer we provided before was wrong. The client may cache wrong data for a long time until it re-sends a query to get the updated information. - It comes at the expense of sometimes returning out-of-date replies and less efficient cache utilization, since old data cannot be flushed when its TTL expires. The cache becomes strictly least-recently-used. - New `fast-dns-retry` option - **gives dnsmasq the ability to originate retries for upstream DNS queries itself**, rather than relying on the downstream client. This is most useful when doing DNSSEC over unreliable upstream network. Retries are generated when no reply was received for 1 second. Retries are repeated with exponential backoff until we give up after 10 seconds. Both values are configurable with millisecond accuracy. Advantages: - Queries without replies to will be retried earlier resulting in significantly reduced reply times on flaky upstream connections. Note that this does only apply to the connection between the Pi-hole and the upstream destination. It does not mean any improvement on unreliable connections between your Pi-hole and clients (like over a weak WiFi signal or an unreliable VPN connection). Drawbacks: - It comes with hard-to-quantify extra costs in memory usage and network bandwidth. - It will only be useful if your Internet connectivity is *really* bad. You should try out any other possible remedy before relying on this one. - New `port-limit=<#ports>` option - by default, when sending a query via random ports to multiple upstream servers or retrying a query dnsmasq will use a single random port for all the tries/retries. Advantages: - This option allows a larger number of ports to be used, which can increase robustness in certain network configurations. Disadvantages: - Note that increasing this to more than two or three can have security and resource implications and should only be done with understanding of those (the requesting port is part of the "secret"). - New `no-round-robin` option - suppresses round-robin ordering of DNS records and ensures answers are always served in the same order. - Enhance `hostsdir` to remove outdated entries on changes. Before, this required a full `dnsmasq` restart (***Pi-hole patch***) - Improve `hostsdir` logging to log the HOSTS file used for generating a local reply (***Pi-hole patch***) **Bugfixes** - Fix bug in `dynamic-host` when interface has `/16` address (***Pi-hole patch***) - Fix in DHCPv4 `rapid-commit` - If a host had an old lease for a different address, the rapid-commit appeared to work, but the old lease was not removed and the new lease was not recorded, so the client and server had conflicting state, leading to problems later.

and is released with

PromoFaux · November 14, 2022, 10:41pm

Sorry, I never saw this tag/topic!

However, this has actually been a part of the docker image since around March of this year:

github.com/pi-hole/docker-pi-hole

Support docker service names and links for PIHOLE_DNS_

pi-hole:dev ← haxwithaxe:support-docker-links-for-PIHOLE_DNS_dev

opened 06:46PM - 09 Mar 22 UTC

haxwithaxe

+20 -4

Added the ability to use docker service names or links in `PIHOLE_DNS_`. ## D…escription In `start.sh` I added a check for valid domains to the block in the loop over `PIHOLE_DNS_`. The valid domains are resolved and the IP addresses are added to the configs in the same way as DNS servers specified as IPs. I also slightly rearranged the if block to avoid duplicating the warning about invalid servers. ## Motivation and Context I have a setup that uses an unbound container to provide DoT. I'm trying to integrate this composition as a stack in a swarm and it would greatly simplify the configuration if docker service names could be used. It would also make the behavior of this image more idiomatic. ## How Has This Been Tested? 1. `ARCH=amd64 ./gh-actions-test.sh` 25 passed, 11 skipped 3. Using the docker-compose.yml (below) with `PIHOLE_DNS_` set to "unbound;1.2.3.4" I started the composition. 4. I logged in to the pi-hole admin UI and verified the IP of the unbound container was set as the first custom server and 1.2.3.4 was the second. Then I removed the etc-* directories created in the working directory. 5. I repeated this with just IPv4 addresses. 6. I repeated this with just IPv6 addresses. The parts related to my change worked, but this produced an unrelated pihole-FTL error that exists in `pihole/pihole:latest` as well. 7. I repeated this with just the docker link. Except for the IPv6 only test the specified IPs or IPs of specified service names were shown as the custom DNS servers and no errors were apparent in the logs. ## Types of changes - [ ] Bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) ## Checklist: - [x] My code follows the code style of this project. (I tried to be consistent with the surrounding code) - [x] My change requires a change to the documentation. - [x] I have updated the documentation accordingly. ``` version: "2" services: pihole: container_name: pihole image: pihole:support-docker-links-for-PIHOLE_DNS_dev-amd64-buster ports: - "53:53/tcp" - "53:53/udp" #- "67:67/udp" # Required for DHCP - "80:80/tcp" environment: TZ: "America/New_York" PIHOLE_DNS_: "unbound;1.2.3.4" volumes: - "./etc-pihole:/etc/pihole" - "./etc-dnsmasq.d:/etc/dnsmasq.d" #cap_add: # Required for DHCP # - NET_ADMIN restart: unless-stopped unbound: image: haxwithaxe/unbound-dot:latest ```

Though maybe with this new code in FTL/dnsmasq, we can change that up a little

Edit:

Ah, yes, @networkException is aware - from the linked PR:

Thanks a lot for implementing this! I can finally decomission my patched start.sh then