Videotron subscribers in Quebec and Ontario sometimes hit a wall: pages time out, sites resolve slowly, or DNS lookups fail entirely while the internet connection itself is perfectly healthy. The culprit is usually Videotron's default DNS resolvers. Knowing the exact IP addresses, understanding what can go wrong with them, and knowing how to swap them out — at the device or router level — fixes most of these problems in under ten minutes.

Videotron's Default DNS Server IP Addresses

Videotron (Quebecor) operates two primary recursive resolvers for residential and business customers:

  • Primary DNS: 205.151.222.250
  • Secondary DNS: 205.151.254.250

These addresses are assigned automatically via DHCP when your modem connects to Videotron's network. Your device never requests them by name — the modem hands them to every device on the LAN. If you have never changed your DNS settings, these are almost certainly what you are using right now.

Videotron also provides IPv6 resolver addresses to customers with IPv6 connectivity, pushed automatically via DHCPv6. To confirm your exact IPv6 resolver, run the verification commands in the next section. This matters on dual-stack connections where intermittent failures may trace back specifically to IPv6 resolution rather than IPv4.

Why You Might Be Having DNS Problems on Videotron

DNS issues on Videotron connections fall into a few distinct categories, ranked by how often they occur in practice:

1. Resolver Latency Spikes

Videotron's DNS resolvers are located in Montreal. If you are in a region with congested routing toward Montreal — or querying during peak evening hours — resolver response times can climb to 80–200 ms per query. For browsing, every new domain requires at least one full round-trip to the resolver. Multiply that across the dozens of unique hostnames a modern webpage loads, and the cumulative delay becomes noticeable as sluggish first-load performance even on a fast connection with otherwise low ping to popular servers.

2. Partial or Total Resolver Outages

Like any infrastructure, Videotron's DNS has experienced outages. Because only one resolver typically responds at a time — the primary — failure on 205.151.222.250 can bring DNS down entirely for several seconds before the OS falls back to the secondary. The failover delay itself (typically 2–5 seconds per attempt) makes sites appear to hang rather than fail immediately, leading many users to conclude the issue is with the website or the internet connection overall rather than DNS specifically.

3. NXDOMAIN Hijacking

Videotron, like many ISPs, has historically redirected NXDOMAIN responses — replies for non-existent domains — to their own search or advertising page rather than returning a clean negative answer. This breaks applications that depend on NXDOMAIN replies to detect offline mode, test domain availability, or implement split-horizon resolution. If a DNS query for a nonexistent hostname returns an IP address instead of SERVFAIL or NXDOMAIN, this is what is happening.

4. Filtering and Blocked Domains

Videotron blocks certain domains at the DNS level in compliance with Canadian court orders — primarily around piracy enforcement. This is distinct from a resolver outage: the query returns immediately, but with a redirect IP rather than the real one. Applications that query these domains for legitimate technical reasons — VPN endpoint validation, CDN health monitors, security tooling — receive false results they cannot easily distinguish from a genuine DNS response.

5. IPv6 Resolver Failures on Dual-Stack Connections

On dual-stack connections, operating systems often send DNS queries over whichever protocol is preferred, which is frequently IPv6. If Videotron's IPv6 resolver is slower or temporarily unreachable while the IPv4 resolver responds normally, the result is intermittent resolution failures that appear random and resist obvious diagnosis. Hardcoding IPv4-only public DNS resolvers or disabling IPv6 DNS on the adapter typically resolves this class of problem immediately.

How to Check Which DNS Servers You Are Actually Using

Before changing anything, confirm what your system is actually querying. Use the DNS Lookup tool to test resolution from outside your network, then run local commands to check the resolver your device is configured to use.

Windows

ipconfig /all | findstr "DNS Servers"

For per-adapter detail in PowerShell:

Get-DnsClientServerAddress -AddressFamily IPv4

macOS

scutil --dns | grep nameserver

Linux (systemd-resolved)

resolvectl status # On systems without systemd-resolved: cat /etc/resolv.conf

Measure Actual Resolver Latency

Run this to compare Videotron's resolver directly against a public alternative:

dig @205.151.222.250 google.com | grep "Query time" dig @1.1.1.1 google.com | grep "Query time"

Run each command five or six times and average the results. A single measurement is meaningless given variable network queuing. If Videotron's resolver consistently returns 80–120 ms and Cloudflare returns 5–15 ms, the case for switching is straightforward.

Faster Alternatives to Videotron's DNS Servers

Three public resolvers consistently outperform ISP DNS in Canada, each with different trade-offs:

Cloudflare (1.1.1.1)

  • Primary: 1.1.1.1
  • Secondary: 1.0.0.1
  • IPv6: 2606:4700:4700::1111 and 2606:4700:4700::1001

Fastest resolver globally by independent benchmarks. Does not log queries beyond 25 hours. No NXDOMAIN hijacking. Supports DoH, DoT, and full DNSSEC validation. For most Videotron customers in Quebec, Cloudflare anycasts to a node in Montreal, making round-trip times competitive with Videotron's own resolvers even before factoring in Videotron's peak-hour congestion.

Google Public DNS (8.8.8.8)

  • Primary: 8.8.8.8
  • Secondary: 8.8.4.4
  • IPv6: 2001:4860:4860::8888 and 2001:4860:4860::8844

Highly reliable with strong anycast coverage in Canada. Google retains more query metadata than Cloudflare, but if you are already signed into Google services routinely, the incremental privacy exposure is marginal. Full technical details at Google's Public DNS documentation.

Quad9 (9.9.9.9)

  • Primary: 9.9.9.9
  • Secondary: 149.112.112.112
  • IPv6: 2620:fe::fe and 2620:fe::9

Non-profit operated. Blocks known malicious domains at the resolver level using curated threat intelligence feeds — a useful built-in protection layer for households or small offices where endpoint security filtering has value. Latency from Montreal is slightly higher than Cloudflare but still measurably better than Videotron's resolvers under load.

How to Change DNS Servers Step by Step

Windows 10 and Windows 11

  1. Open Settings → Network and Internet → Ethernet (or Wi-Fi if wireless)
  2. Click your active connection, then Edit next to DNS server assignment
  3. Switch the dropdown from Automatic (DHCP) to Manual
  4. Enable IPv4, enter your preferred and alternate DNS addresses
  5. Optionally set DNS over HTTPS to On (automatic template)
  6. Click Save

Command-line alternative (run Command Prompt as Administrator):

netsh interface ip set dns "Ethernet" static 1.1.1.1 netsh interface ip add dns "Ethernet" 1.0.0.1 index=2

Flush the resolver cache after making the change:

ipconfig /flushdns

macOS (Ventura, Sonoma, Sequoia)

  1. Open System Settings → Network
  2. Select your active interface (Wi-Fi or Ethernet) → Details
  3. Click the DNS tab
  4. Click + and add 1.1.1.1, then 1.0.0.1
  5. Click OK then Apply

Flush the DNS cache afterward:

sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

Linux (systemd-resolved and NetworkManager)

Via NetworkManager CLI:

nmcli connection modify "Wired connection 1" ipv4.dns "1.1.1.1 1.0.0.1" nmcli connection up "Wired connection 1"

Or edit /etc/systemd/resolved.conf directly:

[Resolve] DNS=1.1.1.1 1.0.0.1 FallbackDNS=9.9.9.9 DNSSEC=yes

Then restart the service:

sudo systemctl restart systemd-resolved

iOS (iPhone and iPad)

  1. Settings → Wi-Fi → tap the (i) next to your network name
  2. Scroll to Configure DNS → Manual
  3. Delete existing servers, tap Add Server, enter 1.1.1.1 then 1.0.0.1
  4. Tap Save

For system-wide DNS over HTTPS on iOS 14 and later, install a DNS configuration profile from Cloudflare rather than relying on the per-network setting, which only applies to the current Wi-Fi network and not to mobile data connections.

Android (9 and Later)

  1. Settings → Network and Internet → Private DNS
  2. Select Private DNS provider hostname
  3. Enter one.one.one.one for Cloudflare over DoT, or dns.google for Google over DoT
  4. Tap Save

Android's Private DNS mode uses DNS-over-TLS globally, overriding per-network DHCP assignments. This is the cleanest fix for Android without root — it applies to every Wi-Fi network and to mobile data automatically.

Changing DNS at the Router Level

Setting DNS on the router means every device on your network inherits the change automatically — phones, smart TVs, game consoles, and IoT devices — without touching each one individually. A router-level change takes one edit to fix the whole household.

Videotron typically supplies customers with a Hitron CODA-4582, CODA-4680, or an Arris or Technicolor gateway. The admin panel for Hitron units is at 192.168.0.1 or 192.168.100.1. Default credentials are printed on the sticker on the bottom of the device.

For a Hitron CODA-4582 or CODA-4680 (common Videotron-supplied hardware):

  1. Log into 192.168.0.1
  2. Navigate to Basic → WAN
  3. Locate DNS Server and switch from Automatic (ISP) to Use the following DNS servers
  4. Enter your preferred primary and secondary DNS IPs
  5. Click Apply

If Videotron's modem is in bridge mode and you are running your own router behind it, the path depends on the brand:

  • Asus (asusrouter.com): WAN → WAN DNS Setting → Connect to DNS server automatically → No → enter IPs manually
  • TP-Link (tplinkwifi.net): Advanced → Network → Internet → DNS → uncheck Get Automatically → enter IPs
  • Netgear (routerlogin.net): Advanced → Setup → Internet Setup → Domain Name Server Address → enter IPs
  • Linksys (linksyssmartwifi.com): Connectivity → Internet Settings → IPv4 → DNS → set to Static → enter IPs
  • Eero (eero app): Settings → Network Settings → DNS → Custom DNS → enter IPs

On OpenWrt: edit /etc/config/network, set option dns '1.1.1.1 1.0.0.1' under the WAN interface block, then run service network restart. On DD-WRT: go to Setup → Basic Setup → Static DNS 1 and Static DNS 2, enter the IPs, and save.

Verifying the Change Worked

💡 After switching DNS, use the DNS Propagation Checker to confirm your domain resolves correctly from multiple global vantage points — not just from your own updated resolver.

Check locally with dig:

dig google.com +short dig whoami.cloudflare.com TXT @1.1.1.1 +short

The second command queries Cloudflare's diagnostic hostname and returns the IP address of whichever resolver answered it. If it returns 1.1.1.1 or 1.0.0.1, you are successfully using Cloudflare. If it returns 205.151.x.x, DNS traffic is still routing to Videotron's servers despite your change.

With nslookup:

nslookup google.com

Check the Server: line in the output — it should show your new resolver IP, not 205.151.222.250. If it still shows the old IP, the change did not take effect at the OS level and may need a network adapter reconnect or system reboot.

On Linux with systemd-resolved:

resolvectl status | grep "Current DNS Server"

2026 Notes on DoH, DoT, DNSSEC, and IPv6

Videotron's resolvers do not support DNS over HTTPS (DoH) or DNS over TLS (DoT). Queries to 205.151.222.250 on port 53 are unencrypted and visible to anyone who can observe your network traffic. Switching to Cloudflare or Google with DoH or DoT enabled encrypts resolver traffic end-to-end, preventing query interception on shared Wi-Fi networks or during ISP-level monitoring.

On DNSSEC: Videotron's resolvers perform some validation but the implementation has historically been inconsistent across record types. Cloudflare and Google both enforce strict DNSSEC validation by default, protecting against cache poisoning attacks. If you run internal services with self-signed zones that lack proper DNSSEC records, moving to a strict-validation resolver can break resolution for those hostnames — test in a staging setup before rolling out network-wide.

On IPv6 in 2026: Videotron has expanded its IPv6 deployment significantly across its subscriber base. On dual-stack connections, operating systems frequently prefer IPv6 for DNS queries. Videotron's IPv6 resolvers have seen more documented intermittent incidents than the IPv4 equivalents. If you are chasing random resolution failures on a dual-stack connection, hardcoding only IPv4 public DNS — 1.1.1.1 and 1.0.0.1 without their IPv6 counterparts — eliminates the IPv6 resolver as a variable while you isolate the cause.

Common Misdiagnoses

"My internet is down" — Run ping 8.8.8.8 (an IP address, not a hostname). If that succeeds but ping google.com fails, the physical connection is live and only DNS is broken. These are different problems requiring different fixes. If you call Videotron support, mention DNS resolution failure specifically — otherwise the call will go through modem reboots first.

"The website must be down" — If one specific site is unreachable and others load fine, check whether the domain recently migrated DNS. Videotron's resolver may be serving a stale cached record. Compare what Videotron returns versus what resolvers in other regions see before contacting the site owner.

"My VPN broke DNS" — Many VPN clients override DNS to their own resolvers on connect. If DNS was already degraded before the VPN connected, the VPN's resolver may carry the same problem if it routes egress through Videotron infrastructure. Test DNS both with and without the VPN active to isolate which layer is failing.

"Clearing browser cache fixed it" — Browser DNS caches are short-lived, typically under 60 seconds for most browsers. If clearing browser cache appears to resolve DNS failures, the actual fix was the passage of time — a stale negative cache entry expiring naturally. The underlying resolver issue likely remains and will recur under the same conditions.

Preventing DNS Problems from Recurring

Configure DNS at the router level rather than per-device. New devices — guest phones, smart TVs, IoT sensors — automatically inherit the correct resolver without additional setup. A single router config change also means you can switch resolvers network-wide in under two minutes if a new problem emerges.

If you are on Videotron business internet and running services that depend on reliable resolution, consider deploying a local caching resolver like Unbound forwarding upstream over DoT. This eliminates repeated query latency for frequently resolved hostnames, provides query-level visibility via local logs, and insulates your resolution from upstream resolver outages for any hostname whose TTL keeps it cached locally.

Keep the original Videotron DNS IPs documented somewhere accessible: 205.151.222.250 (primary) and 205.151.254.250 (secondary). Some Videotron-hosted services — the self-care portal and IPTV where applicable — may resolve more reliably against the ISP's own resolver. Having the originals on hand means reverting for a quick comparison test takes two minutes, not a support call.