Hi  @GRL 

all my servers (physical and virtual ones) and network devices are running on static addresses.

And there are several clients in two groups which are using DHCP: notebooks and IoT devices running Tasmota. Nevertheless I use DHCP for rapid deployment of various systems using netboot-xyz. Reason behind using DHCP for clients is to be flexible for any changes and to be able to roam between sites. To make reservations for clients isn't the best practice and an unnecessary administrative overhead.

The notebooks can update their information in AD integrated DNS (which is the primary DNS on network), but the IoT devices aren't capable of this.

Reason behind local DNS is the ability to monitor availability of devices, which couldn't register itself at AD DNS.

Before switching to Omada I've used Asus routers (the last one was RT-AC-66U_B1) based on OpenWRT - and there was fully functional dnsmasq (which is according OpenWRT docs a default DHCP/local DNS solution) acting as local DNS.

Unfortunately Omada ER605 even with last firmware still can't do this simple (and default) task.

there are then 2 questions to TP-Link:

 - is ER605 using dnsmasq for DHCP? (I assume: yes)

 - if yes, why is the DNS part of it disabled (not configured)?

Hi @p2baron,

unfortunately this feature is a static "DNS" stuff not connected to DHCP and you have to enter manually the entries, which makes this feature absolutely useless.

if there were a link between DHCP and DNS, any lease reservation will have the same effect - just with consistency (if you use this feature in current state, removing a device from network needs to delete the device from two separate lists).

As I wrote in my previous post, my primary DNS on a network is AD integrated DNS where all windows machines can register. Unfortunately other devices aren't capable of this, for example mobile phones/tablets, IoT devices and not domain-joined machines. 

There is no possibility to get any real and accurate data about active devices on the network - the data shown in controller GUI are inconsistent and not accessible. The data gathered via SNMP - the same story............

for the DNS there is apparently unbound used, which is a validating, recursive, caching DNS resolver - what makes it ideal for business use over the dnsmasq used in home routers, which is DHCP server with a forwarder only DNS part needing an upstream DNS, usually the ISP's one.

For reference, look at this locked post

this is my last post about this topic, let's see what will the developer team do in the future.

Hi @gautamkrishnar,

just some notes to your request:

• no larger network (SMB or enterprise) never ever rely on DNS located on router. They usually use AD integrated DNS server as primary DNS server
• the whole DNS stuff on Omada gateway is IMHO misconfigured
  • it uses dnsmasq for DHCP server - but all address leases are private and not exposed anywhere (each stupid homerouter can do this)
    • that what you can see in the Controller's Clients list isn not what to expect - there are not all active DHCP clients listed and they're mixed with some hosts with static IP...
  • it uses unbound DNS server - but this is configured only to passthrough the queries to upstream server. What isn't implemented, and IMHO should is:
    • integrate unbound with dnsmasq to allow DNS resolution of DHCP hosts on the network
    • allow the strongest feature of unbound: the recursive feature (usage of root hints) to bypass the ISP's DNS servers (or any other foreign upstream DNS servers which may track your queries)

I personally do not use DNS feature of the Omada gateway, as the current configuration is IMHO not fit for any larger environment.

My DNS chain is following:

• AD integrated DNS - it resolves all static entries for servers, split-DNS entries and all Windows clients using DHCP (yes, the can register in DNS by itself)
• unknown queries are forwarded to piHole, which makes the filtering and
• then non-blacklisted queries are forwarded to unbound DNS server which resides on piHole host

And I have found out, some people aren't familiar with recursive DNS operation, so I'll explain it quickly on example of looking for tp-link.com:

• the request arrives at unbound, the unbound first looks in the cache, if is there, returns the answer immediately
• if not, unbound asks one of root servers a question: "hey, which DNS is responsible for com TLD?"
  • root hints are 13 DNS servers on the top of the DNS hierarchy and contain information only about the DNS servers responsible for TLDs (Top Level Domains)
• when answer is returned, unbound asks the DNS server responsible for com TLD: "hey, which DNS is responsible for tp-link.com domain?"
• when answer is returned, unbound asks the final DNS server responsible for tp-link.com domain: "hey, what is a "A" record for tp-link.com host?"
• answer is stored in cache and returned to requestor