DNS, and the records you will actually edit

You type riztechacademy.com, not 76.76.21.21. DNS — the Domain Name System — is what turns the name into the address, and it is the internet's phone book. As a DevOps person you will edit DNS records to point a domain at a server, set up a subdomain, configure email, or verify you own a domain — and you will absolutely at some point spend an afternoon on a bug that turns out to be DNS. Understanding it well saves that afternoon. This lesson is DNS and the records you will actually edit.

What DNS does

DNS translates a human-friendly name (riztechacademy.com) into the IP address the network needs (the previous lesson). When your browser needs to reach a site, it first asks DNS "what is the IP for this name?", gets an answer, and then connects to that IP. This lookup happens before every connection to a new name, and it is invisible until it breaks — at which point nothing reaches the server, because there is no address to reach.

The lookup is distributed and hierarchical: your machine asks a resolver (usually your ISP's or one like 8.8.8.8), which, if it does not already know the answer, walks the hierarchy — the root servers point to the .com servers, which point to the name servers for riztechacademy.com, which hold the actual records. You do not manage that machinery; you manage the records at the end of it, through your domain registrar or DNS provider (Cloudflare, Route 53, etc.).

The records you will actually edit

A domain has a set of DNS records, each a mapping of a name to something. A handful matter for everyday work:

• A record — maps a name to an IPv4 address. riztechacademy.com → 203.0.113.10. This is the one you set to point a domain at a server. (AAAA is the same for IPv6.)
• CNAME — maps a name to another name (an alias). www.riztechacademy.com → riztechacademy.com, or a subdomain pointing at a platform's hostname (app.example.com → myapp.vercel.app). Use a CNAME when you want a name to follow wherever another name points, rather than pinning an IP.
• MX record — where email for the domain should go (the mail servers). You set these when configuring email (Google Workspace, etc.).
• TXT record — arbitrary text, used for verification and policy: proving you own a domain, and email security records (SPF, DKIM, DMARC). You will add TXT records constantly for "verify your domain" steps.
• NS record — which name servers are authoritative for the domain. Set at the registrar; determines who answers for your domain.

Ninety percent of the DNS work you do is: set an A or CNAME to point a name at a server or platform, and add TXT records to verify ownership. Knowing those three by name already makes you effective.

TTL and propagation: why changes are not instant

Here is the single most important practical fact about DNS, and the cause of most DNS confusion. Every record has a TTL (time to live) — how long resolvers are allowed to cache the answer before asking again. When you change a record, machines that cached the old answer keep using it until their cache expires. So a DNS change can take minutes to hours to be seen everywhere — this is called propagation.

The consequences you must internalise:

• A change is not instant. After you update an A record, you may still reach the old server for a while, and someone else may see the new one — inconsistently — until caches expire. This is normal, not a bug.
• Lower the TTL before a planned change. If you know you will move a server next week, set the TTL low (e.g. 300 seconds) now, so that when you make the change, the old answer expires quickly. Then raise it again afterwards.
• "It works for me but not for them" during a DNS change is usually caching, not a real difference — give it time, or flush the cache.

More engineers have been fooled by DNS caching than almost anything else — a change that "did not work" that was actually just not propagated yet. When you change DNS, wait and verify, and remember the TTL.

Verifying DNS from the command line

You do not trust the web console blindly; you check what DNS actually returns with dig (or nslookup):

dig riztechacademy.com            # full answer, including the A record and TTL
dig riztechacademy.com +short     # just the answer — the IP address
dig www.riztechacademy.com CNAME  # look up a specific record type
dig riztechacademy.com MX         # the mail records
dig @8.8.8.8 riztechacademy.com   # ask a specific resolver (Google's), bypassing local cache

dig ... +short is the quick "what does this resolve to right now?" check. Asking a specific resolver (@8.8.8.8) is how you check whether a change has propagated to the wider internet versus just your machine. These commands turn "is my DNS right?" from a guess into a fact — and you will run them every time you change a record. (The debugging lesson returns to dig alongside the other network tools.)

Check your work

DNS translates a name → IP address (the internet's phone book); the lookup happens before every connection to a new name and is distributed/hierarchical (resolver → root → TLD → the domain's name servers). You manage the records, not the machinery, via your registrar/DNS provider.

Records you edit: A (name → IPv4; point a domain at a server; AAAA for IPv6), CNAME (name → another name/alias; follow a platform hostname), MX (where email goes), TXT (verification + email security: SPF/DKIM/DMARC), NS (authoritative name servers). Most work = A/CNAME to point, TXT to verify.

TTL & propagation (the big one): each record has a TTL = how long resolvers cache it; a change is not instant — old cached answers persist until TTL expires (propagation). Lower the TTL before a planned change; "works for me not them" during a change is usually caching. Wait and verify.

Verify with dig: dig name +short (what it resolves to now), dig name CNAME/MX (a record type), dig @8.8.8.8 name (ask a specific resolver — check propagation vs local cache).

Practice

1. Explain what DNS does in one sentence, and why nothing reaches a server if DNS is broken.
2. Match each record type (A, CNAME, MX, TXT, NS) to what you would use it for.
3. You are pointing riztechacademy.com at a new server IP — which record do you change, and to what?
4. Explain TTL and propagation, and why a DNS change is not seen everywhere immediately.
5. You plan to migrate servers next week — what do you do to the TTL now, and why?
6. Use dig +short on a real domain, then dig @8.8.8.8 on it, and explain what each tells you.

Official documentation

• MDN — DNS (glossary) — How DNS resolution works.
• Wikipedia — DNS — The system, record types, and how TTL/caching work.
• Wikipedia — List of DNS record types — A, CNAME, MX, TXT, NS and the rest.

Next: HTTP, status codes and headers.