[Pkg-utopia-maintainers] Bug#466014: libnss-mdns: Replace mdns4* by mdns* in /etc/nsswitch.conf

[Pavel Šimerda]

On 04/26/2018 10:09 AM, Simon McVittie wrote:
> Control: forwarded 466014 https://github.com/lathiat/nss-mdns/issues/62
> 
> On Tue, 19 Feb 2008 at 00:15:11 +1000, Ted Percival wrote:
>>>>> Please replace mdns4_minimal and mdns4 by, respectively,
>>>>> mdns_minimal and mdns by default in /etc/nsswitch.conf.
>>>>
>>>> No, don't!
>>>
>>> Why is that ?
>>
>> I think the answer is in bug 388864, comment #20 (http://bugs.debian.org/388864#20):
>>
>>> Because many broken programs (one of
>>> them being "telnet") do host name lookups in a broken way: they first
>>> try an ipv6 lookup and if that fails fall back to ipv4. In mDNS host
>>> name lookups for nonexistant host names take a long time to
>>> timeout.
>>
>> People *do* complain when their apps become mysteriously slow at
>> connecting.
> 
> Yes, this. When people install nss-mdns (perhaps because something
> depends on it), and it makes seemingly unrelated software take an extra
> 5 seconds to connect, in my experience the usual reaction is to complain
> about nss-mdns (or about Debian in general, if the user does not
> successfully diagnose that the delay was caused by nss-mdns).

Both Avahi and glibc are problematic regarding dual-stack networking. I 
created a test suite project for application behavior that can be used 
to catch application problems but I also tested glibc thoroughly and and 
there are problems from the resolver implementation through the limited 
internal nsswitch API to the standard getaddrinfo API which is 
considered limited and unreliable by many and avoided using more custom 
(and also buggy) implementations.

It looks easy but in practice it proves by no means trivial to have a 
proper IPv4/IPv6 client behavior implemented. I have done many 
experiments with that and the situation in open source (or any other) 
software including the core components is not satisfactory at all.

https://github.com/crossdistro/netresolve
https://github.com/crossdistro/network-testing

> The goal of nss-mdns is to make it more likely that "the right thing"
> happens without configuration. If we want that to be the case, then it
> needs to be installed by default, but it is not useful to install it
> by default if it breaks applications.
> 
> On Fri, 03 Jun 2011 at 19:22:00 +0400, Anton Martchukov wrote:
>> Are there any issues left on this? I believe this is needed
>> for reaching full IPv6 release goal.
> 
> The reason to want IPv6 everywhere is that there are not enough
> globally-routable IPv4 addresses for everyone.

There is, in my opinion, no good excuse not to support IPv6 properly in 
open source software nowadays.

> However, mDNS is a
> link-local protocol: it doesn't need globally-routable IPv4 addresses,
> only RFC1918 or RFC3927 locally-valid addresses, and there is no shortage
> of those. So the situations in which it would be useful for nss-mdns to
> look up both IPv4 and IPv6 by default are:
> 
> * when the local machine is IPv6-only (no IPv4 addresses at all, not
>    even link-local addresses in 169.254.x.x); or

You may want to use link-local networking even for machines that have 
global IPv6 or IPv6. The switch to global IPv6 and the behavior of 
avahi/nss-mdns is IMO questionable.

Plus the current usage of IPv4 link-local are just useless because they 
are only used as a fallback to DHCP and only by some implementations and 
deployments.

> * when the machine we are looking up is IPv6-only (again, no IPv4 addresses
>    at all)
> 
> In both of these situations, using mdns_minimal instead of mdns4_minimal
> would turn unsuccessful name resolution into successful name resolution.
> 
> We have to trade these off against the situation in which it's harmful
> for nss-mdns to look up both IPv4 and IPv6 by default:
> 
> * the machine we are looking up is IPv4-only (no IPv6 addresses), or it
>    only advertises its .local name as IPv4; and
> * a program (inadvisably) uses getaddrinfo() with ai_family=AF_INET6,
>    and if that fails, it tries getaddrinfo() with ai_family=AF_INET;
>    or it does the equivalents with the obsolete gethostbyname2[_r]()

I can possibly help with automated tests and with development.

> In that situation, we don't want to incur a 5 second delay while the
> first getaddrinfo() call asks the network "does anyone know an IPv6
> address for printer.local?" and waits for replies.

You actually never want to incur a 5 second delay. I understand it is 
much better than the former 60 seconds or 15 seconds for many protocols 
but I'm convinced that the way to go is to always connect in ~100 ms if 
there is either IPv4 or IPv6 available to connect (i.e. do not enforce 
protocol precedence when one of the protocol is slower than that) and in 
rare cases where sequential connect is acceptable 1 second should be 
good enough.

> Now, it might be possible to modify the code of the mdns module to
> avoid this delay while still providing IPv6 support (perhaps replying
> with IPv6 addresses for AF_UNSPEC queries, but declining AF_INET6
> queries). However, that is not as simple as replacing mdns4_minimal
> with mdns_minimal, and should be done upstream, if at all.
> 
>      smcv

I would be honored if you contacted me directly and we could chat a 
little bit rather than have an online e-mail discussion.

Cheers,

Pavel