DNS turns names like your company's website into the IP addresses computers use. A business deals with two separate halves of it: the resolvers your office uses to look up every site and service your staff reach, and the authoritative records your own domain publishes so the world can find your website and deliver your email. Each half has its own owner, its own failure modes and its own security settings, and a problem with either can look exactly like an internet outage.
Most businesses never think about DNS until it breaks. A domain renewal lapses, a website move forgets the email records, or the office resolver stops answering and every browser shows an error while the circuit is perfectly healthy. A little understanding goes a long way.
Half one: resolving names for your office
Every time a staff member opens a website or an app connects to a cloud service, the device asks a DNS resolver for the address. In a typical office, the firewall or a server hands out a resolver address to every device by DHCP. That resolver might be:
- The carrier's resolvers, often the default on a new circuit.
- A public resolver run by a large provider, such as those run by Google, Cloudflare or Quad9.
- A filtering DNS service that also blocks known malicious or unwanted sites.
- Your own internal DNS server, common in offices with a Windows domain, which answers for internal names and passes everything else on to one of the above.
Resolvers cache answers for a time set by each record, so repeated lookups are fast. If the resolver is slow or down, everything feels slow or down, even though the connection is fine.
Half two: your domain's records
Your domain's records live with a DNS host, which is often, but not always, the registrar where you bought the domain. These records tell the world where everything is.
| Record | What it does | Example use |
|---|---|---|
| A / AAAA | Points a name to an IPv4 or IPv6 address | Your website, a VPN gateway |
| CNAME | Points one name at another name | www to a hosting platform |
| MX | Says which servers receive email for the domain | Your email provider |
| TXT | Holds text used for verification and email security | SPF, DKIM, DMARC, service verification |
| NS | Says which DNS host is authoritative for the domain | Moving DNS between providers |
| PTR (reverse DNS) | Maps an IP address back to a name | Mail servers on your static IPs |
Reverse DNS is the odd one out: it is controlled by whoever owns the IP address, which for your static IPs is usually the carrier. If you send email from your own server, ask the carrier to set it. Our guide to static IPs and BGP explains why mail servers care.
TTL: how long answers are remembered
Every record has a time to live, in seconds, telling resolvers how long to cache it. A long TTL reduces lookups; a short one lets changes take effect quickly. Before you move a website, change email providers or switch internet circuits on a server with a public address, lower the TTL a day or two ahead, so the change spreads in minutes instead of hours. Our guide to switching internet providers without downtime covers this in the context of a circuit change.
Email depends on DNS
Three TXT-based records decide whether your email is trusted:
- SPF lists the servers allowed to send mail for your domain.
- DKIM publishes a key so receivers can verify your messages were signed by your mail system and not altered.
- DMARC tells receivers what to do when a message fails those checks, and where to send reports.
Large mailbox providers have tightened their requirements for senders in recent years, particularly for bulk mail, and missing or broken records are a common reason legitimate email lands in spam. They also make it harder for anyone to send convincing fake email from your domain. If you add a new service that sends mail for you, such as a booking system or a newsletter tool, its details usually need adding to SPF and DKIM.
DNS filtering: a cheap layer of protection
A filtering resolver refuses to look up domains known to host malware, phishing pages or command-and-control servers, so a click on a bad link fails before any connection is made. Most can also block categories of sites by policy. It is one of the least expensive security layers a small business can add, and it works for every device on the network without installing anything on each one.
Two limits to know. Filtering only works if devices actually use your resolver; some browsers and apps use encrypted DNS to their own provider and bypass it, so your firewall policy should account for that. And filtering is a layer, not a complete defense. Our articles on ransomware and your network and our firewall guide cover the rest, and our cybersecurity page covers managed options.
Is it DNS, or is the internet down?
The quickest test: open a command prompt and ping a well-known public IP address, such as a public resolver's address. Then ping a well-known website by name.
| IP ping | Name ping or browser | Likely cause |
|---|---|---|
| Fails | Fails | The connection is down: check the circuit, firewall and carrier |
| Works | Fails | DNS: the resolver is down, unreachable or misconfigured |
| Works | Works for most sites, fails for one | That site's own DNS or hosting, not you |
If it is the resolver, a quick workaround is to point the firewall's DHCP or the affected devices at a different resolver while you fix it. If you run an internal DNS server for a Windows domain, check that server first, because a stopped DNS service on one server can make an entire office look offline. Our outage checklist includes this step.
Internal names and split DNS
Offices with a Windows domain, a file server or internal web apps often need names that only resolve inside the office, such as a server name staff type into a file path. The internal DNS server answers those, and forwards everything else out to a resolver. Two common pitfalls:
- Pointing some devices at a public resolver directly. They can reach the internet but cannot find internal servers, which shows up as "the shared drive is missing on some laptops."
- Using the same name inside and out without planning. If your website and an internal server share a name, the internal DNS needs to answer correctly for both, or staff in the office may not reach your own website.
Remote staff on a VPN usually need the VPN to hand them the internal resolver too, otherwise internal names fail only when they work from home.
Protecting the domain itself
Losing control of your domain is far worse than a resolver hiccup. It takes your website and email with it.
- Turn on auto-renew, and keep a current payment card and contact email on the registrar account.
- Use multi-factor authentication on the registrar and DNS host logins.
- Enable registrar lock so the domain cannot be transferred away without extra steps.
- Make sure the account belongs to the business, not a former employee or a web designer who has since moved on.
- Export a copy of your DNS records and keep it somewhere safe, so they can be rebuilt quickly.
- Consider DNSSEC if your DNS host supports it, which lets resolvers verify your records have not been tampered with.
A worked example
Hypothetical: the firm and the sequence of events are invented to show a common failure.
A 30-person engineering firm comes in on a Monday to find nobody can open websites, Teams will not connect and the phones work only intermittently. The carrier's equipment looks normal. The office manager pings a public resolver's IP address and gets replies, but names fail. The firm's single internal server, which handles DNS for the Windows domain, rebooted overnight for updates and its DNS service did not start.
The IT contractor starts the service and the office is back in minutes. Afterwards, the firm adds a second DNS server, points it at a filtering resolver for outside lookups, sets the firewall to block DNS to anywhere else, and adds the "ping an IP, then a name" test to the printed outage sheet. At the same review, they notice the domain is registered under the web designer's personal account and move it to a company account with multi-factor authentication.
Questions to ask your IT provider or carrier
- Which resolvers do our devices use, and what happens if they fail?
- Is DNS filtering in place, and can devices bypass it?
- Who hosts our domain's DNS, and who has the login?
- Are SPF, DKIM and DMARC set up for every service that sends mail for us?
- Is reverse DNS set on our static IPs, if we send mail from them?
- Is the domain on auto-renew, locked and owned by the business?
The circuit underneath
DNS is only as reliable as the connection under it. We price primary and backup circuits from several Tier 1 carriers, the carrier pays FiberX so nothing is marked up, and our lowest-price promise applies. If your current setup already wins, we will tell you. Quotes are free, you usually hear back the same day, and Phil Morales is your one point of contact. Get in touch, call 478-758-8091 or text (347) 870-0965.
