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.
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.
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.
Regards
Esko
-----Original Message-----
From: avahi <avahi-boun...@lists.freedesktop.org> On Behalf Of Petr Menšík
Sent: Wednesday, December 7, 2022 17:38
To: Avahi ML <avahi@lists.freedesktop.org>
Cc: ago...@google.com; zdoh...@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, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
