Changing DNS on a TP-Link router should take two minutes. In practice it takes twenty — the Tether app exposes DNS settings in two different locations, the first one you find is usually the wrong one, and there is no on-screen confirmation that new servers are actually handling queries. This guide covers the exact tap paths for Tether 4.x, the web admin fallback, Deco mesh specifics, CLI verification commands, and the misconfigurations that make the change appear to do nothing.
Two DNS Settings, One Confusing Interface
Before touching anything, understand what you are changing. TP-Link routers expose DNS in two separate places, and picking the wrong one is the root cause of most failed attempts.
- WAN DNS (upstream resolver): The DNS servers your router itself uses when resolving names on behalf of all devices. When a laptop requests google.com, the router fields it and forwards the query to whatever WAN DNS server is configured here. This is what most people want to change.
- DHCP DNS (advertised to clients): The DNS IP included in DHCP lease offers. Changing this tells client devices to query a specific resolver directly — useful when running Pi-hole or AdGuard Home on the LAN and you want clients to query it rather than the router's forwarder.
In a standard home setup, change WAN DNS only. If you are running a local resolver, change DHCP DNS to point at that resolver's LAN IP and leave WAN DNS as the upstream fallback.
What You Need Before Starting
- TP-Link Tether app 4.0 or later (iOS 16+ / Android 10+)
- Your router already added and reachable in Tether — via local Wi-Fi or TP-Link cloud
- Admin credentials — default is admin / admin or the password printed on the router label
- The DNS server IPs you intend to use
Quick reference for popular public DNS resolvers:
- Cloudflare: 1.1.1.1 / 1.0.0.1 — fastest global average, strong privacy policy (Cloudflare DNS overview)
- Google Public DNS: 8.8.8.8 / 8.8.4.4 — broad anycast coverage, high reliability
- Quad9: 9.9.9.9 / 149.112.112.112 — DNSSEC-validating, blocks known malicious domains
- OpenDNS: 208.67.222.222 / 208.67.220.220 — optional content filtering categories
Change DNS on an Archer Router via Tether
TP-Link reorganised the Tether navigation in late 2023. The paths below apply to Archer AX, AXE, and BE series routers on firmware shipped after mid-2023. EX series range extenders running in Router mode follow the same layout.
Changing WAN DNS (recommended for most users)
- Open Tether and tap your router in the device list.
- Tap the gear icon in the top-right corner.
- Tap Advanced → Network → Internet.
- Scroll to the DNS section. If it shows Get Dynamically from ISP, tap the toggle to switch to Use the Following DNS Addresses.
- Enter your Primary DNS and Secondary DNS IPs.
- Tap Save. The WAN interface restarts in 2–5 seconds. Wi-Fi stays connected throughout.
Changing DHCP DNS (for Pi-hole or direct-to-resolver setups)
- From Advanced → Network, tap DHCP Server.
- Locate the DNS Address field.
- Enter the IP of the resolver you want clients to receive (e.g., a Pi-hole at 192.168.0.200, or 1.1.1.1 to bypass the router forwarder entirely).
- Tap Save. Clients receive the new DNS on their next DHCP renewal — force it immediately with a Wi-Fi toggle or
ipconfig /release && ipconfig /renewon Windows.
Tether 3.x (older Archer C series): The path is gear icon → More → Advanced → Network → WAN Settings. The DNS fields appear in that panel rather than in a separate Internet sub-screen.
Change DNS on a Deco Mesh System
Deco systems (XE75, XE6, BE85, and similar) present a different navigation because all nodes share a single system view in Tether rather than individual device entries.
- Open Tether and tap your Deco system.
- Tap More (bottom-right tab) → Advanced.
- Tap IPv4 → Internet Connection.
- Scroll to DNS Server and switch from Auto to Manual.
- Enter primary and secondary DNS IPs.
- Tap the checkmark or Save. The setting propagates to all satellite nodes automatically — no per-node configuration needed.
For Deco DHCP DNS: More → Advanced → IPv4 → DHCP Server → DNS Address → Save.
Change DNS via the Web Admin Panel
Use this when Tether shows Device Offline, when the Tether DNS field is greyed out, or when you simply prefer a browser interface over the app.
- Connect to your TP-Link network via Wi-Fi or Ethernet.
- Open a browser and navigate to tplinkwifi.net or 192.168.0.1. Some older Archer models (WR840N, C50 v1) default to 192.168.1.1 — check the label on the router's underside.
- Log in with your admin credentials.
- Go to Advanced → Network → Internet.
- Deselect Get Dynamically from ISP → enter your DNS IPs → click Save.
For DHCP DNS via web admin: Advanced → Network → DHCP Server → DNS Address → Save.
Third-Party Firmware: OpenWrt and DD-WRT
The Tether app does not work with custom firmware. If your TP-Link Archer (C7, C2300, WR940N) runs OpenWrt or DD-WRT, use those admin interfaces directly.
OpenWrt (LuCI)
Upstream WAN DNS: Network → Interfaces → WAN → Edit → Advanced Settings → uncheck Use DNS servers advertised by peer → enter IPs under Use custom DNS servers.
LAN forwarding via dnsmasq (all clients benefit without querying upstream directly): Network → DHCP and DNS → General Settings → DNS forwardings → add your DNS IPs. Clients query dnsmasq on the router, which forwards to the upstream. Persistent across reboots.
DD-WRT
Setup → Basic Setup → scroll to Network Address Server Settings (DHCP) → fill Static DNS 1 and Static DNS 2 → click Apply Settings. Check Use DNSMasq for DNS to enable forwarding mode.
Verify the Change with CLI Tools
Router UIs confirm saves silently. Run these from a device on your LAN after saving to confirm queries are actually flowing through the new resolvers.
Windows
macOS
Linux (systemd-resolved)
The whoami.cloudflare.com TXT test is the most reliable confirmation: Cloudflare returns the IP their network sees the query arriving from. If the result is your router's public WAN IP rather than your ISP resolver's IP, Cloudflare is handling your DNS correctly.
Platform Overrides That Bypass Router DNS
Changing the router's DNS setting does not guarantee every device on the network respects it. Several modern platforms allow DNS to be configured at the OS or app level, and those settings override DHCP.
- Windows 11: Settings → Network & Internet → Wi-Fi → [network name] → DNS server assignment. Any manual entry or DoH hostname configured here overrides DHCP-supplied DNS completely. This is the first place to check when a Windows machine ignores your router change.
- macOS Ventura / Sonoma: System Settings → Network → Wi-Fi → Details → DNS. Any IP listed in this tab takes precedence over DHCP. Remove all entries to inherit the router's DNS setting.
- Android 9+: Settings → Network & Internet → Private DNS. A custom hostname such as
dns.cloudflare.comroutes all app queries over DoT, bypassing your router's DNS entirely. This is a device-level setting independent of whatever is configured on the router. - iOS 14+: iOS uses DHCP-provided DNS by default, but any MDM-deployed configuration profile or DoH profile overrides it. Check Settings → General → VPN, DNS & Device Management for active profiles before assuming the router setting is the problem.
- Linux (systemd-resolved): A
DNS=directive in/etc/systemd/resolved.confoverrides DHCP. Runresolvectl statusand look at the nameserver source field — if it says static rather than DHCP, the config file wins regardless of what the router sends.
If a specific device is unaffected by the router change, one of these local overrides is almost certainly the cause — not the router configuration.
Common Misdiagnoses
- Devices still resolving via ISP after the change. Most likely the device has a manual DNS entry in its own network settings that overrides DHCP. Check the OS-level network settings directly on the device. Also force a DHCP lease renewal:
ipconfig /release && ipconfig /renewon Windows, or toggle Wi-Fi off and back on for mobile devices. - DNS field greyed out in Tether. Your WAN connection type is PPPoE or a static IP configuration where the ISP pushes DNS via PPP negotiation. Find and uncheck the Use ISP DNS or Get Dynamically from ISP option first. On some ISP-branded firmware this field is read-only — set DNS on individual devices as a workaround.
- Set Cloudflare but dig still shows Google (8.8.8.8). You likely changed DHCP DNS but the device is ignoring DHCP-advertised DNS due to a hardcoded setting or a VPN client that redirects all DNS traffic. Check the VPN's DNS leak prevention settings.
- tplinkwifi.net does not load. Try the gateway IP directly: 192.168.0.1 or 192.168.1.1. If you changed the router's LAN IP address at some point, use that address. Some ISP-branded TP-Link units block port 80 on the LAN side — try
https://192.168.0.1if the firmware supports HTTPS admin access. - Change saves in Tether but reverts after reboot. Known regression in certain Archer firmware releases. Update via Advanced → System → Firmware Upgrade — several mid-2024 builds patched this specific issue.
2026 Update: DoH, IPv6, and DNSSEC
Plain DNS over port 53 is what the steps above configure. In 2026 there are three additional layers worth understanding before you consider the setup complete.
Native DoH Support in Newer TP-Link Firmware
Archer firmware 5.x (shipping on AX55, AX73, AXE75 from late 2024 onward) and Deco firmware 6.x introduced a DNS Encryption toggle under Advanced → Network → Internet. Enabling it wraps all upstream queries in HTTPS, preventing ISP-level DNS interception and query logging. Supported providers in the firmware UI as of mid-2026 include Cloudflare, Google, and Quad9. Selecting a provider auto-populates the DoH endpoint — no manual URL entry is required. If your firmware version does not show this toggle, a firmware update is the fastest path to DoH without deploying a separate resolver.
IPv6 DNS
If IPv6 is active on your router (Advanced → Network → IPv6), the router receives an IPv6 DNS address alongside the IPv4 one — for example, 2606:4700:4700::1111 for Cloudflare. Dual-stack devices prefer IPv6 DNS. If you set IPv4 DNS manually but leave IPv6 DNS on auto, queries from dual-stack clients may still flow through your ISP's IPv6 resolver. Set both IPv4 and IPv6 DNS explicitly in the Internet settings panel to ensure consistent upstream resolution across all devices.
DNSSEC Validation
Quad9 (9.9.9.9) validates DNSSEC signatures and drops responses with broken chains. If switching to Quad9 causes specific domains to stop resolving, those domains have misconfigured DNSSEC records — typically a stale DS record at the registrar or an expired DNSKEY. Switching back to Cloudflare or Google restores resolution, but the broken chain is the domain owner's problem to fix. See RFC 4035 for the full DNSSEC validation specification.
Confirming the Fix Worked
- Cloudflare whoami (most reliable): run
dig @192.168.0.1 whoami.cloudflare.com TXT +shortfrom any LAN device. The result should be your public WAN IP, confirming Cloudflare received the forwarded query from your router. - DNS leak test: visit dnsleaktest.com and run the extended test. Resolver hostnames in the results should match your chosen provider (e.g., 1dot1dot1dot1.cloudflare-dns.com), not your ISP's resolver hostname.
- Tether settings confirmation: re-open Advanced → Network → Internet in Tether. The DNS fields should display the IPs you entered, not Dynamically from ISP.
Preventing Accidental Resets
- Export a config backup: web admin → Advanced → System → Backup & Restore → Backup. The .bin file restores all settings including DNS and WAN configuration after a factory reset.
- Document WAN type and DNS IPs in a password manager entry alongside the admin credentials — easy to lose track of after ISP-mandated power cycles or hardware swaps.
- For business networks: centralise DNS distribution in a dedicated DHCP server such as pfSense, Windows Server DHCP, or a Unifi controller rather than relying on the TP-Link router. This survives router hardware replacements and gives you a single authoritative management point for all network segments.
- OpenWrt users: back up
/etc/config/networkand/etc/config/dhcp. These files contain your DNS configuration in full and survive firmware reflashes when you preserve the /overlay partition.