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 dynamic-dnsmasq.pl which "tries to emulate DynDNS.org'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
.home.arpa - the revised domain in RFC8375
I was using the domain name home.arpa. 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 _http._tcp.openwrt.home.arpa
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. .home.arpa ohybridproxy doesn't translate the query domain and hands it unchanged to mdnsd. It finds no services in domain .home.arpa. 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>.home.arpa</domain-name>
domain name does not end in .arpa ohybridproxydoes translate the domain to .local. Then DNS lookups can find the services registered with the default .local domain
So I should be using .home.arpa 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
