info_i_25x25.png See important information about Ubiquiti Devices and KRACK Vulnerability in this article. We will update this document as more information becomes available.

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.

book_25x25.png   NOTES & REQUIREMENTS:

Applicable to EdgeOS 1.9.0+ firmware. 


Table of Contents


Step 1: Enable dnsmasq for DHCP
Step 2: Adjust DNS Forwarding, DHCP, and System settings
Step 3: View Leases
Step 4: Testing
Notes
Related Articles


Step 1: Enable dnsmasq for DHCP


Back to Top

Currently, this feature must be enabled using the CLI as there is not a webUI option to enable dnsmasq. Enter the following commands: 

configure
set service dhcp-server use-dnsmasq enable
commit
save
exit

Step 2: Adjust DNS Forwarding, DHCP, and System settings


Back to Top

To allow local hostname resolution across networks, the following changes will need to be made 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

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 dhs forwarding cache-size (optional)

set service dns forwarding cache-size 400 

5. Set system domain-name

set system domain-name home.local 

6. Set domain-name for dhcp-servers

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

7. Set static host mapping for local device. In this example we will use a CloudKey set to 10.0.100.44. Repeat this for all necessary devices.

set service dhcp-server shared-network-name Management subnet 10.0.100.0/24 static-mapping cloudkey ip-address 10.0.100.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

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

Note: 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.


Step 3: View Leases


Back to Top

There are future plans to allow DCHP leases to show in the webUI, much like they do when using ISC DHCPD for DHCP. However, as of version 1.9.1, DHCP leases must be viewed from the CLI using this command in operational mode:

cat /var/run/dnsmasq-dhcp.leases

Example:

admin@ubnt:~$ cat /var/run/dnsmasq-dhcp.leases
1486236179 38:c9:86:12:aa:11 10.0.100.9 mbp 01:38:c9:86:12:aa:11
1486235720 c8:69:cd:44:22:ee 10.0.100.157 Apple-TV-3 01:c8:69:cd:44:22:ee
1486214664 80:2a:a8:33:dd:cc 10.0.100.93 AFi-R-HD-D91DC3 *
1486451443 44:d9:e7:9d:5a:4c 10.0.100.44 cloudkey 01:44:d9:e7:9d:5a:ac

Step 4: Testing


Back to Top

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

ubnt-MBP:~ admin$ ping 10.0.100.44
PING 10.0.100.44 (10.0.100.44): 56 data bytes
64 bytes from 10.0.100.44: icmp_seq=0 ttl=63 time=3.849 ms
64 bytes from 10.0.100.44: icmp_seq=1 ttl=63 time=3.047 ms
^C
--- 10.0.100.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
PING cloudkey.home.local (10.0.100.44): 56 data bytes
64 bytes from 10.0.100.44: icmp_seq=0 ttl=63 time=4.823 ms
64 bytes from 10.0.100.44: icmp_seq=1 ttl=63 time=2.883 ms
^C
--- cloudkey.home.local 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
ubnt-MBP:~ admin$ ping cloudkey.home.local
PING cloudkey.home.local (10.0.100.44): 56 data bytes
64 bytes from 10.0.100.44: icmp_seq=0 ttl=63 time=4.181 ms
64 bytes from 10.0.100.44: icmp_seq=1 ttl=63 time=5.441 ms
^C
--- cloudkey.home.local 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

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.20.1 rather than a global DNS server like 8.8.8.8.

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

; <<>> DiG 9.8.3-P1 <<>> cloudkey.home.local
;; 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.local. IN A

;; ANSWER SECTION:
cloudkey.home.local. 86400 IN A 10.0.100.44

;; Query time: 3 msec
;; SERVER: 10.0.20.1#53(10.0.20.1)
;; WHEN: Mon Feb  6 10:06:19 2017
;; MSG SIZE  rcvd: 60

Notes


Back to Top

  • 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. As in the example above, we could ping mbp and it will resolve to 10.0.100.9. When dnsmasq is enabled, hostfile-update is ignored.
  • 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.
  • 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 ...
  • When dnsmasq is enabled, the authoritative setting will be applied to all shared-networks, if set for one of the shared-networks. If none of the shared-networks have authoritative enabled, it will not be enabled for all networks.
  • 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.

Related Articles


Back to Top

EdgeRouter - Configure DHCP server on EdgeRouter