mdns takes care of .local names. Everything else goes tp dns. Thus, the namespaces for mdns and dns are nicely separate.
1 Like
I was replying the the earlier post that linked a howto for making systemd-resolve/dnsmasq also answer queries for .local host names.
Yes, so that’s the DNS part of it. If you want DNS to also resolve the mDNS .local, then you’d have to configure Avahi as an upstream resolver for .local in dnsmasq in that scenario. But as @vekruse pointed out, that’s not generally necessary.
That doesn’t appear to be what the howto is recommending. The howto says to put the following in /etc/hosts and have dnsmasq directly (and in competition with Avahi) answer .local queries.
Excerpted from setup-dnsmasq-and-systemd-resolved-for-local-hostnames:
I have lines like these in my /etc/hosts file:
127.0.0.1 toph.local
127.0.0.1 drafts.toph.local
127.0.0.1 quiz.toph.local
So in the above example, if someone plugs something named “toph” into their local network that broadcasts Avahi packets, what address will come back in response to nslookup toph.local?
Edit: My mistake, Vladislav pointed out that nslookup doesn’t pass requests through the libraries configured in /etc/nsswitch.conf. I should have asked, “… what address will come back in response to getent hosts toph.local (or any other program that calls the getaddrinfo() libc function)?”
1 Like
That howto is confusing. There is no need to run systemd-resolved if you already run dnsmasq, as dnsmasq will do the caching, and systemd-resolved would disable caching in this case.
If you want to resolve .local names with dns or /etc/hosts, you should disable nss-mdns; that can be done with authselect.
2 Likes
The systemd-resolved manpage is clear:
Note that these days, it's generally recommended to avoid
defining ".local" in a DNS server, as RFC6762[2]
reserves this domain for exclusive MulticastDNS use.
dnsmasq is kindly performing DNS for “.local” TLD.
systemd-resolved is NOT handling “.local” TLD by DNS unless it is mentioned as domain.
If it is mentioned as domain, it will be shown by “resolvectl query, dig and nslookup” but most programs will fail because mdns4_minimal bails out before systemd-resolved gets the chance to resolve it.
#getent hosts test1.local
# getent -s resolve hosts test1.local
192.168.99.99 test1.local
This with a remote dnsmasq, and “local” as “DNS domain” in systemd-resolved.
So general conclusion: avoid the .local domain when using DNS.
systemd-resolved is the DNS client. dnsmasq is a DNS server. You definitely can use both and dnsmasq doesn’t need to live on the same machine - just on the same network.
You can. It is just simpler if you don’t. And running both have no added advantage.
Again, they’re two different components. It’s not one or the other. systemd-resolved is a client. dnsmasq is a server. They do two distinctly separate things.
Both are server and client at the same time, and there is a huge overlap of what dnsmasq and systemd-resolved can do.
It has been mentioned that dnsmasq will read /etc/hosts and make the names therein available. And so can systemd-resolved. If you add the option DNSStubListenerExtra= to resolved.conf, then systemd-resolved can be a dns server for other machines and server the addresses found in /etc/hosts. And so can dnsmasq.
It looks like systemd-resolved has mDNS options as well. To avoid conflicts or race conditions, I’d probably try to run everything under systemd-resolved if possible. Although, I’ve read that mDNS has limitations when it comes to multi-homed network configurations (two or more IP addresses tied to a machine). Apparently mDNS cannot resolve/route traffic to specific IP addresses in that case. If that is true, I’d probably disable mDNS completely and not use it at all.
You need to make a choice and should not mix these options
-
Don’t use mDNS at all
-
Resolve mDNS using avahi and nss-mdns
-
Resolve mDNS using systemd-resolved
For option 1. and 3. you should disable nss-mdns using autheselect and disable avahi. If you wish, you can even remove the corresponding packages.
In addition, for option 3. you should enable MulticastDNS=yes in resolved.conf
Option 2. is the default, and you should keep MulticastDNS=no in resolved.conf
avahi and nss-mdns is useful if you would like to auto*discover and auto-configure printers on the local network. systemd-resolved is not sufficient for this.
If you have virtual machines in qemu, you would normally have an extra (virtual) network interface, which implies that each network will also respond to the ip addres of the other interface; so practically multi-homed. This has never caused any problems for me.
mDNS by nature only works within a single network as it is limited what you can send via broadcast UDP. If you have multiple networks connected by routers, you would then need a real DNS server for resolving names.
2 Likes