The DNS records every freelancer must know

Most freelance web work in Kenya dies at the same place. Not design. Not code. DNS.

You build the site, the client approves it, and then you point the domain — and the site does not load. Or the site loads but email stops. Or it works on your laptop and not on the client’s phone. You wait. You blame “propagation”. You tell the client to wait 48 hours. Sometimes it fixes itself and you never learn why.

That is the gap this guide closes. Six record types, one timing concept, and five failures. Learn these and you stop guessing.

What DNS actually is

DNS is a lookup. A browser has a name — example.co.ke — and needs a number, because the network only routes numbers. DNS is the system that turns one into the other.

Think of it as directory enquiries for the internet. Nobody remembers 154.72.x.x. Everybody remembers the name. DNS holds the mapping between them, and it holds a few other things besides.

A zone is the full set of records for one domain. A record is a single line in that zone. When you edit DNS you are editing lines in a zone file, whether or not the control panel shows it that way.

The six records that matter

There are dozens of record types. In practice, six carry almost all the work.

A — name to IPv4 address

The workhorse. It points a name at an IPv4 address.

example.co.ke.        3600    IN    A       102.130.115.20
www.example.co.ke.    3600    IN    A       102.130.115.20

Left to right: the name, the TTL in seconds, the class (always IN), the type, and the value.

Note that example.co.ke and www.example.co.ke are different names. They are not the same thing and one does not imply the other. This catches people constantly — the site works at www and fails at the bare domain, or the reverse, because only one A record exists.

The bare domain is called the apex or root. Remember that word; it matters in a minute.

AAAA — name to IPv6 address

Same job as A, but for IPv6.

example.co.ke.        3600    IN    AAAA    2c0f:fe38:2000::20

Two practical points. First, if you publish an AAAA record, that address must actually work — a client on IPv6 will try it first and, if the server is not listening there, they get a broken site while you see a working one. Publishing a wrong AAAA is worse than publishing none.

Second, IPv6 adoption on Kenyan mobile networks is real and growing. Test both, or publish neither.

CNAME — name to another name

An alias. It says: this name is really that name, go and look that up instead.

www.example.co.ke.    3600    IN    CNAME   example.co.ke.

CNAME has one hard rule that breaks more sites than any other single thing in DNS:

A CNAME cannot coexist with any other record on the same name.

That is not a convention. It is in the standard. If a name has a CNAME, it can have nothing else — no A, no MX, no TXT.

Which produces the rule everyone eventually learns painfully: you cannot put a CNAME on the apex. The apex must carry NS records and usually MX records, so by definition it cannot be a CNAME. Any provider that appears to let you is doing something non-standard behind the scenes — usually called ALIAS, ANAME, or CNAME flattening — where they resolve the target and serve an A record on the fly.

So when a platform tells you to “point your domain at something.netlify.app with a CNAME”, that instruction works for www and cannot work for the apex. You either use the provider’s flattening feature, or you use an A record to their IP, or you serve the site at www and redirect the apex.

MX — where email goes

MX records say which servers accept mail for the domain.

example.co.ke.    3600    IN    MX    10 aspmx.l.google.com.
example.co.ke.    3600    IN    MX    20 alt1.aspmx.l.google.com.

The number is the priority, and lower wins. A sender tries priority 10 first, and only falls back to 20 if that fails. It is a fallback ordering, not a load-balancing weight.

Two things to internalise. MX points to a name, never to an IP address — an MX record containing an IP is invalid, though some panels will accept it silently. And MX is entirely independent of A. Your website and your email can, and frequently should, live on completely different servers.

This is where the classic disaster happens. The freelancer migrates a site to new hosting, copies over the A record, forgets MX, and the client’s email vanishes. The site looks perfect. The business cannot receive orders. You will hear about it.

Before you change any nameserver, export the existing zone. Every record. That single habit prevents most of the damage in this article.

TXT — arbitrary text, mostly for proving things

TXT holds free-form text. Almost all of it is verification and email authentication.

example.co.ke.    3600    IN    TXT    "v=spf1 include:_spf.google.com ~all"

The three you will meet constantly:

SPF lists which servers may send mail as your domain. One SPF record per domain — if you have two, SPF is broken, not doubled. When you add a new sender, you merge it into the existing record.

DKIM publishes a public key so receivers can verify a signature on your mail. It sits on a selector name like google._domainkey.example.co.ke.

DMARC tells receivers what to do when SPF and DKIM fail. It lives at _dmarc.example.co.ke. Start at p=none and watch the reports before you tighten to quarantine or reject — going straight to reject on a domain you do not fully understand will silently bin legitimate client mail.

Get these three right and your client’s invoices stop landing in spam. That alone is worth charging for.

NS — who is authoritative

NS records name the servers that hold the real zone for the domain.

example.co.ke.    86400    IN    NS    ns1.hostafrica.com.
example.co.ke.    86400    IN    NS    ns2.hostafrica.com.

This is the record that decides whose control panel actually matters. Point the NS at your host and edits in the registrar’s DNS panel do nothing. Point it at the registrar and edits at the host do nothing.

Ninety per cent of “I changed the record and nothing happened” is this. The record was changed in a zone that is not authoritative. Before editing anything, check where the domain is actually served:

dig NS example.co.ke +short

Edit there. Nowhere else.

TTL, and why “propagation” is the wrong word

Every record carries a TTL — time to live, in seconds. It tells resolvers how long they may cache the answer before asking again.

DNS does not “propagate”. Nothing is pushed anywhere. Your authoritative server changed the instant you clicked save. What is happening is that resolvers around the world are still serving cached copies of the old answer until their TTL expires.

That reframing has a practical payoff. If you know a migration is coming, lower the TTL first. Drop it to 300 seconds a day ahead of the change. Caches everywhere expire down to five minutes. Then make the change, confirm it, and raise the TTL back to 3600 once things are stable.

Do this and cutovers take minutes. Skip it and you tell the client to wait two days — which is not a technical limit, it is the cost of not planning.

Two caveats. The 24–48 hour figure still applies to nameserver changes at the registry, which is a different mechanism with its own timing, and .ke is no exception. And a resolver that ignores your TTL exists; you cannot control every network. Plan for the majority, not the outliers.

The five failures, and how to spot them

1. Editing the wrong zone. Nothing changes, no matter how many times you save. Run dig NS domain +short and edit wherever that points.

2. CNAME on the apex. The site loads at www and fails on the bare domain, or email breaks the moment the CNAME is added. Use an A record, or the provider’s flattening feature.

3. Losing MX during a migration. The site works, email dies, and you find out from an angry client days later. Export the zone before you touch anything.

4. Two SPF records. Mail authentication fails intermittently and invoices land in spam. Merge them into one.

5. Trusting the browser. Browsers and operating systems cache aggressively and lie to you about the current state. Check with a resolver directly:

dig A example.co.ke +short
dig MX example.co.ke +short
dig TXT example.co.ke +short
dig @8.8.8.8 A example.co.ke +short    # what a public resolver sees

dig is on macOS and Linux already. On Windows, use WSL or nslookup.

Practise this today

Reading this changes nothing. Do the exercise.

Take a domain you control — or register a cheap .co.ke for the purpose, which is the better option because you can break it freely.

1. Run dig NS on it and confirm which nameservers are authoritative.
2. Export the full zone and save it to a file. Every migration you ever do should start this way.
3. Create an A record on a subdomain — test.yourdomain.co.ke — pointing anywhere. Confirm it with dig.
4. Set its TTL to 300, wait, change the address, and time how long the change actually takes to appear.
5. Set the TTL to 86400, change it again, and time it. Feel the difference. That is the entire lesson.
6. Publish an SPF record. Send mail. Check the headers of what arrives.

An afternoon of that puts you ahead of most people charging for this work in Nairobi right now.

The point

DNS is small. Six records, one timing concept. It has an outsized reputation for difficulty because most people learn it by breaking a client’s business and guessing at the fix.

Learn it deliberately instead, and it becomes something you can charge for — the thing you get called about when someone else’s migration has gone wrong. That call is worth more than the site build.

Technology changes. Principles endure. DNS has worked essentially this way since the 1980s, and it will outlast whichever framework you are using this year.