adding ip to .local dns zone

[tcurdt]

Announcing services is easy and works fine - but does zerconf also allow for adding IPs to the zones like e.g. .local? Similar to what dnsmasq does.

[grandcat]

Sorry, I do not really get your question.
How should IPs be announced?

[tcurdt]

@grandcat TBH I have no clue how this actually works in detail myself - but it is zeroconf/mdns based :)

Just as an example: your boot up your RPi with octoprint installed and the machine is resolvable as octopi.local. Other machines in the local network can just "magically" resolve that name.
What I don't get yet is how the machine that looks up the name for the .local domain actually starts the resolving. But AFAIU when you run dnsmasq or avahi-daemon there is some kind of DNS server that get announced.

I assume this zeroconf project does not implement a DNS server as such, but I am also wondering if it could do the announcement and how it would need to look like.

Sorry for the vague issue - but does that make a little more sense now?

[tmm1]

This can be enabled by adding something like this to handleQuestion:

+	case s.service.HostName: // host.local.
+		resp.Answer = s.appendAddrs(resp.Answer, ttl, ifIndex, false)

The problem is zeroconf library doesn't really know if the hostname of the machine is already resolvable, so in some cases it might not make sense to respond to hostname questions (maybe you are on macOS and the system has a bonjour responder for the hostname, or you're on linux but have avahi-daemon installed also).

[tcurdt]

@tmm1 Do you know a bit more about the resolving process? The code you provided looks like the zeroconf responds with the actual address (so there isn't even any DNS resolver involved). I would have thought .local is still a DNS zone though.

I am really a little lost on finding the proper details on this.

[tmm1]

Maybe https://tools.ietf.org/html/rfc6762#section-5 is what you're looking for

[tcurdt]

@tmm1 Unless I misinterpret the rfc the zeroconf library could indeed be modified (as you suggested above). The only limitation is that the first answer wins - but that's expected with this kind of ip resolving. So a feature worth adding @grandcat ?