[avahi] Is it time to drop .local SOA heuristic?

Fri Dec 9 09:41:37 UTC 2022

Thanks Petr for your thorough explanation. 

The root server statistics for .local are interesting; as the Special-Use Domain registration and associated rules are supposed to stop such .local queries from reaching the DNS root server.
So these stats would support a decision to stop supporting ".local" over unicast or trying to avoid it as much as possible.

That said, I had quite some cases myself where I tried a .local resolution on a Linux system which failed when no mDNS component was installed. Probably this just got sent as unicast DNS query. 
Such cases add up to the volume.

For a correct ".local" legacy use support, it would need to auto-configure itself per interface and even per network (e.g. if I let my laptop sleep and bring it to a new WiFi network, or new Ethernet, it needs to redetect on the new network, whether .local means mDNS or unicast-query.)

Esko

-----Original Message-----
From: avahi <avahi-bounces at lists.freedesktop.org> On Behalf Of Petr Menšík
Sent: Thursday, December 8, 2022 21:09
To: avahi at lists.freedesktop.org
Subject: Re: [avahi] Is it time to drop .local SOA heuristic?

Thanks for your reply. Unfortunately the situation with .local is still 
bad. That domain is often queried on DNS root servers and not only for 
SOA record, which would make this heuristic probably the reason.

Interesting root server statistics:
https://stats.dns.icann.org/stats/d/wom-ext-5minagg-qtype-vs-tld/qtype-vs-tld?orgId=1&var-Server=IMRS&var-Region=All&var-Country=All&var-City=All&var-Instance=All

I think the problem is inability to disable avahi just on *some* 
networks, where .local unicast domain might be used for some 
network-specific content. nss-mdns package is optional, but you can 
either disable it always or enable it always. There is no way to 
specify: just on this network disable mdns resolution. File 
/etc/mdns.allow might configure manually whether .local is acceptable 
for multicast resolution. It would be used always. Just like disabling 
avahi-daemon. That is what .local SOA? query allows, disabling mdns on 
networks where it gets positive response. We lack a good way to disable 
that resolution just sometimes.

More below...

On 07. 12. 22 21:14, Esko Dijk wrote:
> Hi Petr,
>
> Besides the mDNS RFC there is also RFC 6761 that defines the special-use domain names, one of which is ".local". Both RFCs were completed early 2013 so nearing 10 years now.
> Implementations that ignore the special status of ".local" are not just 'ignoring mDNS' but they are ignoring the foundations of the domain name system.
>
> The special-use domains are not available for other purposes than their special use, so for ".local" it means use for mDNS only is intended. Section 22.1 defines the formal requirements.
> A DNS server that follows these relevant IETF specs shouldn't be normally configurable for .local use , however an exception is allowed for test use and special use.
>
> Also a resolver library by default does not create DNS unicast queries for .local :
>
>     3. Name resolution APIs and libraries SHOULD recognize these names
>           as special and SHOULD NOT send queries for these names to their
>           configured (unicast) caching DNS server(s).
>
> The "SHOULD/SHOULD NOT" allows an exception for unspecified exception cases; I believe this was to cater for older resolver code and for legacy/test networks.
>
> So it seems clear that Avahi and other software (some was mentioned in [1] I think) needs by default to treat the .local domains as "special" and not do any unicast name resolutions for it.
> If software needs to be configured specifically to disable unicast queries for .local then this is the wrong way around!  Doing a manual configuration action to enable the unicast .local queries would be acceptable, for the aforementioned legacy, hacking, and testing purposes.
There is a problem some people were using .local zone even before MDNS 
were created. They should be told that their configuration is wrong, but 
I doubt nss-mdns is a good place for it. I think avahi-daemon might 
report warning in such case, just once per start. It used to work and it 
seems some people still rely on this unregistered domain name. Anyway, 
any change for them would cause regression. That is why I am looking for 
some backward compatible way at least partially.
> In the latter case, when unicast .local queries are enabled, could the queries be sent in parallel? The first-one-then-the-other waiting approach seems strange.
No, parallel queries cannot be done easily in nsswitch. Because mdns 
module implements just mdns and dns is implemented by another module and 
the order of modules used is fixed. One module cannot call the other 
one. It would be nice if the order could be changed dynamically, but the 
API does not allow that. This is also privacy related. We do not want to 
leak all names used on local network to DNS server far on the internet. 
That is why under normal circumstances we do just mdns and if not found, 
we end there for *.local names. On the other hand, DNS resolution is 
quick, unlike long timeout required for NXDOMAIN response on mdns.
> Since the special use of .local for mDNS remains valid even when someone decides to configure their DNS server with ".local".  If someone really wants only unicast .local queries to be sent out it's always possible to disable Avahi.

I agree multicast resolution should be preferred, but I think we want 
per-network configuration of mdns resolution, just like NM can do with 
systemd-resolved. Manual change works fine for device fixed in just one 
network. But with laptops and mobile devices that won't work well.

I would like to extend avahi-daemon eventually to be able to configure 
used interfaces dynamically. But that will not be a tiny change.

>
> Regards
> Esko
>
> -----Original Message-----
> From: avahi <avahi-bounces at lists.freedesktop.org> On Behalf Of Petr Menšík
> Sent: Wednesday, December 7, 2022 17:38
> To: Avahi ML <avahi at lists.freedesktop.org>
> Cc: agoode at google.com; zdohnal at redhat.com
> Subject: [avahi] Is it time to drop .local SOA heuristic?
>
> Hello everyone.
>
> We have spent almost whole day discussing options about fixing issue [1]
> with non-working .local resolution. It turned out the responsible were
> unicast name server, which contains .local zone with SOA record.
>
> I think current implementation is not the best one. I believe Apple
> product is doing similar checks, but with different results [2]. If they
> find .local SOA record, then they first send query to DNS, then if not
> found there try at least mdns. That seems to be ideal way to solve it.
> DNS can respond fast that no such name exists, unlike its multicast
> counterpart.
>
> Unfortunately nss-mdns plugin just skips MDNS, but never retries it
> after the DNS. I see there two problems:
>
> - mdns should not implement dns queries itself, especially when parallel
> IPv4+IPv6 queries occur.
> - resolve plugin does not allow anything pass after that in current
> fedora's configuration. So appending fallback mdns plugin AFTER dns
> would not work, because nothing reaches there when systemd-resolved is
> active.
>
> There is a question, whether still in year 2022, almost 10 years after
> MDNS RFC were published, exist deployed .local zones in unicast DNS with
> a real data. Would anyone know? Do we still want to prevent .local zone
> breakage in unicast DNS?
>
> Our results of the best available solution were this:
>
> - if .local SOA is detected, do MDNS query anyway
> - if the host is not found on MDNS, return UNAVAIL as result to nss.
> Allow continuing to next module, resolve or dns. We expect
> /etc/nsswitch.conf contains something like hosts: ... mdns4_minimal
> [NOTFOUND=return] dns
> - set shorter timeout in this case, so the DNS response is returned in 1
> or 2 seconds. Current 5 seconds does not seem acceptable.
> - (optional) move .local SOA query to avahi-daemon, so it can be cached
> for at least few seconds.
>
> If .local SOA is not found, then return NOT_FOUND and stop further
> resolution.
>
> An alternative would be removing this test at all and do mdns queries
> always. If we had network-specific configuration of mdns, like
> systemd-resolved can do, this would not be necessary. You could just
> disable mdns where .local unicast domain provides useful data.
>
> What would you think about that plan? Does it sound reasonable or not? I
> think it would make it still usable even on legacy networks. Without
> dramatic regression. Yes, it would add increased delay to unicast
> *.local names, but otherwise they would stay working.
>
> Any comments welcome. I have tried to do draft [3] on nss-mdns plugin,
> which keeps timeout unchanged, but at least allows DNS query after
> unsuccessful MDNS query. If someone would like to test it, I would be
> grateful.
>
> Regards,
> Petr
>
> 1. https://bugzilla.redhat.com/show_bug.cgi?id=2148500
> 2. https://github.com/lathiat/nss-mdns/issues/75
> 3. https://github.com/lathiat/nss-mdns/pull/84
>
-- 
Petr Menšík
Software Engineer, RHEL
Red Hat, http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB