You're halfway through an Edmonton workday when websites stop loading. Your Wi-Fi icon still looks normal, Teams may remain open, but Google, your bank, and Outlook 365 keep saying they can't find the server. Restarting the browser doesn't help because the problem may not be the browser or the website. It may be DNS, the lookup service that turns a web address into the network location your device needs.
DNS issues range from a stale cache on one laptop to a failed resolver, damaged coax connection, misconfigured IPv6, or an outage affecting a cloud dependency. The right response isn't to change random router settings. It's to isolate the fault in a fixed order, collect useful evidence, and stop before a simple connectivity problem becomes a damaged configuration.
Table of Contents
- What DNS Issues Look Like in Real Edmonton Homes and Offices
- Confirming the Problem Is DNS and Not Your ISP
- Running Command-Line Tests That Actually Tell You Something
- Fixes You Can Do Yourself on Windows, Mac, Routers, and Phones
- DNS Propagation Caching and Why a Site Takes Forever to Load
- When to Stop Troubleshooting and Call a Local Edmonton Technician
- Quick Reference and When to Think Bigger Than DNS
What DNS Issues Look Like in Real Edmonton Homes and Offices
Tuesday morning starts badly at a small Sherwood Park accounting office. The spreadsheets already open on the server continue working, but Google won't resolve, the bank's website won't open, and Outlook 365 refuses to send messages. One workstation shows “server not found,” while another still reaches a site it visited earlier. That pattern points to a partial DNS failure, not necessarily a complete internet outage.
The same issue can hurt a Whyte Avenue café differently. The point-of-sale terminal may lose access to its payment service during a busy period, while music streaming on a staff phone continues. At a Clareview basement suite, one tenant might stream Netflix normally because the device has a usable cached address, while another sees DNS_PROBE_FINISHED_NXDOMAIN, meaning its resolver says the requested name doesn't exist.
The symptoms that matter
Watch for the combination, not just one error message:
- Websites time out: Browsers report “server not found,” “DNS_PROBE_FINISHED_NXDOMAIN,” or a similar name-resolution error.
- Applications lose services: Email sits in an outbox, cloud software reports “cannot reach host,” and an otherwise connected laptop can't sign in.
- Local devices disappear: A network printer suddenly vanishes even though it's powered on, especially when devices rely on hostnames rather than fixed addresses.
- Only some devices fail: This often suggests a local cache, device configuration, wireless segment, or resolver difference.
- Everything fails together: If every device loses websites and cloud services, look harder at the gateway, ISP connection, or upstream resolver.
Edmonton technicians also see physical and firmware-related causes. Shaw and Rogers modem behaviour can change after firmware pushes, and stale records may remain available from a gateway after a regional interruption. Exterior coax connectors and cable runs can also contract during severe cold and behave inconsistently during freeze-thaw cycles, causing intermittent traffic loss that looks like a DNS problem.
Practical rule: If one device fails, start at that device. If wired and wireless devices fail together, test the gateway and resolver before changing individual computers.
The useful diagnostic path is straightforward: test connectivity by IP, compare name-based and IP-based requests, inspect the assigned resolvers, clear local state, and then examine the modem, router, and cabling. That's the same order an on-site technician should follow after arriving at your door.
Confirming the Problem Is DNS and Not Your ISP
Don't change the router first. Start with three quick checks that separate name resolution from a broader internet failure.
Check the link without using DNS
Open a browser and try a known public IP address such as 142.250.80.46. If a page responds by IP while ordinary website names fail, the physical connection is probably active and DNS becomes the leading suspect. If the IP also fails, you may be dealing with an ISP, modem, router, cable, Wi-Fi, or routing fault instead.
Next, open a terminal or Command Prompt and test the same destination by name and by IP. A name-based ping requires DNS before it can send traffic. An IP-based ping skips that lookup, although some servers block ICMP, so a failed ping alone doesn't prove the service is offline.
Compare the default resolver with a public one
Temporarily set the device's DNS to a public resolver such as Cloudflare at 1.1.1.1 or Google at 8.8.8.8, then retry the failing websites. If pages begin working, the ISP-provided resolver or the gateway's DNS forwarding is likely involved. Restore the automatic ISP settings after testing unless you've deliberately chosen a different setup.
The order matters. Changing DNS immediately can hide an ISP resolver fault and leave the underlying modem or cable problem undiscovered. On Edmonton Telus fibre installations, the gateway may continue advertising its own IPv6 resolvers even after manual device changes, so a gateway reboot may be necessary before the comparison is meaningful. Shaw Hitron equipment can also serve stale records after a regional disruption.
For broader gateway checks, use this modem troubleshooting guide after you've recorded the original settings.
Quick Tests Is It DNS or the ISP
| Test | If It Works | If It Fails |
|---|---|---|
| Open a known public IP address | The internet path is active, so DNS is suspicious | Check the modem, router, Wi-Fi, cable, or ISP connection |
| Reach a website by name | Name resolution and connectivity are functioning for that destination | Query the resolver directly and compare another device |
Switch temporarily to 1.1.1.1 or 8.8.8.8 |
The default resolver or gateway DNS forwarding may be at fault | The problem may sit upstream of DNS, or the public resolver may not be reachable |
| Test wired and wireless devices | A failure limited to one segment points to local configuration | A shared failure points toward the gateway, ISP, or upstream service |
Canada's federal DNS resilience guidance recommends checking primary and secondary recursive resolvers and testing a known-good IP address to separate DNS failure from general connectivity loss. Once those checks confirm DNS, command-line tools provide better evidence than repeated browser refreshes.
Running Command-Line Tests That Actually Tell You Something
A browser error is useful, but it doesn't identify which resolver failed. Command-line output does. On Windows, begin with the assigned network information:
ipconfig /all
Look for the DNS Servers entries under the active adapter. If the listed address belongs to your router, the router is forwarding requests to another resolver. If the entries are unexpected, duplicated, or different from the settings you intended, you've found a configuration clue.
Clear the Windows client cache next:
ipconfig /flushdns
Windows documents ipconfig /displaydns for viewing cached entries, including records from the local Hosts file and recently resolved names, and ipconfig /flushdns for clearing that cache during troubleshooting. Use ipconfig /displaydns before flushing when you want to preserve a record of what the computer has been using.
Then force a query against a public resolver:
nslookup google.ca 8.8.8.8
The Server line identifies the resolver that answered. The Address line shows the returned address information. A normal response indicates that the selected resolver can answer the request, while SERVFAIL, a timeout, or an unexpected result requires comparison with another resolver.
macOS and Linux checks
On macOS, inspect resolver configuration with:
scutil --dns
For the cache reset, use:
sudo dscacheutil -flushcache
On Linux, resolver management varies by distribution, so inspect the active resolver configuration before clearing anything. A direct query with dig is useful:
dig @1.1.1.1 google.ca +short
The +short option reduces the response to the returned address information. In a full dig response, the ANSWER SECTION shows the records returned. A clean answer differs from SERVFAIL, which signals a resolver-side failure, and NXDOMAIN, which means the queried name was reported as nonexistent.
For readers who want a broader collection of network checks, this connectivity issue solver from Premier Broadband is a practical reference. You can also use this guide to find your IP address before documenting the device and gateway involved.
Ping can mislead. A failed name-based ping may indicate DNS failure, but it may also mean the destination blocks ICMP. Pair it with nslookup or dig, and record the server and response rather than relying on the ping result alone. Those commands create evidence that a technician can read during an on-site assessment or a supported troubleshooting session.
Fixes You Can Do Yourself on Windows, Mac, Routers, and Phones
Use a controlled sequence. Randomly rebooting everything and changing several settings at once destroys the clues that tell you what fixed the problem.
Follow the order
- Restart the affected device first. This clears temporary application state and reconnects the network adapter without changing the entire household or office network.
- Power-cycle the modem and router separately. Unplug the modem, wait for it to shut down, then restart it and allow its connection to stabilise before restarting the router. If your ISP supplied a combined gateway, treat it as one unit and wait for its lights and status to settle.
- Clear the local DNS cache. On Windows, run
ipconfig /flushdns. On macOS, usesudo dscacheutil -flushcache. Flushing before restarting the router can waste the effort if the router is still handing out bad information. - Test an alternate resolver. Temporarily use
1.1.1.1or8.8.8.8on one device. If that device recovers while others remain affected, the router's DNS forwarding or ISP resolver deserves attention. - Change router DNS only after testing. A router-level change affects every device that accepts its DNS settings, including televisions, printers, phones, and smart-home equipment. Record the original configuration first.
- Refresh phones properly. Toggle airplane mode, reconnect, and, if necessary, forget the Wi-Fi network and join it again. This forces the phone to obtain fresh network settings.
- Test IPv6 as an isolation step. Temporarily disabling IPv6 on one device can reveal dual-stack confusion, especially when a gateway advertises an IPv6 resolver that doesn't respond reliably. Re-enable it after testing unless you're applying a deliberate network design.
For router changes, document the existing configuration and use a measured master router configuration guide rather than guessing at advanced options. Don't alter static routes, firewall rules, or firmware settings just because a website won't load.
The device-level test is temporary by design. If switching to a public resolver fixes the issue, you've learned where to investigate. You haven't necessarily proven that the public resolver is the best permanent choice for privacy, filtering, parental controls, or business policy.
DNS Propagation Caching and Why a Site Takes Forever to Load
A newly changed website can appear healthy from one Edmonton connection and unavailable from another because several caches sit between the device and the authoritative DNS service. The authoritative server holds the published answer, while a recursive resolver stores that answer for the time permitted by its TTL. Your router, operating system, browser, and ISP resolver can each contribute to what you see.
CIRA's DNS research shows why the infrastructure deserves serious attention. CIRA reports that its DNS infrastructure answers about 800 million queries per day and, in a study of .CA authoritative name servers, tested 119,443 servers across Canada over six months. 93% failed to answer at least one query during the period, while 7% achieved a perfect 100% success rate. CIRA also recorded 128,218 authoritative name servers for .CA domains, with about 30,000 failing to answer even a single query during the testing window. Those results point to resilience gaps, not a guarantee that every slow website is broken.
Know which cache is showing you the old answer
| Cache Layer | Typical TTL | Effect on User | How to Clear |
|---|---|---|---|
| Browser cache | Set by the browser or application | A browser may reuse recent connection information | Close the browser, clear site data, or test another browser |
| Operating system cache | Controlled by the device | One computer may behave differently from the rest of the network | Flush the local DNS cache |
| Home router cache | Controlled by firmware and configuration | Several devices may receive the same stale result | Restart the router or use its DNS management tools |
| ISP or public recursive resolver | Set by the published record and resolver policy | Different providers may show different answers temporarily | Query another resolver or wait for the cached entry to expire |
| Authoritative DNS | Controlled by the domain's DNS provider | Incorrect records affect every resolver that refreshes them | Correct the published record and verify authoritative responses |
For a record change, query authoritative nameservers directly or compare resolver results. Cloudflare's troubleshooting guidance recommends verifying the exact hostname, including the zone apex and subdomains, and checking authoritative responses when propagation or caching is suspected. The practical tool is dig +trace, or a reputable propagation checker that compares multiple resolvers.
Slow resolution across many unrelated sites isn't normal propagation. It points more strongly toward a local resolver, gateway, ISP path, or routing problem. A single newly changed domain behaving differently across providers is a caching issue until proven otherwise.
When to Stop Troubleshooting and Call a Local Edmonton Technician
Self-service ends when the evidence points to equipment, cabling, or a business-impacting intermittent fault. Continuing to experiment after that point doesn't make you more thorough. It makes the network harder to diagnose.
Call for on-site help when:
- Several devices fail repeatedly: Phones, wired computers, televisions, and printers all lose name resolution, even after local cache clearing.
- The outage comes and goes: Intermittent failures that coincide with severe cold or freeze-thaw conditions deserve a physical inspection of exterior coax, connectors, splitters, and wall outlets.
- The modem never stabilises: Status lights continue cycling or the gateway doesn't return to a consistent online state after a complete power cycle.
- Business work stops regularly: Staff lose access to cloud applications, payment systems, email, or shared resources often enough to interrupt operations.
- Different resolvers give conflicting results: That can indicate gateway forwarding, IPv6, split-horizon configuration, or an upstream service issue rather than a simple laptop cache.
- The fix requires advanced settings: Static routes, firewall policies, firmware recovery, VLANs, and managed Wi-Fi should not be changed by trial and error.
Why a door-to-door visit can be faster
An ISP support agent can confirm service status and send a replacement modem. They usually can't inspect every cable inside your office, identify a failing third-party router, test multiple wired drops, or explain why one tenant's network works while another's doesn't.
An on-site technician can swap suspect Ethernet and coax cables, reseat connectors affected by Alberta freeze-thaw cycles, test the modem at the wall, compare wired and wireless behaviour, and replace a failing router with a properly configured unit. That's often faster than making another support call when the ISP connection is technically online but the local network remains unreliable.
Don't flash router firmware because a resolver is slow. Don't enter static routes from a forum post. Don't disable security features permanently to make one application connect. Those actions can corrupt firmware, create a second outage, or complicate an ISP support agreement.
Nerds 2 You provides in-person service in Edmonton, not remote services. It doesn't provide full MSP services, but it does provide ongoing support and network monitoring for small and medium businesses. The team handles most major hardware repairs on site, but it doesn't provide board-level repairs.
Quick Reference and When to Think Bigger Than DNS
Use this compact sequence before you reset anything advanced:
- Identify the symptom: Record which devices, websites, applications, and printers fail.
- Separate DNS from internet loss: Try a known-good IP address and compare it with a hostname.
- Run
nslookup: Query the default resolver, then compare a public resolver. - Inspect and clear the cache: Use
ipconfig /displaydns, followed byipconfig /flushdnswhen appropriate. - Restart in the right order: Reboot the device, then power-cycle the modem and router separately.
- Test another resolver: Change one device temporarily, not the whole network immediately.
- Check propagation: Compare authoritative and recursive results when only one domain is affected.
- Escalate with evidence: Save command output, timestamps, modem status, and the list of affected devices.
Recurring DNS instability usually signals a wider infrastructure problem. Aging router firmware can leave a network exposed to DNS hijacking, while IPv6 misconfiguration can create a dual-stack failure that affects only some devices. Malware can inject rogue resolvers, and a business that depends entirely on cloud services may have a continuity gap if name resolution fails.
Canada's DNSSEC readiness data also warrants caution. CIRA reported that only 12% of Canada's internet was DNSSEC-ready at the time of publication, while a separate CIRA and M-Lab presentation reported 19% of IPT users as DNSSEC-capable. Those figures show why enterprises shouldn't assume every client, home network, ISP resolver, and authoritative service is ready for an end-to-end DNSSEC rollout. Validate each hop before enabling it, especially with split-horizon DNS, managed Wi-Fi, or outsourced resolvers.
CIRA's public incident records document DNS service interruptions, including a Canadian Shield Private DNS incident on 2025-08-27 lasting 57 minutes and an incident on 2026-01-22 where Canadian Shield Private DNS and Family DNS were reported down. These events reinforce the operational lesson: DNS is a monitored dependency, not an invisible utility that can be ignored.
A one-off household failure is usually manageable. Weekly disruptions in a home office, retail shop, or professional practice justify a network audit, firmware inventory, resolver review, and a continuity plan. Treat repeated DNS issues as a symptom of infrastructure debt, not an annoyance that needs another reset.
Nerds 2 You Edmonton brings on-site computer repair, network troubleshooting, Wi-Fi configuration, and practical IT support to homes and offices, including ongoing support and network monitoring for small and medium businesses. If DNS issues keep returning after the basic checks, visit Nerds 2 You Edmonton to arrange help at your door.
Contact Nerds 2 You for quality professional service
Experience the difference with our dedicated team of experts ready to assist you. Whether you need immediate support or have questions about our services, we are here to help. Reach out today and let us provide you with the reliable service you deserve. Your satisfaction is our priority and we guarantee a prompt response to all inquiries.