How DNS works
The domain name system is the lookup layer of the internet. Machines reach each other by numeric addresses; people remember names. DNS is the directory that converts one into the other, and it runs every time somebody opens your site, sends you an email or verifies your domain with a platform.
The lookup happens in stages. The visitor’s device asks a resolver, usually run by their internet provider or by a public service. That resolver works out which nameservers are authoritative for your domain, then asks them for the record it needs — the A record that points the website at a server, the MX records that route mail, the TXT records that prove ownership. Every answer is cached along the way for the length of its time to live, which is why an edit is never visible to everyone at the same moment.
Why DNS matters
DNS is the single point where your website and your company email both live or die, and the two are usually managed by different people who assume the other is handling it. A wrong record does not give you a broken page to debug. It gives you nothing at all, or worse, it quietly routes mail to a server nobody collects from while the site looks fine.
It is also the layer marketing keeps touching. Verifying a domain in Search Console, connecting an email platform, pointing a campaign subdomain at a landing page builder, moving to a faster server — every one of those is a DNS edit, and each tends to be made by whoever is nearest the control panel rather than whoever understands the zone.
Common mistakes with DNS
Changing nameservers when you only meant to change one record is the classic failure. Nameservers hand the entire zone to a different provider, so the moment you switch, only the records that provider holds apply. Anything you did not copy across — mail routing above all — stops working immediately, and the symptom often appears hours later when a customer says an email bounced.
The second is editing with a long time to live still in place, so a mistake stays cached on other networks long after you have corrected it. The third is a paperwork problem: nobody in the business knows where DNS is actually managed. It may sit at the registrar, at the host, or at a proxy service added years ago by someone who has left. Finding out costs hours you do not have during an outage.
Working with DNS safely
Export or screenshot the full zone before you touch anything, so there is a written record of the configuration that worked. Shorten the time to live on the records you plan to change well ahead of the change itself, then restore it afterwards. Make one edit at a time and check both the website and a real test email after each one, because the two fail independently.
When the change is part of a server move rather than a single record, sequence it properly: get the new host serving identical content, confirm it directly, and only then point DNS at it. A hosting migration run in that order has no window where the old site has gone and the new one is not yet reachable.