EdgeRouter - Using dnsmasq for DHCP Server


Overview


The default EdgeRouter configuration will use the ISC DHCPD as the backend for the integrated DHCP server for EdgeRouter. As of version 1.9.0, dnsmasq is now an available alternative option. One of the main advantages to using dnsmasq for DHCP is the ease of resolving local hostnames. This article will give instructions on how to enable dnsmasq for DHCP on an EdgeRouter and explains the details of this option.

NOTES & REQUIREMENTS: 
This article applies to all EdgeRouter models with firmware higher than 1.9.0. Knowledge of the Command Line Interface (CLI) and basic networking knowledge is required. Please see the Related Articles below for more information.

Table of Contents


  1. Frequently Asked Questions
  2. How to Enable dnsmasq for DHCP
  3. How to Configure DNS Forwarding, DHCP, and System Settings
  4. Testing & Verification
  5. Related Articles

Frequently Asked Questions


Back to Top

Do I need to enable hostfile-update?

No. If DNS forwarding is also configured on the EdgeRouter, local hosts will automatically resolve without having to enable hostfile-update as you would when using ISC DHCPD. When dnsmasq is enabled, hostfile-update is ignored. 

Do I need to set "Listen-on" interfaces? 

No. When dnsmasq is enabled, the DHCP server will serve the "listen-on" interfaces set for DNS Forwarding on the EdgeRouter. If DNS forwarding is not being used and no listen-on interfaces are set, dnsmasq will listen on all interfaces.

Will my existing ISC DHCP options still work?

No. If dnsmasq is enabled, specific configuration settings for ISC DHCPD will be ignored such as DHCP failover and optional parameters. If options are needed for DHCP when using dnsmasq, parameters must be set under the DNS forwarding configuration using this command:
set service dns forwarding options ...

Can I set the DHCP server to be "authoritative"?

Setting a DHCP server to "Authoritative" will help assign DHCP addresses faster for devices switching networks. When using dnsmasq for DHCP, if authoritative mode is enabled for one of the subnets, this feature will be turned on for all subnets without specifying the feature for each subnet. Unlike when using ISC DHCP where each server must have this specified. If no DHCP servers are set to authoritative, the feature will be turned off for all servers.

What if I change the hostname of my device that has a static mapping?

When using dnsmasq, the entries configured under "static-mapping" will be translated to statically assigned A records in dnsmasq (using the dnsmasq host-record directive). If a client with a static-mapping entry sends a DHCP request with a different client-name, that client-name will be ignored.

How to Enable dnsmasq for DHCP


Back to Top

This feature can be enabled using CLI. Enter the following commands: 

CLI: Access the command line interface (CLI). You can do this using the CLI button in the GUI or by using a program such as PuTTY.
configure
set service dhcp-server use-dnsmasq enable
commit
save
exit

How to Configure DNS Forwarding, DHCP, and System Settings


Back to Top

To allow local hostname resolution across networks, the following changes will be needed to allow clients to use the router address as the DNS server, configure DNS forwarding options, and set the system name-server. This will also require setting a domain-name on the router and adding this domain-name to the DHCP Server(s) to distribute to clients so local hostnames resolve properly across networks.

1. Set system name-server to loop back to the router itself, which will forward requests to the DNS servers set in the DNS forwarding settings by entering the following:

set system name-server 127.0.0.1

2. Set global name-servers to resolve all external resolutions.

set service dns forwarding name-server 8.8.8.8

3. Set DNS forwarding listen-on address for all LAN interfaces including VLANs.

set service dns forwarding listen-on eth1
set service dns forwarding listen-on eth1.20

4.  Increase DNS forwarding cache-size.

set service dns forwarding cache-size 4000 

5. Set system domain-name.

set system domain-name home.lan

6. Set domain-name for dhcp-servers.

set service dhcp-server shared-network-name Management subnet 10.0.10.0/24 domain-name home.lan
set service dhcp-server shared-network-name Corp subnet 10.0.20.0/24 domain-name home.lan

7. Set static host mapping for local device. In this example we will use a UniFi Cloud Key set to 10.0.10.44. Repeat this for all necessary devices that you would like to access by using a hostname rather than IP.

set service dhcp-server shared-network-name Management subnet 10.0.100.0/24 static-mapping cloudkey ip-address 10.0.10.44 
set service dhcp-server shared-network-name Management subnet 10.0.100.0/24 static-mapping cloudkey mac-address 44:d9:e7:9d:5a:4c

8. Use the commit and save commands to make these changes active and persistent.

ATTENTION: Ensure that a public DNS server is not manually set on a client attempting to use the router address as the DNS server. If an address like 8.8.8.8 is manually set on the client, it will prefer that address over the router address issued by the DHCP-Server causing all DNS queries to be resolved using a global DNS server rather than the local EdgeRouter DNS server.

Testing & Verification


Back to Top

If having trouble, first ping the local IP of the device, then ping the hostname including domain name, then ping the hostname. In this example, we have a Cloud Key with a static-host-mapping set in the DHCP server set in step 7 above.

ubnt-MBP:~ admin$ ping 10.0.10.44
PING 10.0.10.44 (10.0.10.44): 56 data bytes
64 bytes from 10.0.10.44: icmp_seq=0 ttl=63 time=3.849 ms
64 bytes from 10.0.10.44: icmp_seq=1 ttl=63 time=3.047 ms
^C
--- 10.0.10.44 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 3.047/3.448/3.849/0.401 ms

ubnt-MBP:~ admin$ ping cloudkey.home.lan
PING cloudkey.home.lan (10.0.10.44): 56 data bytes
64 bytes from 10.0.10.44: icmp_seq=0 ttl=63 time=4.181 ms
64 bytes from 10.0.10.44: icmp_seq=1 ttl=63 time=5.441 ms
^C
--- cloudkey.home.lan ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 4.181/4.811/5.441/0.630 ms

ubnt-MBP:~ admin$ ping cloudkey
PING cloudkey.home.lan (10.0.10.44): 56 data bytes
64 bytes from 10.0.10.44: icmp_seq=0 ttl=63 time=4.823 ms
64 bytes from 10.0.10.44: icmp_seq=1 ttl=63 time=2.883 ms
^C
--- cloudkey.home.lan ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.883/3.853/4.823/0.970 ms


To test that addresses are resolving using the router address you can use the dig tool to verify the server that is being used to resolve addresses. In this case it shows our router address of 10.0.10.1 rather than a global DNS server like 8.8.8.8.

ubnt-MBP:~ admin$ dig cloudkey.home.lan

; <<>> DiG 9.8.3-P1 <<>> cloudkey.home.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17501
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;cloudkey.home.lan. IN A

;; ANSWER SECTION:
cloudkey.home.lan. 86400 IN A 10.0.10.44

;; Query time: 3 msec
;; SERVER: 10.0.10.1#53(10.0.10.1)
;; WHEN: Fri Aug  31 3:54:19 2018
;; MSG SIZE  rcvd: 60

Related Articles


Back to Top

EdgeRouter - Configure DHCP Server on EdgeRouter