Hi, as usual, get rid of systemd-resolved first.
- I would suggest dnf remove systemd-resolved. Minimal action is systemctl disable --now systemd-resolved - Then rm /etc/resolv.conf symlink - create own /etc/resolv.conf nameserver 127.0.0.1 nameserver 192.168.178.1 search mydomain.lan. - restart dnsmasq Are all those /etc/hosts entries on the server host, IP 192.168.178.9? If you kick the resolved out of the picture it should contact local dnsmasq first. Dnsmasq would skip localhost and query 192.168.178.1 for all names it does not know. - use auth-zone=lan or at least local=/lan/ If not sure resolved got in the way, query the name to localhost explicitly. Trailing dot would ensure no search cause is used. dig @localhost server.mydomain.lan. As Geert suggested already, you might want your server as DNS resolver for your network. I do that on routerboard AP too. Keep it assigning DHCP if you wish, but override the servers it offers to 192.168.178.9 192.168.178.1. Normal hosts without resolved should be able to resolve lan hosts reliable. Resolved would be unreliable, because it can choose the second server as preferred. Unless you can direct fritz.box router to forward subdomain to your server, either offer just the server address and have it up all times or disable things like systemd-resolved. consider adding line like: server=/fritz.box/192.168.178.1 On 5/23/22 02:44, Grayan Adams wrote: > Apologies if this turns out to be trivial, but getting dnsmasq to work > has completely frustrated and defeated me, after days of faffing around. > > I have a bunch of apache named vhosts on a server, and need to access > them from other devices. To date, I’ve done this via /etc/hosts on > each device. However, an iPad, iPhone and Samsung tablet now also need > access, hence looking at dnsmasq. > > The Problem: I cannot access any of the vhosts from any of the other > devices on the LAN. Works perfectly on the server, but then it also > worked just fine via /etc/hosts before installing dnsmasq. > > Vast amounts of reading, postings to Serverfault, AskFedora, plus > various friends have resulted in endless tweaks and fiddles, confusing > things ever more. > I should stress that I know less than nothing about network admin. > > The current objective is to run dnsmasq as a DNS server only, leaving > the router to assign DHCP leases as it sees fit. So all *.lan queries > from devices on the LAN should end up at the dnsmasq server. All non > *.lan queries should go to the router and on to the world. > The eventual objective is to set up a VPN, but baby steps! > > I've disabled the NetworkManager dnsmasq plugin, and run the process > with $ systemctl start dnsmasq.service > > systemd-resolved seems to be completely out of the picture: > $ netstat -tulpn | grep ":53 " > tcp/udp 0 0 192.168.178.9:53 0.0.0.0:* LISTEN [pid]/dnsmasq > tcp/udp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN [pid]/dnsmasq > ... ... > > I don't think it's a firewall issue: > $ firewall-cmd --zone=FedoraWorkstation --list-services >> dhcpv6-client http https mdns mysql samba-client ssh ... > > When dnsmasq starts up, journalctl msgs are generated: >> reading /etc/resolv.conf >> ignoring nameserver 192.168.178.9 - local interface >> using nameserver 192.168.178.1#53 (router) > > Turning log-queries on results in vast numbers of journalctl msgs: >> server.lan dnsmasq[pid]: query[AAAA] docs.fedoraproject.org from >> 192.168.178.9 >> server.lan dnsmasq[pid]: forwarded docs.fedoraproject.org to >> 192.168.178.1 >> server.lan dnsmasq[pid]: reply docs.fedoraproject.org is <CNAME> >> server.lan dnsmasq[pid]: reply wildcard.fedoraproject.org is >> 2605:bc80:3010:600:dead:beef:cafe:fed9 (ha ha!) > > Dig output on the server: > ; <<>> DiG 9.16.28-RH <<>> vhost1.lan > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12212 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;vhost1.lan. IN A > ;; ANSWER SECTION: > vhost1.lan. 0 IN A 192.168.178.9 > ;; Query time: 0 msec > ;; SERVER: 192.168.178.9#53(192.168.178.9) > ;; WHEN: Sun May 22 21:22:47 CEST 2022 > ;; MSG SIZE rcvd: 55 > > journalctl msgs generated from dig vhost1.lan on the server: >> server.lan dnsmasq[pid]: query[A] vhost1.lan from 192.168.178.9 >> server.lan dnsmasq[pid]: /etc/hosts vhost.lan is 192.168.178.9 > > > I am beginning to wonder if the Fritzbox is getting in the way > somehow, with its naming schema. Irritatingly, it slaps ".fritz.box" > onto the end of some devices - and afaik it can't be changed. So > "server.mydomain.lan" becomes "server.fritz.box. Example run on on > the laptop: > > laptop$ dig server.mydomain.lan > > ; <<>> DiG 9.16.24-RH <<>> server.mydomain.lan > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9628 > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 65494 > ;; QUESTION SECTION: > ;server.mydomain.lan. IN A > ;; AUTHORITY SECTION: > . 1894 IN SOA a.root-servers.net. > nstld.verisign-grs.com. 2022052201 1800 900 604800 86400 > ;; SERVER: 127.0.0.53#53(127.0.0.53) Note: this is systemd-resolved responding. It does not follow exact order of nameservers as default. Use resolvectl to check what server it has chosen. If it has chosen router, then you would have to direct router to forward just *.lan names to your server. I were able to configure some Ubiquity gateway to do that in ssh. Not sure if fritz.box uses dnsmasq inside and whether it allows adding custom server=/lan/192.168.178.9 to /etc/dnsmasq.d/lan.conf. > > But: > laptop$ dig server.fritz.box > > ; <<>> DiG 9.16.24-RH <<>> server.fritz.box > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46068 > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 65494 > ;; QUESTION SECTION: > ;server.fritz.box. IN A > ;; ANSWER SECTION: > server.fritz.box. 9 IN A 192.168.178.9 > ;; AUTHORITY SECTION: > server.fritz.box. 9 IN NS fritz.box. > ;; ADDITIONAL SECTION: > fritz.box. 9 IN A 192.168.178.1 > ;; SERVER: 127.0.0.53#53(127.0.0.53) This would happen if server is hostname of your server and it obtained its address from the router. Just note the server responding this is systemd-resolved on address 127.0.0.53, not dnsmasq on address 127.0.0.1. > > > > ---- System -------------------------- > Fedora 35, installed Nov.2021 > Linux 5.15.5-200.fc35.x86_64 > dnsmasq v 2.86 > > /etc/hosts: > 127.0.0.1 localhost localhost.localdomain > ::1 localhost localhost.localdomain > 192.168.178.9 server.mydomain.lan > 192.168.178.10 laptop.mydomain.lan > 192.168.178.9 vhost1.lan > 192.168.178.9 vhost2.lan Append vhost1.lan and vhost2.lan after server.mydomain.lan. dig -x 192.168.178.9 would return just server then, but vhost1 and vhost2 would work as aliases. > > Router: Fritzbox 7490 > Local DNS Server: 192.168.178.9 > > /etc/NetworkManager/NetworkManager.conf > [main] > dns=none > systemd-resolved is known to break some use cases. Avoid it running on the server if dnsmasq is running there. It provides better service. > /etc/systemd/resolved.conf > DNS=192.168.178.9 > DNSStubListener=no > > /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf > nameserver 192.168.178.9 > nameserver 192.168.178.9 > nameserver 192.168.178.1 > search localhost > > NM config for IPv4 wlp5s0 (wifi conn on server) > Method: Manual > Address: 192.168.178.9/24 > Gateway: 192.168.178.1 (router) > DNS Servers: 192.168.178.9 (server) > Search domains: localhost > > /etc/dnsmasq.conf: > domain-needed > bogus-priv > local=/lan/ > address=/lan/192.168.178.9 > address=/lan/127.0.0.1 > interface=wlp5s0 (wifi) > listen-address=127.0.0.1 > no-dhcp-interface=wlp5s0 > bind-interfaces I am confused. On which machine is this configuration used? Is it the server or your workstation? address= line would make any *.lan name to have 127.0.0.1 address. Is this what you want? I doubt so. Contents of /etc/hosts should be sufficient, no address should be required. > > Cheers, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss