DNSMasq – Setting Up as DNS and DHCP Server on LAN

dhcpdnsmasqhostnamelocal-area-network

My routers:

Main Router: 192.168.100.1

Second Router: 192.168.101.1

The Main Router is provided by my ISP(a modem/router combo all in one). I don't have control over its settings. Except for changing the WIFI password and SSID.

On the Second Router, I have control over its DNS settings.

My Second Router's WAN port is connected to a LAN port on the Main router.
I have a Debian Server with dnsmasq installed and connected on the Second Router's network with a static IP of 192.168.101.121. For those who don't know, dnsmasq is both a DNS and DHCP server(not enable by default).

On the Second Router's DNS setting, I added the dnsmasq DNS server(debian server) IP as the primary DNS IP and the Main Router's IP as the the secondary DNS IP. It works fine.

Every line in /etc/hosts on the Debian server is accessible on all hosts that is connected on the Second Router's network. That's ok.

The problem is with DHCP. As a DHCP client, you can send your hostname to the DHCP server, and it will be added to the DNS.

As the Second Router is already acting as a DHCP server, I can't just enable DHCP on dnsmasq. If I do enable it, I'll have to provide a different range(other than the second router is providing).

Only the second router is getting the hostnames, not dnsmasq. Has anyone run into the same problem ? Is it possible to pull the hostname entries from the second router to dnsmasq ? Thanks.

Best Answer

That's not a problem, that's expected behavior. It you want to register the DHCP leases in DNS the DHCP server must do so. Your off the shelf router most probably just can't, so you will have to disable DHCP on the router and enable it in Dnsmasq.

Related Solutions

Linux – Getting Samba, DHCP and DNS to play nice

SMB is a network file sharing protocol so there isn't a name resolution mechanism that is specific to SMB/CIFS shares. Name resolution for SMB/CIFS is dependent on the client and it's configured name resolution mechanisms (DNS, WINS, broadcast, etc) and order and is dependent on whether you're using an FQDN or a single-label name.

In the absence of a DNS or WINS server, Windows clients will use NetBIOS broadcasts (if NetBT over TCP is enabled) to attempt to resolve names. Windows Vista, 7, and W2K8 clients will also use LLMNR for local name resolution.

Without getting in to all the gory details about how and in what order Windows clients resolve host names, I might suggest you implement a more robust DNS server internally, such as Windows DNS.

NetworkManager & dnsmasq – ignore auto DNS settings

I'm not using dnsmasq, but I had a similar issue. The solution for me was:

Put the DNS servers you want in /etc/resolv.conf (ref)

# IPv4 nameservers: 
nameserver 1.1.1.1
nameserver 1.0.0.1
# IPv6 nameservers:
nameserver 2606:4700:4700::1111
nameserver 2606:4700:4700::1001

Tell NetworkManager not to modify your /etc/resolv.conf by writing in your /etc/NetworkManager/NetworkManager.conf (ref)
```
[main]
dns=none
```

Probably restart NetworkManager etc. afterward. If you do nmcli dev show it shows the DNS server reported by the router:

IP4.DNS[1]:                             192.168.50.1

But if you use nslookup (from bind-tools in Arch), it looks like 1.1.1.1 is actually used for the query:

» nslookup google.com
Server:     1.1.1.1
Address:    1.1.1.1#53

Non-authoritative answer:
Name:   google.com
Address: 172.217.9.238
Name:   google.com
Address: 2607:f8b0:4006:801::200e

UPDATE: config with dnsmasq

I tried out a config with dnsmasq. NetworkManager has a dnsmasq plugin that you can use by putting into /etc/NetworkManager/NetworkManager.conf the following:

[main]
dns=dnsmasq

This will start dnsmasq with NetworkManager and put 127.0.0.1 into /etc/resolv.conf (ref). However, I did not do it this way because then dnsmasq isn't managed by systemctl and you don't automatically end up with logging in journalctl (maybe there is some way around this).

Instead, I used the following config (ref):

/etc/NetworkManager/NetworkManager.conf:
```
[main]
dns=none
```
/etc/resolv.conf:
```
nameserver 127.0.0.1
```

/etc/resolv.dnsmasq.conf:

 # IPv4 nameservers: 
 nameserver 1.0.0.1
 # IPv6 nameservers:
 nameserver 2606:4700:4700::1111
 nameserver 2606:4700:4700::1001

/etc/dnsmasq.conf:

 resolv-file=/etc/resolv.dnsmasq.conf
 log-queries

Restart NetworkManager and dnsmasq. Now, verify your local nameservers didn't get overwritten:

» cat /etc/resolv.conf
nameserver 127.0.0.1

We can also question NetworkManager:

» cat /run/NetworkManager/resolv.conf 
# Generated by NetworkManager
nameserver 192.168.50.1

» nmcli dev show
...
IP4.DNS[1]:                             192.168.50.1

But those entries are seemingly just indicating what the router has reported, not necessarily what will actually be used for a query, because if we do drill google.com, we see that 127.0.0.1 was in fact used:

;; Query time: 0 msec
;; SERVER: 127.0.0.1
;; WHEN: Fri Apr 20 11:32:59 2018
;; MSG SIZE  rcvd: 44

Also, if you put log-queries into /etc/dnsmasq.conf as shown above, you see in journalctl after running drill stackoverflow.com twice:

dnsmasq[27679]: query[A] stackoverflow.com from 127.0.0.1
dnsmasq[27679]: forwarded stackoverflow.com to 1.0.0.1
dnsmasq[27679]: reply stackoverflow.com is 151.101.1.69
dnsmasq[27679]: reply stackoverflow.com is 151.101.65.69
dnsmasq[27679]: reply stackoverflow.com is 151.101.129.69
dnsmasq[27679]: reply stackoverflow.com is 151.101.193.69
dnsmasq[27679]: query[A] stackoverflow.com from 127.0.0.1
dnsmasq[27679]: cached stackoverflow.com is 151.101.193.69
dnsmasq[27679]: cached stackoverflow.com is 151.101.129.69
dnsmasq[27679]: cached stackoverflow.com is 151.101.65.69
dnsmasq[27679]: cached stackoverflow.com is 151.101.1.69

The first time it asked 1.0.0.1, the second time it found the result in the cache. You can remove log-queries from dnsmasq.conf if satisfied.

Best Answer

Related Solutions

Linux – Getting Samba, DHCP and DNS to play nice

NetworkManager & dnsmasq – ignore auto DNS settings

UPDATE: config with dnsmasq

Related Topic