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

[Simon McVittie]

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).

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. 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
* 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]()

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.

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