DNS Records Explained for Non-Experts Who Manage Their Own Domain

DNS records are the instructions that tell the internet where your domain’s services live, and once you understand the handful of common types, you can manage your own domain without guessing. This guide explains DNS records for non-experts who manage their own domain, focusing on the mechanics you will actually encounter in a terminal or a control panel, not the theory behind the whole system.

What a DNS record actually is

Every DNS record is a small piece of text stored on a nameserver, and it follows a strict format defined by the DNS protocol. When you query a domain, your computer sends a UDP packet to a resolver, which then asks the authoritative nameserver for the answer. The response comes back as a series of records, each with a name, a type, a class, a TTL (time to live), and the record-specific data. The type field is what matters most to you, because it tells the resolver what kind of answer this is, an IP address, a mail server, a text string, or something else.

You can see the raw format yourself with the dig command, which is the standard tool on Linux and macOS, and available on Windows if you install it. Run this against your own domain to see the actual records:

dig example.com ANY +noall +answer
; <<>> DiG 9.18.0 <<>> example.com ANY +noall +answer
;; global options: +cmd
example.com.    3600    IN    A    93.184.216.34
example.com.    3600    IN    NS    a.iana-servers.net.
example.com.    3600    IN    MX    10 mail.example.com.

Notice the columns: the name, the TTL in seconds, the class (always IN for internet), the type, and then the data. That is the entire mental model you need. Every record type is just a different kind of data in that last column, and the type tells the resolver how to interpret it.

The record types you will actually use

The A record maps a hostname to an IPv4 address, and it is the most common record you will edit. If you point example.com at a server, you create an A record with the server’s IPv4 address. The AAAA record does the same for IPv6, and you should create both if your host gives you both addresses, because some visitors will only have IPv6 connectivity. The CNAME record is an alias, it maps one name to another name instead of to an IP. For example, www.example.com can be a CNAME pointing to example.com, so you only update the A record in one place. Do not use a CNAME for the root domain itself, because the DNS protocol forbids it, and many resolvers will silently ignore it.

The MX record tells mail servers where to deliver email for your domain. It includes a priority number, lower numbers are tried first, and then a hostname. You cannot put an IP address in an MX record, it must be a hostname that itself has an A or AAAA record. The TXT record is a free-form text field, and it is used for verification tokens, SPF email authentication, and DKIM keys. You will often see long TXT records that look like random strings, and that is normal, they are just opaque data for another system to read. The NS record lists the authoritative nameservers for your domain, and you usually set these at your registrar, not in your own zone, but you will see them in every query.

Less common but still useful are SRV records for service discovery, like _sip._tcp.example.com, and PTR records for reverse DNS, which map an IP back to a name. You will rarely edit these yourself, but you should recognize them when you see them in a query result, so you do not mistake them for a problem.

How to troubleshoot a DNS change that will not propagate

When you change a record, the old value does not disappear instantly. Every resolver caches the result for the TTL you set, and some resolvers ignore short TTLs and cache longer anyway. The first thing to check is the TTL on the old record, because if it was 86400 seconds (24 hours), you will wait a day before most users see the new value. Lower the TTL to 300 seconds before you make a planned change, wait for the old TTL to expire, then make the edit. After the change, verify with dig against the authoritative nameserver directly, bypassing the cache entirely:

dig @ns1.example.com example.com A +noall +answer
; <<>> DiG 9.18.0 <<>> @ns1.example.com example.com A +noall +answer
;; global options: +cmd
example.com.    300    IN    A    192.0.2.10

If that shows the new value but dig example.com A without the @ still shows the old one, the problem is caching, not your record. You can flush your local resolver with sudo systemd-resolve --flush-caches on systemd systems, or sudo dscacheutil -flushcache on macOS, but you cannot flush anyone else’s cache. You just wait. If the authoritative query also shows the old value, then your change did not save, or you edited the wrong zone. Check that you are editing the zone for the exact domain name, including the trailing dot, and that you saved the file or clicked the apply button in your control panel.

Another common mistake is a trailing dot in the data field. In DNS, a fully qualified domain name ends with a dot, like mail.example.com. If you omit it, the resolver appends your domain name, turning mail into mail.example.com.example.com. Most control panels add the dot for you, but if you are editing a raw zone file, you must include it. Use dig to check the exact name in the answer, and if you see a doubled domain, that is your problem.

Reading a zone file directly

If you manage your own nameserver, you will edit a zone file. The format is the same as the dig output, but with directives. A minimal zone file looks like this:

$ORIGIN example.com.
$TTL 3600
@    IN    SOA   ns1.example.com. admin.example.com. (
                2025010101 ; serial
                7200       ; refresh
                3600       ; retry
                1209600    ; expire
                3600 )     ; minimum
@    IN    NS    ns1.example.com.
@    IN    A     192.0.2.10
www  IN    CNAME example.com.

The $ORIGIN sets the base domain, and every name that does not end with a dot is relative to it. The @ symbol means the origin itself. The SOA record is the start of authority, and it contains a serial number that must increase every time you change the file, otherwise secondary nameservers will not pick up the update. The serial is a date plus a revision, like 2025010101, and you increment the last two digits for each edit. The other numbers in the SOA are timing values for refresh, retry, expire, and negative caching, and you can leave them at the defaults your nameserver software provides.

When you edit a zone file, always run a syntax check before reloading. The command depends on your nameserver software, but for the most common one it is named-checkzone. Run it against the file, and it will tell you if you have a missing dot, a bad IP, or a duplicate record. Fix those errors before you reload, because a broken zone file can take your whole domain offline, not just the record you were editing.

What to do next

Start by running dig on your own domain and reading the output line by line, matching each record type to what you now know. Then make one small change, like adding a TXT record for a verification token, and watch it appear with dig after a few minutes. That hands-on loop, edit, query, verify, is the fastest way to build confidence, and it will make every future change feel routine instead of risky.