How DNS works: propagation, TTL and record types
The Domain Name System (DNS) turns a name such as yourbusiness.co.za into the addresses computers use to reach your website and your mail. Each answer is cached for a time the zone sets, called the time to live (TTL), so when you change a record the old answer lingers until that time runs out. What people call "propagation" is those caches expiring at different moments around the world. This article explains a lookup step by step, how to make changes without disruption, and what each common record does.
What happens in a lookup
When someone opens your website, their device does not know where it lives. It asks a recursive resolver, usually run by their internet provider or a public DNS service, and the resolver finds the answer on their behalf:
- The resolver asks the root servers, which point it to the servers for .za.
- The .za servers point it to the servers for co.za.
- The co.za servers return the nameservers for yourbusiness.co.za. This is the delegation your registrar set up when you chose nameservers.
- Your nameservers are authoritative: they hold the zone, the list of records for the name, and return the answer, for example the address of the web server.
- The resolver hands the answer to the device and caches it, so the next person who asks gets it straight away.
Every step except the last is also cached. A busy resolver rarely has to start from the root.
TTL: how long an answer is kept
Every DNS record carries a TTL, a number of seconds. The DNS standard, RFC 1035, defines it as the time a record may be cached before the source should be consulted again. A TTL of 3600 means a resolver may keep using the answer for an hour.
TTL is a trade-off. A long TTL means fewer lookups and faster answers. A short TTL means changes reach visitors sooner. Zones commonly use somewhere between five minutes and a day.
Why "propagation" takes time
Nothing is pushed out to the internet when you edit a record. Your nameservers start giving the new answer at once. But every resolver that looked the name up recently still holds the old answer, and keeps using it until its TTL runs out. Since each resolver cached the record at a different moment, the change appears to spread unevenly: one person sees the new site, a colleague still sees the old one.
A nameserver change has two layers of caching. The delegation in the parent zone (the co.za servers in the example) has its own TTL, set by the registry, and the records in your new zone have theirs. Until the delegation's TTL expires, some resolvers keep asking your old nameservers.
"Not found" is cached too. RFC 2308 allows resolvers to cache a "this name does not exist" answer, for a time set by the zone's SOA record. If someone looked up a new subdomain before you created it, they may keep getting "not found" for a while.
How to change DNS without disruption
RFC 1034 describes the routine: if a change can be anticipated, reduce the TTL before the change and raise it again afterwards.
- Lower the TTL on the records you will change, for example to 300 seconds, at least one old TTL ahead of the change. If the old TTL was a day, do it a day before.
- Make the change and check it against your nameservers directly.
- Keep the old service running until the old TTL has passed, so visitors who still have the old answer are not stranded.
- Raise the TTL again once everything is settled.
For a move between providers, build the complete zone at the new provider before you switch the nameservers, and compare it record by record with the old one.
The record types you will meet
| Record | What it does | Example use |
|---|---|---|
| A | Points a name to an IPv4 address | The website's server |
| AAAA | Points a name to an IPv6 address | The website's server over IPv6 |
| CNAME | Makes one name an alias of another | www pointing to the main domain |
| MX | Names the servers that accept mail for the domain | Your mail server, with a priority |
| TXT | Holds text | SPF, DKIM, DMARC and verification codes |
| NS | Names the authoritative nameservers | Set at the registrar and in the zone |
| SOA | Marks the start of the zone and holds its timers | Serial number, negative caching time |
| SRV | Gives the server and port for a service | Calendar, chat or voice services |
| CAA | Names the certificate authorities allowed to issue certificates | Limiting certificates to one authority |
Two rules catch people out:
- A CNAME cannot sit beside other records. If a name has a CNAME, it may have nothing else, so the bare domain (which needs its SOA, NS and usually MX records) cannot be a CNAME.
- An MX or NS record must not point to a CNAME. It must point to a name with its own A or AAAA record.
The three mail records
Three TXT records decide whether mail from your domain is trusted:
- SPF (RFC 7208) lists the servers allowed to send mail for your domain. A domain may have only one SPF record, so a second sending service is added to the existing record, not given a new one.
- DKIM (RFC 6376) publishes the public key that receiving servers use to check the signature on your outgoing mail, at an address such as selector._domainkey.yourbusiness.co.za.
- DMARC, published at _dmarc.yourbusiness.co.za, tells receiving servers what to do with mail that fails SPF and DKIM, and where to send reports. Its current specification is RFC 9989, published in 2026.
Our knowledgebase guide on protecting your domain from spoofing shows how to set them up on Noiz hosting.
DNSSEC in one paragraph
DNSSEC adds digital signatures to DNS answers, so a validating resolver can confirm that an answer came from the real zone and was not altered on the way. It does not encrypt anything. The signatures form a chain of trust from the root, and the link between your zone and the registry is a DS record held at the registry. That link must be handled with care when a domain or its DNS moves: the .za registry warns that a DNSSEC error can make a correctly hosted website look unavailable to validating resolvers.
DNS at Noiz
On every Noiz hosting plan, the DNS zone for your domain sits in the Plesk panel beside the website and the mail, on our nameservers ns1.noiz.co.za and ns2.noiz.co.za. Our guide on adding and editing DNS records in Plesk covers the panel. A domain without hosting can use DNS Only, a zone on our servers that you run from your account. The Cloudflare add-on puts a hosted domain's DNS on Cloudflare, kept in sync with the records in your Noiz control panel.
Find out more, and see every extension's price, on Domains at Noiz.
Sources
Checked 19 October 2026.
Standards (RFC Editor)
- RFC 1034, Domain names: concepts and facilities, section 3.6
- RFC 1035, Domain names: implementation and specification, sections 3.2 and 3.3
- RFC 2181, Clarifications to the DNS specification, sections 8 and 10
- RFC 2308, Negative caching of DNS queries, section 5
- RFC 2782, DNS SRV records
- RFC 3596, DNS extensions to support IPv6
- RFC 4033, DNS security introduction and requirements
- RFC 6376, DomainKeys Identified Mail (DKIM)
- RFC 7208, Sender Policy Framework (SPF)
- RFC 8659, DNS Certification Authority Authorization (CAA)
- RFC 9364, DNS Security Extensions (DNSSEC)
- RFC 9499, DNS terminology
- RFC 9989, DMARC
Registry
Noiz
Note: while some of this content was produced with the help of AI, the final editing has been done by a real human being.
