Hnet service registration/discovery

Configuring my routers to use hnet for Homenet. One of the things Homenet should do is allow registration and discovery of resources (printers, http servers, etc). Is there a way to use hnet with dnsmasq to register services as DNS records?

I can see in hnet's option.c the function hncp_sd_write_dnsmasq_conf() which writes out a dnsmasq config file, but for services it only writes out pointer records for b._dns-sd._udp... and lb._dns-sd._udp... as per RFC6763 " DNS-Based Service Discovery". But there is no pointer record for r._dns-sd._udp... for registering new services, and no SRV or TXT records. hnet also updates the config file on a timer and restarts dnsmasq, so any changes added would get lost.

I know that dnsmasq can dynamically update the DNS from new DHCP records, but that only seems to be for hostnames/ip, not services.

I've come across the Perl script which "tries to emulate's dynamic dns service" but that also seems to deal with hostname/ip records (via the option 'addn-hosts') rather than service records. It also restarts dnsmasq by sending SIGHUP, which also seems like an 'out of band' mechanism.

/etc/dnsmasq.conf could have service records added, but I kind of think that should be a relatively static file, rather than one which is dynamically updated as services come and go.

And now I've run out of ideas. Anyone else got some?

Okay, I think I've got it. Service discovery in OpenWrt using DNS is based on 4 components:

  • the DNS server - dnsmasq
  • the mDNS daemon - mdnsd
  • whatever registers services e.g. Avahi
  • the translator between DNS and mDNS - ohybridproxy

What is not so obvious is that the behaviour between the first two is conditioned by the domain names chosen in hnet and ohybridproxy. The choices seem to be:

  • .local - used initially by Apple's Bonjour, still the default domain for mDNS services
  • .home - common, and in the original HNCP RFC7788
  • - the revised domain in RFC8375

I was using the domain name in the config files /etc/configuration/hnet and /etc/config/ohybridproxy. For services, I was registering them using Avahi and leaving the domain to the default, i.e. .local. A typical failing query was

dig PTR

Using .arpa and .local is where it broke down. Looking at logread and the source code for ohybridproxy there are two cases:

  • domain name ends in .arpa e.g.
    ohybridproxy doesn't translate the query domain and hands it unchanged to mdnsd. It finds no services in domain Avahi (or dns-sd or whatever registers services) has to register them in the same domain.
    For example in /etc/avahi/services/XYZ.service it needs
  • domain name does not end in .arpa
    ohybridproxy does translate the domain to .local. Then DNS lookups can find the services registered with the default .local domain

So I should be using throughout, but there are still seem to be many services which advertise themselves in the .local domain. Hmmm, a nuisance, but that is a different problem!

Update: I've registered it as an issue at ohybridproxy because it looks like a bug to me :slight_smile:


This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.