Parallel host search for both IPv6 and IPv4 addresses should be offered to nss-mdns

[pemensik]

I have just created new issue https://github.com/lathiat/nss-mdns/issues/83 for nss-mdns. But I think Avahi itself is missing the required functionality.

The resolution of nx.local, when that host does not exist, takes quite a long time. I think it should be possible to make queries in parallel, because the applications using getaddrinfo() calls tells us clearly to use both families. To have IPv6 handled by default also, we need to make that resolution quicker. I think there is no good reason to lookup them in serial way, like it does now. It doubles timeout time.

Instead we should have implemented logic for speeding up the search if we have already answer for a single address family. That makes NXDOMAIN response to NOERROR. I think we might want to limit additional waiting just to 200ms after the first response of any families were received.

Anyway, I think MDNS protocol allows nx.local IN ANY? query, which would be useful exactly for this reason. I have not found way to request this via avahi-resolve command, so I doubt we have it implemented already. I think to enable both protocol by default in a distribution, we need something similar.

Is there already some support for it? I think local names are more needed for IPv6, so they should work out of the box. But they don't on current Fedora, I think other distributions have similar issues.

[arrowd]

Bumped into exactly this problem. Running avahi-resolve-address <some ip that doesn't have avahi running> takes 5 seconds until timeout. When using nss-mdns it makes connecting via SSH to also be delayed by 5 seconds. It'd be great to have this fixed somehow.

[pemensik]

We may not need to send ANY query on mdns, but we should create two separate lookups based on single request received from simple socket used by nss-mdns. That needs modification of procotol used:

• Need to be able to serve multiple answers to single request. Current way is to serialize requests on plugin side and do them sequentially. Current protocol is trivial and line oriented, expects single line request and single line answer. Variable number of answers need to be supported, where order of first answer address family is not guaranteed.
• Ability to send back instructions whether the resolution ends or should continue to the next plugin, probably dns. That would allow caching local. SOA? unicast DNS query result in the daemon and instruct plugin to continue with unicast DNS. Usually that would be done without sending resolved address back. But we might want to be able to try both, mdns and unicast dns when local exist in normal DNS.
• This might unnecessary delay unicast DNS resolution of local domain until avahi-daemon responds, but I doubt there is a better variant to current implementation. The need to resolve local domain should be exceptional anyway.

Having it configurable at the daemon would allow nicer syntax too.

[pemensik]

Something like support for RESOLVE-HOSTNAME-ANY, in addition to RESOLVE-HOSTNAME-IPV4 and RESOLVE-HOSTNAME-IPV6. There is already RESOLVE-HOSTNAME in simple-protocol.c, but problem with it is it cannot serve multiple responses. It serves just one answer, even if there are more possible answers. I think that is primary reason why it is not used anymore. This would need a new AVAHI_LOOKUP_RESULT_ flag and modify host_name_resolver_callback to be called multiple times somehow.

Alternative might be just spawning two host_name_resolvers and for each write either success address. If one fails, we know at client which one was that by checking AF of response. If both fails, not sure client needs to know which result were for which family. At least nss-mdns won't report it in any complex way in that case.