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
