Device names not showing in NextDNS dashboard with ASUS Merlin + CLI (setup-router=false)

[mkaand]

Hello,

I’m running NextDNS CLI on an ASUS RT-AX86U (Merlin firmware) and trying to achieve proper device name visibility in the NextDNS dashboard without breaking my current DNS architecture.

Goal:

See all LAN devices under a single profile
With real device names (hostnames)
Instead of IPs or generic Device #xxxx
Current architecture:

Clients → dnsmasq (router) → NextDNS CLI (127.0.0.1:5555) → NextDNS (DoH)

dnsmasq is actively used (local overrides, ad-blocking, etc.)
upstream configuration:
server=127.0.0.1#5555
no-resolv
add-mac
add-subnet=32,128
NextDNS CLI config:

setup-router false

listen 127.0.0.1:5555

report-client-info true

use-hosts true

profile

Observed behavior:

DNS resolution works correctly
Client IPs are correctly visible in query logs
However, in the dashboard devices appear as Device #xxxx
Important finding:

When setup-router=true is enabled, device names are correctly detected.

However, this mode:

modifies router DNS behavior
interferes with my existing dnsmasq-based setup (especially local overrides / Diversion)
So I must keep setup-router=false.

Expectation:

In setup-router=false mode, I would expect at least one of the following:

dnsmasq hostnames being forwarded to NextDNS
DHCP lease / hosts-based names reflected in dashboard
or a documented/recommended way to achieve this behavior
Additional notes:

CLI -config = mapping was tested → no consistent result
MAC-based profile mapping works, but not suitable for my use case (I want a single profile)
Conclusion:

Without router mode, I cannot get device names in the dashboard.
With CLI in setup-router=false, names are not shown.

What is the recommended architecture for this use case?

Thanks in advance

 

[killweav]

dnsmasq is actively used (local overrides, ad-blocking, etc.)

Are you using AdGuard alongside NextDNS filtering?

 

[mkaand]

Are you using AdGuard alongside NextDNS filtering?

No, I’m not using AdGuard.

I’m using dnsmasq (and Diversion on Merlin) for local overrides and some domain-level blocking (e.g. redirecting specific domains to 127.0.0.1).

NextDNS is used purely as upstream DNS (DoH) + filtering/logging layer.

So the setup is:

dnsmasq (local control & overrides) → NextDNS (cloud filtering)

The issue is not related to double filtering, but rather that in this architecture device hostnames are not reflected in the NextDNS dashboard when setup-router=false.

 

[killweav]

Try the following flag: nextdns config set -discovery-dns 192.168.1.1 -report-client-info true

Use the IP of your router. I "think" it instructs the daemon to check back with your router for hostnames before making a DoH request to the service. As it stands, it seems that diversion is taking those requests, and if not already blocked, forwarding them to NextDNS without the host names. This "should" put your router back in the loop.. see if that helps.

If Diversion blocks a query locally, it will never get forwarded to NextDNS. In effect, you will have 2 places to look for a full picture. Harder for troubleshooting?

There are more experienced folks with regard to diversion. I don't use it.

Update: searching on your behalf I found someone with similar issues had resolved it with the following flag:
nextdns config set -mdns=disabled

NextDNS KB Article

 

[dave14305]

NextDNS CLI is evil insofar as it inserts an exit 0 into the dnsmasq.postconf, preventing any non-NextDNS lines from executing.

 

[mkaand]

Thanks both, really appreciate the input

@killweav
That’s an interesting idea. I haven’t tested -discovery-dns with the router IP yet.

At the moment I’m away from my setup, but once I’m back I’ll try:

• setting discovery-dns to the router IP
• and also fully disabling Diversion to see if it’s intercepting and stripping hostname context before forwarding

Your theory makes sense — right now dnsmasq (and Diversion) might be answering/forwarding queries without passing hostname metadata upstream.

Also to confirm:
I already tested mdns=disabled, but it didn’t change the behavior.

@dave14305
That’s a very interesting point about dnsmasq.postconf.

In my case I’m running with setup-router=false, so NextDNS shouldn’t be modifying dnsmasq directly — but I’ll double-check whether anything is being injected or short-circuited there.

Plan when I’m back:

1. Disable Diversion completely
2. Test with:
3. Re-check if hostnames start appearing in dashboard

I’ll report back with results

 

[mkaand]

Update – dnsmasq + NextDNS CLI hostname issue​

Quick update after further testing. I am not restating the full setup, only what was tested and observed.

Current setup (unchanged)​

• ASUS Merlin router
• dnsmasq is actively used (DHCP + local overrides)
• NextDNS CLI runs on 127.0.0.1:5555
• dnsmasq forwards to:
  server=127.0.0.1#5555
• Key options: add-mac add-subnet=32,128 report-client-info=true discovery-dns=192.168.50.1

---

What is confirmed working​

• Client IPs are correctly visible in NextDNS logs
  (192.168.50.x is preserved)
• Local PTR resolution works via dnsmasq:
  nslookup 192.168.50.112 127.0.0.1→ correct hostname returned

This confirms:

• DHCP leases are correct
• dnsmasq hostname resolution is working

---

The issue​

NextDNS still shows devices as:

Device #XXXX instead of hostnames.

So:

• IP is known
• PTR works locally
• but hostname is not used by NextDNS

---

Tests performed​

1. discovery-dns

• Tested with:
  
  • 127.0.0.1
  • 192.168.50.1
  • with and without :53
• No change

---

2. dnsmasq validation

Confirmed active config:
no-resolv server=127.0.0.1#5555 add-mac add-subnet=32,128
dnsmasq forwarding is correct.

---

3. Diversion / Skynet

• Fully disabled (no iptables hooks, no dnsmasq modifications)

No change.

---

4. mDNS

• Tested both enabled and disabled

No change.

---

5. hardened-privacy

• Tested true / false

No effect.

---

6. detect-captive-portals

• Enabled / disabled

No effect.

---

7. setup-router=true (important observation)
When enabling:
setup-router=true
Device names appear correctly.

However:

• It overrides router DNS behavior
• Breaks dnsmasq-based setup

So it is not usable in this architecture.

---

Key observation​

dnsmasq can resolve:
IP → hostname (PTR)
But NextDNS CLI does not seem to use that information, even with:
discovery-dns<br>report-client-info=true<br>

---

Question​

In a dnsmasq-forwarded setup (setup-router=false):

How is NextDNS expected to obtain hostnames for local clients?

Is PTR lookup for private IP ranges (192.168.x.x) supported or intentionally skipped?

---

Goal​

Keep:

• dnsmasq as primary resolver (for local overrides)

While:

• using NextDNS as upstream
• and still getting proper device hostnames

---

Any clarification or working example with this setup would be appreciated.