2

I am using Debian Trixie on a server. I have installed it using ZFSBootMenu documentation, without a desktop environment. The installation is quite minimal in term of packages.

My motherboard has 2 ethernet interfaces.

My hostname is configured correctly (I think, I have done systemctl set-hostname servername).

/etc/hosts:

127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters 127.0.0.1 servername

/etc/hostname:

servername

/etc/network/interfaces:

auto lo iface lo inet loopback auto eno1 iface eno1 inet dhcp hostname servername auto eno2 iface eno2 inet dhcp hostname servername

/etc/dhcpcd.conf:

# was: hostname hostname servername # was: duid clientid persistent vendorclassid option domain_name_servers, domain_name, domain_search option classless_static_routes option interface_mtu option host_name require dhcp_server_identifier slaac private

extract from /etc/nsswitch.conf:

# hosts: files mdns4_minimal [NOTFOUND=return] dns # stock Debian conf hosts: files myhostname mdns4_minimal [NOTFOUND=return] dns mdns4 netgroup: nis

find /usr/lib -iname '*libnss*':

/usr/lib/x86_64-linux-gnu/libnss_mdns.so.2 /usr/lib/x86_64-linux-gnu/libnss_mdns6.so.2 /usr/lib/x86_64-linux-gnu/libnss_compat.so /usr/lib/x86_64-linux-gnu/libnss_mdns_minimal.so.2 /usr/lib/x86_64-linux-gnu/libnss_files.so.2 /usr/lib/x86_64-linux-gnu/libnss_compat.so.2 /usr/lib/x86_64-linux-gnu/libnss_hesiod.so.2 /usr/lib/x86_64-linux-gnu/libnss_mdns4_minimal.so.2 /usr/lib/x86_64-linux-gnu/libnss_hesiod.so /usr/lib/x86_64-linux-gnu/libnss_dns.so.2 /usr/lib/x86_64-linux-gnu/libnss_mdns6_minimal.so.2 /usr/lib/x86_64-linux-gnu/libnss_mdns4.so.2

extract from systemctl status:

 │ ├─networking.service │ │ ├─1010 "dhcpcd: eno1 [ip4] [ip6]" │ │ ├─1011 "dhcpcd: [privileged proxy] eno1 [ip4] [ip6]" │ │ ├─1013 "dhcpcd: [network proxy] eno1 [ip4] [ip6]" │ │ ├─1016 "dhcpcd: [control proxy] eno1 [ip4] [ip6]" │ │ ├─1093 "dhcpcd: [DHCP6 proxy] fe80::redacted" │ │ ├─1094 "dhcpcd: [BPF ARP] eno1 192.168.1.82" │ │ ├─1110 "dhcpcd: [DHCP6 proxy] 2a01:redacted" │ │ ├─1122 "dhcpcd: eno2 [ip4] [ip6]" │ │ ├─1123 "dhcpcd: [privileged proxy] eno2 [ip4] [ip6]" │ │ ├─1124 "dhcpcd: [network proxy] eno2 [ip4] [ip6]" │ │ ├─1125 "dhcpcd: [control proxy] eno2 [ip4] [ip6]" │ │ └─1163 "dhcpcd: [BOOTP proxy] 192.168.1.82"

extract from ip addr:

2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether ac:redacted brd ff:ff:ff:ff:ff:ff altname enp2s0 altname enxac1f6bd3405a inet 192.168.1.82/24 brd 192.168.1.255 scope global dynamic noprefixroute eno1 valid_lft 40861sec preferred_lft 35461sec inet6 2a01:redacted/64 scope global dynamic mngtmpaddr noprefixroute valid_lft 86377sec preferred_lft 86377sec inet6 fe80::redacted/64 scope link valid_lft forever preferred_lft forever

extract from journalctl -u networking.service:

servername dhcpcd[1117]: eno1: carrier acquired servername dhcpcd[1117]: DUID 00:01:00:01:30:5d:c4:58:ac:1f:6b:d3:40:5b servername dhcpcd[1117]: eno1: IAID 6b:d3:40:5b servername dhcpcd[1117]: eno1: adding address fe80::redacted servername dhcpcd[1117]: eno1: soliciting a DHCP lease servername dhcpcd[1117]: eno1: soliciting an IPv6 router servername dhcpcd[1117]: eno1: probing for an IPv4LL address servername dhcpcd[1117]: eno1: carrier lost servername dhcpcd[1117]: eno1: deleting address fe80::redacted servername dhcpcd[1117]: eno1: carrier acquired servername dhcpcd[1117]: eno1: IAID 6b:d3:40:5b servername dhcpcd[1117]: eno1: adding address fe80::redacted servername dhcpcd[1117]: eno1: soliciting a DHCP lease servername dhcpcd[1117]: eno1: offered 192.168.1.126 from 192.168.1.254 servername dhcpcd[1117]: eno1: soliciting an IPv6 router servername dhcpcd[1117]: eno1: probing address 192.168.1.126/24 servername dhcpcd[1117]: eno1: leased 192.168.1.126 for 43200 seconds servername dhcpcd[1117]: eno1: adding route to 192.168.1.0/24 servername dhcpcd[1117]: eno1: adding default route via 192.168.1.254 servername dhcpcd[1117]: eno1: Router Advertisement from fe80::redacted servername dhcpcd[1117]: eno1: adding address 2a01:redacted servername dhcpcd[1117]: eno1: adding route to 2a01:redacted servername dhcpcd[1117]: eno1: adding default route via fe80::redacted

The system is using the DHCP client dhcpcd. My router is a Freebox.

The system gets an IP address from the router but reverse DNS does not work:

nmap -sP -T4 192.168.1.0/24 gives:

Starting Nmap 7.93 ( https://nmap.org ) at 2025-09-17 13:58 CEST Nmap scan report for laptop (192.168.1.16) <--- this is my laptop: name is shown Host is up (0.00095s latency). Nmap scan report for 192.168.1.82 <--- this is my server: no name shown Host is up (0.0026s latency). Nmap scan report for _gateway (192.168.1.254) <--- this is my router / DHCP server Host is marsup (0.0039s latency). Nmap done: 256 IP addresses (3 hosts up) scanned in 2.93 seconds

ping laptop does work, ping servername does not work (Name or service not known).

dig -x 192.168.1.82 from my laptop:

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> 192.168.1.82 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 53842 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;192.168.1.82. IN A ;; AUTHORITY SECTION: . 486 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2025091801 1800 900 604800 86400 ;; Query time: 112 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) ;; WHEN: Thu Sep 18 21:07:31 CEST 2025 ;; MSG SIZE rcvd: 116

I have installed avahi and avahi works (ping servername.local works) but reverse DNS still does not work. I have tried to specify the hostname in /etc/dhcpcd.conf, changed from duid to clientid, delete leases, rebooted, but no improvement.

I would like to get dhcpcd to work because it is the default one that came when I installed Debian Trixie. I think the Raspberry pi official Linux also use (used?) dhcpcd and has reverse DNS working, so this should be possible.

Improve this question
7
  • And what does /etc/dhcpcd.conf look like atm? Also assuming that you restarted dhcpcd after the changes ... ? Commented Sep 17 at 17:32
  • @tink I have added my current /etc/dhcpcd.conf When testing I was running /etc/init.d/networking restart that I assumed restarted dhcpcd but maybe I was wrong. Anyway I tried to reboot between some tests. Commented Sep 17 at 18:25
  • I can't tell from your logvomit, but do your two NICs have different MAC addresses? Duplicate MAC addresses confuse DHCP. Commented Sep 17 at 19:27
  • Yes, two MAC addresses. I found this serverfault question for a somewhat similar environment (also using ifupdown). Commented Sep 17 at 19:36
  • We need information on how your hostname resolution is configured on your system, as that is not mentioned at all in the logs you posted. What's on the hosts: line of your /etc/nsswitch.conf file? And what is the output of ls -l /usr/lib/*/libnss_* ? Are you planning on mDNS-based reverse DNS resolution, or are you expecting regular reverse DNS to have your hostname? If the latter, make sure the bind9-dnsutils package is installed and run dig -x 192.168.1.82 and show us what it reports, please. Commented Sep 17 at 23:42

1 Answer 1

Reset to default
3

What's happening

Your /etc/nsswitch.conf has the classic dns keyword, but the fact that dig output says

;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)

indicates you're using systemd-resolved through its backwards-compatibility stub listener, i.e. your /etc/resolv.conf points to 127.0.0.53 only. So to see your actual DNS server settings, you must run resolvectl status.

Each keyword in the /etc/nsswitch.conf file actually references one of the /usr/lib/<system architecture>/libnss_<keyword>.so.2 libraries: each library contains the necessary code to provide the resolution method(s) corresponding to that keyword.

The AUTHORITY SECTION part of the dig output indicates your residential gateway did not claim DNS authority over the 192.168.1.0/24 reverse DNS zone (as a fully functional, properly configured DNS server for your local network probably should have done), but instead passed on the query to your Internet Service Provider's DNS server, which provided an answer as seen by a.root-servers.net, i.e. one of the public global DNS root servers. Since 192.168.1.0/24 is not globally unique, the only answer the global DNS root servers can provide is "as far as I know, that is an empty segment". And so, the result of the query was status: NXDOMAIN, i.e. "Non-Existent Domain Name".

To minimize the load on global root nameservers, those servers provide authoritative, cacheable answers on all network segments that are not supposed to be globally unique, such as the common 192.168.1.0/24. If you want a real reverse DNS service for your private home network, you must have your own DNS server and configure it to claim authority for that reverse DNS segment and any other DNS domains/zones you wish to use locally. The recommended forward DNS domain name for home use is now home.arpa.: unlike other domain names, it is guaranteed to not conflict with any globally-registered DNS zone.

Unfortunately, most consumer-grade residential gateways I've seen don't actually have a fully functional DNS server; most will just provide a DNS proxy that provides a easily-usable name for the gateway itself (mostly for the purpose of accessing the gateway admin web interface), and forward all other queries to the ISP's DNS servers. If yours has a real DNS server to which you can register hosts in your local network (either manually or automatically by DHCP), you're in luck.

The hosts: line of /etc/nsswitch.conf defines the priority order of various hostname resolution methods. The mdns4_minimal keyword activates mDNS, but the _minimal means it will only resolve names that end in .local and IP addresses in the link-local 169.254.*.* range. (See: https://github.com/avahi/nss-mdns/blob/master/README.md#activation )

As your network uses 192.168.1.*, the mdns4_minimal ignores the reverse queries, and so the query passes to the dns keyword, which causes it to be handed over to systemd-resolved in your case. Had the DNS servers been unable (or unwilling) to answer for the reverse DNS query, it would have been passed on to mdns4 without the _minimal suffix, which might have been able to resolve it using mDNS. But the public DNS servers did provide a valid answer: it just was a negative one: NXDOMAIN, or in human terms, "There is definitely no reverse DNS record registered in the global DNS for that IP address".

The resolver library is not going to look for second opinions: once it receives a valid answer, that's final.

Your options

You could certainly set up a private DNS server for your home network and have it claim reverse DNS authority over the 192.168.1.0/24 segment, but since you already have mDNS working in the forward direction, that might seem like overkill. I've done this: it takes a bit of effort up front, but has a lot of benefits if you also integrate it with the DHCP server. If you want to try this, dnsmasq might have all you need in a single software package.

The old-school way would be to add the IPs and hostnames of your private network to /etc/hosts (since files is the highest-priority hostname resolution method), but if you have a lot of systems in your private network, that will eventually become a maintenance hassle.

If you just need a way to quickly look up IP addresses to names for yourself (i.e. not for programs), you could use a mDNS-specific reverse lookup command, e.g. avahi-resolve --address 192.168.1.82. If you think you'd need it often, you might want to create an easy, short alias for it.

To use mDNS for reverse lookups for IP ranges other than 169.254.. system-wide, you would have to move the mds4 (without _minimal) keyword before dns on the hosts: line of /etc/nsswitch.conf, and create a /etc/mdns.allow file that would restrict the use of mDNS only to the forward & reverse DNS zones you use in your local private network, to prevent the mDNS lookup attempts from slowing down your regular DNS lookups when you're e.g. browsing the internet.

Unfortunately, the use of the mdns.allow file is overall poorly documented (see the link above for one of the few docs that even mentions it) and after a quick look through the libnss_mdns4.so.2 source code, it seems to mee the reverse lookups won't check the mdns.allow file at all, so placing the mdns4 keyword before dns would slow down all reverse lookups, not just ones for your private network.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.