Bell Canada's Home Hub routers ship with Bell's own upstream DNS resolvers locked in by default. For most subscribers that's invisible — but if you want faster resolution, privacy-respecting lookups, DNSSEC enforcement, or DNS-based content filtering across every device on your home network, you need to override those defaults yourself. This guide covers every Home Hub model still active in 2026, with the exact firmware menu paths Bell doesn't document clearly in its own support materials.

Why Bell's Default DNS Falls Short

Bell's resolvers serve the functional minimum. They resolve hostnames and return answers, but they also route your DNS queries through Bell's own infrastructure (associating lookup patterns with your account), implement CRTC-mandated domain blocks, and have historically shown inconsistent DNSSEC validation — some signed records validate correctly, others fail silently. They also offer no support for DNS-over-HTTPS or DNS-over-TLS on the upstream resolver path, meaning every query leaves your router unencrypted over UDP port 53.

Replacing Bell's resolvers with Cloudflare (1.1.1.1), Google (8.8.8.8), or Quad9 (9.9.9.9) addresses all of these issues. Canadian latency is a non-issue: both Cloudflare and Google operate anycast nodes in Toronto and Vancouver, typically delivering query responses in under 5ms — significantly faster than Bell's resolvers routed through their backbone.

Which Bell Home Hub Do You Have?

The model number is on the sticker on the router's bottom or back panel. Bell has deployed four generations under the Home Hub brand, all sharing the same default admin URL:

  • Home Hub 1000 — ADSL2+/VDSL modem-router combo, still active in non-Fibe DSL areas. Oldest firmware, most limited DNS options.
  • Home Hub 2000 — dual-band 802.11n/ac WiFi 5, deployed on early Fibe installs before 2019. DNS configuration available but not prominently surfaced.
  • Home Hub 3000 — the dominant deployed model as of 2026. GPON or MoCA coax WAN input, 802.11ac WiFi 5. Most users reading this guide land here.
  • Home Hub 4000 — WiFi 6 (802.11ax), deployed on Gigabit Fibe plans from 2022 onward. Redesigned web interface with native IPv6 DNS fields in the same panel as IPv4.

The admin interface URL is identical across all models: http://192.168.2.1. Bell uses the 192.168.2.0/24 subnet by default — not the 192.168.1.x or 192.168.0.x range found on most other consumer routers.

WAN DNS vs DHCP DNS: The Distinction That Trips Everyone Up

Bell's Home Hub has two separate DNS configuration points, and mixing them up explains most failed attempts at this change:

  • WAN DNS — the upstream resolver the router itself queries. Changing this affects the router's own resolution. Devices that receive 192.168.2.1 via DHCP still talk to the router first; the router then queries your new WAN DNS upstream.
  • DHCP DNS — the resolver address handed out to client devices when they join via DHCP. If this stays set to 192.168.2.1, devices query the router as a forwarder. If you change it to 1.1.1.1 directly, devices bypass the router resolver entirely and speak to Cloudflare themselves.

For most users, changing both gives the cleanest result. Changing only WAN DNS means all client DNS still passes through the router's resolver layer. Changing only DHCP DNS means the router itself still uses Bell's resolvers for its own lookups (NTP, firmware update checks, etc.). The sections below cover both paths.

Bell Home Hub 3000: Step-by-Step

The HH3000 buries the DNS setting under WAN configuration — not under LAN or DHCP where you might expect it.

  1. Open http://192.168.2.1 in any browser on the network.
  2. Log in. Username is admin. The password is the 10–12 character string printed on the sticker on the router's base, labeled "Admin Password" — it is not your Wi-Fi password.
  3. Click the Advanced tab in the top navigation bar (not the Home tile).
  4. In the left sidebar, select WAN.
  5. You'll see a table of WAN connections. Your active connection is listed — typically labeled "Internet" with status "Connected." Click Edit next to it.
  6. Scroll down to the DNS Settings section. The default reads "Obtain DNS server address automatically."
  7. Select Use the following DNS server addresses.
  8. Enter your primary DNS in the first field and secondary DNS in the second.
  9. Click Apply. The router applies the change without a full reboot — your internet connection stays live.
💡 After a DNS change, propagation to external resolvers is a separate concern. Use the DNS Propagation Checker to test how global resolvers are answering for any domain you're troubleshooting.

Bell Home Hub 4000: Step-by-Step

The HH4000 ships with a redesigned interface. The steps are similar but the menu labels shift:

  1. Navigate to http://192.168.2.1 and log in with admin credentials.
  2. Click Advanced Setup in the top navigation bar.
  3. Select WAN Configuration from the left sidebar.
  4. Find your active WAN connection entry (showing your connection type and "Connected" status).
  5. Click the edit icon next to the DNS row.
  6. Switch the DNS mode from Dynamic (DHCP) to Static.
  7. Enter your primary and secondary IPv4 DNS addresses.
  8. Scroll down the same panel to the IPv6 DNS fields — fill these in too (covered in the section below).
  9. Click Save. The HH4000 may drop the WAN connection for 5–10 seconds while applying.

Home Hub 1000 and 2000: Older Firmware Path

These models run a legacy interface with a flat menu structure:

  1. Navigate to http://192.168.2.1 and log in.
  2. Go to Settings → Internet → Connection Type (HH2000) or Setup → WAN Settings (HH1000).
  3. Under the active connection, locate the DNS fields labeled DNS 1 and DNS 2.
  4. Uncheck "Automatically obtain DNS" if it appears, then enter your addresses.
  5. Click Save.

HH1000 and HH2000 firmware varies by Bell region and deployment year. If the path above doesn't match what you see, look under a Connection or Broadband tab — the DNS field is always adjacent to the WAN IP configuration, never inside the Wi-Fi section.

Pushing Custom DNS to All Devices via DHCP

To ensure every device on your network — smart TVs, IoT devices, guest phones — resolves through your chosen DNS rather than Bell, update the DHCP server configuration:

  1. In the Advanced menu, navigate to LAN → DHCP Server (HH3000) or Advanced Setup → LAN Configuration (HH4000).
  2. Find the DNS Server or Primary DNS field in the DHCP options section.
  3. Change the value from 192.168.2.1 to your chosen DNS server address directly (e.g., 1.1.1.1).
  4. Enter a secondary DNS in the corresponding field (e.g., 1.0.0.1).
  5. Click Apply.

Existing devices won't switch immediately — they hold their current DHCP lease until it expires (typically 24 hours on Bell HH3000 defaults). To force an immediate switch on a Windows machine: run ipconfig /release followed by ipconfig /renew. On macOS or Linux, toggle Wi-Fi off and back on. On iOS or Android, forget the Wi-Fi network and rejoin.

Setting IPv6 DNS — Do Not Skip This in 2026

Bell's Fibe network is dual-stack. Your connection carries both IPv4 and IPv6 simultaneously, and a modern smartphone or laptop will prefer AAAA records (IPv6) over A records (IPv4) when both are available. If you only configure IPv4 DNS servers, those devices still send AAAA queries to Bell's IPv6 resolvers — typically in the 2607:f798:: range. On a device doing significant HTTPS traffic, that can mean the majority of your DNS queries are still hitting Bell.

IPv6 DNS addresses for the major public resolvers:

  • Cloudflare: 2606:4700:4700::1111 / 2606:4700:4700::1001
  • Google: 2001:4860:4860::8888 / 2001:4860:4860::8844
  • Quad9: 2620:fe::fe / 2620:fe::9

On the HH4000, these fields appear directly below the IPv4 fields in the same WAN DNS edit panel. On the HH3000, navigate to Advanced → WAN → IPv6 as a separate sub-tab to find the IPv6 DNS Server fields.

Verifying the Change with CLI Commands

Give DHCP clients 2–3 minutes to renew their leases, then verify the change is in effect from the command line.

Linux

# Check which DNS your system resolver is using resolvectl status # Run a test query and confirm which server answered dig google.com A # Query a specific nameserver directly to compare round-trip time dig @1.1.1.1 google.com A +stats | grep -E "SERVER:|Query time"

macOS

# Show DNS servers currently in use scutil --dns | grep nameserver # Flush the DNS cache after changing sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder # Test and confirm the responding server nslookup google.com

Windows

# Show DNS servers assigned via DHCP ipconfig /all | findstr /i "DNS Servers" # Flush the local DNS resolver cache ipconfig /flushdns # Test resolution via a specific server nslookup google.com 1.1.1.1

For an external view of how a domain resolves from outside your network entirely, the DNS Lookup tool lets you run queries against specific nameservers from multiple global locations and compare response times between resolvers.

iOS and Android Device-Level Overrides

iOS (iPhone/iPad): Go to Settings → Wi-Fi → tap the (i) next to your network → Configure DNS → Manual. Delete the existing server entry and add 1.1.1.1. This overrides whatever the router hands out via DHCP and survives across router resets.

Android 9+ (Pixel, stock Android): Go to Settings → Network & internet → Advanced → Private DNS. Enter a DoT hostname — Cloudflare uses 1dot1dot1dot1.cloudflare-dns.com; Google uses dns.google. This encrypts DNS traffic over TLS port 853 and bypasses any router-level DNS assignment entirely. On Samsung One UI: Settings → Connections → More connection settings → Private DNS. Note that enabling Private DNS on Android means your custom router DNS settings have no effect on that device.

DNSSEC and DoH in 2026

Bell Home Hub routers — all four models — do not natively support DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) in their stock firmware as of mid-2026. DNS queries from the router to the upstream resolver travel unencrypted over UDP port 53. The practical solution for encrypted DNS transport is device-level enforcement rather than router-level:

  • Android: Private DNS setting (DoT) — covers all traffic from that device regardless of network
  • iOS: DNS configuration profile installed via Settings → VPN & Device Management — enforces DoH system-wide
  • Windows 11: Settings → Network & internet → Wi-Fi → Hardware properties → DNS server assignment → Edit → enable DNS over HTTPS
  • macOS Ventura+: Requires a configuration profile; native DoH is not exposed in System Settings UI

If you run a secondary router behind the Home Hub (with the HH in bridge mode), OpenWrt supports Stubby (DoT forwarder) and cloudflared (DoH proxy) as installable packages. DD-WRT builds from 2024 onward include native DoT support under Services → DNS.

DNSSEC validation is worth noting separately. Cloudflare and Google both perform full DNSSEC validation and return SERVFAIL for zones with broken signatures. Bell's resolvers have historically passed broken DNSSEC records silently. If switching DNS makes a specific site unreachable, check whether that domain's zone has a DNSSEC misconfiguration — the issue predates your change, Bell was just masking it.

Common Misdiagnoses

Changed router DNS but devices still resolve through Bell

Cause: DHCP lease has not expired. The router is still handing out 192.168.2.1 as DNS to your clients, and your change was to WAN DNS only. Update the DHCP DNS setting as described above, then force a lease renewal per device. Running ipconfig /all on Windows will confirm what DNS your machine actually received from DHCP.

DNS settings reset after a reboot or maintenance window

Bell pushes OTA firmware to Home Hub units without requiring user consent — this is documented behavior. Major firmware version updates sometimes reset WAN DNS back to automatic. After any Bell maintenance notification or unexpected reboot, re-check under Advanced → WAN. On the HH4000, Advanced → Device → Automatic Updates allows deferring non-security updates, though Bell can still push critical patches regardless.

HTTPS sites fail after DNS change, but DNS queries succeed

Not a DNS problem. This points to an MTU or MSS mismatch. Bell Fibe PPPoE operates with an MTU of 1492 bytes. If your device or a secondary router isn't clamping TCP MSS to 1452, large TLS handshakes stall while small DNS UDP packets get through fine. Fix by setting WAN MTU to 1492 on whatever device connects to Bell's PPPoE session, or enable MSS clamping in your secondary router's firewall settings.

Content filtering DNS stops blocking known bad sites

If a device has Private DNS (Android) or a DNS configuration profile (iOS) installed, it bypasses your router-level DNS completely. The device-level setting wins. Audit per-device DNS settings before assuming router-level filtering is broken.

Preventing Reversion and Confirming the Fix Stays

  • After setting DNS, note the firmware version under Advanced → Device → About. Re-verify DNS settings after any Bell maintenance notification or firmware version change.
  • For maximum resilience, configure DHCP to push 1.1.1.1 directly to clients — that way, even if the WAN DNS reverts to automatic after a firmware update, client devices still have 1.1.1.1 in their active lease and continue resolving through Cloudflare.
  • Run a periodic verification: nslookup google.com 192.168.2.1 from a device on your network. The response will include the server that answered — if it shows Bell's resolver IP instead of your configured upstream, the WAN DNS has reverted.
  • Android Private DNS and iOS DNS profiles function as a permanent device-level backstop regardless of what the router does — worth enabling on primary devices in addition to the router change.

For the formal DNS specification covering how resolvers handle queries end-to-end, RFC 1035 is the foundational standard. For a practical explanation of the full resolver chain from stub resolver to authoritative nameserver, Cloudflare's DNS learning center covers it without requiring a deep networking background.