Not all local hosts resolve

Hi there, like most, devices on my LAN have their own hostnames and these seem to resolve just fine locally. Recently I’ve added a dozen Tasmota IoT devices and these have their default hostname, something like ‘tasmota_FC16FE-5886’. Mystery is none are resolving even on a reverse lookup or fully qualified. Has someone else experienced this and should I be looking at the unbound docs?

Hi,

by “added”, I assume you mean they try to obtain an IP address via DHCP from your IPFire machine. Correct?

Hm, could you run

cat /etc/unbound/dhcp-leases.conf

on your IPFire machine and report back its contents? Feel free to redact any sensitive information first.

Thanks, and best regards,
Peter Müller

by added, I mean to say added to the network over the last few months, and i’ve also added reservations (pictured) into DHCP, although interestingly none appear in the leases file:

local-data: "kobo.lan 60 IN A 192.168.77.188"
local-data: "188.77.168.192.in-addr.arpa 60 IN PTR kobo.lan"
local-data: "thinkpad.lan 60 IN A 192.168.77.175"
local-data: "175.77.168.192.in-addr.arpa 60 IN PTR thinkpad.lan"
local-data: "android-83a52961299dbe60.lan 60 IN A 192.168.77.162"
local-data: "162.77.168.192.in-addr.arpa 60 IN PTR android-83a52961299dbe60.lan"
local-data: "DELL7C0E5D.lan 60 IN A 192.168.77.167"
local-data: "167.77.168.192.in-addr.arpa 60 IN PTR DELL7C0E5D.lan"
local-data: "SimonespleWatch.lan 60 IN A 192.168.77.190"
local-data: "190.77.168.192.in-addr.arpa 60 IN PTR SimonespleWatch.lan"
local-data: "EntertamentRoom.lan 60 IN A 192.168.77.160"
local-data: "160.77.168.192.in-addr.arpa 60 IN PTR EntertamentRoom.lan"
local-data: "iPhone.lan 60 IN A 192.168.77.196"
local-data: "196.77.168.192.in-addr.arpa 60 IN PTR iPhone.lan"
local-data: "roberts-iPhone.lan 60 IN A 192.168.77.161"
local-data: "161.77.168.192.in-addr.arpa 60 IN PTR roberts-iPhone.lan"
local-data: "jacobs-iPhone.lan 60 IN A 192.168.77.198"
local-data: "198.77.168.192.in-addr.arpa 60 IN PTR jacobs-iPhone.lan"
local-data: "homeassistant.lan 60 IN A 192.168.77.3"
local-data: "3.77.168.192.in-addr.arpa 60 IN PTR homeassistant.lan"
local-data: "EntertamentRoom.lan 60 IN A 192.168.77.4"
local-data: "4.77.168.192.in-addr.arpa 60 IN PTR EntertamentRoom.lan"
local-data: "raspberrypi.lan 60 IN A 192.168.77.7"
local-data: "7.77.168.192.in-addr.arpa 60 IN PTR raspberrypi.lan"
local-data: "office.lan 60 IN A 192.168.77.8"
local-data: "8.77.168.192.in-addr.arpa 60 IN PTR office.lan"
local-data: "kitchen81.lan 60 IN A 192.168.77.9"
local-data: "9.77.168.192.in-addr.arpa 60 IN PTR kitchen81.lan"
local-data: "adar81.lan 60 IN A 192.168.77.10"
local-data: "10.77.168.192.in-addr.arpa 60 IN PTR adar81.lan"
local-data: "cam-garage2.lan 60 IN A 192.168.77.14"
local-data: "14.77.168.192.in-addr.arpa 60 IN PTR cam-garage2.lan"
local-data: "shellyht-957199.lan 60 IN A 192.168.77.20"
local-data: "20.77.168.192.in-addr.arpa 60 IN PTR shellyht-957199.lan"

2021-07-15-174411_462x425_scrot

Hi again, not only with my ‘tasmota’ devices, but random other devices can have a hostname which don’t go into the LAN’s DNS (OpenWrt APs are another example)

So, to better understand, does “DHCP give to DNS” or “DNS takes from DHCP” ??

Hi,

there is a dedicated Python 3.x script for this (its source code is accessible here). Technically, the DNS resolver gets a dynamically generated file for hostnames of DHCP leases, receives a reload request via unbound-control, and serves its contents happily afterwards. :slight_smile:

Should be a relatively fail-proof thing, but at least in your case, it is not… :expressionless:

The generated file, however, looks fine. To rule out any search-domain issues (frequently occur on Windows devices), could you run something like

dig @[IP address of your IPFire machine] thinkpad.lan

on a Linux or BSD client behind your IPFire, and post its results here? Please replace thinkpad.lan by any other FQDN, should that Thinkpad be offline at the time of testing.

Thanks, and best regards,
Peter Müller