[Bug]: Network based approach to identify "Meshtastic" service, not following established RFCs.

[AssetBurned]

Category

WiFi

Hardware

Not Applicable

Firmware Version

2.2.23

Description

Currently Meshtastic devices uses DNS-Based Service Discovery to announce their presence within an IP based network with a generic hostname. However there are several problems with this in the form of security conciderations, hostname collisions and misleading interpretations of RFC 6763 (https://www.rfc-editor.org/rfc/rfc6763.html).

The currentway of how a Meshtastic device is identified within an network is my looking at either its IP address or by using the announced meshtastic.local hostname.

There are three problems here.

1. Having a static hostname is a known "Current Hostname Practice Considered Harmful" (https://www.rfc-editor.org/rfc/rfc8117.html). Further information of why are outlined in this RFC. This RFC also informs in the introduction (https://www.rfc-editor.org/rfc/rfc8117.html#section-1): "Hostnames have to be unique within the domain in which they are created and used. They do not have to be globally unique identifiers, ..."

2. Hostname conflicts As it is not possible to change "meshtastic.local" to a different hostname, we run into what is outlined in Section 9 of RFC 6762 (https://www.rfc-editor.org/rfc/rfc6762#section-9) "A common example of a resource record type that is intended to be unique, not shared between hosts, is the address record that maps a host's name to its IP address. Should a host witness another host announce an address record with the same name but a different IP address, then that is considered inconsistent, and that address record is considered to be in conflict." Actually the Meshtastic nodes do not even attemp to renagociate the given hostname as they do not listen first for exsisting broadcasts. Which could classify an Meshtastic device as an harmful device within a network.

3. Expecting that the hostname matches the service that is offered. Meshtastic devices only announced themself as an _http._tcp and _https._tcp service. Wich identifies the hosts as devices that provide a web page serviice.

This infromation should inform webbrowsers and other similar applications can reach a host that offers an HTTP(S) service inside the network with the via the hostname "meshtastic.local". This should ease the way how users can reach their devices.

However the wrong expectation is that every device that is called "meshtastic.local" is also a meshtastic device. As any form of devices can use this as a hostname.

Conclusion: As every Meshtastic devices is claiming this hostname, we now have the situation that we have an none unique hostname in the network and the wrong expectation that every host named meshtastic.local is offering a meshtastic node service. On top we do have an inconvinience for users that, due to the hostname conflict, the hostname can no longer be used to address a device. Which leaves the function to announce the hostnames sole purpose to be an confirmation of the type of service offered.

Solution: Looking at RFC 6763 and RFC 2782 provide well established guidelines on how to differeniate between services offered and how to identify an individual host.

RFC 2782 (https://datatracker.ietf.org/doc/html/rfc2782) "A DNS RR for specifying the location of services (DNS SRV)" gives further information on how services should be announced within a network. The RFC uses her a simple example of offering a LDAP server within an network.

Based on above a more appropriate way to identify that a specific device as an Meshtastic compatible device would be to announce itself for example as "_meshtastic._tcp.". While also announcing that there are _http._tcp and _https._tcp services offered by this device.

This would not only allow any of the applications who are developed as part of the overall Meshtastic Project, to more reliable know that this is a compatible device, but also allow third party tools to have an idea what kind of service this webservice is actually offering.

Not only that decuple of the service discovery from a general device discovery would means that it can be possible to give each Meshtastic node inside a network an unique hostname.

By having a dedicated service announcement (again e.g. "_meshtastic._tcp.") additional information can be published without the need to actually connect to the service. For example the firmware version, used frequencies, channel names could be announced or API versions. This would make it even easier for applications to provide users with those information, as most modern operating system would cache this locally.

Relevant log output

No response

[andrekir]

1. RFC 8117 is informational only and simply brings up the risk of tracking devices using their hostnames as unique identifiers. completely unrelated.

2. there are no hostname conflicts. if "meshtastic.local" is taken, "meshtastic-<number>.local" is used.

3. http and https are announced because they do provide a web service.

[dougle03]

+1 for user configurable mDNS hostnames. I've a very busy network and being able to edit the hostname would be very useful. Thanks

[cshields]

relates to #3230 where the network hostname (correct or not) is not used when reporting the hostname to syslog, rather the BLE identifier with an underscore which breaks parsing the logs per DNS naming in RFC 1035 / RFC 1123.

[AssetBurned]

About 1: Yes it is informational, and that point was more meant to be as such. But also as an additional reason why an user changeable hostname would make sense.

About 2: So looking at my other ticket (which actually caused this) https://github.com/meshtastic/firmware/issues/3252 this means that tickets are closed here and slightly misleading answers are given. Grand nobody can know everything and I haven't seen something in the documentation. However i have read by know the same statement that you have to go via IP rather than an alternative hostname. Is there a way to provide a feedback for the documentation as it definitely should be documented (so that others can reference the correct information) that Meshtastic is actually preventing name collisions?

About 3: Correct, like i stated those should remain to be advertised as the devices do indeed offer a web service. However to identify that this web service is also a Meshtastic device, another indicator should be used.

I still think a user changeable hostname makes more sense. Not only in case you want to setup a device where the display is not there (or visible) but also not everyone has an DHCPd or the knowledge to set fixed IPs.

[Heppie]

+1 for configurable mDNS names

[JoKneeMo]

Landed here while looking for a config item to set the hostname.

Currently multiple devices broadcast mDNS with an incrementing number, but the self signed TLS cert doesn't take that into account. It forces every devices cert to meshtastic.local in mesh/http/WebServer.cpp#L102

I think the fall-through network naming order should be Hostname:

1. config.network.hostname
2. meshtastic
3. meshtastic-X

Domain:

1. config.network.domain
2. .local