[Dnsmasq-discuss] DNS only on LAN: what's not working?

Mon May 23 11:21:20 UTC 2022

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: pemensik at redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB