Your Cogeco internet is up but certain sites crawl, refuse to load, or work fine on mobile data and fail on home Wi-Fi. Nine times out of ten, the culprit is DNS. Knowing Cogeco's DNS server addresses, understanding when their resolvers misbehave, and knowing exactly how to verify or replace them will save you hours of head-scratching.

Cogeco DNS Server IP Addresses

Cogeco auto-assigns DNS resolvers via DHCP, so most subscribers never see these IPs. You need them for manual device configuration, router lockdown, or targeted troubleshooting.

Ontario — Cogeco Connexion

Primary DNS: 24.156.128.3 Secondary DNS: 24.156.128.4

Quebec and Legacy Network Segments

Primary DNS: 66.39.166.178 Secondary DNS: 66.39.166.12

Cogeco does not publish an official, static DNS resolver list in its support documentation. These addresses are consistent across their HFC network but DHCP assignments can vary by node and region. Always confirm what is actually being pushed to your device — the verification commands below take 30 seconds and show exactly what Cogeco is handing out on your specific connection.

💡 Not sure which DNS servers your machine is actually using right now? Our DNS Propagation Checker shows how lookups from your IP resolve in real time — useful for confirming a resolver change took effect.

Finding Your Current Cogeco DNS Assignment

Before changing anything, confirm what Cogeco is actually delivering over DHCP. If you skip this step you risk fixing a problem you do not have.

Windows

ipconfig /all

Find your active adapter — typically Ethernet adapter Ethernet or Wireless LAN adapter Wi-Fi. The DNS Servers line shows what is in use.

macOS (Ventura, Sonoma, Sequoia)

scutil --dns

Look for nameserver[0] and nameserver[1] under your active interface. GUI path: System Settings > Network > Wi-Fi (or Ethernet) > Details > DNS.

Linux (systemd-resolved)

resolvectl status

For older distributions that predate systemd-resolved:

cat /etc/resolv.conf

iOS

Settings > Wi-Fi > tap your network name > (i) > Configure DNS. "Automatic" means Cogeco's DHCP is controlling it.

Android

Settings > Network & internet > Wi-Fi > tap your network > edit (pencil) > Advanced options > IP settings: Static. Android only exposes DNS fields in static IP mode. Separately, check Settings > Network & internet > Advanced > Private DNS — if a hostname is entered there it overrides your DHCP-assigned servers system-wide.

Testing Cogeco DNS Response Time

A healthy ISP resolver inside its own network should respond in under 30 ms. Anything consistently above 80 ms during off-peak hours points to a resolver problem worth addressing.

Linux and macOS

dig @24.156.128.3 google.com +stats | grep "Query time"

Run it three to five times. The first query may be slower due to the resolver's own cache miss. The second and third results give a reliable baseline.

Windows (Command Prompt)

nslookup google.com 24.156.128.3 nslookup google.com 24.156.128.4

Both should return IPs within a second. A timeout on either server means it is down — check Cogeco's service status page and temporarily switch to an alternate resolver.

Batch Test Both Resolvers on Linux and macOS

for ns in 24.156.128.3 24.156.128.4; do echo -n "Server $ns: " dig @$ns cloudflare.com +noall +stats 2>&1 | grep "Query time" done

Why Cogeco DNS Fails — Root Causes Ranked by Frequency

When Cogeco DNS stops working or slows to a crawl, these are the real causes in order of how often they appear in practice:

  1. Resolver overload during peak hours (6–10 PM EST) — Cogeco's HFC network concentrates subscribers, and shared recursive resolvers handle enormous concurrent query loads on weekday evenings. Query times can triple from off-peak baselines.
  2. Stale router DNS cache — Your router caches DNS responses independently of your devices. After a domain's IP changes, your router may serve the old address for hours. A 30-second power cycle clears it.
  3. Cogeco infrastructure maintenance — Cogeco rotates or replaces resolver infrastructure without widely publicizing it. If both primary and secondary go silent overnight and return by morning, maintenance is the most likely cause.
  4. DNSSEC validation failures — Cogeco's resolvers validate DNSSEC signatures. A domain with a broken or expired DNSSEC chain returns SERVFAIL from Cogeco's resolvers but resolves fine on non-validating resolvers. This looks identical to an intentional block from the subscriber's perspective and is frequently mislabeled as a Cogeco outage.
  5. DNS hijacking and NXDOMAIN redirection — Some older Cogeco modem firmware redirected failed lookups to a Cogeco search portal instead of returning a proper NXDOMAIN. This mostly stopped around 2019 but unreplaced legacy equipment may still do it.
  6. IPv6 resolver misconfiguration — If your router has an IPv6 WAN connection but no IPv6 DNS server configured, dual-stack lookups stall silently, making DNS appear intermittently slow even when IPv4 resolves fine.

Manually Configuring Cogeco DNS on Each Platform

Windows 10 and Windows 11

Navigate to Settings > Network & Internet > Wi-Fi (or Ethernet) > Hardware properties > DNS server assignment > Edit > Manual.

Preferred DNS: 24.156.128.3 Alternate DNS: 24.156.128.4

After saving, flush the resolver cache immediately:

ipconfig /flushdns

For dual-stack systems on IPv6, add Cogeco's IPv6 resolver if your DHCP lease includes one, or use Cloudflare's 2606:4700:4700::1111 as the IPv6 DNS entry.

macOS (Ventura, Sonoma, Sequoia)

System Settings > Network > [your connection] > Details > DNS. Click + to add each server. Remove any ISP-injected or unrecognized entries. After saving:

sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

Ubuntu and Debian (systemd-resolved)

sudo nano /etc/systemd/resolved.conf

Under the [Resolve] section:

[Resolve] DNS=24.156.128.3 24.156.128.4 FallbackDNS=1.1.1.1 8.8.8.8
sudo systemctl restart systemd-resolved resolvectl status

iOS 16 and Later

Settings > Wi-Fi > tap your network > Configure DNS > Manual > Add Server. Enter 24.156.128.3 then 24.156.128.4. This is per-network — repeat it for each Wi-Fi network you use regularly.

Android 9 and Later

For per-network static DNS: long-press your Wi-Fi network > Modify network > Advanced options > IP settings: Static, then fill DNS 1 and DNS 2. For encrypted system-wide DNS, see the DoH and DoT section below — Cogeco does not expose a DoT hostname, so Private DNS requires a third-party provider.

Configuring DNS at the Router Level

Router-level DNS is the right approach for home networks. Every client inherits it automatically, including smart TVs, game consoles, and IoT devices you cannot easily reconfigure. Cogeco-supplied modems — Hitron CODA-4582, CODA-4680, and Arris TG2492 models — typically sit at http://192.168.100.1. For third-party routers:

  • Asus (asusrouter.com): Advanced Settings > WAN > WAN DNS Setting — disable "Connect to DNS Server automatically," enter the IPs.
  • TP-Link (tplinkwifi.net): Advanced > Network > Internet — set DNS Address to Manual, fill Primary and Secondary DNS.
  • Netgear (routerlogin.net): Advanced > Setup > Internet Setup > Domain Name Server (DNS) Address — uncheck "Get automatically from ISP."
  • Linksys (linksyssmartwifi.com): Connectivity > Internet Settings > IPv4 > Static DNS 1 / Static DNS 2.
  • D-Link (192.168.0.1): Setup > Internet > DNS Settings.
  • Eero (app only): Home > Settings > Network Settings > Advanced > DNS.
  • Orbi (orbilogin.com): Advanced > Setup > Internet Setup — set DNS Servers manually.
  • Mi Router / Xiaomi (miwifi.com): Common Settings > Dial-up / WAN — enter DNS manually.

OpenWrt: Navigate to Network > Interfaces > WAN > Edit > Advanced Settings. Uncheck "Use DNS servers advertised by peer" and add custom DNS. Or edit /etc/config/network directly, adding option dns '24.156.128.3 24.156.128.4' to the WAN interface stanza, then run service network restart.

DD-WRT: Setup > Basic Setup > Network Address Server Settings (DHCP) — set Static DNS 1 and Static DNS 2.

When to Replace Cogeco DNS Entirely

Cogeco's resolvers handle routine browsing under normal load. Switch to a public resolver when you see any of these conditions:

  • Query times consistently above 50 ms during off-peak hours (11 PM–7 AM)
  • NXDOMAIN or SERVFAIL for domains that resolve fine with dig @8.8.8.8
  • Sites load on mobile data or a VPN but fail on the home connection
  • You need DNS-level blocking of malware and phishing domains
  • You want encrypted DNS — Cogeco's resolvers do not support DoH or DoT
# Cloudflare — fastest globally in independent benchmarks Primary: 1.1.1.1 Secondary: 1.0.0.1 # Google Public DNS — reliable anycast coverage, strong Canadian peering Primary: 8.8.8.8 Secondary: 8.8.4.4 # Quad9 — DNSSEC-validating, blocks known malicious domains Primary: 9.9.9.9 Secondary: 149.112.112.112

Google's Public DNS documentation explains how these resolvers handle caching, privacy, and DNSSEC in detail: developers.google.com/speed/public-dns.

💡 After switching resolvers, verify the change with our DNS Lookup tool. Enter a domain and confirm it returns the correct IP. If the lookup is right but the site still fails, the problem is TLS or routing — not DNS.

DNSSEC Validation on Cogeco Resolvers

As of 2026, Cogeco validates DNSSEC on its recursive resolvers. This prevents cache poisoning attacks but introduces a real-world gotcha: any domain with a broken, expired, or mismatched DNSSEC chain returns SERVFAIL from Cogeco's resolvers while resolving without error on non-validating resolvers. From a subscriber's view it looks like Cogeco is blocking the site.

Test whether DNSSEC validation is active:

# Should return SERVFAIL if DNSSEC validation is working: dig @24.156.128.3 dnssec-failed.org A # Should resolve normally: dig @24.156.128.3 google.com A

If a site resolves via dig @8.8.8.8 but returns SERVFAIL on Cogeco's resolver, the domain's DNSSEC records are broken at the registrar or authoritative DNS level. That is the domain owner's problem to fix, not Cogeco's. Send them the dig output showing the SERVFAIL and ask them to check their DS and RRSIG records.

IPv6 DNS on Cogeco in 2026

Cogeco has deployed IPv6 across most of its HFC network. If your router shows a global 2607:... prefix on its WAN interface, it is running dual-stack. Cogeco distributes IPv6 DNS servers via DHCPv6. Verify what you are receiving:

# Linux resolvectl status | grep "DNS Servers" # macOS scutil --dns | grep nameserver

If your router gets an IPv6 WAN address but no IPv6 DNS server, dual-stack lookups stall while waiting for AAAA queries to time out before falling back to IPv4. This appears as random slow DNS that is difficult to diagnose. The fix: add an explicit IPv6 DNS server in your router's WAN configuration. Cloudflare's 2606:4700:4700::1111 and 2606:4700:4700::1001 are reliable choices if Cogeco's DHCPv6 is not delivering IPv6 resolver addresses.

DNS over HTTPS and DNS over TLS on a Cogeco Connection

Cogeco's resolvers do not expose a DoH endpoint on port 443 or a DoT endpoint on port 853. Standard queries to their servers travel unencrypted on UDP port 53. If privacy or eavesdropping resistance matters to you, switch to a third-party resolver that supports encrypted DNS:

  • Windows 11: Settings > Network & Internet > [adapter] > DNS server assignment > Edit — set servers to 1.1.1.1 and 8.8.8.8, then set the DNS over HTTPS dropdown to On (automatic template) for each entry.
  • Android 9+: Settings > Network & internet > Advanced > Private DNS > enter dns.google or 1dot1dot1dot1.cloudflare-dns.com. This overrides all per-network DNS settings system-wide.
  • Firefox: Settings > General > Network Settings > Enable DNS over HTTPS — select Cloudflare or enter a custom provider URL.
  • macOS and iOS: Enable DoH or DoT system-wide via a signed .mobileconfig profile. Apple's built-in network UI does not expose a consumer DoH toggle as of 2026; a configuration profile is required for system-level encrypted DNS.

Common Misdiagnoses

"Cogeco DNS is broken" — actually the router cache

A router running for months builds a large DNS cache. After a domain migrates to a new host, your router may serve the old IP for hours or even days depending on the original TTL. Power-cycle the router — hold the power button off for 30 seconds — before drawing any conclusions about Cogeco's resolvers. This single step resolves a significant fraction of reported DNS problems.

"Cogeco is blocking this site" — actually a DNSSEC failure

NXDOMAIN or SERVFAIL from a DNSSEC validation failure is visually indistinguishable from an intentional ISP block. Run dig @8.8.8.8 yourdomain.com. If it resolves there but SERVFAIL on Cogeco's resolver, DNSSEC is misconfigured at the registrar or DNS provider level. Cogeco is not blocking the domain.

"DNS is slow" — actually the first query after a DHCP renewal

The first DNS lookup after a WAN reconnect can be slow while the router re-establishes its uplink. Run five consecutive queries and look at results three through five, not the first outlier.

"Switching to 8.8.8.8 fixed it" — actually the cache flush did

Reconfiguring DNS almost always triggers a cache flush. If stale cache was the real problem, the resolver change gets unearned credit. Run ipconfig /flushdns on Windows or sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder on macOS first, before permanently switching resolvers.

Confirming the Fix

After any DNS change, confirm the new servers are active and returning correct results:

Windows

ipconfig /flushdns ipconfig /all nslookup google.com

The Server: line in nslookup output must show the resolver you configured, not your router's LAN IP — which would indicate the router is still intercepting and forwarding queries.

macOS

sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder scutil --dns dig google.com

Linux

sudo systemctl restart systemd-resolved resolvectl flush-caches resolvectl query google.com

The output shows which server answered. Confirm it matches your configured resolver and not an intercepting proxy or VPN DNS override.

Preventing DNS Problems from Recurring

  • Set DNS at the router level, not per-device. One change covers the entire network, including devices you cannot configure individually.
  • Use two servers from different providers as primary and secondary — for example, Cogeco's 24.156.128.3 as primary and Cloudflare's 1.1.1.1 as secondary. If Cogeco's resolver goes down, Cloudflare silently catches the fallback without any user impact.
  • Monitor resolver availability — a tool like Uptime Kuma can probe port 53 on 24.156.128.3 every 60 seconds and alert you the moment it stops responding. Knowing immediately beats finding out during a client call.
  • Document your DNS settings — when you swap routers or change ISPs, having the exact server IPs already written down avoids repeating this troubleshooting session from scratch.