DNS Explained: What It Actually Controls

Most business owners only ever encounter DNS twice: once when the website or email is first set up, and again — usually in a slight panic — when something stops working after a change nobody quite remembers making. It's one of the least visible parts of running a website, right up until it breaks something. This guide explains what DNS actually controls, walks through what happens behind the scenes between typing a domain and a page loading, lists the records that matter for a small business, shows where to actually go to change them, and covers the handful of mistakes responsible for almost every DNS-related outage.

What DNS actually does

Every device on the internet is really found by a numeric address, not a name. DNS is the system that maps the domain name people actually type — or click from a search result — to that underlying address, the same way a phonebook maps a person's name to their number. When someone visits yourdomain.com, their browser asks DNS "where does this domain point?", gets an answer in a fraction of a second, and loads the site from there. Nothing about your website's content lives in DNS itself — it's purely the address book that gets a visitor to the right place, and the same lookup happens again, separately, every time a mail server needs to deliver an email to your domain.

How a DNS lookup works, step by step

A single visit to a website triggers a short chain of lookups most people never see, each one checked before the next is asked:

• Browser and device cache. The browser and operating system first check whether they already know the answer from a recent visit, and if so, skip straight to loading the page.
• Recursive resolver. If not cached, the request goes to a resolver — usually run by the visitor's internet service provider or a public service — which does the actual work of finding the answer on the visitor's behalf.
• Root and TLD servers. The resolver asks the internet's root servers which servers are responsible for the domain's extension (.com, .my and so on), then asks that extension's registry which nameservers handle the specific domain.
• Authoritative nameserver. The resolver then asks the domain's own nameservers — the ones set at the registrar — for the actual record, such as the A record pointing at the website's server.
• Answer returned and cached. The resolver hands the answer back to the browser, which connects to that server address, and the answer is cached for next time, for as long as its TTL allows.

All of this normally finishes in well under a second. It only becomes visible when a step in the chain returns the wrong answer — usually because a record was recently changed and an older cached answer is still being served from somewhere in that chain.

The DNS records that actually matter for a small business

Most domains only need a handful of record types in practice. An A record points a domain — or a specific part of it, like a subdomain — directly at the IP address of the server hosting your website; it's the record that makes yourdomain.com load your site. A CNAME record points one domain name at another instead of at an IP address, most commonly used to make www.yourdomain.com resolve to the same place as yourdomain.com. An MX record tells the internet which mail server handles email for your domain, so a message sent to [email protected] actually reaches your inbox. A TXT record holds text-based settings rather than routing anything — the most common use today is SPF, DKIM and DMARC, covered further down, which help receiving mail servers confirm an email claiming to be from your domain is genuine rather than spoofed. An NS record is slightly different from the rest: it's the record, held at the registry, that says which nameservers are authoritative for the domain in the first place.

DNS record types at a glance

Where your DNS is actually managed

This trips people up more than any other part of DNS: DNS isn't automatically tied to wherever a domain was registered. What actually matters is which nameservers the domain currently points to. If a domain still uses its registrar's default nameservers, DNS is managed from the registrar's control panel. If it's been pointed at a hosting provider's nameservers instead — common when the domain and hosting are with the same company, or after a migration — DNS is managed from the hosting account instead, and the registrar's own DNS settings are effectively ignored. Before changing anything, it's worth confirming which nameservers a domain currently uses, which any registrar's or host's control panel will show.

Nameservers vs DNS records: who controls what

The two layers are easy to confuse because both live under the word "DNS." The nameservers are set once, at the registry level, through the domain registrar — they say which company's servers are authoritative for the domain. The records — A, CNAME, MX, TXT and the rest — live inside those nameservers' own zone file, and that's where the day-to-day changes happen. Pointing a domain at a new nameserver moves the entire zone file somewhere else; editing a single record changes one line within whichever zone file is currently in charge.

Why a DNS change doesn't show up right away

Every DNS record carries a TTL (time to live) — a duration that tells every other server on the internet how long to keep using the answer it already has before checking again. A short TTL, such as 300 seconds (five minutes), means a change can show up quickly; a longer one, such as 86,400 seconds (24 hours) and common on records nobody expects to change often, can take up to 24–48 hours to be visible everywhere, since different networks around the world refresh their local cache on their own schedule rather than all at once. Before a planned change — a website migration, switching email providers — it's good practice to lower the TTL a day or two in advance, so the eventual switch propagates faster once it's made.

Planning a DNS change without downtime

Most DNS-related outages happen because a change is made at the same moment the thing it depends on isn't ready yet. A short, deliberate sequence avoids that:

• Lower the TTL first. A day or two before the planned change, reduce the TTL on the record you intend to touch, so the eventual switch is visible sooner rather than stuck behind a long cache window.
• Get the destination ready before pointing anything at it. Confirm the new server is serving the website, or the new mail provider is accepting mail, before any record is changed — never the other way round.
• Change one record at a time. Update the record, confirm it resolves correctly using a DNS lookup tool, then move to the next one rather than batch-editing several records in one sitting.
• Keep the old destination running for a buffer period. Don't decommission the old server or mailbox immediately — some visitors and mail servers will still be using a cached, older answer for a while.
• Raise the TTL back once things are stable. A short TTL is useful during a migration; left permanently short, it adds unnecessary load without any ongoing benefit.

DNS and email deliverability: SPF, DKIM and DMARC

Beyond the MX record that routes mail in, three TXT-based records increasingly decide whether outgoing mail lands in an inbox or a spam folder. An SPF record lists which mail servers are allowed to send email on behalf of a domain, so a receiving server can reject a message claiming to be from that domain but actually sent from somewhere else. DKIM attaches a cryptographic signature to outgoing mail that proves it wasn't altered in transit and genuinely came from an authorised server. DMARC builds on both, telling receiving mail servers what to do with a message that fails those checks — quarantine it, reject it, or merely report it. None of these are required for a website to work, but major mailbox providers increasingly treat domains without them as more likely to be spam, which matters for any business sending invoices, quotes or marketing email from its own domain.

Common mistakes

• Changing or deleting an MX record by accident. This is the single most common way a business quietly loses incoming email — with no error message, since it simply stops arriving rather than bouncing back.
• Pointing the A record at a new server before it's ready. Switching a domain to a new server during a migration before that server can actually serve the site takes a live website offline for no reason.
• Forgetting to update SPF after switching email providers. An old SPF record that doesn't list the new provider's servers can cause legitimate email to be marked as spam or rejected outright.
• Leaving the TTL high going into a planned migration. A long TTL set the day of a cutover means the old answer keeps being served for up to 24–48 hours after the new one is live.
• Editing several records in one sitting with no verification in between. One typo in a batch of changes is hard to spot until something — usually email — has already been broken for hours.
• Assuming DNS is tied to the registrar. Looking for records in the registrar's panel when the domain was actually pointed at a host's nameservers wastes time and can lead to editing the wrong, inactive zone file entirely.

Where Gotka Technologies fits

Whether a domain or its hosting is with Gotka, DNS records are managed from the same client area already used for billing and support — no separate login or tool required. Gotka's domain registration includes domain lock and WHOIS privacy protection as standard, and Cloud Hosting plans — from Go AI Lite at RM17.80/month on a 36-month term — include free migration, so DNS is handled correctly as part of moving a website rather than left for the owner to untangle. For the registration side specifically, our guide to choosing between a .my and .com domain covers what to decide before DNS even comes into it.

Key terms used in this guide

• DNS (Domain Name System): the internet-wide system that translates domain names into the server addresses computers actually use.
• Nameserver: a server, set at the registrar, that's authoritative for a domain and holds its zone file of records.
• Zone file: the set of DNS records — A, MX, TXT and the rest — held by a domain's current nameservers.
• A record: points a domain or subdomain directly at a server's IP address.
• CNAME record: points one domain name at another domain name instead of an IP address.
• MX record: tells the internet which mail server handles incoming email for a domain.
• TTL (time to live): how long other servers should keep a cached DNS answer before checking for a fresh one.
• Propagation: the period during which a DNS change becomes visible across different networks worldwide, governed by TTL.
• SPF / DKIM / DMARC: TXT-based records that let receiving mail servers verify an email genuinely came from the domain it claims to.