You can ping an IP address, Netflix loads fine on one device, but half the internet is broken and websites just time out. Or maybe everything stopped resolving overnight after a firmware update. If you own an Asus router — an RT-AX88U, RT-AC68U, RT-AX86U, ZenWiFi AX, or any model in the RT or ZenWiFi lineup — a misconfigured or stuck DNS setting is one of the most common causes of exactly that kind of intermittent, maddening failure. This guide cuts straight to the diagnosis and the fix, covering every realistic cause from ISP-assigned DNS servers that have gone dark to Asus DDNS conflicts, DoT (DNS-over-TLS) misconfigurations, and the DNSFilter feature that quietly overrides client settings.

How to Tell the Problem Is Actually DNS

Before touching the router, confirm DNS is the culprit. From any device on your network, open a terminal or command prompt and run two quick tests:

ping 8.8.8.8 nslookup google.com

If the ping succeeds but nslookup google.com returns a timeout or "server failed" error, DNS is broken. If both fail, you have a broader connectivity problem — check WAN status first. On Windows you can also run:

ipconfig /all

Look at the "DNS Servers" line under your active adapter. If it shows the router's LAN IP (commonly 192.168.1.1 or 192.168.50.1 on Asus routers), the router itself is acting as DNS proxy. That means the problem lives in the router, not on the client device. On macOS or Linux:

cat /etc/resolv.conf dig google.com @192.168.1.1

If the dig query times out or returns SERVFAIL, you have confirmed the router's DNS resolver is not forwarding queries correctly.

Log into the Asus Router Admin Panel

Open a browser and go to asusrouter.com or type 192.168.1.1 directly (some models default to 192.168.50.1). Log in with your admin credentials. If you have never changed them, the default username is admin and the default password is printed on the label on the bottom of the router. Once inside the web UI, work through each potential cause below in order.

Cause 1: Bad or Unreachable DNS Servers Assigned by ISP

By default, most Asus routers relay whatever DNS servers your ISP hands out via DHCP on the WAN interface. If your ISP's DNS servers are slow, down, or blocking certain domains, every device on your network suffers.

How to Check

Go to WAN > Internet Connection. Scroll down to the WAN DNS Setting section. If the "Connect to DNS Server automatically" toggle is set to Yes, the router is using ISP-assigned servers. Note the addresses shown in gray (they are the live values pushed by your ISP).

The Fix: Override With Public DNS

Set "Connect to DNS Server automatically" to No, then enter reliable public DNS servers:

  • Cloudflare: 1.1.1.1 and 1.0.0.1
  • Google: 8.8.8.8 and 8.8.4.4
  • Quad9 (blocks malware): 9.9.9.9 and 149.112.112.112

Click Apply. The router will reconnect the WAN interface within a few seconds. Test again with nslookup or dig.

Cause 2: DNS-over-TLS (DoT) Misconfiguration

Asus firmware added DNS Privacy (DNS-over-TLS) support in firmware versions 3.0.0.4.386 and later. It is a great feature, but if the upstream DoT server is unreachable, misconfigured, or the router's clock is wrong (causing TLS certificate validation to fail), all DNS resolution breaks silently — no fallback, no error message in the UI, just timeouts.

Where to Find It

Navigate to WAN > Internet Connection > DNS Privacy Protocol. If this is set to DNS-over-TLS (DoT), and you are having DNS problems, test by temporarily switching it back to None and clicking Apply.

Common DoT Mistakes

  • The server address in the DoT profile does not match the TLS hostname (e.g., entering 1.1.1.1 but leaving the hostname blank instead of cloudflare-dns.com).
  • The router's system time is wrong. DoT uses TLS, which requires valid certificate dates. Go to Administration > System and confirm NTP is working.
  • Port 853 is being blocked by the ISP — less common, but it happens on some mobile broadband connections.

Correct DoT profile for Cloudflare: IP 1.1.1.1, TLS hostname cloudflare-dns.com. For Google: IP 8.8.8.8, TLS hostname dns.google.

Cause 3: Asus DNSFilter Overriding Client DNS

DNSFilter is an Asus-specific feature that forces all DNS queries on the network through a router-chosen resolver, regardless of what individual devices are configured to use. It is found under Adaptive QoS > Traditional QoS > DNSFilter (or directly under Parental Controls > DNS Filter on some firmware versions).

If DNSFilter is enabled and pointed at a server that is down, throttled, or miscategorizing your traffic, DNS breaks for every device on the network — and because it overrides client settings, you cannot fix it from the device side. Check this setting, and if it is not something you deliberately configured, set it to No Filtering or disable it entirely.

After making any DNS change on the router, wait two to three minutes and then use the DNS Propagation Checker to verify your domain is resolving correctly from multiple global vantage points — not just from your local network.

Cause 4: DHCP Not Pushing the Right DNS to Clients

Even if the router's WAN DNS is configured correctly, the router might be pushing the wrong DNS addresses to your LAN clients via DHCP. Navigate to LAN > DHCP Server. Look at the DNS Server 1 and DNS Server 2 fields. These control what DNS servers clients receive in their DHCP lease.

By default these are blank, which means the router advertises its own LAN IP as the DNS server and proxies queries upstream — this is normal and correct. But if someone has filled in an old or dead DNS server address here, clients will be sent directly to that broken server instead of the router. Clear any incorrect entries and leave the fields blank to restore default proxying behavior, then click Apply.

After applying, clients need to renew their DHCP lease to get the updated DNS. On Windows:

ipconfig /release ipconfig /renew ipconfig /flushdns

On macOS: go to System Settings > Network > your interface > TCP/IP > Renew DHCP Lease.

Cause 5: Stuck or Corrupted DNS Cache on the Router

Asus routers run dnsmasq as their DNS/DHCP daemon. Occasionally after a power cut, firmware update, or ISP outage, dnsmasq ends up with a corrupt cache or fails to restart cleanly, causing it to return SERVFAIL for all queries even though the WAN connection is up.

Quick Fix: Restart the Router

Go to Administration > System > Reboot and do a clean restart. This is different from just power-cycling — it flushes dnsmasq's state properly. If the problem recurs regularly, consider enabling SSH access (Administration > System > Enable SSH) and restarting dnsmasq manually when it happens:

service restart_dnsmasq

You can also flush the router's DNS cache without a full reboot by running that same command over SSH. Asus routers running stock firmware accept standard BusyBox shell commands once SSH is enabled.

Cause 6: VPN Client Interfering With DNS

If you have a VPN client configured on the router (under VPN > VPN Client), and that tunnel is up but the VPN provider's DNS is not responding, you will get DNS failures for all traffic routed through the tunnel. Check VPN > VPN Client > [your profile] > DNS setting. Options are typically "Exclusive" (only use VPN DNS), "Relaxed" (use VPN DNS if available, fall back to WAN DNS), or "Disabled." Switch to Relaxed or Disabled if the VPN DNS is unreliable. Also confirm the VPN tunnel itself is actually connected — a half-open tunnel can hold DNS queries indefinitely.

Cause 7: Firmware Bug or Known Regression

Asus firmware 3.0.0.4.388.x introduced several DNS-related bugs that were later patched. If your router is on an older 388 build and started having DNS problems after a firmware update, check the SNBForums Asus firmware thread for your model. Rolling back one firmware version can be done via Administration > Firmware Upgrade > Manual Firmware Upgrade — download the previous firmware from the Asus support site for your exact model number.

Verifying the Fix

Once you have applied a change, verify resolution is working from multiple angles. Use the DNS Lookup tool to query a domain from outside your network and confirm the authoritative answer looks correct. Locally, run:

nslookup google.com 1.1.1.1 nslookup google.com 192.168.1.1

Both should return an answer. If the first works but the second fails, the router's DNS proxy is still broken — revisit the dnsmasq restart or look for a DNSFilter rule overriding things. On Windows, also flush the local resolver cache after any router change:

ipconfig /flushdns

On macOS Ventura and later:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

How to Prevent This From Happening Again

  • Pin reliable public DNS servers in WAN settings rather than relying on ISP-assigned servers. ISP DNS servers change, go down for maintenance, and are sometimes throttled without notice.
  • Keep firmware updated. Asus releases DNS-related patches regularly. Enable automatic update notifications under Administration > Firmware Upgrade.
  • If using DoT, monitor it. Consider the Merlin firmware (Asuswrt-Merlin) for your router model if you want more robust DoT fallback behavior and better logging than stock firmware provides.
  • Enable router logging. Go to System Log > General Log and turn on DNS query logging if your firmware version supports it. This makes future diagnosis much faster.
  • Set a DNS monitoring alert. Tools like UptimeRobot have a free DNS monitoring tier — point it at your router's public IP resolving a test hostname and get an email the moment resolution breaks.
  • Document your settings. After you get DNS working correctly, export your router configuration from Administration > Restore/Save/Upload Setting. If a firmware update wipes your settings, you can restore in under a minute.

When the Problem Is Not the Router

If you have worked through every setting above and DNS is still broken, the issue may be upstream of your router entirely. Contact your ISP and ask specifically whether their DNS servers or DHCP-assigned configurations have changed recently. Also confirm there is no transparent DNS interception or captive portal active on the line — some ISPs redirect all port 53 traffic to their own resolvers regardless of what you configure, which will break DoT and any attempt to use non-ISP resolvers. In that case, switching to DNS-over-HTTPS via a custom firmware like Asuswrt-Merlin with stubby or unbound is the only reliable workaround.