Linux clients not resolvoing local DNS entries

[patrickRx]

Hello all, this problem I will admit is likely not related to Pi-Hole and is more likely linux client configuration specific, but I'm hoping others have experienced this same as issue as well so I'm posting here.

Expected Behaviour:

I make broad use of the Local DNS functionality of Pi-Hole and all my internal services have DNS entries. An example would be "server", with an ip address of 10.128.1.7 has a dns entry of server.myregistereddomain.com. I can ping this server and reliably connect to it using this address on my windows clients. This is all internal traffic, nothing is leaving my network.

Actual Behaviour:

On linux, it's another story. I cannot ping that address. nslookup can't find an IP address. I can't connect to this client using that DNS entry in any services. This all works fine however if I specify the IP address instead, so connections can be made.
-ubuntu, debian (PROXMOX), opensuse

Debug Token:

https://tricorder.pi-hole.net/bwgPRnTh/

This seems to be a misunderstanding (on my part) in the way linux is handling DNS lookup.

For what it's worth, it my DNS server is being resolved appropriately by my client - /run/systemd/resolve/resolv.conf does show the pi-hole IP address.

Any help with this is greatly appreciated. Thank you!

[deHakkelaar]

@patrickRx

server.myregistereddomain.com

Pi Hole and .com Domain

Adding to above, I would advice against using/configuring a public domain name as a search suffix domain at home! If you do, the public DNS records you've create for that domain wont resolve on your local network bc those queries wont be forwarded to upstream but blocked instead by below settings (those queries are considered "local"): [image] Your router does something similar. And if you disable above settings, certain local queries that cant be answered by Pi-hole or router will leak to …

[patrickRx]

Thanks for the reply. I read your linked post and I'm not clear how this would impact me. I do also have a .local DNS entry as well. For example, truenas-home.local has a local DNS entry for a local IP on pi-hole, which resolves on windows clients but not on linux clients.

The nslookup reports it's looking at 127.0.0.53, although my understanding is that systemd is actually checking the the DNS entry the /run folder? Here's the output of both of those.

server@docker:~$ nslookup truenas-home.local
;; Got SERVFAIL reply from 127.0.0.53
Server:         127.0.0.53
Address:        127.0.0.53#53

** server can't find truenas-home.local: SERVFAIL

server@docker:~$ cat /run/systemd/resolve/resolv.conf 
# This is /run/systemd/resolve/resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 10.128.1.4
search localdomain

[deHakkelaar]

@patrickRx

I'm not clear how this would impact me

I recomend to not use the public domain myregistereddomain.com as a search suffix domain at home bc DNS queries for public records for that domain wont resolve at home (they get blocked with default OOTB settings).

Also .local is scuffed as that search suffix domain is intended for mDNS exclusively and not for regular DNS:

Using ".local" as a private top-level domain conflicts with Multicast DNS and may cause problems for users.

https://www.rfc-editor.org/rfc/rfc6762.html
(Appendix G)

So to me it looks like you have to review the whole naming scheme first before diagnosing particular issues.

[patrickRx]

Changing to truenas-home.internal allows linux clients to resolve successfully, thank you!

I'm still interested to know why Windows clients will resolve an FQDN and a .local address when I assign them to internal IP addresses in Local DNS of Pi-hole, while the linux clients do not? Any ideas?

**edited - wrote .local was successful, I meant .internal

[deHakkelaar]

@patrickRx

Any ideas?

Not really.
But mDNS is default supported on current Windows releases.
And for Linux you usually have to install an mDNS daemon:

$ apt show avahi-daemon
[..]
Description: Avahi mDNS/DNS-SD daemon
 Avahi is a fully LGPL framework for Multicast DNS Service Discovery.
 It allows programs to publish and discover services and hosts
 running on a local network with no specific configuration. For
 example you can plug into a network and instantly find printers to
 print to, files to look at and people to talk to.
 .
 This package contains the Avahi Daemon which represents your machine
 on the network and allows other applications to publish and resolve
 mDNS/DNS-SD records.

$ apt policy avahi-daemon
avahi-daemon:
  Installed: 0.8-5+deb11u2

On another Linux system of mine:

$ apt policy avahi-daemon
avahi-daemon:
  Installed: (none)

EDIT:

$ grep -i mdns /etc/services
mdns            5353/udp                        # Multicast DNS

$ sudo ss -nlup sport = 5353
Netid  State   Recv-Q  Send-Q   Local Address:Port    Peer Address:Port  Process
udp    UNCONN  0       0              0.0.0.0:5353         0.0.0.0:*      users:(("avahi-daemon",pid=19905,fd=12))
udp    UNCONN  0       0                    *:5353               *:*      users:(("avahi-daemon",pid=19905,fd=13))