Your Asus AiMesh network has exactly one place that controls DNS for the entire mesh — and it is not where most people look first. ASUS firmware splits DNS configuration across two separate menus: WAN DNS, which governs what the router itself queries upstream, and LAN DHCP DNS, which governs what resolver IP your devices receive via DHCP. Changing only one of them is the root cause of most AiMesh DNS complaints. This guide covers both settings precisely, how AiMesh propagates DNS to every node, verification commands for every platform, and the DoH and DoT options built into 2025–2026 ASUS firmware builds.
How AiMesh Distributes DNS Across the Mesh
AiMesh uses a centralized DHCP model. The main router — the unit physically connected to your modem or ONT — owns the DHCP server for the entire mesh. Satellite nodes enrolled in the mesh act as managed access points: they pass all traffic, including DHCP negotiation, back to the main router. Every device that connects to any node gets its IP address and DNS server assignment from the main router's DHCP scope, not from the node it happens to be nearest to.
The practical implication: you configure DNS once, on the main AiMesh router, and it applies to every node and every client on the mesh. Per-node DNS configuration does not exist in standard ASUS firmware. If you browse to a satellite node's IP address after enrollment, the firmware redirects you to the main router's admin interface. All DNS work happens on the main unit only.
Two things break this otherwise clean model in practice: stale DHCP leases on devices that have not renewed since you changed the settings, and Android's system-level Private DNS override that bypasses DHCP-assigned DNS entirely. Both are covered in detail below.
WAN DNS vs LAN DNS: The Distinction That Trips Everyone Up
ASUS firmware has two conceptually different DNS settings, and conflating them is the single most common source of AiMesh DNS confusion:
- WAN DNS (Advanced Settings > WAN > Internet Connection): The upstream resolver the router uses for its own DNS queries — firmware update checks, DDNS hostname resolution, NTP lookups, and query forwarding when the router is acting as a DNS relay for client devices.
- LAN DHCP DNS (Advanced Settings > LAN > DHCP Server): The DNS server IP(s) the router advertises to clients via DHCP Option 6. This is what your MacBook, iPhone, smart TV, and every other device on the mesh actually query when resolving a domain name.
By default, the LAN DHCP DNS fields are blank. A blank entry causes the router to advertise its own LAN IP — typically 192.168.1.1 — as the DNS server for all clients. Devices then send queries to the router, which forwards them upstream using the WAN DNS setting. This two-hop setup works most of the time, but it routes all client DNS through the router's built-in dnsmasq forwarder, adding latency and introducing a failure point if dnsmasq stalls or serves stale cached entries.
The recommended configuration for most AiMesh setups: set both WAN DNS and LAN DHCP DNS to your preferred resolver. The router uses it for its own lookups, and clients receive it directly via DHCP without the forwarding hop.
Step-by-Step: Configuring DNS on an Asus AiMesh Network
Step 1: Log Into the Main AiMesh Router
Open a browser and navigate to http://router.asus.com or directly to the router's LAN IP, typically http://192.168.1.1. If your router is in Access Point mode or sits behind another router, the IP may differ — check your upstream router's DHCP client list to find the ASUS unit's address. Log in with your admin credentials; if you have never changed them, the default username and password are printed on the label on the device's underside.
Do not attempt to configure DNS by accessing a satellite node's IP directly. Enrolled AiMesh nodes redirect admin requests to the main router. All DNS configuration must happen on the main unit.
Step 2: Set the WAN DNS (Router's Upstream Resolver)
Go to Advanced Settings > WAN > Internet Connection. Scroll to the WAN DNS Setting section near the bottom of the page. By default, Connect to DNS Server automatically is enabled, pulling DNS from your ISP via DHCP or PPPoE negotiation. To override with a custom resolver:
- Uncheck Connect to DNS Server automatically.
- Enter your primary resolver in DNS Server 1 — for example,
1.1.1.1(Cloudflare),8.8.8.8(Google), or9.9.9.9(Quad9). - Enter a fallback in DNS Server 2 — for example,
1.0.0.1,8.8.4.4, or149.112.112.112. - Click Apply. The change takes effect immediately without a reboot.
Step 3: Set the LAN DHCP DNS (What Devices Actually Receive)
Go to Advanced Settings > LAN > DHCP Server. Locate the DNS and WINS Server Setting section partway down the page. The DNS Server 1 and DNS Server 2 fields are blank by default. To push a resolver directly to all clients on the mesh:
- Enter
1.1.1.1in DNS Server 1. - Enter
1.0.0.1(or8.8.8.8) in DNS Server 2. - Click Apply.
ASUS firmware defaults the DHCP lease time to 86400 seconds (24 hours). Devices will not receive the updated DNS server IP until their lease renews. To push the change immediately, force a lease renewal on each device you need to update now.
Step 4: Force DHCP Lease Renewal on Client Devices
Enabling DoH and DoT on AiMesh (Firmware 3.0.0.4.388 and Later)
Firmware shipped from late 2023 through 2026 introduced a native DNS Privacy Protocol option on RT-AX series, TUF-AX series, and ZenWiFi XT8, XT9, ET8, and ET12 models. This enables encrypted DNS at the router level, covering every device on the mesh without per-device configuration — a significant improvement over managing DoH individually on dozens of household devices.
Navigate to Advanced Settings > WAN > DNS Privacy Protocol. Select DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT). The page expands to show a provider list with presets:
- Cloudflare: hostname
cloudflare-dns.com, IP1.1.1.1 - Google: hostname
dns.google, IP8.8.8.8 - Quad9: hostname
dns.quad9.net, IP9.9.9.9 - AdGuard: hostname
dns.adguard.com
When DoH or DoT is active, the WAN DNS plaintext entries you set earlier are replaced by the encrypted resolver. The LAN DHCP DNS setting still controls what IP clients receive via DHCP. For the cleanest household setup, leave LAN DHCP DNS blank so clients query the router's LAN IP, which relays all queries over DoH. Every device on the mesh gets encrypted DNS without any per-device configuration. Alternatively, point LAN DHCP DNS directly at 1.1.1.1 to bypass the relay entirely, but those queries will be plaintext unless each device has its own DoH configuration.
On DNSSEC: firmware 3.0.0.4.388+ includes a separate DNS Security (DNSSEC) toggle under Advanced Settings > WAN. Both Cloudflare and Google already validate DNSSEC responses upstream, making router-level DNSSEC redundant for most users. It can also cause resolution failures for misconfigured DNSSEC zones — some CDN and cloud providers have historic issues that major resolvers quietly work around. Leave it disabled unless you have a specific security requirement for it.
Configuring DNS on Individual AiMesh Nodes
Through the standard ASUS firmware UI, you cannot configure DNS on individual enrolled nodes. AiMesh nodes do not expose independent DNS settings after enrollment — the main router manages DNS policy for the entire mesh. This is expected behavior, not a bug or a firmware limitation waiting for a workaround.
If you need standalone access to a node for diagnostics or a factory reset, hold the physical reset button for 5–10 seconds to remove it from the AiMesh enrollment. The node then reverts to a standalone router accessible at 192.168.1.1 with its default credentials (typically admin/admin or whatever is printed on the label). Configure it as needed, then re-enroll it through the main router's AiMesh > AiMesh Node panel.
On supported models — RT-AX88U, RT-AX86U, ZenWiFi XT8, XT9, ET8, ET12 — the main router's AiMesh > Topology view shows each enrolled node with a Remote Settings option. This exposes radio, backhaul, and band-steering controls, but not DNS. If you see DNS discrepancies between devices connected to different nodes, the cause is almost always stale DHCP leases, not per-node DNS configuration. Force lease renewals on affected devices as shown in Step 4 above.
Verifying DNS Settings on Every Platform
After applying changes and renewing leases, confirm the correct resolver is in use before assuming the fix worked. Skipping this step is how people spend an hour troubleshooting a problem that solved itself two reboots ago — or discover the wrong setting was changed.
Windows
macOS
Linux
iOS
Go to Settings > Wi-Fi > tap the connected network > Configure DNS. If it reads Automatic, the listed nameservers should match what you configured in the router's DHCP DNS fields. To override DNS for a specific network without touching the router, tap Manual and add your resolver IPs directly — this takes precedence over DHCP for that network only.
Android
Android 9 and later includes a system-wide Private DNS setting at Settings > Network & Internet > Advanced > Private DNS. If this is set to a hostname such as dns.google or 1dot1dot1dot1.cloudflare-dns.com, the device uses that resolver over DoT for all networks, completely ignoring DHCP-assigned DNS. This is the most common reason Android devices appear to ignore AiMesh DNS settings — it is a feature, not a misconfiguration. Set Private DNS to Automatic to use DoT when available and fall back to DHCP DNS, or set it to Off to rely exclusively on whatever the router advertises.
Common Problems and Misdiagnoses
DNS changed on router but devices still show old servers
DHCP leases on ASUS firmware default to 86400 seconds. Devices renew at the halfway mark, so a device that obtained its lease 12 hours ago won't see updated DNS for another 12 hours. The fix is a forced lease renewal on each affected device, not reducing the global DHCP lease time. Reducing lease time globally on a large AiMesh network with many clients increases DHCP chatter without addressing the root issue.
WAN DNS is set to a custom resolver but queries trace back to ISP servers
Check the LAN DHCP DNS fields first. If they are blank, the router is advertising its own LAN IP (192.168.1.1) to clients, and dnsmasq is forwarding those queries using WAN DNS. If the dnsmasq cache holds stale ISP DNS entries from before your change, those stale results persist even after updating WAN DNS. SSH into the router (enable SSH at Administration > System > SSH Daemon if not already active) and restart dnsmasq to flush the cache immediately:
Devices on AiMesh nodes have different DNS than devices on the main router
This is almost always a stale DHCP lease, not a per-node DNS configuration issue. All nodes serve clients from the same DHCP scope managed by the main router. Force lease renewal on the affected devices. If the problem persists after forced renewal, verify the main router has both WAN DNS and LAN DHCP DNS set correctly — one of them may have reverted after a recent firmware update.
IPv6 DNS is ignoring custom settings
IPv6 DNS is handled separately through DHCPv6 or Router Advertisement (RA). Navigate to Advanced Settings > IPv6. If the IPv6 connection type is Native or Tunneling with auto-configuration enabled, the router may relay ISP-provided IPv6 DNS addresses independently of your IPv4 DNS changes. To override: set IPv6 DNS to Manual and enter your resolver's IPv6 addresses. Cloudflare: 2606:4700:4700::1111 and 2606:4700:4700::1001. Google: 2001:4860:4860::8888 and 2001:4860:4860::8844. Quad9: 2620:fe::fe and 2620:fe::9.
Third-party firmware on mesh nodes
OpenWrt and DD-WRT are not supported on AiMesh nodes, and the AiMesh enrollment protocol will not accept them. A device running OpenWrt that was previously an AiMesh node operates as an independent router or dumb AP — it cannot rejoin the mesh. DNS on OpenWrt is configured at Network > DHCP and DNS > General Settings, with upstream resolvers set under Network > Interfaces > WAN > Advanced Settings > Use custom DNS servers. These settings are entirely separate from the ASUS AiMesh network.
How to Confirm the Fix Worked
After renewing leases, run a final verification from a device connected through the mesh before closing the browser tab:
If nslookup google.com shows 1.1.1.1 (or your chosen resolver) as the answering server, the LAN DHCP DNS change is live. If it still shows 192.168.1.1, the client is querying through the router's forwarder — not broken if WAN DNS is set correctly, but force a lease renewal to get the direct resolver assignment.
For end-to-end DNSSEC and DoH validation, the Google Public DNS documentation includes specific test procedures and verification steps that confirm both resolver identity and DNSSEC chain-of-trust behavior, useful when validating a DoH deployment across the AiMesh network.
Preventing DNS Drift After Firmware Updates
ASUS firmware OTA updates occasionally reset the WAN DNS setting back to automatic on major version jumps — particularly when moving between firmware branches such as 3.0.0.4.38x to 3.0.0.4.39x. The LAN DHCP DNS fields are more stable across updates but are not immune to reversion. After every firmware update, log into router.asus.com and verify both the WAN DNS and LAN DHCP DNS settings before marking the update complete.
Export a router configuration backup immediately after finalizing DNS settings: Administration > Restore/Save/Upload Setting > Save Setting. The exported CFG file preserves all DNS configuration and restores cleanly after a factory reset or firmware re-flash. Store it alongside the router's serial number and admin credentials so it is recoverable from any machine on the network.
On firmware 3.0.0.4.388+, the DNS Privacy Protocol (DoH/DoT) settings have proven more persistent across updates than WAN DNS plaintext entries. If long-term DNS consistency is a priority and your hardware supports it, configuring DoH at the router level provides a more durable setup than relying on manual WAN DNS entries that ISP-triggered or firmware-triggered resets can silently clear.