3

This seems to be a behavior difference which only started in either 18.10 or 19.04.

While avahi-resolve --name my.subdomain.local returns a valid IP address and is working it doesn't work outside of that, i.e. ping, curl or chrome.

The name resolution does still work though for subdomain.local. This seems to be related to the fact that *.subdomain.local is resolved as mDNS CNAME.

Content of nsswitch.conf

passwd:         compat systemd
group:          compat systemd
shadow:         compat
gshadow:        files

hosts:          files mdns4_minimal [NOTFOUND=return] dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Content of /etc/resolv.conf

nameserver 127.0.0.53
options edns0
platzhirsch
  • 133
  • 8
  • What does the "hosts" line in /etc/nsswitch.conf look like (post in original question)? what does the /etc/resolv.conf link to, and its contents? What changes did you make to the default installation? – ubfan1 Sep 20 '19 at 04:56
  • @ubfan1 Thanks for querying the content of those files, I've added it to the question. I didn't do any modifications to the default installation that I know of – platzhirsch Sep 23 '19 at 17:29
  • Try adding the libnss-resolve package if it exists in 19.04. (manually edit the /etc/nsswitch.conf file otherwise to change the hosts line to: hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname That may fix some/all errros. – ubfan1 Sep 23 '19 at 20:35
  • @ubfan1 the libnss-resolve package solved it. Could you add this as an answer with an explanation why it helped? Thanks! – platzhirsch Sep 24 '19 at 18:48

2 Answers2

4

The following worked for me on Ubuntu 19.10:

sudo apt install libnss-resolve

sudo bash -c "cat > /etc/mdns.allow" <<'EOF'
.local.
.local
EOF

Then, edit /etc/nsswitch.conf as root and change:

hosts:          files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

to

hosts:          files mdns4 [NOTFOUND=return] resolve [!UNAVAIL=return] dns

This behavior is due to the two-label limit heuristic in nss-mdns. Other such limits are:

  • If the request does not end with .local or .local., it is rejected. Example: example.test is rejected.
  • If the request has more than two labels, it is rejected. Example: foo.bar.local is rejected. This is the two-label limit heuristic.
  • If, during a request, the system-configured unicast DNS (specified in /etc/resolv.conf) reports an SOA record for the top-level local name, the request is rejected. Example: host -t SOA local returns something other than "Host local not found: 3(NXDOMAIN)." This is the unicast SOA heuristic.

The above solution is adapted from github issue #64.

Colin
  • 63
  • 3
  • Is this one change on a single host expected to fix name resolution on all networked clients? Or this is only expected to fix each client's name-resolution strategy, and must be applied to all clients that wish to participate in non-minimal zeroconf name resolution? These might be stupid questions, but I'm basing it on the belief that avahi uses nss to figure out if it should respond to a zeroconf name resolution query, or whatever. AND that even when I change these the `hosts: line` and add the `mdsn.allow` file and reboot, I'm not able to ping or reach by `sub.domain.local` even locally. – Jason Kleban Jun 27 '20 at 12:55
2

There are many ways to set up DNS, but with the standard Ubuntu install using systemd I find that intermittent failures occur unless I also install the libnss-resolve package. The only thing this package does is to alter the "hosts" line in the /etc/nsswitch.conf file -- adding in "resolve [!UNAVAIL=return]" before the dns entry. e.g.

hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname

See bugs 1727237 systemd-resolved is not finding a domain, 1805027 systemd-resolved can't resolve Comcast mail server addresses, and 1804487 systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled

What makes these name resolution failures hard to track down is that they occur only under certain conditions, when a fallback to UDB has a limit of 512 bytes for results. How this problems relates to the nsswitch.conf hosts line is even harder to figure out, but the suggestion of adding the libnss-resolve package was mentioned in the bugs, and it fixed all my occasional problems.

This "fix" would be applied to the discovering machine(s), but no longer works in Ubuntu 20.04. short names are no longer resolved regardless of the installation of libnss-resolve unless passed directly to the router in dig. On the bright side, I see no more name resolution errors without the libnss-resolve package (which is not installed by default).

Pang
  • 371
  • 1
  • 5
  • 12
ubfan1
  • 17,041
  • 4
  • 39
  • 47
  • Ah, what's odd. It fixed resolving it with `avahi-resolve` but it still doesn't resolve in Chrome or ping or curl. – platzhirsch Sep 28 '19 at 00:14
  • Does this fix the host that we want to be discoverable or does it need to be applied on all machines doing the discovering? – Jason Kleban Jul 03 '20 at 03:06