3

This is about how to provide a total solution for a local home network --

  • I've found a good one here about dnsmasq configuration.
  • I managed to use the above article to have dnsmasq server set up for local home network, and I use the same server to act as DHCP server as well. It works well within the server itself.
  • However, the other laptops within the same local home network cannot do DNS query for local machines.

I.e., somehow the dnsmasq installed on those Ubuntu laptops cannot do LAN DNS query from my DNS server, even though I've disabled the DNS service in my router. I.e., all DNS services should have been provided by my DNS server. All those Ubuntu laptops have nameserver 127.0.1.1 in the /etc/resolv.conf file, which in turn should cache the DNS resolve from my DNS server, right?

UPDATE2:

It turns out that it is the (Ubuntu laptops') NetworkManager that is causing them to have a weird 127.0.1.1 nameserver setting. Here is the log for dhclient to renewal DHCP:

Oct  5 21:07:27 mylptp NetworkManager[854]: <info>  [1507252047.0729] manager: NetworkManager state is now DISCONNECTED

Oct  5 21:07:42 mylptp NetworkManager[854]: <info>  [1507252062.9239] device (eth0): Activation: starting connection 'Wired connection 1' (daa2...b460)
Oct  5 21:07:42 mylptp NetworkManager[854]: <info>  [1507252062.9241] audit: op="connection-activate" uuid="daa2...b460" name="Wired connection 1" pid=4822 uid=0 result="success"
Oct  5 21:07:42 mylptp NetworkManager[854]: <info>  [1507252062.9243] device (eth0): state change: disconnected -> prepare (reason 'none') [30 40 0]
Oct  5 21:07:42 mylptp NetworkManager[854]: <info>  [1507252062.9245] manager: NetworkManager state is now CONNECTING
Oct  5 21:07:42 mylptp NetworkManager[854]: <info>  [1507252062.9253] device (eth0): state change: prepare -> config (reason 'none') [40 50 0]
Oct  5 21:07:42 mylptp NetworkManager[854]: <info>  [1507252062.9266] device (eth0): state change: config -> ip-config (reason 'none') [50 70 0]
Oct  5 21:07:42 mylptp NetworkManager[854]: <info>  [1507252062.9270] dhcp4 (eth0): activation: beginning transaction (timeout in 45 seconds)
Oct  5 21:07:42 mylptp NetworkManager[854]: <info>  [1507252062.9299] dhcp4 (eth0): dhclient started with pid 4826

Oct  5 21:07:42 mylptp dhclient[4826]: DHCPREQUEST of 192.168.2.126 on eth0 to 255.255.255.255 port 67 (xid=0x71e88c46)
Oct  5 21:07:42 mylptp dhclient[4826]: DHCPACK of 192.168.2.126 from 192.168.2.102
Oct  5 21:07:42 mylptp NetworkManager[854]: <info>  [1507252062.9619] dhcp4 (eth0):   address 192.168.2.126
Oct  5 21:07:42 mylptp NetworkManager[854]: <info>  [1507252062.9620] dhcp4 (eth0):   plen 24 (255.255.255.0)
Oct  5 21:07:42 mylptp NetworkManager[854]: <info>  [1507252062.9620] dhcp4 (eth0):   gateway 192.168.2.1
Oct  5 21:07:42 mylptp NetworkManager[854]: <info>  [1507252062.9620] dhcp4 (eth0):   server identifier 192.168.2.102
Oct  5 21:07:42 mylptp NetworkManager[854]: <info>  [1507252062.9620] dhcp4 (eth0):   lease time 4294967295
Oct  5 21:07:42 mylptp avahi-daemon[799]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.2.126.
Oct  5 21:07:42 mylptp NetworkManager[854]: <info>  [1507252062.9620] dhcp4 (eth0):   hostname 'mylptp'
Oct  5 21:07:42 mylptp avahi-daemon[799]: New relevant interface eth0.IPv4 for mDNS.
Oct  5 21:07:42 mylptp NetworkManager[854]: <info>  [1507252062.9620] dhcp4 (eth0):   nameserver '192.168.2.102'

Oct  5 21:07:42 mylptp avahi-daemon[799]: Registering new address record for 192.168.2.126 on eth0.IPv4.
Oct  5 21:07:42 mylptp NetworkManager[854]: <info>  [1507252062.9620] dhcp4 (eth0):   domain name 'my.domain.name'
Oct  5 21:07:42 mylptp NetworkManager[854]: <info>  [1507252062.9621] dhcp4 (eth0): state changed unknown -> bound
Oct  5 21:07:42 mylptp NetworkManager[854]: <info>  [1507252062.9630] device (eth0): state change: ip-config -> ip-check (reason 'none') [70 80 0]
Oct  5 21:07:42 mylptp NetworkManager[854]: <info>  [1507252062.9635] device (eth0): state change: ip-check -> secondaries (reason 'none') [80 90 0]
Oct  5 21:07:42 mylptp NetworkManager[854]: <info>  [1507252062.9637] device (eth0): state change: secondaries -> activated (reason 'none') [90 100 0]
Oct  5 21:07:42 mylptp NetworkManager[854]: <info>  [1507252062.9638] manager: NetworkManager state is now CONNECTED_LOCAL

Oct  5 21:07:43 mylptp NetworkManager[854]: <info>  [1507252063.0394] manager: NetworkManager state is now CONNECTED_GLOBAL
Oct  5 21:07:43 mylptp NetworkManager[854]: <info>  [1507252063.0395] policy: set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS
Oct  5 21:07:43 mylptp NetworkManager[854]: <info>  [1507252063.0403] device (eth0): Activation: successful, device activated.

Oct  5 21:10:43 mylptp systemd-resolved[1009]: Switching to DNS server 192.168.2.102 for interface eth0.
Oct  5 21:10:43 mylptp systemd-resolved[1009]: Using degraded feature set (TCP) for DNS server 127.0.1.1.
Oct  5 21:10:43 mylptp systemd-resolved[1009]: Using degraded feature set (UDP) for DNS server 127.0.1.1.
Oct  5 21:10:43 mylptp systemd-resolved[1009]: Using degraded feature set (TCP) for DNS server 127.0.1.1.
Oct  5 21:10:43 mylptp systemd-resolved[1009]: Using degraded feature set (UDP) for DNS server 127.0.1.1.
Oct  5 21:10:43 mylptp systemd-resolved[1009]: Using degraded feature set (TCP) for DNS server 127.0.1.1.
Oct  5 21:10:43 mylptp systemd-resolved[1009]: Using degraded feature set (UDP) for DNS server 127.0.1.1.

I cut the long log into groups for clarity. From the log we can clearly see that the dnsmasq has been pushing the correct IP address of the DNS server in the DHCP reply (group 3, last line). However, it is the NetworkManager (or systemd-resolved) that is acting up (group 6, first line).

Why NetworkManager/systemd-resolved is not using the correct DNS server that it is instructed to use? My laptop has no problem using/querying my local DNS server:

me@mylptp$ dig @192.168.2.102 coral
...
;; ANSWER SECTION:
coral.                  0       IN      A       192.168.2.102

;; Query time: 0 msec
;; SERVER: 192.168.2.102#53(192.168.2.102)
;; WHEN: Thu Oct 05 21:16:22 EDT 2017
;; MSG SIZE  rcvd: 50

All my machines are of:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 17.04
Release:        17.04
Codename:       zesty

$ ls -l /etc/resolv.conf 
lrwxrwxrwx 1 root root 35 2017-10-05 21:07 /etc/resolv.conf -> /var/run/NetworkManager/resolv.conf

Please help.

UPDATE1:

What I'm missing is that I "should be pushing the correct IP address of the DNS/DHCP server in the DHCP reply", thanks to dirkt for the direction. However, how can I do that with dnsmasq? I've been to the following urls but none gave me the answer:

Thx.

xpt
  • 8,261
  • 38
  • 102
  • 156
  • So you have your dnsmasq server in /etc/resolv.conf of other nodes in your network? If yes, and it doesn't work, I'd check if your dnsmasq listens on external IP and if there is no firewall in place, which could block the connection. – Jaroslav Kucera Oct 01 '17 at 06:49
  • The usual way to do this is to combine the dnsmasq server with a DHCP server (many home routers already do that), and in the DHCP information, tell all clients to use the dnsmasq server as DNS source. – dirkt Oct 01 '17 at 13:02
  • @JaroslavKucera, OP updated: All those Ubuntu laptops have nameserver 127.0.1.1 in the /etc/resolv.conf file, which in turn should cache the DNS resolve from my DNS server, right? – xpt Oct 01 '17 at 18:35
  • @dirkt, oh, you are right, I should look for solution from the DHCP server instead. BTW, my OP updated: my `dnsmasq` acts as both DNS server and DHCP server as well. – xpt Oct 01 '17 at 18:38
  • 1
    No, `nameserver 127.0.1.1` (shouldn't that be `127.0.0.1`?) will cause the clients (Ubuntu laptops) to try to resolve DNS from `localhost`, i.e. they in turn need to have some sort of DNS cache or other DNS service installed locally (which may work if done correctly, but is overkill, and probably not done correctly in the first place, leading to your problems). Instead of `localhost`, you should be pushing the correct IP address of your DNS/DHCP server in the DHCP reply. – dirkt Oct 01 '17 at 19:44
  • First step is to find out of something is locally installed which causes `nameserver 127.0.0.1`, or if it's the DHCP. So kill `dhclient` (or whatever they use) on one client, start it manually, watch `dmesg` both on server and client, and if it doesn't tell the option, do `tcpdump` or `wireshark` on server or client. If it's `dnsmasq`s fault, please edit your question to include the configuration file. – dirkt Oct 04 '17 at 04:31
  • Thx @dirkt, it is NOT `dnsmasq`s fault, but NetworkManager/systemd-resolved's. See updated OP for details. – xpt Oct 06 '17 at 01:50
  • I can't help you with NetworkManager, I always get rid of it because I can never get it to do what I want instead of what it wants. Same for systemd's buggy not-invented-here copies of main system features. – dirkt Oct 06 '17 at 06:18
  • @dirkt, totally understand, I hate NetworkManager too. Thanks for helping thus far! – xpt Oct 06 '17 at 14:23

0 Answers0