How to fix DNS short name lookup failures on Ubiquiti EdgeRouter firmware v1.9.1

Posted by Paul Braren on Jan 1 2017 (updated on Jan 3 2017) in
  • HowTo
  • Network
  • SmartHome
  • Ubiquiti
  • EdgeRouterLite

    Which EdgeRouters?

    There are other members of the Ubiquiti EdgeRouter family that use this same v1.9.1 firmware, so this article likely applies to those folks as well, including:

    • ERLite-3 and ERPoe-5
    • ER-8, ERPro-8, and EP-R8
    • ER-X, ER-X-SFP, and EP-R6


    Within about 30 seconds of getting all my Windows and Linux PCs and VMs talking to each other on a firstname (short name) basis last summer, I fell for my new Ubiquiti EdgeRouter Lite, aka UBNT ERLite-3. This polite behavior was with plain old DHCP for these systems, no manual DNS tinkering on the clients required. Finally! Something no consumer router could do, running my home network and my home lab, together. When coupled with my new eero Wi-Fi in bridge-mode blanketing my home in as-fast-as-wired speeds, both my VMware VCSA 6.5 appliance and my family were finally all very happy indeed.

    It wasn't hard to configure, and future articles will cover my exact configuration process, all using the web based GUI. I'd say it required intermediate skills to figure out, but once I get the details published, any home lab enthusiast can turn this pro-sumer router/ SOHO router into a consumer router that's no harder to use than the vast array of consumer routers out there. Only way faster, more better.


    All that said, no networking product is perfect. The web changes. Regular firmware updates are today's reality. The minor bumps in the road that affected my configuration these last 7 months of ownership included:

    • firmware release 1.8.5 worked well, including L2TP over IPSec VPN tunnel functions from native Windows 10 and iOS VPNs

    • firmware release 1.9.0 worked well, except my occasionally-used L2TP over IPSec tunnel server feature wouldn't allow clients to reliably connect after that first successful connection

    Dec 2016, firmware v1.9.1 arrives

    I was relieved when I spotted this release. Just in time for my planned vSphere 6.5 follow-on to my popular how-to videos! I'm planning to use proper DHCP and DNS server configuration, much better than host file hacks on each system. This router as the short name, FQDN, and reverse lookup that VMware VCSA requires without the need for Active Directory, all for well under $90 USD. Also capable of processing a million packets per second, future-proofing my home for my next bump up in speeds from my current 300Mbps down/30Mbps up Cox Communications DOCIS 3.0 connection.

    Of course, I quickly read the 1.9.1 release notes, and found comments in the forums that the following shortcomings are still present:

    • the OpenSSH VPN server doesn't support hardware offload (it does support L2TP hardware offload, but L2TP is less secure)
    • using dnsmasq for DHCP instead of the default DHCP server results in blank DHCP Lease information in the GUI

    These weren't show-stoppers for me. I was just really wanting to be sure I was going to have a set of how to install vSphere 6.5 instructions without having to recommend a backlevel firmware to folks. I was also hopeful that 1.9.1 would offer an improved IPSEC VPN connection experience too. So I went and downloaded 1.9.1 and installed it, simple enough:

    How to install Ubiquiti EdgeMAX EdgeRouter firmware v1.9.1 onto UBNT ERLite-3

    At first, good news! L2TP over IPSec now worked every connection, full VPN or split, from native Windows 10 and from iOS.

    The sad trombone moment

    But minute later, a new problem surfaced. I tried to visit my VMware vSphere 6.5 VCSA VM by short name:
    which used to work just fine, but now failed. Uh oh.

    Did a bit of the usual nslookup and ping troubleshooting, and experienced the following:

    C:\>nslookup apc
    Server:  ubnt-home.lab.local
    Name:    apc
    C:\>nslookup apc.lab.local
    Server:  ubnt-home.lab.local
    Name:    apc.lab.local
    C:\>ping apc
    Ping request could not find host apc. Please check the name and try again.
    C:\>ping apc.lab.local
    Pinging apc.lab.local [] with 32 bytes of data:
    Reply from bytes=32 time=2ms TTL=60
    Reply from bytes=32 time=2ms TTL=60
    Reply from bytes=32 time=2ms TTL=60
    Reply from bytes=32 time=2ms TTL=60
    Ping statistics for
        Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
        Minimum = 2ms, Maximum = 2ms, Average = 2ms

    So off to the friendly Ubiquiti forums I went, signing up for a free account, and posting my question there:

    To my amazement, a proposed workaround was posted by lanefu within about 10 hours, and it worked! For folks that have multiple DHCP servers configured, see also joemoor's comment. It's amazing the level of problem determination details that several folks presented, basically a free root cause analysis to the problem I was experiencing. Not something you see everyday.

    There were also quickly reports of other folks noticing the same problem, adding to my new forum thread, and even a Ubiquiti employee chiming in

    Looks like it the same issue as described here ->

    Bug ticket has already been created.

    For my lab with a local domain of
    all I needed to do was the following fix.

    The Fix Procedure

    More of a workaround really, only needed only until the next firmware release:

    1. ssh into my router, which is at in my home, and authenticate to an admin account such as the default username ubnt
    2. type

      and press Enter

    3. type
      set service dhcp-server global-parameters 'option domain-name "lab.local";'

      and press Enter

    4. type

      This saves the change to the working set of the router. Optionally, now you can take a moment to do a dhcp /renew on a Windows client, to be sure you're happy with the change, and to re-test that short name lookups such as ping vcsa (or some other home networked device with a DHCP reservation) functions.

    5. type

      This saves the configuration change to persist across reboots of the router, and across future upgrades of the router. It makes the one line DHCP configuration change permanent.

    6. type
    7. type
    Here's exactly how the fix looked on my router.

    Video of the simple workaround

    DNS short name lookup fails on Ubiquiti EdgeRouter firmware v1.9.1, here's the simple fix


    Now I have a 1.9.1 that behaves just like the prior releases, but now an IPSEC VPN server that is reliable too. Yay, I can move onward to other things.

    Glad that little bump in the road wasn't hard to go over. Basically a one-liner workaround is needed only until the next release arrives, which is probably a few months away.

    This overall Ubiquiti support experience is so vastly different from the many consumer routers I've used, so very much better. Real useful community and employee support, for free. This is a very comforting feeling. Know I know why so many folks feel good about their Ubiquiti products.

    Hopefully my family and my router can now glide right through 2017 and beyond, with minimal fuss. Hopefully this article helps others glide right through with me!

    See also at TinkerTry

    See Also