Docker : Reply from unexpected source

Help
1

Expected Behaviour:

[Docker host machine DNS lookups should be using the local PiHole server]

Actual Behaviour:

[Ping / nslookup doesn't work. Ping gives a DNS failure, and nslookup gives the message ";; reply from unexpected source: 127.0.0.1#53, expected 127.0.0.53#53". If I change /etc/resolv.conf from "nameserver 127.0.0.53
" to "nameserver 127.0.0.1" then it all functions correctly. However this file appears to be overwritten on startup / regularly so this is not a good permanent solution.]

Hi, I have installed pihold in a docker container, and it seems to be working for all of my other PCs on the network which is great. However I have changed the DNS server distributed by the DHCP server (my router), and now the docker PC is unable to correctly resolve domain names unless I manually modify /etc/resolv.conf. I have tried searching and trying solutions from across the net, but I can't seem to get it running correctly. The docker image is running on Ubuntu Server 17.10, and this PC is pretty much only running docker images.

Just figured I would see if anyone had any ideas that may be helpful.I know this isn't strictly related to pihole, but hopes someone may be able to point me in the right direction.

Cheers

Here is the docker configuration I am using :slight_smile:

    pihole:
      command:
        - ""
      container_name: pihole
      entrypoint:
        - /init
      environment:
        - ServerIP=10.1.1.25
        - ServerIPv6=10.1.1.25
        - PATH=/opt/pihole:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
        - TAG=alpine
        - ARCH=amd64
        - setupVars=/etc/pihole/setupVars.conf
        - PIHOLE_INSTALL=/tmp/ph_install.sh
        - S6OVERLAY_RELEASE=https://github.com/just-containers/s6-overlay/releases/download/v1.20.0.0/s6-overlay-amd64.tar.gz
        - WEBLOGDIR=/var/log/nginx
        - PHP_CONFIG=/etc/php5/php-fpm.conf
        - PHP_ENV_CONFIG=/etc/php5/fpm.d/envs.conf
        - PHP_ERROR_LOG=/var/log/nginx/error.log
        - IPv6=True
        - S6_LOGGING=0
        - S6_KEEP_ENV=1
        - S6_BEHAVIOUR_IF_STAGE2_FAILS=2
        - WEBPASSWORD=lifefm
      hostname: xxxxxxxx
      image: diginc/pi-hole:alpine
      ipc: shareable
      labels:
        image: diginc/pi-hole:alpine_amd64
        maintainer: adam@diginc.us
        url: https://www.github.com/diginc/docker-pi-hole
      log_driver: json-file
      mac_address: 02:42:ac:11:00:04
      net: bridge
      ports:
        - 53:53/tcp
        - 80:80/tcp
        - 53:53/udp
      restart: always
      volumes:
        - /docker/pihole/dnsmasq.d:/etc/dnsmasq.d
        - /docker/pihole/config:/etc/pihole
1 Like
2

What is it reverted to? Your router? What if you just plug your pi-hole IP 10.1.1.25 into the router's DHCP DNS?

Also why 127.0.0.53 instead of 127.0.0.1? I think the docker userland proxy maybe forcing it to come from 127.0.0.1 instead of 53 - if you want 127.0.0.53 you could try using that on your docker config for the port binding.

3

I just answered my own question with a quick bit of googling on modifying systemd's resolv.conf records. https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html#/etc/resolv.conf

so it is a systemd thing to use 127.0.0.53, ok.

I had someone pull request a little bit of info about updating systemd DNS into my readme here in case you missed it: https://github.com/diginc/docker-pi-hole/pull/181/files

If you perfer to leave systemd DNS on the first link I sent documents customizing the servers early on in the page:

The DNS servers contacted are determined from the global settings in /etc/systemd/resolved.conf, the per-link static settings in /etc/systemd/network/*.network files, the per-link dynamic settings received over DHCP and any DNS server information made available by other system services. See resolved.conf(5) and systemd.network(5) for details about systemd's own configuration files for DNS servers. To improve compatibility, /etc/resolv.conf is read in order to discover configured system DNS servers, but only if it is not a symlink to /run/systemd/resolve/resolv.conf (see below).

4

Awesome thanks, that does seem to have fixed my problem. For reference of my self and anyone else that comes across this query, the fix was the following commands:

sudo systemctl disable systemd-resolved.service
sudo service systemd-resolved stop
sudo rm /etc/resolv.conf

I didn't do anything iwth NetworkManager as it would appear that in the installation of Ubuntu Server that I have this service isn't installed / used.

2 Likes