Avahi .local domain warning on Ubuntu

I updated my long-unused Turris Omina to 5.0.3 and plugged it to my network. Since then I am getting a warning message “Your current network has a .local domain , which is not recommended and incompatible with the Avahi network service discovery.” on my Ubuntu 18.04 laptop.

I checked both Forris and Luci and I don’t see .local domain configured anywhere. My “Domain of DHCP clients in DNS” is set to “lan”. On the other hand, I’m pretty sure it has something to do with Turris as I did not get this warning with my previous router.

I’m quite lost in the complexities of Ubuntu DNS system with systemd-resolved so I don’t know how to debug the issue. I see that local domain is resolved when using the default server

host -t soa local.
local has SOA record local. nobody.invalid. 1 3600 1200 604800 10800

but not when I use my Omnia directly

host -t soa local.
Using domain server:

Host local. not found: 3(NXDOMAIN)

For now I got rid by the message by uninstalling avahi but I’d rather understand what changed when I started using Omnia and how to fix it.

I don’t think you need to worry. Default Omnia immediately answers any queries within local by NXDOMAIN (as specified), but it adds this SOA which appears to confuse your client into thinking that local gets some content in DNS. I’ll re-check later if we could “improve” these answers.

EDIT: the answers look like this:
$ dig local
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56352
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;local. IN A

local. 10800 IN SOA local. nobody.invalid. 1 3600 1200 604800 10800

explanation.invalid. 10800 IN TXT “Blocking is mandated by standards, see references on https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

Oh, I looked at their code. The notification seems to mean that avahi gets disabled, so I suppose some people could dislike that. The system scripts use that command host -t soa local. and apparently systemd-resolved gets confused into answering positively (in Ubuntu 18.04 at least, when forwarding to kresd).

Ok, but does it mean there is a bug in the avahi detection script, in systemd-resolved or in Omia. I found out that I actually need avahi as otherwise I cannot print in the office. My home setup works without avahi so I can kind of ignore the warning but it’s a bit annoying. Would do you suggest to do?

I think it will be easiest to use some workaround, probably one that just disables this check, e.g.: https://blog.naver.com/lucidmaj7/220372148021

What’s buggy? In my opinion it’s mainly systemd-resolved in this case, but to most users it doesn’t really make a difference whose mistake it is – if you replaced any of those three parts, you probably wouldn’t have the problem anymore. Behavior of each of the three isn’t ideal here.