mDNS functioneert niet op LAN domainname

[mithras]

Al lange tijd gebruik ik voor mijn LAN een domainname die met DHCP option wordt verspreid naar alle devices. Werkt perfect voor mDNS. Als ik een nieuw device (bijv RPi met software) in het netwerk breng kan ik met <hostname>.<domainname> het ding bereiken. Werkte met Windows, Ubuntu (16.* geloof ik), Android, iOS etc.

Niet meer met Ubuntu 18+ Avahi houdt vast aan de .local en niet het domeinnaam wat ik via DHCP verspreid. En dat gaat dus problemen geven met (Let's Encrypt) certificaten...

Ik heb afgelopen week een Xiaomi Mi notebook gekocht om mee te spelen, daar staat nu Ubuntu 18.10 op. mDNS functioneert hier niet naar behoren. Avahi is by default geinstalleerd, maar het luistert niet naar de domainname (of search list) die via DHCP wordt doorgegeven. En ondertussen wordt ik gek omdat ik ook geen consistente resultaten krijg.

kari is een RPi met software en slui.mn is het domeinnaam wat ik gebruik

mithras@katya:~$ hostname -f
katya
mithras@katya:~$ domainname 
slui.mn
mithras@katya:~$ dnsdomainname 
mithras@katya:~$ nslookup kari
Server:         127.0.0.53
Address:        127.0.0.53#53

** server can't find kari: SERVFAIL

mithras@katya:~$ nslookup kari.slui.mn
Server:         127.0.0.53
Address:        127.0.0.53#53

** server can't find kari.slui.mn: NXDOMAIN

mithras@katya:~$ nslookup kari.local
Server:         127.0.0.53
Address:        127.0.0.53#53

** server can't find kari.local: NXDOMAIN

mithras@katya:~$ ping kari
ping: kari: Temporary failure in name resolution
mithras@katya:~$ ping kari.local
PING kari.local (192.168.2.8) 56(84) bytes of data.
64 bytes from 192.168.2.8 (192.168.2.8): icmp_seq=1 ttl=64 time=1.20 ms
64 bytes from 192.168.2.8 (192.168.2.8): icmp_seq=2 ttl=64 time=2.79 ms
64 bytes from 192.168.2.8 (192.168.2.8): icmp_seq=3 ttl=64 time=1.95 ms
^C
--- kari.local ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 1.204/1.983/2.792/0.649 ms
mithras@katya:~$ ping kari.slui.mn
ping: kari.slui.mn: Name or service not known
mithras@katya:~$ 

Verder heb ik relevante bestanden soms wat gewijzigd, maar zonder succes en relevante stukken weer teruggezet:

mithras@katya:~$ cat /etc/nsswitch.conf | grep hosts
hosts:          files mdns4_minimal [NOTFOUND=return] dns
mithras@katya:~$ cat /etc/resolv.conf | grep search
search slui.mn
mithras@katya:~$ cat /etc/avahi/avahi-daemon.conf | head -n 40 | tail -n 20
[server]
#host-name=foo
#domain-name=local
#browse-domains=0pointer.de, zeroconf.org
use-ipv4=yes
use-ipv6=yes
#allow-interfaces=eth0
#deny-interfaces=eth1
#check-response-ttl=no
#use-iff-running=no
#enable-dbus=yes
#disallow-other-stacks=no
#allow-point-to-point=no
#cache-entries-max=4096
#clients-max=4096
#objects-per-client-max=1024
#entries-per-entry-group-max=32
ratelimit-interval-usec=1000000
ratelimit-burst=1000
mithras@katya:~$ 

Korte, ogenschijnlijk simpele vraag; hoe krijg ik mDNS weer werkend onder Ubuntu 18.10? Er staan online diverse opties (via nsswitch, resolv.conf etc) die bij mij niks uithalen. De opties als statisch hosts onder /etc/hosts opnemen zie ik niet zitten, want het is juist het mooie van mDNS dat het geheel dynamisch en redelijk goed via je DHCP server geregeld kan worden

[Hero of Time]

Dit vind ik anders wel een hele mooie in de config van avahi:

mithras@katya:~$ cat /etc/avahi/avahi-daemon.conf | head -n 40 | tail -n 20
[server]
#host-name=foo
#domain-name=local

Zoals het er staat, met het # ervoor, is dat de default. Wat zou er toch gebeuren als je dat instelt op het domein wat je voert?

[mithras]

Hero of Time schreef op maandag 8 oktober 2018 @ 21:51:
Zoals het er staat, met het # ervoor, is dat de default. Wat zou er toch gebeuren als je dat instelt op het domein wat je voert?

Ook dat heb ik geprobeerd, avahi-daemon.conf domain.name naar slui.mn gezet, avahi-daemon service opnieuw gestart, nslookup verandert daar niks aan. Ook avahi-discover geeft alles nog binnen .local aan trouwens.

Dus het is een van de dingen die ik wel geprobeerd heb, maar liever (als dit zou werken, mogelijk heb ik een foutje gemaakt omdat ik ook iets anders nog moet aanpassen?) niet op deze manier: ik zet dat de domeinnaam weer statisch in een config terwijl hij prima via DHCP moet kunnen doorkomen

[Voor 4% gewijzigd door mithras op 08-10-2018 22:05]

[Hero of Time]

Andere optie is om gewoon heel avahi eraf te trappen (heb nooit echt het nut ervan begrepen en zie meer issues erdoor dan het iets oplost), maar Ubuntu kennende zal er wel weer het een en ander aan dependencies aan hangen waardoor je je halve systeem weggooit.

[mithras]

mithras@katya:~$ sudo systemd-resolve --flush-caches 
mithras@katya:~$ ping kana.slui.mn
PING kana.slui.mn (192.168.2.1) 56(84) bytes of data.
64 bytes from kana.slui.mn (192.168.2.1): icmp_seq=1 ttl=64 time=1.58 ms
64 bytes from kana.slui.mn (192.168.2.1): icmp_seq=2 ttl=64 time=2.18 ms
64 bytes from kana.slui.mn (192.168.2.1): icmp_seq=3 ttl=64 time=2.38 ms
64 bytes from kana.slui.mn (192.168.2.1): icmp_seq=4 ttl=64 time=3.10 ms
^C
--- kana.slui.mn ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 8ms
rtt min/avg/max/mdev = 1.577/2.309/3.099/0.543 ms
mithras@katya:~$ nslookup kana.slui.mn
Server:         127.0.0.53
Address:        127.0.0.53#53

** server can't find kana.slui.mn: NXDOMAIN

mithras@katya:~$ ping kana.slui.mn
ping: kana.slui.mn: Name or service not known
mithras@katya:~$ sudo systemd-resolve --flush-caches 
mithras@katya:~$ ping kana.slui.mn
PING kana.slui.mn (192.168.2.1) 56(84) bytes of data.
64 bytes from kana.slui.mn (192.168.2.1): icmp_seq=1 ttl=64 time=1.60 ms
64 bytes from kana.slui.mn (192.168.2.1): icmp_seq=2 ttl=64 time=2.63 ms
^C
--- kana.slui.mn ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 3ms
rtt min/avg/max/mdev = 1.595/2.111/2.627/0.516 ms
mithras@katya:~$ 

Jep, we komen met #1727237 en #1766969 al wat dichter bij de oorzaak: systemd-resolve.

Ik heb nu /etc/resolve.conf laten verwijzen naar /run/systemd/resolve/resolve.conf ipv stub-resolve.conf en dit schijnt te werken.

Volgens mij zou dit zomaar het probleem kunnen zijn, maar even wat meer testen om daar zeker van te zijn...

[Hero of Time]

Ik kwam ook al wat tegen over systemd-resolv. Weer iets wat een init-systeem niet moet doen. Uitschakelen mogelijk?