6

Something I've noticed on all my home machines is that none of them can resolve .local addresses for IPv6. This seems odd because they can resolve them for IPv4 and all of my home machines have both Link-Local fe80:: addresses and public 2a00:: addresses.

So far I've been unable to figure out what's missing for these to work.

IPv4

# ping neptune.local
PING neptune.local (192.168.1.223) 56(84) bytes of data.
64 bytes from neptune (192.168.1.223): icmp_seq=1 ttl=64 time=275 ms
64 bytes from neptune (192.168.1.223): icmp_seq=2 ttl=64 time=197 ms

IPv6

# ping -6 neptune.local
ping: neptune.local: Name or service not known

# ping -6 2a00:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
PING 2a00:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx(2a00:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx) 56 data bytes
64 bytes from 2a00:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx: icmp_seq=2 ttl=64 time=2.21 ms
64 bytes from 2a00:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx: icmp_seq=3 ttl=64 time=3.13 ms

Hosts entry from /etc/nsswitch.conf:

hosts:          files mdns4_minimal [NOTFOUND=return] dns

How do you enable mDNS for IPv6 on Ubuntu and/or Debian?

Philip Couling
  • 17,591
  • 5
  • 42
  • 82
  • Would you please add your `/etc/nsswitch.conf` to the question? – Rui F Ribeiro May 13 '20 at 09:50
  • 1
    @RuiFRibeiro I've never needed to edit this on any machine so they are all the default that ships with Debian or Ubuntu. I've added the relevant line to my question. The issue appears to be one that applies to freshly installed machines, so the question is really how to enable from a stock install. – Philip Couling May 13 '20 at 10:30

2 Answers2

10

For enabling IPv6 for mDNS in avahi there is a need to change configurations, both in the client and server side for Linux VMs. The steps are:

1) Configure avahi for IPv6, if it is not already done (Debian 10 has already that as a default):

In /etc/avahi/avahi-daemon.conf

[server]
use-ipv6=yes

2) Change the mDNS line line entry in /etc/nsswitch.conf from:

hosts:          files mdns4_minimal [NOTFOUND=return] dns

To:

hosts:          files mdns_minimal [NOTFOUND=return] dns

3) Then restart the avahi service, either with:

sudo service avahi-daemon restart

or:

sudo systemctl restart avahi-daemon.service

see Enabling IPv6 support in Avahi (Zeroconf/Bonjour)

Rui F Ribeiro
  • 55,929
  • 26
  • 146
  • 227
  • For future readers could you clarify which hosts need the two settings. *I believe* that `nsswitch.conf` settings need to only be on the client trying to resolve a name, where the `avahi-daemon.conf` settings need to be on the server who's name is being resolved... or maybe both? For a happy life, all settings should be on all boxes, but it's worth knowing what each setting does. – Philip Couling May 13 '20 at 13:19
  • 1
    @PhilipCouling Sensible and pertinent question. Both. Both the client and server have to be IPv6 aware IMO. All the machines involved in this setup would benefit from these settings, if Zeroconf functionality is desired. – Rui F Ribeiro May 13 '20 at 13:21
4

See http://0pointer.de/lennart/projects/nss-mdns/

In /etc/nsswitch.conf, mdns4_minimal enables mDNS resolution for IPV4 only, and for .local domain and link-local addresses (169.254.. in IPv4) only.

There is a corresponding mdns6_minimal for IPv6-only, and mdns_minimal for both IPv4 and IPv6 resolution. And if you wamt mDNS to also resolve non-link-local addresses, there are also corresponding versions without the _minimal suffix.

/usr/share/doc/libnss-mdns/README.Debian on your system describes why the default configuration is your 

hosts:          files mdns4_minimal [NOTFOUND=return] dns

and not the upstream's

hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4

Basically, the latter form was found to frequently cause 5-second delays on attempts to resolve non-local DNS information that does not actually exist. It turns out that rapid detection of non-existing DNS records is important for user experience.

That's also why the default is to enable mDNS on IPv4 only: enabling it for IPv6 (either exclusively or together with IPv4) in an environment where IPv6 is not actually in use may cause long timeouts in name resolution, as the resolver library will generally try IPv6 resolution before IPv4 unless explicitly told otherwise.

telcoM
  • 87,318
  • 3
  • 112
  • 232
  • You've slightly lost me with the two hosts lines. Neither would resolve IPv6; correct? – Philip Couling May 13 '20 at 12:42
  • Debian’s default configuration deletes the ...mdns4 at the end, compared to upstream recommendations. Just replace mdns4_minimal with mdns_minimal if you want mDNS for both IPv4 and IPv6, or with mdns6_minimal if you want it for IPv6 only. – telcoM May 13 '20 at 12:50
  • ah, so the upstream vs downstream configuration was a side discussion and not directly answering the question. Okay understood. Thanks for the clarification. – Philip Couling May 13 '20 at 13:12
  • Just anticipating a possible "but why the upstream author's recommendation is different?" add-on question. :-) If I recall correctly, the behavior with the `...mdns4` tacked on at the end was annoying. – telcoM May 13 '20 at 13:15
  • Yeah. What is an interesting question is why `mdns4[_minimal]` is default and not `mdns[_minimal]` – Philip Couling May 13 '20 at 13:21
  • @PhilipCouling Avoiding IPv6 side effects from ones not using it or with it badly configured? IPv6 takes precedence over IPv4 by default. – Rui F Ribeiro May 13 '20 at 13:26
  • @RuiFRibeiro to rephrase... side effects? do you have any in mind or are you assuming there are some? – Philip Couling May 13 '20 at 13:27
  • @PhilipCouling Just a supposition. In the past, I was running the network/systems of some big organizations, including a couple of ISPs and witnessed very weird problems due to some strange interactions between IPv6 and IPv4. – Rui F Ribeiro May 13 '20 at 13:30
  • @PhilipCouling Intended to post an answer earlier, and beat only telcoM by a minute, because 3 work meetings and lunch with wife had priority. ;-P – Rui F Ribeiro May 13 '20 at 13:32
  • 1
    @RuiFRibeiro Apparently that supposition has been found entirely correct, as long name resolution delays induced by IPv6 attempts are mentioned in the first link I posted. – telcoM May 13 '20 at 13:38