Asus routers running Merlin firmware occupy a rare middle ground: consumer hardware with near-enterprise DNS flexibility. Stock AsusWRT gives you custom DNS server fields, but Merlin unlocks DNS-over-TLS natively, per-client DNS routing through DNS Director, dnsmasq configuration overlays that survive firmware updates, and fine-grained content filtering — all from the same web interface. If your Merlin router is still forwarding to your ISP's resolvers, you are leaving speed, privacy, and filtering capability unused.

What Merlin Adds to the DNS Stack

Standard AsusWRT lets you swap WAN DNS entries and set DHCP-advertised resolvers. Merlin (maintained by Eric Sauvageau, currently tracking the 388.x and 3006.x series) extends this considerably:

  • DNS Privacy Protocol — native DNS-over-TLS via a bundled Stubby instance, configurable from the main WAN settings panel without third-party scripts
  • DNS Director — UI-based per-client DNS routing introduced in 386.7 and refined in 388.x
  • DNSFilter — network-wide DNS-based content filtering with per-client overrides keyed to MAC address
  • dnsmasq overlay — persistent custom directives in /jffs/configs/dnsmasq.conf.add that survive reboots and firmware upgrades
  • Entware — optional package manager for running Unbound, dnscrypt-proxy, or standalone Stubby with configuration deeper than the UI exposes

The admin interface is accessible at router.asus.com, 192.168.1.1, or 192.168.50.1 (GT-series and some AX models default to the .50.x subnet). All menu paths below refer to the standard Merlin web UI unless SSH is explicitly mentioned.

Step 1 — Set WAN DNS Servers

Navigate to Advanced Settings → WAN → Internet Connection. Scroll to WAN DNS Setting. Change Connect to DNS Server Automatically to No, then fill in DNS Server 1 and DNS Server 2.

Common choices in 2026:

  • Cloudflare: 1.1.1.1 / 1.0.0.1 — fast, privacy-focused, DNSSEC-validating
  • Google Public DNS: 8.8.8.8 / 8.8.4.4 — reliable, high availability
  • Quad9: 9.9.9.9 / 149.112.112.112 — DNSSEC validation plus malware domain blocking, no logging
  • NextDNS: your assigned IP from the NextDNS dashboard — custom blocklists, per-profile analytics
  • Mullvad: 194.242.2.2 / 194.242.2.3 — no logging, no EDNS client subnet, Sweden-based

Click Apply. The change takes effect immediately without a reboot. This controls two things: what the router itself uses for its own name resolution, and what dnsmasq forwards to for LAN client queries when DoT is not active. When DoT is enabled in Step 2, these WAN DNS IP fields are still used for TLS connection establishment — the TLS hostname field in the DoT profile then takes over for certificate verification.

ISP override scenario: if an ISP-provided modem sits upstream of your Asus, it may push DNS addresses to the Asus WAN port via DHCP, silently overwriting your values. Verify after applying by connecting via SSH and running nvram get wan_dns. If the output shows your ISP's resolver IPs instead of yours, the modem is the culprit. Solutions: put the modem in bridge or passthrough mode, or activate DNSFilter which intercepts outbound port 53 from all LAN clients regardless of what the WAN side is doing.

💡 After swapping WAN DNS servers, confirm the upstream resolver is actually responding correctly by running a test through the DNS Propagation Checker — especially useful when switching to a filtering resolver like Quad9 or NextDNS where blocked domains should return NXDOMAIN or a sinkhole address rather than a real IP.

Step 2 — Enable DNS-over-TLS

DoT encrypts DNS queries between your router and the upstream resolver on TCP port 853, preventing ISP snooping, DNS hijacking, and man-in-the-middle inspection. Merlin ships with a Stubby instance that handles the TLS tunnel and hands resolved responses back to dnsmasq for caching and local distribution.

Navigate to Advanced Settings → WAN → Internet Connection. Scroll to DNS Privacy Protocol. Set the dropdown to DNS-over-TLS (DoT). A profile list appears with preconfigured entries for Cloudflare, Google, Quad9, and CleanBrowsing. Each entry contains three fields:

  • IP address — the resolver's IP that Stubby opens the TCP connection to on port 853
  • TLS Hostname — the server name sent in the TLS SNI field (e.g., cloudflare-dns.com), used for certificate verification against the resolver's TLS certificate
  • SPKI Hash — optional SHA-256 pin of the resolver's public key, providing a pinning layer beyond the certificate chain for environments requiring stronger assurance

Select a profile and click Apply. Merlin starts Stubby on 127.0.0.1:5335 and reconfigures dnsmasq to forward queries there instead of directly to the WAN DNS IPs.

Version note: the DoT option in the web UI requires Merlin 384.13 or later. If you are on an older 384.12 or early 386.x build and the DNS Privacy Protocol field is absent, update first — the latest stable is available at asuswrt-merlin.net.

# Verify DoT is working — from router SSH (enable at Administration → System → Enable SSH): # Confirm Stubby process is running: ps | grep stubby # Confirm dnsmasq forwards to Stubby's local listener: cat /etc/dnsmasq.conf | grep server # Expected: server=127.0.0.1#5335 # Confirm no plaintext DNS leaves the WAN interface: tcpdump -i eth0 -n udp port 53 # Should produce no output if DoT is routing everything through Stubby # Query directly through Stubby to verify it resolves: dig @127.0.0.1 -p 5335 example.com +short

Step 3 — LAN and DHCP DNS Distribution

By default, Merlin's DHCP server advertises the router's LAN IP (192.168.1.1) as the DNS server for all clients. Clients query the router, dnsmasq handles caching and local hostname resolution, then forwards upstream — through Stubby if DoT is active. For most home and small-office setups this is correct and should not be changed.

To point DHCP clients at a different resolver such as a Pi-hole at 192.168.1.10, navigate to Advanced Settings → LAN → DHCP Server. Set DNS Server 1 to your target IP and DNS Server 2 as a fallback. Click Apply. Clients pick up the new assignment at their next DHCP renewal; to force it immediately, release and renew the IP on each device.

Side effects of bypassing dnsmasq: LAN hostname resolution breaks entirely because the upstream resolver has no knowledge of your LAN devices. The router's DNS cache is bypassed. DNSFilter rules no longer apply to clients using the bypassed resolver. Unless you are running a dedicated LAN resolver like Pi-hole that handles local hostnames itself, keep DHCP DNS pointed at the router.

Step 4 — DNS Director: Per-Client DNS Routing

DNS Director routes individual LAN clients to different DNS resolvers from a single UI panel without scripting. Common use cases: children's devices use a filtering resolver, work machines use a corporate DNS server, IoT devices are isolated on a quarantine resolver, and other devices bypass filtering entirely.

Navigate to Advanced Settings → LAN → DNS Director. The panel lists all known clients. To configure a client:

  1. Click the edit icon on the client row
  2. Under Redirect DNS to, choose Router (default dnsmasq chain), No Redirect, or Custom
  3. For Custom, enter the destination resolver IP — a Pi-hole at 192.168.1.10, Quad9 at 9.9.9.9, or a NextDNS assigned endpoint
  4. Optionally enable Force Redirect Port 53 — this intercepts outbound port 53 traffic and redirects it even when the client has a DNS server hardcoded in its own network settings
  5. Save

DNS Director works by inserting iptables PREROUTING rules that NAT-redirect UDP and TCP port 53 from the matched source IP. Inspect the active rules from SSH:

iptables -t nat -L PREROUTING -n -v | grep -i 53

MAC randomization conflict: iOS 14+, Android 10+, and Windows 11 all randomize MAC addresses per network by default. DNS Director matches by MAC address, so if a client connects with a different randomized MAC than what was stored, the rule will not apply. Disable MAC randomization per network on affected devices. On iOS: Settings → WiFi → [network] → Private Address → Off. On Android: Settings → WiFi → [network] → pencil icon → Privacy → Use device MAC. On Windows 11: Settings → Network and Internet → WiFi → [network] → Random hardware addresses → Off.

💡 To confirm which resolver a specific device is actually hitting, run a DNS query from that device and verify the response source against your expected resolver using the DNS Lookup tool — if you see a different nameserver than expected, DNS Director may have lost the MAC-to-IP mapping, or the browser is bypassing port 53 entirely via DoH.

Step 5 — DNSFilter for Network-Wide Content Blocking

Navigate to Advanced Settings → Firewall → DNS Filter. Enable Global DNS-based Filtering. Options include No Filtering, Router (the default dnsmasq chain), OpenDNS Family Shield (208.67.222.123), SafeDNS, and Custom where you specify any resolver IP.

The per-client override table below the global setting lets you exempt or reassign specific MAC addresses. A client row set to No Filtering bypasses the global filter for that device. DNS Director per-client rules take precedence over the global DNSFilter setting for matched clients — DNSFilter handles the default case for everyone else.

DNSFilter operates at the iptables level, intercepting outbound port 53 traffic before it leaves the router. It does not intercept DoH running over port 443, which is a separate problem addressed in the 2026 section below. If you need true enforcement across all DNS transports, the approach shifts from router-level interception to resolver-level enrollment.

Advanced — Custom dnsmasq Rules via /jffs

For scenarios the UI does not cover — static local DNS records, split-horizon forwarding, blocking specific domains network-wide, or routing a single domain to a different upstream — use Merlin's persistent dnsmasq overlay file:

# SSH into the router: ssh admin@192.168.1.1 # Edit the persistent overlay file: nano /jffs/configs/dnsmasq.conf.add # Local A record — a NAS or server with a static IP: address=/nas.home/192.168.1.20 # Forward an internal corporate domain to an internal DNS server: server=/corp.internal/10.8.0.1 # Block a domain network-wide (returns 0.0.0.0): address=/tracker.example.net/0.0.0.0 # Apply the changes without a full reboot: service restart_dnsmasq

The file must live in /jffs/configs/ — the JFFS2 flash partition that persists across reboots and upgrades. Files placed in /tmp/configs/ are ramdisk and disappear on every reboot. Confirm JFFS2 is enabled at Administration → System → Enable JFFS partition at next boot. Always verify your syntax before applying: run dnsmasq --test --conf-file=/tmp/dnsmasq.conf from SSH. A single bad directive causes dnsmasq to silently reject the entire add-on file and fall back to defaults with no obvious error message in the UI.

To forward all LAN queries to a Pi-hole while keeping the Asus as the DHCP server:

# In /jffs/configs/dnsmasq.conf.add: server=192.168.1.10 no-resolv # Restart dnsmasq: service restart_dnsmasq # Verify the router is forwarding to Pi-hole (check Pi-hole query log after this): dig @192.168.1.1 example.com

Verifying DNS Configuration Across Platforms

After any configuration change, test from the device types that matter most in your environment:

# Linux — systemd-resolved systems: resolvectl status dig @192.168.1.1 example.com +short # Linux — traditional resolv.conf systems: cat /etc/resolv.conf nslookup example.com 192.168.1.1 # macOS: scutil --dns | grep nameserver nslookup example.com 192.168.1.1 # Windows (Command Prompt): ipconfig /all nslookup example.com 192.168.1.1 # Windows (PowerShell): Resolve-DnsName -Name example.com -Server 192.168.1.1 # Android 10+ — check assigned DNS: # Settings → WiFi → [network] → pencil icon → Advanced options → DHCP → DNS 1 # iOS 15+ — check assigned DNS: # Settings → WiFi → [network] → info (i) icon — shows current DNS assignment

From the router SSH shell, check the full stack in one session:

# What DNS is configured on the WAN side: nvram get wan_dns # What upstream dnsmasq resolv.conf is pointing to: cat /etc/resolv.conf # Is Stubby running — confirms DoT is active: ps | grep stubby # Check dnsmasq is listening on the LAN interface: netstat -an | grep ':53 ' # Quick test query through dnsmasq: nslookup example.com 127.0.0.1

Common Misconfigurations

ISP resolver persisting after WAN DNS change. The upstream modem is pushing DNS via DHCP to the Asus WAN port and overwriting your settings. Confirm with nvram get wan_dns from SSH — if you see ISP IPs, the modem is the source. Fix: bridge mode on the modem, or enable DNSFilter to force all LAN client queries through your chosen resolver at the iptables level regardless of what the WAN DHCP assignment says.

DoT active but plaintext DNS still leaving WAN. Either Stubby failed to start (check ps | grep stubby returns a process) or the TLS hostname in the DoT profile mismatches the resolver certificate and Stubby falls back silently. Also check for clients with a resolver hardcoded in their IP settings — DNS Director with Force Redirect enabled handles those.

LAN hostnames stopped resolving. DHCP DNS was changed to an upstream resolver like 8.8.8.8, bypassing dnsmasq. The upstream resolver has no knowledge of LAN hostnames. Revert the DHCP DNS setting under Advanced Settings → LAN → DHCP Server back to the router's LAN IP.

DNS Director rules not applying to a mobile device. MAC randomization is almost always the cause. The device connected with a different randomized MAC than what DNS Director stored. Disable MAC randomization for your home network on that device and reconnect before checking again.

dnsmasq.conf.add changes ignored after reboot. Either the file landed in /tmp/ instead of /jffs/, or the syntax contains an error and dnsmasq discarded the entire file silently. Run the dnsmasq syntax test command above before applying any new directives.

2026 Notes: DoH Bypass, DNSSEC, and IPv6 DNS Leaks

Browser DoH bypasses your entire router DNS stack. Chrome, Firefox, and Edge now enable Secure DNS (DoH) automatically in many regions. Queries go directly to 8.8.8.8:443 or 1.1.1.1:443 over HTTPS, completely bypassing dnsmasq, Stubby, DNS Director, and DNSFilter with no visible indication at the router level. Blocking DoH requires blocking HTTPS to specific IP ranges, which causes collateral damage. The effective solution in 2026 is to shift your filtering to the resolver layer: enroll devices in NextDNS or Cloudflare Gateway using their system-level profiles or browser extensions, ensuring filtering happens before the query leaves the device regardless of transport protocol.

DNSSEC validation. Both Quad9 (9.9.9.9) and Cloudflare (1.1.1.1) perform DNSSEC validation server-side, so using either with DoT gives you DNSSEC protection without additional router configuration. To add client-side DNSSEC validation in dnsmasq as well, add dnssec and dnssec-check-unsigned directives to dnsmasq.conf.add — Merlin's dnsmasq binary includes DNSSEC support from 386.x onward. Verify it works: dig @9.9.9.9 sigfail.verteiltesysteme.net should return SERVFAIL from a validating resolver because the domain intentionally has an invalid DNSSEC signature. For the foundational DNS specification, RFC 1035 remains the authoritative reference for DNS message format and resolver behavior.

IPv6 DNS leaking your configuration. If your ISP provides IPv6 connectivity, clients receive IPv6 DNS server addresses via DHCPv6 or Router Advertisements and use them instead of your IPv4 DNS config — completely bypassing every setting covered in this article. This is the single most common reason content filtering appears to work on most sites but randomly fails on others. Navigate to Advanced Settings → IPv6. Set Auto DNS Setting to Off. Enter IPv6 DNS server addresses manually: Cloudflare is 2606:4700:4700::1111, Google is 2001:4860:4860::8888, Quad9 is 2620:fe::fe. If DoT is active, add the corresponding IPv6 endpoint entries to your Stubby DoT profile as well so encrypted resolution extends to IPv6 queries.

Backing Up Your DNS Configuration

Merlin stores DNS settings in NVRAM and in /jffs files. Back up both after finalizing your configuration:

# Full settings backup via the web UI (recommended after any major change): # Administration → Restore/Save/Upload Setting → Save Setting # Downloads a .CFG file you can restore verbatim after any firmware upgrade # Back up custom dnsmasq directives from SSH: cp /jffs/configs/dnsmasq.conf.add /jffs/configs/dnsmasq-backup-$(date +%Y%m%d).conf # Inspect current DNS NVRAM values before making changes: nvram show | grep -i dns

One verification to run immediately after every Merlin firmware update: navigate to Advanced Settings → WAN → Internet Connection and confirm DNS Privacy Protocol is still set to DNS-over-TLS. This setting resets to Disabled after some upgrades more reliably than any other DNS-related option. Everything else in NVRAM typically survives, but DoT silently reverts to plaintext forwarding if you do not verify it post-upgrade.