When a colleague says the internet is down, there is a good chance the internet is fine and DNS is the thing that has actually broken. DNS is the quiet system that turns a name you can remember, like servnet.co.uk, into the string of numbers a computer needs to reach it. It runs millions of times a day without anyone noticing, which is exactly why nobody understands it until it fails and email, the website and half your cloud apps all go dark at once. This is a plain-English guide to what DNS is, what happens in the second after you press enter, and why it is so often the culprit.
DNS is the internet's phone book
Every device on the internet is reached by an IP address, a numeric label like 203.0.113.10 that means nothing to a human. DNS, the Domain Name System, is the directory that maps the friendly names people type into those numbers. You ask for a name, DNS hands back an address, and your device connects. That is the whole job, and it is why people call it the phone book of the internet: you look up a name, you get a number.
The reason this matters to a business is that almost nothing you use is reached by its raw number. Your website, your email, your accounting software, your file storage and your video calls are all found by name. If the lookup for those names stops working, every one of those services becomes unreachable at the same instant, even though the servers behind them are running perfectly. That single point of dependence is why a DNS fault feels like the whole internet has gone.
What happens in the second after you press enter
When you type an address, your device rarely knows the answer itself, so it asks a chain of helpers. First it checks its own short-term memory, the cache, in case it looked the name up recently. If not, it asks a resolver, usually run by your internet provider or a service like your firewall. The resolver, if it does not already know, walks up the hierarchy: it asks the root servers who handles .uk, asks those who handles your domain, and finally asks the server that holds the actual record.
All of that happens in a fraction of a second, and the answer is then cached at several points along the way so the next person does not have to repeat the whole journey. Caching is what makes DNS fast, but it is also why DNS changes are not instant: an old answer can linger in a cache for as long as its time-to-live allows. That lag is the source of the classic phrase you hear after any change, give it time to propagate.
- •Your device checks its own cache first for a recent answer
- •If not cached, a resolver does the lookup on your behalf
- •The resolver walks the hierarchy: root, then the domain's nameservers, then the record
- •Answers are cached along the way, controlled by each record's time-to-live (TTL)
The records that actually run your business
A domain is not one setting, it is a small set of records that each point a different service somewhere. An A record (or AAAA for newer addresses) points a name at a server's address. A CNAME points one name at another. An MX record tells the world which server receives your email. And TXT records carry the email-authentication settings, SPF, DKIM and DMARC, that stop other people sending spam in your name.
Knowing which record does what is the difference between a five-minute fix and a day-long outage. A great many real incidents come down to one record: an MX pointed at the wrong host so email vanishes, an A record left on a decommissioned server, or an SPF record edited badly so legitimate email lands in spam. The records are simple individually; the damage comes from changing the wrong one without realising what depends on it.
Why DNS is so often the thing that breaks
DNS gets blamed so often partly because it genuinely fails and partly because it is the first domino. A mistyped record, an expired domain, a registrar lock, a nameserver outage at your provider, or a change that has not propagated yet will all present identically to a user: nothing loads. Because every named service shares the same dependency, one small mistake produces a very large, very visible symptom.
There is also a security dimension. Attackers target DNS precisely because it is central and often poorly monitored. Hijacking a domain or poisoning a cache can quietly redirect your customers or your email to somewhere hostile. That is one reason DNS belongs inside your wider security thinking rather than treated as plumbing, the same mindset behind network security generally.
How to make DNS boring again
DNS should be invisible, and a few habits keep it that way. Keep an inventory of your records so a change is never a guess. Lower a record's TTL a day before you plan to move it, so the change takes effect quickly when you make it. Use a reputable DNS host with redundancy rather than a single fragile nameserver. And lock your domain registration with auto-renew and registrar-level protection so it cannot lapse or be transferred out from under you.
For most businesses the right answer is to have someone own DNS deliberately, document it, and monitor it, rather than discover how it works during an outage. If you would rather not carry that in-house, it sits naturally within a managed networking arrangement. Either way, the goal is the same: a system you never have to think about, because the day you are thinking about DNS is rarely a good day.