Every website relies on the Domain Name System to be found. When someone types your address, the DNS turns that name into the number of the server holding your site. Most of the time it works quietly in the background.
Things change when you move hosts, add email or connect a new service. Suddenly you are looking at a screen full of records with short, cryptic names. Knowing what each one does makes those jobs far less stressful and helps you avoid taking your site offline by accident.
How the DNS finds your website
The auDA explanation of domain names and the DNS puts it simply. The DNS matches domain names with the numerical Internet Protocol addresses that identify where a site is hosted. Numbers such as 1.1.1.1 are hard for people to remember, so names sit on top of them.
That matching is handled by a global network of name servers working in a hierarchy. A query passes through that network until it reaches the authoritative name servers for the domain. Those servers hold the real records for your site. auDA notes that .au DNS queries are processed within 250 milliseconds 99.99 per cent of the time.
The records themselves were defined decades ago. RFC 1034, Domain Names Concepts and Facilities was published in November 1987 and remains an Internet Standard. Its companion, RFC 1035, sets out the main record types still used today. The descriptions below draw on those documents.
The records most sites use
A and AAAA records
An A record points a name at a host address. In RFC 1034 that is a 32 bit IP address, the older IPv4 format. An AAAA record does the same job for the newer IPv6 format. RFC 3596 describes it as storing a single IPv6 address, which is 128 bits long.
These are the records that send visitors to your web server. When you change hosts, the A record is usually the one you edit. Your new provider gives you the address to use. Some hosts also supply an IPv6 address for an AAAA record.
CNAME records
A CNAME makes one name an alias of another. RFC 1034 says it identifies the canonical name of an alias. A common use is pointing the www version of a domain at the bare domain. Many outside services also ask you to add a CNAME so they can work under your own domain.
There is one firm rule to remember. RFC 1034 says that if a CNAME is present at a name, no other data should be present. The bare domain already holds NS records, so a CNAME there clashes with that rule. This is why hosts ask for an A record on the bare domain.
MX records
An MX record identifies a mail exchange for the domain. In plain terms, it tells other servers where to deliver your email. Each MX record carries a preference number. RFC 1035 states that lower values are preferred, so the lowest number is tried first.
Email and website can live with different providers, and MX records are what keep them separate. That matters when you move a website, because email should keep flowing to the same place. The same records come into play when you set up one of the email marketing tools for small businesses, which often ask for extra DNS entries.
TXT records
RFC 1035 says TXT records hold descriptive text, and their meaning depends on where they are found. Today they are used heavily for proving you own a domain. Search tools, email services and certificate providers often ask you to add one. They also carry email sender rules, which deserve a separate guide.
NS records
NS records name the authoritative name servers for the domain. They decide which company’s DNS settings actually count. If your NS records point to your registrar, edits made at your web host will do nothing. Check this first whenever a change seems to have no effect.
Time to live and why changes take a while
Each record carries a TTL, or time to live. RFC 1034 defines it as a number of seconds describing how long a record can be cached before it should be discarded. The person managing the domain sets that value. A zero TTL prohibits caching altogether.
Caching is why DNS is fast. Resolvers keep recent answers and reuse them rather than asking the authoritative servers every time. The side effect is that an old answer can linger until its TTL runs out. That delay is what people usually mean by DNS propagation.
You can plan around it. Lower the TTL on the records you intend to change a day or so before the change. Once the move is done and working, raise it again. Our guide to migrating your website to a new hosting provider covers where this fits in the wider move.
Keeping your DNS safe and tidy
Write down your current records before editing anything. A simple screenshot or exported copy lets you put things back quickly. Change one record at a time and test it before moving to the next. Mistakes in MX records in particular can stop email without any obvious warning.
Keep control of the account where your DNS lives. It should be in the business name with login details the owner holds, rather than a past contractor. This is worth sorting out early, and it belongs on any online business start up checklist. Remove old records for services you no longer use so the zone stays easy to read.
Finally, remember that DNS is only one part of how quickly a site appears. Once the name resolves, the server and the page itself take over. If visitors still find the site slow, look at hosting and page weight next. Our article on website speed and SEO picks up from there.
Frequently asked questions
What is the difference between an A record and a CNAME?
An A record points a name straight at an IP address. A CNAME points a name at another name, which then resolves to an address. Hosts generally ask for an A record on the bare domain and a CNAME for www.
Why is my DNS change not showing yet?
Resolvers may still be holding the old answer until its TTL expires. Also check your NS records. If they point somewhere else, your edit has been made in the wrong place.
Will moving my website affect my email?
Only if your MX records change. Email delivery follows the MX records, not the A record. Leave them as they are unless your email is moving too.