TekSavvy DNS Servers Setup, IPs, and Troubleshooting for Canadian Users

TekSavvy assigns DNS resolvers automatically via DHCP, but those defaults don't always give you the fastest or most reliable resolution — and since TekSavvy's DNS is subject to Canadian court-ordered blocking rules, some subscribers hit dead-ends on sites that resolve fine on mobile data. Whether you're confirming TekSavvy's own server IPs, pinning them into a static config, or switching to a faster alternative, this guide covers every platform with exact steps and verification commands.

TekSavvy's Default DNS Server IPs

TekSavvy operates two primary recursive resolvers for residential and small-business subscribers on both DSL (Bell infrastructure) and cable (Rogers/Cogeco infrastructure) connections. These are the addresses pushed to your router via DHCP:

• Primary DNS: 205.210.42.205
• Secondary DNS: 205.210.42.206

If your device shows a different DNS IP (commonly 192.168.100.1 or 192.168.0.1), it's hitting your modem's built-in DNS proxy — the modem forwards queries upstream to TekSavvy's resolvers anyway. This distinction matters when you're troubleshooting or setting static DNS: use the actual upstream IPs, not the modem's LAN address. Confirm what's really answering your queries before assuming there's a problem:

Why TekSavvy DNS Causes Problems (Ranked by Frequency)

Most subscriber complaints trace back to one of these root causes, ordered by how commonly they actually appear:

1. CRTC-Ordered Domain Blocking

Since 2018, Canadian courts have ordered ISPs including TekSavvy to block specific domains at the DNS layer. TekSavvy's resolvers return NXDOMAIN or redirect blocked queries to a block-page IP for affected domains. This is a legal obligation, not a misconfiguration. The clearest symptom: a site loads fine on your phone's LTE but fails on your TekSavvy Wi-Fi connection. Switching to a resolver outside Canadian ISP infrastructure — Cloudflare 1.1.1.1, Google 8.8.8.8 — bypasses the block entirely, as does DNS-over-HTTPS, which ISPs cannot intercept transparently.

2. Peak-Hour Latency Spikes

TekSavvy's resolvers share infrastructure with general subscriber traffic. Between 6 PM and 10 PM EST, query latency can climb from a baseline of 10–15 ms to 150 ms or higher on congested cable segments. This is noticeable in gaming sessions, VoIP calls, and any application that issues DNS lookups per request. Cloudflare's 1.1.1.1 consistently benchmarks under 15 ms from most Canadian metro areas regardless of time of day.

3. Stale Negative Cache (NXDOMAIN Holdover)

If TekSavvy's resolver cached a failed lookup during a domain transition or DNS outage, your client inherits that negative TTL — typically 15 to 30 minutes — and every query returns NXDOMAIN until it expires. You cannot flush TekSavvy's upstream cache from the client side. The fastest workaround is switching temporarily to 8.8.8.8, which has its own independent cache and almost certainly has a valid positive answer already queued.

4. IPv6 Resolver Misconfiguration

TekSavvy supports IPv6 natively on most cable accounts (a /64 prefix appears on your router's WAN page when enabled). Their IPv6 resolver addresses are sometimes not pushed correctly via DHCPv6 depending on the modem firmware version. The symptom is selective: IPv4-only sites load instantly, but dual-stack sites (Google, Cloudflare, most CDNs) take 3–5 seconds as the OS tries AAAA first, times out waiting for an IPv6 resolver response, then falls back to A records.

5. DNS Leaks on VPN Connections

If you run a VPN over TekSavvy, the VPN client installs its own resolver — but if the tunnel drops or the client fails to set the split-DNS rules correctly, queries fall back silently to TekSavvy's resolvers. Check for leaks at dnsleaktest.com with the tunnel both up and down. A leak means your VPN's "kill switch" or DNS binding is not working.

Configuring TekSavvy DNS on Every Platform

Setting DNS at the router covers every device on your LAN automatically and survives device resets. Per-device settings make more sense for laptops that roam between networks.

Router-Level Setup (All Brands)

Log into your router's admin interface and find DNS settings under WAN configuration or the DHCP server section. Admin URL and menu path by brand:

• Hitron (192.168.0.1) — Basic → WAN → DNS Server → uncheck Auto → enter IPs. TekSavvy's supplied Hitron CGNM-2250 and CGN3 both use this path.
• TP-Link (tplinkwifi.net or 192.168.0.1) — Advanced → Network → Internet → Primary DNS / Secondary DNS
• ASUS (asusrouter.com or 192.168.1.1) — WAN → Internet Connection → WAN DNS Setting → disable "Connect to DNS Server automatically"
• NETGEAR (routerlogin.net or 192.168.1.1) — Basic → Internet → Use These DNS Servers
• Linksys (linksyssmartwifi.com or 192.168.1.1) — Connectivity → Internet Settings → Static DNS
• Orbi (orbilogin.com or 192.168.1.1) — Advanced → Setup → Internet Setup → Domain Name Server (DNS) Address
• Xiaomi/Mi (miwifi.com or 192.168.31.1) — Settings → Network → DNS

On OpenWrt, set upstream resolvers via UCI. On DD-WRT, the path is Setup → Basic Setup → Network Address Server Settings (DHCP):

Windows 11 / Windows 10

1. Open Settings → Network & Internet → Wi-Fi (or Ethernet) → Hardware properties
2. Under DNS server assignment, click Edit
3. Switch to Manual, toggle IPv4 on
4. Preferred: 205.210.42.205 — Alternate: 205.210.42.206
5. Save, then flush the local resolver cache

macOS (Sonoma / Ventura)

1. System Settings → Network → [your connection] → Details → DNS
2. Click + and add 205.210.42.205, then add 205.210.42.206
3. Click OK then Apply

Linux (Ubuntu / Debian — systemd-resolved)

iOS 17 / iPadOS

1. Settings → Wi-Fi → tap (i) next to your network → Configure DNS → Manual
2. Delete any existing entries, tap Add Server
3. Enter 205.210.42.205 then add a second: 205.210.42.206
4. Tap Save

Android 13 / 14

For per-network static DNS: Settings → Wi-Fi → long-press your network → Modify Network → Advanced Options → IP Settings: Static, then fill DNS1 and DNS2. For a system-wide encrypted option, use Private DNS: Settings → Network & Internet → Private DNS → Private DNS provider hostname. TekSavvy does not publish a DoT hostname, so enter a public option like 1dot1dot1dot1.cloudflare-dns.com if encrypted resolution is the goal.

Confirming the Fix Worked

TekSavvy's resolvers have supported DNSSEC validation since 2020. If you see the AD (Authenticated Data) flag set in dig output, the resolver is performing cryptographic validation of signed zones. Per RFC 4033, the AD flag only appears when the full chain of trust from root to the queried zone validates cleanly.

Faster and More Private Alternatives

If TekSavvy's resolvers are consistently slow or you need to work around CRTC blocking, these are the realistic choices for Canadian subscribers:

• Cloudflare 1.1.1.1 / 1.0.0.1 — Fastest from BC and Ontario in independent benchmarks; privacy-first logging policy; full DoH and DoT support. Does not enforce CRTC blocking orders.
• Google 8.8.8.8 / 8.8.4.4 — Reliable global anycast; good fallback when Cloudflare has a regional event. See Google Public DNS documentation for privacy and logging details.
• Quad9 9.9.9.9 / 149.112.112.112 — Swiss-based, DNSSEC-validating, blocks malware domains using threat intelligence feeds. Strong privacy posture, solid Canadian peering.
• CIRA Canadian Shield 149.112.121.10 / 149.112.122.10 — Operated by the Canadian Internet Registration Authority; data stays in Canada; Protected mode blocks malware and phishing. Best choice if domestic data residency matters for your use case.

2026 Update: DoH, DoT, and IPv6 on TekSavvy

As of mid-2026, TekSavvy does not publish a DNS-over-HTTPS or DNS-over-TLS endpoint for their own resolvers. This is a meaningful gap: without encrypted DNS, your TekSavvy connection can intercept and log all plaintext DNS queries on port 53, which is how court-ordered DNS blocking is implemented in the first place.

Your options for encrypted resolution while on TekSavvy:

• Browser-level DoH — Chrome, Firefox, and Edge all support DoH natively. In Firefox: Settings → Privacy & Security → DNS over HTTPS → Max Protection → choose Cloudflare or a custom provider. This encrypts browser DNS queries regardless of your OS resolver settings.
• OS-level DoH/DoT — Windows 11 supports DoH natively in Network Adapter settings (set the server IP and it auto-detects the DoH endpoint). macOS supports per-profile encrypted DNS via Configuration Profiles. Linux with systemd-resolved 247+ supports DoT via DNSOverTLS=yes in /etc/systemd/resolved.conf.
• Router firmware DoH — OpenWrt 23.x ships with https-dns-proxy; recent DD-WRT builds support stubby for DoT. Configure either to use CIRA Canadian Shield or Cloudflare as the upstream DoH endpoint and every device on your LAN inherits encrypted resolution automatically.

Dual-stack IPv6 subscribers should explicitly configure both their IPv4 and IPv6 DNS addresses. Use Cloudflare's 1.1.1.1 (IPv4) and 2606:4700:4700::1111 (IPv6) together, or TekSavvy's 205.210.42.205 (IPv4) alongside a verified IPv6 resolver. Leaving IPv6 DNS unconfigured while TekSavvy pushes a /64 prefix is the number-one cause of the 3–5 second AAAA timeout delay described earlier.

Common Misdiagnoses

• Blaming TekSavvy DNS for firewall blocks. Windows Defender Firewall or third-party AV suites blocking outbound port 53 produce identical symptoms to DNS server failure. Test with nslookup google.com 8.8.8.8 — if that also fails, port 53 is blocked locally, not at TekSavvy.
• Attributing slow browsing to DNS when it's network congestion. A 150 ms DNS query adds 150 ms to a single page load. If pages take 5–10 seconds, TCP handshake latency or slow origin servers are almost always the real bottleneck. Run mtr 8.8.8.8 and look for the hop where latency spikes.
• Using the modem's LAN IP as a static DNS server. Pinning 192.168.100.1 as your DNS entry means a modem reset or factory restore silently breaks your DNS config. Use the upstream resolver IPs (205.210.42.205/206) or a public resolver when setting static entries.
• Assuming the secondary server is optional. Without a secondary, every primary resolver timeout takes 30 seconds before the OS gives up. Always configure both slots.