Not all local hosts resolve

alexgill · 15 July 2021 21:10

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?

pmueller · 15 July 2021 21:16

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

alexgill · 15 July 2021 21:48

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

alexgill · 22 July 2021 16:02

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” ??

pmueller · 22 July 2021 16:51

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.

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

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

alexgill · 29 July 2021 20:31

Hello Peter,

So while I didn’t fully digest the script you linked to, it was very helpful in working this issue out. What I did notice is any hostname with an underscore never made it into ‘/etc/unbound/dhcp-leases.conf’ which I believe is by design since it’s an invalid character.

By chance there was a Tasmota commit this week to avoid the invalidly generated hostnames:
https://github.com/arendst/Tasmota/commit/e039edde334541ecd4cfe50590f0e972180db114

Could you share your view on scenario where a hostname changes on a fixed lease? Seems the new hostname doesn’t automatically update DNS records, but maybe that’s by design.

And Thanks.

pmueller · 30 July 2021 09:53

Hi,

good point - glad you spotted this.

Well, actually, underscores in FQDNs are valid characters as far as I am aware (unless they are terminal, I believe). So we should adjust this script to process such FQDNs properly.

EDIT: Bug #12664 has been raised for this.

Um, I have never really tried this. The “static” only applies to the DHCP context, though, but perhaps we do not call unbound-dhcp-leases-bridge in such cases; I am not quite sure.

Thanks, and best regards,
Peter Müller

bonnietwin · 30 July 2021 10:09

Not quite as simple as underscore allowed in FQDN.
Underscores (and hyphens) are allowed in the domain name. However the underscore is not allowed in the hostname although the hyphen is.

So the first part of a FQDN must not have an underscore but the remainder of the FQDN can.

I can’t remember the reason for this now but it made some sense when I read through RFC1035 and RFC2181 multiple times when I was working on Bug #12428

pmueller · 30 July 2021 10:44

Hi Adolf,

thanks for bringing this up. The plot thickens, I guess…

RFC 1035, section 2.3.1 does not really give a statement on underscores, unless I overlooked something. RFC 2181, section 11 appears to be commonly referred to justify DNS labels to contain anything. Searing for this, I found this answer of Stephane Bortzmeyer helpful: He points out host names are actually covered in RFC 1123, and section 2.1 in it forbids the usage of underscores.

Given records such as _dmarc.example.com or similar, underscores are fine in any part of a FQDN.

Our DHCP server, however, violates section 2.1 of RFC 1123, as it accepts DHCP clients which think their hostname comes with an underscore. On the other hand, I guess we won’t do our users a favour if we start dropping such DHCP requests.

Sigh. The world is a complicated place…

Thanks, and best regards,
Peter Müller

bonnietwin · 30 July 2021 11:36

Hi Peter,

Yes things are never as easy as you first think they should be. The wonders of standards by committee.

In the Edit Hosts page you can not specify a hostname with an underscore. It comes up with invalid hostname.

In the DHCP Server page you can put the first word in the remark with something like test_time and it will except it. That first word is supposed to be treated as if it is the hostname but I have always specified them in the Edit Hosts page manually.

There has been a bug request to have IPFire automatically take the first word in the DHCP Server Fixed Lease remark box and add that to the Edit Hosts page but then that would also mean that any existing entries that have an underscore would have to be excluded.

That was the entry I remember finding when I was figuring out what should be allowed where and when. Well done on finding that. I am not sure I could have found it now after 7 months.