DNS Records Explained

The Domain Name System (DNS) gives resources stable human-readable names to solve various potential internet problems; for example, it translates domain names to IP addresses so users don’t have to remember long numbers to access websites. Administrators can create records of several standardized types, and each type solves a specific problem. If you ever wondered how DNS records work, what each record type does, and how to manage DNS records, this article is the right place to start.

What Is a DNS Record?

Every interaction on the internet involves a translation process, where a human-readable domain name becomes a machine-understandable IP address. DNS records are the essential building blocks of this process. They come in several types to handle different aspects of internet operations, such as routing emails (MX records) and aliasing one domain name to another (CNAME records.)

DNS records are aliases for short pieces of text stored in a DNS database, and each one maps a specific domain to an IP address or another piece of data. For example, if you have the alias example.com, you can send it to a DNS server to connect to the aliased value 2606:2800:220:1:248:1893:25c8:1946.

Alt:

Each DNS record contains various pieces of information like the name of the host, the type of DNS record, the data associated with it, and the TTL (time to live) value. We’ll explain all the information inside a record later in this article. Understanding DNS records is fundamental to maintaining a reliable and efficient online presence.

What Problems Do DNS Records Solve?

The primary problems DNS records solve are giving IP addresses human-readable names (i.e., domain names) and decoupling services from one another. You achieve the latter by adding a DNS record as an indirection between services, so if one service’s IP or domain name changes, you only need to change the related DNS record, and the consuming service can remain unchanged. Let’s look at some examples:

• The A record maps a domain name like example.com to an IPv4 address like 192.168.0.1.
• The CNAME record maps a domain name like mail.example.com to another domain name like customer123.mailprovider.net.
• The TXT name maps a domain name like hello.example.com to arbitrary text like “Hello, world!”.

Don’t fret if these examples don’t yet make sense to you, as we will look into the details in the following sections of this article. By the end of the article, you’ll know what they mean!

How Do DNS Records Work?

Every time you type a URL into your browser, click on a link, or send an email (among other things) a DNS query is initiated in a process called DNS lookup. This query works its way through the hierarchical structure of the DNS until it reaches the DNS server responsible for the specific domain. This server contains the DNS records for that domain. You can learn about this process in our dedicated article under “How Does DNS Lookup Work?”

Each domain has several DNS records associated with it, like an address book, that help to direct traffic to the right location. For instance, an A record translates a domain name into an IP address that computers can understand. Here’s a table showing the range of DNS records:

When a DNS server receives a query, it checks the DNS records of the relevant domain in its zone file. The server then responds with the corresponding record’s data, effectively directing the user’s device to the correct IP address.

A DNS record is an entry in a zone used by a DNS server. The DNS system is split into zones, each managed by a DNS server that keeps zone-related records in a zone. The entries in this file have the following structure:

• The name field contains a fully qualified domain name, the alias discussed earlier.
• The type field contains the record type; it describes how to interpret the data field.
• The data field contains the aliased text, for example, an IP address or another domain.
• The time to live (TTL) contains the time (in seconds) a client can cache the resolved data locally.
• The class field contains a protocol class. On the internet, its value is always IN.

Common DNS Record Types

Now that you understand DNS records and how they work, let’s look at the most common record types. Again, DNS records are just aliases for text; their type determines their purpose.

A and AAAA DNS Records

These types of DNS records map domain names to IP addresses. They are at the end of every resolution process because computers can only communicate with each other through IP addresses. There are two IP address record types; the A type is for IPv4, and the AAAA type is for IPv6 addresses.

The internet grew so much that IPv4 could no longer handle the number of devices requiring IP addresses. IPv6 allows significantly more devices to be addressed on the internet.

Examples of A and AAAA DNS records:

CNAME and ANAME DNS Records

CNAME records allow you to map a subdomain to another domain, unlike A/AAAA records, which only allow you to map a domain to an IP address. Some DNS providers offer non-standard ANAME records, sometimes called ALIAS records, or CNAME Flattening.

A common use case for the ANAME record is hosting your website on the servers of a third-party provider that gives you a subdomain but no fixed IP address. You can’t create an A record because you don’t have an IP address, nor can you create a CNAME record because it would require a subdomain. An ANAME record is the only solution.

Examples of CNAME and ANAME DNS records:

If you want to learn more, check out our CNAME article.

The NS DNS Record Type

This record type defines the authoritative DNS servers for a DNS zone. Authoritative means the server holds all DNS records for that zone instead of caching DNS server responses from other zones.

If you own the example.com domain, you add an NS record for your DNS servers to the TLD server that manages all “com” domains. You can also add multiple NS records, providing clients with secondary DNS servers for load balancing or failover purposes.

The target domains of NS records can be in the same zone, but don’t have to be; in fact, most websites use the DNS servers of their domain provider, which the provider hosts in their zone. NS records are crucial for DNS because they’re part of the mechanism that links all DNS servers to form the global DNS tree structure. Here are some examples of NS DNS records:

MX DNS Records

MX records are used for mail service discovery. If you send an email, your email client will use the part after the @ in a DNS query for an MX record in order to find the receiving mail server. Here are some examples of MX DNS records:

If you want to learn more about MX records, check out our MX record article.

TXT DNS Records

You use TXT records for all DNS-related use cases that don’t have a dedicated record type. You can use a TXT record to map a domain name to arbitrary text. The size limit is 255 characters (or octets.)

An example of a use case for TXT records is domain verification, where you create a special TXT record to prove you own the domain. Another example is stable URLs for content-based identifiers (CIDs) in the interplanetary file system (IPFS.) These CIDs change when the content they address changes, so saving them in a TXT record enables IPFS clients to query that record to ensure they always get the newest CID for their desired content. Here are some examples of TXT DNS records:

How to Manage DNS Records

You can manage DNS records by using the web UI of your domain provider or by running your own DNS server. Using the web UI of your domain provider is the easiest option. It will present you with a list of records and allow you to create, update, and delete them. Below is a screenshot from the Gcore DNS record UI. The UI of your provider may look different, but overall it will have similar features.

Gcore allows you to import DNS records from a zone file, specifically, a BIND zone file. BIND is a popular open-source DNS server, and many providers and DNS server implementations use the BIND zone file format as their import and export format, so let’s have a quick overview of how to use it.

How to Manage DNS Records with a Zone File

Caution: As we dive into the complexities of zone files and DNS record intricacies, note that the upcoming discussion is particularly tailored for those with a higher level of technical expertise in DNS operations—beginners, however, should not be deterred, as every expert was once a beginner!

Each authoritative DNS server is responsible for a zone, which is made up of one or more domain names. Nowadays, popular DNS servers like PowerDNS and Microsoft DNS store and manage their DNS records via databases. However, the BIND zone file format is still used as a general text representation. You can create a zone file to define DNS records or export one from an existing provider or system, and then import it into a DNS server that stores them in their database.

Each line in the zone file that starts with a domain name or a placeholder becomes a DNS record, and each line that begins with a dollar sign becomes a variable. Semicolons initiate comments, and parentheses let you split record definitions over multiple lines.

Let’s look at the following example:

; zone file of examples.com$ORIGIN example.com.$TTL 3600@ IN SOA ns.example.com. admin.example.com. (    2022040101 ; Zone file serial number    3600       ; Refresh    1800       ; Retry    3600       ; Expire    3600)      ; Minimum TTL  @ IN NS ns.example.com.@ IN MX 10 mail.example.com.@ IN A 192.0.2.1mail IN A 192.0.2.2ns IN A 192.0.2.3@ IN AAAA 2001:db8::1www IN CNAME example.com.@ 7200 IN TXT "v=spf1 ip4:192.0.2.1 -all"customer1 IN NS ns.customer1.net.

Now let’s break down what this zone file tells us:

• The first line is a comment that describes to which zone the file belongs.
• The second line defines the $ORIGIN variable with the value example.com. The trailing dot makes it a fully qualified domain name that starts from the root of all domains. You can see it a bit like an absolute file path. To use the $ORIGIN variable, you can use the @ symbol as a placeholder. Everywhere you write @, the content of the $ORIGIN variable will be added—in this case, example.com.
• Use the $TTL variable to set the default caching time for each DNS record that doesn’t define its TTL explicitly.
• The SOA record is mandatory for a zone file; the example uses parentheses to split it over multiple lines for readability and includes comments to explain the numbers. It also uses the @ placeholder, so we don’t have to repeat our domain root.
• One NS record is also mandatory to define the authoritative DNS server of the zone.
• Subdomains are the next element. The A record for the email server only uses mail as a name. Since it doesn’t include a trailing dot, it will become a subdomain of the domain root.
• The TXT record defines an explicit TTL with 7200 seconds, which overrides the default of 3600.
• The last entry is an NS record for a subdomain; it delegates the resolution of the customer1 subdomain and all the subdomains under it to another DNS server.

Conclusion

DNS records let you define domain names for everything connected to the internet, including IP addresses, other domain names, email addresses, and anything you can represent in a short text. NS records even include the very mechanism that binds the distributed DNS network together. Since DNS is essentially a huge distributed lookup table, you can use it for all kinds of data you want to make accessible via a domain name, including addresses for mail or DNS servers, proofs of ownership, and more obscure things like CIDs for IPFS resources.

Gcore provides DNS servers for your domains and allows you to manage your DNS records in an intuitive UI. The servers are in different locations worldwide to ensure low latency resolutions for your users and come with automatic failover out-of-the-box.

Try it for free!