Cannot resolve device hostname but pi.hole works

Hello!

I am playing with a few IoT devices and everything works except one little thing. I have the following setup:

  • jetson nano 2g (hostname: jetsonnano2g) with IP 10.7.1.67
  • raspberry pi 1 (hostname: rpi4b8g1) with IP 10.7.1.61
  • raspberry pi 2 (hostname: rpi4b8g2) with IP 10.7.1.62

Pihole is installed on the jetson nano and works great except when I try to ping/nslookup/dig the hostname.
My router has only one DNS server and it is the pihole IP.
All my IoT devices have entries for each other in /etc/hosts.
If I get the /etc/hosts from the pihole docker using this command

docker exec pihole cat /etc/hosts

I see all my entries

10.7.1.61 rpi4b8g1
10.7.1.62 rpi4b8g2
10.7.1.67 jetsonnano2g

From my local computer, I can ping, nslookup both raspberry pi using their hostname but not the hostname where pihole is running.


[8:59:10 - gillouche@arch:~]$ ping -c 1 rpi4b8g1
PING rpi4b8g1 (10.7.1.61) 56(84) bytes of data.
64 bytes from rpi4b8g1 (10.7.1.61): icmp_seq=1 ttl=64 time=0.155 ms
[8:59:15 - gillouche@arch:~]$ ping -c 1 rpi4b8g2
PING rpi4b8g2 (10.7.1.62) 56(84) bytes of data.
64 bytes from rpi4b8g2 (10.7.1.62): icmp_seq=1 ttl=64 time=0.155 ms
[8:59:18 - gillouche@arch:~]$ ping -c 1 jetsonnano2g
ping: jetsonnano2g: Name or service not known
[8:59:27 - gillouche@arch:~]$ ping -c 1 pi.hole     
PING pi.hole (10.7.1.67) 56(84) bytes of data.
64 bytes from pi.hole (10.7.1.67): icmp_seq=1 ttl=64 time=2.82 ms
[9:00:51 - gillouche@arch:~]$ nslookup rpi4b8g2    
Server:         127.0.0.53
Address:        127.0.0.53#53
Non-authoritative answer:
Name:   rpi4b8g2
Address: 10.7.1.62
** server can't find rpi4b8g2: SERVFAIL
[9:00:56 - gillouche@arch:~]$ nslookup jetsonnano2g
Server:         127.0.0.53
Address:        127.0.0.53#53
** server can't find jetsonnano2g: NXDOMAIN

If I do dig by targeting the pihole server, I get the correct result.

[9:01:11 - gillouche@arch:~]$ dig jetsonnano2g @10.7.1.67

; <<>> DiG 9.18.2 <<>> jetsonnano2g @10.7.1.67
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48176
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;jetsonnano2g.                  IN      A

;; ANSWER SECTION:
jetsonnano2g.           0       IN      A       10.7.1.67

;; Query time: 3 msec
;; SERVER: 10.7.1.67#53(10.7.1.67) (UDP)
;; WHEN: Fri May 06 09:02:09 CEST 2022
;; MSG SIZE  rcvd: 57

[9:02:09 - gillouche@arch:~]$ dig jetsonnano2g           

; <<>> DiG 9.18.2 <<>> jetsonnano2g
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10893
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;jetsonnano2g.                  IN      A

;; Query time: 3713 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Fri May 06 09:06:00 CEST 2022
;; MSG SIZE  rcvd: 41

Here is the ansible tasks that I used

- name: Set FTLCONF_REPLY_ADDR (single mode)
  set_fact:
    ftlconf_reply_addr4: "{{ ansible_host }}"
    execution_mode: "single node setup"

- name: Start/Update pihole container
  docker_container:
    name: "{{ pihole_container_name }}"
    image: "{{ pihole_image }}"
    pull: yes
    restart_policy: unless-stopped
    env:
      TZ: "{{ timezone }}"
      FTLCONF_REPLY_ADDR4: "{{ ftlconf_reply_addr4 }}"
      WEBPASSWORD: "{{ pihole_webpassword }}"
      PIHOLE_DNS_: "{{ pihole_dns }}"
      DNSMASQ_LISTENING: "local"
    dns_servers:
      - 127.0.0.1
      - "{{ static_dns }}"
    network_mode: host
    volumes:
      - "/home/{{ ansible_user }}/pihole/pihole/:/etc/pihole/"
      - "/home/{{ ansible_user }}/pihole/dnsmasq.d/:/etc/dnsmasq.d/"
    log_driver: json-file
    log_options:
      max-size: "10m"
      max-file: "5"

Would you have any idea on how to fix this? Configuration problem on my side?
Thanks a lot.

Expected Behaviour:

The hostname where pihole is running should be reachable with ping/nslookup/dig and not only pi.hole.

Actual Behaviour:

The hostname where pihole is running is not reachable.

Some general advice before we take a look at your issue:

First, use dig or nslookup to analyse DNS issues - ping isn't adequate, as it uses additional ways beyond DNS to resolve hostnames, e.g. mDNS or considering /etc/hosts (that file goes back to the early days, before the advent of DNS, when you had to download a copy from Network Information Control Center if you wanted to access remote hosts by name. It isn't part of DNS, and local hosts definitions of your Pi-hole host system exclusively are elevated to DNS records only by virtue of Pi-hole creating them for you when reading that file).

Still, you wouldn't want to rely on /etc/hosts to populate Pi-hole's DNS records when running a containerised Pi-hole:
Docker would only pass that file to a container in host network mode - in virtually all other modes, definitions "in /etc/hosts are not inherited (quoting Docker's docs)".
So while your current configuration with network_mode: host may work, you may want to consider creating Local DNS Records via Pi-hole's UI instead.

With regards to local name resolution, you should also be aware that same-link hosts would be able to resolve each others mDNS names (i.e. a hostname appended by .local, like rpi4b8g2.local, presumably).
Provided that both hosts would feature mDNS support, you should be able to ping a same-link host by name, courtesy of mDNS.
Perhaps that may already serve as notable contribution to meeting your local name resolution requirements?

Now back to your issue:
You are observing a failure to provide an expected name resolution on your Pi-hole host.

Above output would suggest that some local resolver attached to 127.0.0.53 would handle DNS requests on your Docker host machine - I'd guess that wouldn't be Pi-hole, but rather a different DNS resolver that wouldn't necessarily use your Pi-hole as its only upstream.

Let's check by running the following commands on your Docker host machine:

dig +short @127.0.0.53 chaos txt version.bind
dig +short @10.7.1.67 chaos txt version.bind

If my assumption would be correct and results would indeed differ, you'd have two options to address this:
a) Configure the stub resolver at 127.0.0.53 to use only your Pi-hole as upstream DNS server
b) Disable the stub resolver and point your Docker host to use your Pi-hole as DNS resolver

Hello,

thanks for the great reply. Sorry for the delay, I didn't have access to a computer.

I'll have a look at all of that. I am perfectly fine with using .local to access my devices. I just want to avoid accessing them using their IP. I'll try that tonight to check if it works.

I already had to disable some DNS resolver on my home computer to strictly use pihole so I'll do that as well on the pihole device itself, thanks. I didn't make the link in my head that that could be the problem, sorry.

I'll do your suggestions tonight and update/close this post.
Thanks again.

edit: here is the result of the commands

┌─[user@jetsonnano2g]─[10.7.1.67]─[~]
└──╼ $ dig +short @127.0.0.53 chaos txt version.bind
"dnsmasq-pi-hole-2.87test8"
┌─[user@jetsonnano2g]─[10.7.1.67]─[~]
└──╼ $ dig +short @10.7.1.67 chaos txt version.bind
"dnsmasq-pi-hole-2.87test8"
┌─[user@jetsonnano2g]─[10.7.1.67]─[~]
└──╼ $ docker ps
CONTAINER ID   IMAGE                     COMMAND      CREATED      STATUS                  PORTS     NAMES
218dfebc7043   pihole/pihole:2022.04.3   "/s6-init"   4 days ago   Up 25 hours (healthy)             pihole

That should have been different it seems. I'll keep looking.

From my home computer, I tried traceroute and got these results

(venv) [19:28:55 - user@arch:~/workspace/ansible-cluster-playground]$ traceroute jetsonnano2g.local
jetsonnano2g.local: Temporary failure in name resolution
Cannot handle "host" cmdline arg `jetsonnano2g.local' on position 1 (argc 1)

(venv) [19:29:02 - user@arch:~/workspace/ansible-cluster-playground]$ traceroute rpi4b8g2
traceroute to rpi4b8g2 (10.7.1.62), 30 hops max, 60 byte packets
 1  rpi4b8g2 (10.7.1.62)  0.164 ms  0.186 ms  0.172 ms

(venv) [19:29:25 - user@arch:~/workspace/ansible-cluster-playground]$ traceroute rpi4b8g2.local
rpi4b8g2.local: Temporary failure in name resolution
Cannot handle "host" cmdline arg `rpi4b8g2.local' on position 1 (argc 1)

(venv) [19:29:47 - user@arch:~/workspace/ansible-cluster-playground]$ traceroute jetsonnano2g
jetsonnano2g: Name or service not known
Cannot handle "host" cmdline arg `jetsonnano2g' on position 1 (argc 1)

I also tried to update /etc/systemd/resolved.conf and use 10.7.1.67 in the DNS key; then restarted the service systemd-resolved on the docker host device but I still got the problem.

┌─[user@jetsonnano2g]─[10.7.1.67]─[~]
└──╼ $ sudo  netstat -tulpn | grep ":53 "
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      6659/pihole-FTL     
tcp6       0      0 :::53                   :::*                    LISTEN      6659/pihole-FTL     
udp        0      0 0.0.0.0:53              0.0.0.0:*                           6659/pihole-FTL     
udp6       0      0 :::53                   :::*                                6659/pihole-FTL     

I also added jetsonnano2g and jetsonnano2g.local to point to 10.7.1.67 in the local DNS settings in the admin panel of pihole but I still can't use jetsonnano2g nor jetsonnano2g.local on my home computer.

Sorry if there is something obvious that I don't see, networking is really not my area of expertise.

I may have misunderstood you - it seems to me now that when you write "local computer", you are referring to a client rather than your Pi-hole host.

I guess then I have been wrongly assuming that your nslookup exposing 127.0.0.53 originated from your Pi-hole host.

It seems it was run from a client instead, so my musings would apply to that client instead of Pi-hole's host machine. It would be that client that runs a stub resolver and may not be forwarding local names to Pi-hole, or maybe not using Pi-hole at all.

Consequently, my suggestions should be applied to that client:

(Of course, that client isn't your Docker host)

No, that would be the expected output for a default Pi-hole when run from the Pi-hole host.

Don't mix mDNS with DNS - .local is reserved for mDNS usage.

That's ok, but shouldn't have been necessary, as your earlier dig results already demonstrated your Pi-hole to answer correctly:

Your issue lies with your client (gillouche@arch) not using Pi-hole for those requests.

1 Like

Hi,

you understood correctly, I was the one who misunderstood your explanations.

I disabled systemd-resolved and updated /etc/resolvconf.conf to add my pihole DNS IP and then executed

sudo resolvconf -u

Now I have nameserver 10.7.1.67 in my /etc/resolv.conf and everything works.

Thanks again.