Pass avahi-daemon parallel IPv4/6 queries

[danielzgtg]

This optimizes the query time.

glibc patches are required to ensure getent ahosts uses _nss_mdns_gethostbyname4_r. As such, this is untested until the patches land.

Closes: #83

[pemensik]

I am afraid it won't be so simple. RESOLVE-HOSTNAME command can return only 1 IP address. We need to modify it to return multiple addresses. For AAAA and A records, each can have multiple addresses.

RESOLVE-HOSTNAME-ANY command should be defined as new. Reusing RESOLVE-HOSTNAME command would lead to problems.

[danielzgtg]

need to modify it to return multiple addresses. For ... and A records, ... can have multiple addresses.

The second half should be another PR. I am preserving the existing behavior of getent ahosts daniel-tablet1.local. Without my modifications:

home@daniel-desktop3:~$ getent ahosts daniel-tablet1.local
192.168.3.91    STREAM daniel-tablet1.local
192.168.3.91    DGRAM  
192.168.3.91    RAW    
home@daniel-desktop3:~$

This is despite Wireshark showing the remote avahi-daemon responding with two addresses (Ethernet then WiFi): This is because avahi-daemon responds twice with one address twice and clears the other one. The existing RESOLVE-HOSTNAME-IPV4 and RESOLVE-HOSTNAME-IPV6 seem capable of only returning one address each.

There might be a change for dual IPv4/IPv6 networks. Do we really want to return both IPv4 and IPv6 addresses? @evverx objected to my avahi/avahi#765 (comment) PR saying "nss-mdns ... [should use] RESOLVE-HOSTNAME where it can send A and AAAA queries at the same time and return whatever comes first".

[evverx]

@evverx objected to my avahi/avahi#765 (comment) PR saying "nss-mdns ... [should use] RESOLVE-HOSTNAME where it can send A and AAAA queries at the same time and return whatever comes first".

I closed that PR because it changed the Avahi public API in the sense that it was no longer possible to send AAAA queries over IPv4 for example.

@danielzgtg can you maybe open an issue based on avahi/avahi#765 (comment) (where you mentioned that with use-ipv6=no, mdns4* and resolved your .local queries leaked to the DNS resolvers) and add as many details as possible? I get that you are interested in fixing your particular use case but it should be necessary to keep the other use cases in mind as well and that would be more involved than short patches getting things to work to cover specific use cases.

[danielzgtg]

I'll rewrite this PR to use select(2) (compatible with BSD). I tried adding RESOLVE-HOSTNAME-ANY but faced architectural obstacles only allowing returning one address. Sorry, in that avahi PR, I didn't realize the mDNS equivalent of dig @1.1.1.2 google.com AAAA was possible.

I'll PR systemd about Domains= later. Failing that, I can always live with the 5 s delay or write a libnss module to return NOTFOUND for IPv6 .local.

[evverx]

I'll PR systemd about Domains= later

I'm not sure Domains= is the culprit here. I launched resolved built from the main branch with its default config and saw

varlink: New incoming connection.
varlink: Connections of user 1000: 0 (of 576 max)
varlink-15-15: Setting state idle-server
varlink-15-15: Received message: {"method":"io.systemd.Resolve.ResolveHostname","parameters":{"name":"freebsd.local","family":10,"flags":0}}
varlink-15-15: Changing state idle-server → processing-method
idn2_lookup_u8: freebsd.local → freebsd.local
Looking up RR for freebsd.local IN AAAA.
Failed to connect to /run/systemd/resolve.hook/io.systemd.Network: Connection refused
Socket '/run/systemd/resolve.hook/io.systemd.Network' is not connectible, probably stale, ignoring: Connection refused
varlink-15-15: Sending message: {"error":"io.systemd.Resolve.NoNameServers"}
varlink-15-15: Changing state processing-method → processed-method
varlink-15-15: Changing state processed-method → idle-server
varlink-15-15: Changing state idle-server → pending-disconnect
varlink-15-15: Changing state pending-disconnect → processing-disconnect
varlink-15-15: Changing state processing-disconnect → disconnected

As far as I understand it would mean that for example Fedora by default ships configs that leak all the .local queries to the DNS resolvers and that would be useful to keep track of it here.

[evverx]

That being said it doesn't look like queries actually go anywhere so I'm not sure what happens in your case. Either way can you open an issue and attach as many details as possible?

[danielzgtg]

I finished the select(2) work. Effects on getent are still absent while waiting for glibc patches. What works is ./avahi-test daniel-tablet1.local doing AF_UNSPEC as instantly as AF_INET.

After rereading @pemensik's comment, I realized select(2) doesn't help the goal of returning both addresses. I removed that syscall (and its speedup) and preserved the idea of launching both queries before reading any. Here is the test after enabling IPv6 (in NetworkManager and avahi-daemon) on the remote:

$ /home/home/CLionProjects/nss-mdns/avahi-test daniel-tablet1.local
AF_INET: 192.168.3.91
AF_UNSPEC: 192.168.3.91
AF_UNSPEC (count): 2
AF_UNSPEC (list): 192.168.3.91
AF_UNSPEC (list): fe80::8e40:17a:41ab:2a9f
REVERSE: daniel-tablet1.local
AF_INET6: fe80::8e40:17a:41ab:2a9f

@evverx Sorry I meant having the Domain= variable set like Domains=~. .

[danielzgtg]

My use case is satisfied by systemd/systemd#39800, which additionally fixes the extra DNS SOA packet.

What remains in this PR is focused solely on #83.