DNS Explained: What Business Owners Need to Know

Your website has an address. Not just the one people type into a browser, but a numerical address that computers use to find it on the internet. DNS is the system that connects the two. And when it breaks, nothing else matters. Your site doesn't load. Your emails don't arrive. Your business disappears from the internet as if it never existed.

We've lost count of how many panicked calls we've gotten from Calgary businesses whose websites "went down" when the actual problem was a DNS record that expired, got deleted during a domain transfer, or was misconfigured by someone who didn't fully understand what they were changing. The site itself was fine. The server was running. But nobody could reach it because DNS stopped pointing people in the right direction.

DNS is one of those systems that sits underneath everything you do online, and most business owners never think about it until something goes very wrong. That needs to change.

What DNS Actually Does

DNS stands for Domain Name System. It translates human-readable domain names (like yourcompany.ca) into IP addresses (like 104.26.10.78) that computers use to locate servers on the internet. That's the one-sentence explanation, and it's accurate, but it skips over why this matters to you.

Every single time someone visits your website, sends you an email, or clicks a link to your business on Google, a DNS lookup happens behind the scenes. Their device asks a series of servers: "Where is yourcompany.ca?" Those servers check your DNS records and return the IP address of whatever server hosts your site. The browser connects to that IP address, and your website appears. This happens in milliseconds, thousands of times a day, and you never see any of it.

The reason this matters is that DNS is a single point of failure. Your hosting could be rock-solid. Your code could be perfect. Your SSL certificate could be current. But if your DNS records are wrong or your DNS provider is down, none of that matters. Visitors get a blank page or an error message, and they move on to your competitor.

DNS is the phone book of the internet. If your number is listed wrong, it doesn't matter how good your business is. Nobody can find you.

Think of it in concrete terms. You have a physical office. Your website's hosting server is that office. DNS is the directory listing that tells people how to get there. If someone updates the directory with the wrong address, or removes your listing entirely, visitors show up at the wrong building or wander around with nowhere to go. The office is still there. The lights are still on. But the directory is broken, so nobody walks in.

The DNS Records That Run Your Business

Your domain doesn't have a single DNS record. It has several, each responsible for a different part of how your online presence works. The common record types are A, CNAME, MX, TXT, and NS, and understanding what each one does will save you from expensive mistakes.

A records point your domain name to an IPv4 address. When someone types yourcompany.ca into a browser, the A record tells their device which server to connect to. This is the most basic DNS record, and it's the one most people think of when they think of DNS. If you move your website to a new hosting provider, the A record is what you update to point traffic to the new server.

CNAME records are aliases. Instead of pointing directly to an IP address, they point one domain name to another. A common example: www.yourcompany.ca might have a CNAME record pointing to yourcompany.ca, which itself has an A record pointing to the actual IP. CNAMEs are also used when connecting your domain to third-party services like Shopify, Squarespace, or a CDN like Cloudflare. The service gives you a CNAME to add, and it handles the rest.

MX records control where your email goes. MX stands for Mail Exchange. When someone sends an email to [email protected], the sending server checks your MX records to find out which mail server handles email for your domain. If you use Google Workspace, your MX records point to Google's mail servers. Microsoft 365, they point to Microsoft's. Get these wrong and email stops arriving. We've seen businesses go days without receiving email because an MX record was accidentally deleted during a DNS migration.

TXT records store text-based information that other services read. The most common use cases are email authentication (SPF, DKIM, and DMARC records are all TXT records, which we covered in detail in our guide to email authentication), domain verification for services like Google Search Console, and security policies. TXT records are where a lot of behind-the-scenes trust verification happens.

NS records define which DNS servers are authoritative for your domain. These are the records that tell the entire internet "the real DNS information for yourcompany.ca lives on these specific nameservers." When you move your DNS management from your registrar to Cloudflare, for instance, you're changing your NS records.

How DNS Changes Spread (And Why It Takes So Long)

This is the part that confuses most people, and honestly, it confuses some developers too.

When you change a DNS record, the change doesn't take effect instantly everywhere. DNS is a distributed, cached system. Thousands of DNS servers around the world store copies of your records so they don't have to look them up every single time someone visits your site. When you make a change, those cached copies need to expire before the servers fetch the updated version.

That expiration is controlled by TTL, the Time to Live value attached to every DNS record. If your A record has a TTL of 86400 seconds (24 hours), then DNS servers that cached it will keep using the old version for up to 24 hours before checking for an update. This is DNS propagation, and it's why the answer to "how long until my DNS change goes live" is always "it depends."

In practice, most changes are visible within a few hours. Some ISPs and corporate networks are aggressive about caching and might take the full TTL period. A few edge cases take even longer because some resolvers ignore TTL values entirely and use their own caching schedule.

Here's the practical takeaway: if you're planning a website migration or switching hosting providers, lower your TTL well before the move. A week before your migration, change your TTL from 86400 (24 hours) to 300 (five minutes). Let that lower TTL propagate for a few days. Then, when you update your A record to point to the new server, DNS servers worldwide will check for updates every five minutes instead of once a day. After the migration is stable, raise the TTL back to a higher value. This one step prevents most of the "my site is showing the old version for some people" problems that plague migrations.

We handle DNS planning as part of our migration and launch work. It's one of those details that's easy to overlook and expensive to get wrong.

Real-World DNS Failures (And What Caused Them)

DNS outages aren't hypothetical. They happen to major companies, and they're devastating when they hit small businesses that don't have dedicated infrastructure teams to respond within minutes.

In October 2021, Facebook, Instagram, WhatsApp, and Messenger all went offline for approximately six hours. The cause was a BGP routing update that accidentally withdrew the routes to Facebook's DNS nameservers. The servers running Facebook's DNS were still operational, but the rest of the internet couldn't reach them. From the outside, it looked like Facebook's domain simply stopped existing. Over three billion users were affected, and Meta estimated revenue losses of roughly $60 million during the outage.

In July 2016, a massive DDoS (Distributed Denial of Service) attack hit Dyn, a major DNS provider used by companies including Twitter, Reddit, Spotify, GitHub, and The New York Times. The attack overwhelmed Dyn's DNS servers with traffic, making them unable to respond to legitimate DNS queries. The sites themselves were up, but users couldn't reach them because DNS resolution failed. The attack exploited the Mirai botnet, a network of compromised IoT devices. The lesson for businesses was clear: your DNS provider is a dependency, and if it goes down, you go down with it.

These are extreme examples, but we see smaller-scale DNS problems regularly. A Calgary client switched domain registrars last year and didn't realize the transfer reset their DNS records to defaults. Their MX records vanished. For two business days, every email sent to their domain bounced. They didn't notice immediately because emails they sent out still worked fine. Inbound email just stopped silently.

Another common failure: letting a domain expire. Domain registrations have expiration dates, and if you miss the renewal, your registrar can suspend your DNS. Your entire online presence goes dark. We've seen businesses lose their domain entirely because it expired, entered a redemption period, and was eventually purchased by a domain squatter.

How to Protect Your DNS

DNS isn't something you set once and forget—especially if you're launching a new business in Alberta and setting up your digital infrastructure for the first time. A few straightforward practices will prevent most of the problems we've described.

Use a reputable DNS provider. Your domain registrar's default DNS hosting works, but dedicated DNS providers like Cloudflare (free tier), AWS Route 53, or Google Cloud DNS offer faster resolution times, better uptime guarantees, and built-in DDoS protection. Cloudflare's free tier alone provides Anycast DNS (your DNS queries are answered by the closest data centre), automatic DDoS mitigation, and a web dashboard that's far easier to use than most registrar panels.

Enable auto-renewal on your domain. This sounds obvious, but domain expirations are still one of the most common causes of DNS outages for small businesses. Set your domain to auto-renew and make sure the payment method on file is current. Put a calendar reminder for 30 days before expiration as a backup.

Keep your DNS records documented. Before making any changes, export or screenshot your current DNS configuration. We keep a spreadsheet for every client listing every DNS record, what it does, and when it was last changed. When something breaks at 2 a.m., you don't want to be guessing what the records were supposed to look like.

Lock your domain. Most registrars offer a domain lock (also called registrar lock or transfer lock) that prevents unauthorized transfers. This stops someone from hijacking your domain by initiating a transfer you didn't authorize. It takes 30 seconds to enable and prevents a catastrophic scenario.

Understand your SSL and security headers. DNS and SSL are tightly connected. If you move your DNS to a new provider and don't configure SSL correctly, visitors will see security warnings or your site won't load over HTTPS at all. Every DNS change should include a check that SSL certificates are still valid and properly assigned.

Lower TTL before changes. We said it earlier, but it's worth repeating. If you know a DNS change is coming, lower your TTL to 300 seconds at least 48 hours beforehand. This single step reduces the propagation window from hours to minutes.

Test changes with tools, not guesses. After making a DNS change, don't just refresh your browser and assume it worked because the site loads. Your device might be using cached records. Use external tools instead:

• MXToolbox DNS Lookup checks your records from external servers and shows exactly what the world sees.
• DNS Checker tests propagation across 20+ global locations so you can confirm the change has spread.
• nslookup or dig from a command line will query specific DNS servers directly if you need granular control.

The One Thing to Remember

DNS is boring infrastructure until it breaks, and then it's the only thing that matters. Most business owners don't need to manage DNS records themselves. But they do need to understand what DNS is, why it matters, and what questions to ask when something goes wrong. If your web developer or IT person can't explain what your DNS records do in plain language, that's a problem worth fixing before it becomes an emergency.

Sources

• Cloudflare — What Is DNS? — Cloudflare's learning centre overview of how DNS works, including record types and resolution process
• IANA — Root Zone Database — The Internet Assigned Numbers Authority's authoritative root zone data, documenting the top-level domain delegation system underlying all DNS
• RFC 1035: Domain Names — Implementation and Specification — The original IETF specification defining DNS message format, record types, and resolution behaviour
• Cloudflare — DNS Records — Detailed explanations of A, AAAA, CNAME, MX, TXT, NS, and other DNS record types
• Cloudflare — What Is DNS Propagation? — How TTL values control caching and why DNS changes don't take effect instantly
• ICANN for Beginners — How Domain Names Work — ICANN's official guide to how DNS names are structured and resolved globally
• MXToolbox DNS Lookup — Free DNS record lookup and diagnostic tool for checking A, MX, TXT, CNAME, and NS records
• Cloudflare Blog — Understanding the Facebook Outage (October 2021) — Cloudflare's technical analysis of how a BGP misconfiguration caused Facebook's DNS to become unreachable for six hours
• Dyn DNS DDoS Attack Analysis (October 2016) — Coverage of the Mirai botnet DDoS attack on Dyn's DNS infrastructure that took down major websites