Types of DNS Records & Their Functions

DNS records are sets of instructions that connect domain names to IP addresses within DNS servers. DNS itself is a system for translating human-friendly domain names into machine-friendly IP addresses. This allows you to browse the web using easily memorable URLs instead of hard-to-remember numerical sequences. You can even leverage DNS to create private domains for your devices.

DNS records are the backbone of our internet experience, making complex systems simple and user-friendly. They come in several different types that we will discuss below.

A record (Address Record)

The A record is probably the most important DNS record type. The "A" stands for "address" because it shows the IP address for a specific hostname or domain. 

For instance, if you do a DNS record lookup for the domain example.com, you'll get back an IP address. Let's check out what that might look like:

‍

In this example, the IP address for example.com is 93.184.216.34. The A record allows us to navigate the web with easy-to-remember domain names instead of typing in a string of numbers. It links a domain name to an IPv4 address. 

If you ever wondered why you can simply type "example.com" into your browser instead of remembering "93.184.216.34," that’s all thanks to the A record.

The main job of an A record is to facilitate IP address lookup. When you type a domain name into your web browser, the A record helps direct you to the right server by translating the domain name into its corresponding IP address. This is why you don’t have to memorize IP addresses to visit your favorite websites.

A records are also often used in the domain name system-based blackhole list (DNSBL). This is a method of blocking mail from known spam sources. By returning a specified IP address for domains known to send spam, mail servers can easily filter out unwanted messages.

AAAA record (IPv6 Address Record)

AAAA records, often called "quad A" records, are like A records but for IPv6 addresses, the longer and more complex next-generation IP addresses. 

Instead of the typical IPv4 address like "192.0.2.1," an AAAA record points to an IPv6 address like "2001:0db8:85a3:0000:0000:8a2e:0370:7334."

IPv6 addresses were created because we were running out of IPv4 addresses. These new addresses allow for a massive number of unique combinations. Configuring an AAAA record is similar to setting up an A record, but it uses this extended format for the address.

When you set up an AAAA record, you specify a Fully Qualified Domain Name (FQDN) and point it to an IPv6 address. Let’s say you have a website at "example.com." You might create an AAAA record that looks something like this:

‍

This tells DNS that "example.com" maps to the IPv6 address "2001:0db8:85a3:0000:0000:8a2e:0370:7334." 

Another useful feature of AAAA records is that you can have multiple AAAA records for the same domain. This setup can provide redundancy. For instance, both "server1.example.com" and "server2.example.com" can point to the same IPv6 address. Here's an example:

‍

When querying AAAA records, you can use the `dig` command to find the IPv6 address associated with a domain. The command might look like this:

‍

The result will show you the fully qualified domain name, the time-to-live (TTL), and the IPv6 address. So in the output, you would see something like this:

‍

In DNS management systems, setting up AAAA records involves specifying the name, TTL, and the IPv6 address. Despite the complexity of IPv6 addresses compared to IPv4, setting up AAAA records is straightforward and works similarly to A records, just with a different type of address.

CNAME (Canonical Name) record

CNAME records are crucial in DNS management. They are like aliases that map one domain name to another. For example, if you have a primary domain, say `example.com`, and you also want `www.example.com` to resolve to the same IP address, a CNAME record is your friend. 

Instead of maintaining separate A records, you can create a CNAME record as follows:

‍

This setup directs `www.example.com` to follow the path of `example.com`. If the IP address for `example.com` changes, you only need to update it in one place, and `www.example.com` will automatically follow. It's a neat way to simplify domain management.

But there's a catch. CNAME records must point to another domain, not directly to an IP address. Here’s what that looks like in action:

‍

In this scenario, `shop.example.com` is an alias for `store.example.com`, which resolves to `192.0.2.1`.

CNAME records are particularly handy for pointing multiple services to the same resource. Imagine you’re running an FTP server and a web server on different ports but the same IP. You can use CNAME records to point `ftp.example.com` and `www.example.com` to `example.com`.

‍

Here, if `example.com`'s IP changes, so do `ftp.example.com` and `www.example.com`.

However, CNAME records have restrictions. If a CNAME record is present at a node, no other data should be at that node. This rule ensures that data for a canonical name and its aliases can't conflict. 

Also, CNAMEs cannot exist at the zone apex (the root of a DNS zone), which must have an SOA record and may have other records like NS and MX.

Lastly, avoid chaining CNAMEs since it can lead to inefficient lookups and loops:

‍

This configuration creates an unresolvable loop, which the DNS resolver cannot handle.

So, CNAME records are fantastic for simplifying DNS management and ensuring consistency but you should always remember their constraints.

MX (Mail Exchange) record

MX records are the guides that direct emails to the right mail server. When someone sends an email to "user@example.com," the MX record tells the sending mail server where to deliver the message.

Setting up an MX record is straightforward. You specify the priority and the mail server's domain name. Here's an example to give you a clear picture:

‍

In this record, `example.com` is the domain, `3600` is the Time-to-Live (TTL), `IN` denotes the Internet class, `MX` stands for Mail Exchange, `10` is the priority, and `mail.example.com` is the mail server.

The priority number is crucial. Lower numbers have higher priority. So, if you have multiple mail servers, the one with the lowest number gets the mail first. For instance:

‍

Here, emails will first attempt to be delivered to `mail1.example.com`. If it's unreachable, the system will try `mail2.example.com`. This setup ensures that your emails have a fallback option, making your mail system more reliable.

It's not just about pointing to the mail server. You can also integrate MX records with other DNS records for added functionality. 

For example, combine MX with TXT records to enhance email security. TXT records can hold SPF (Sender Policy Framework) data that specifies which mail servers are authorized to send emails on behalf of your domain. 

Here's how you might set that up:

‍

In this case, the TXT record ensures that only specified servers can send emails for `example.com`, reducing the risk of email spoofing.

Another interesting feature is the use of multiple MX records for load balancing. By assigning the same priority to different mail servers, you can distribute the email load evenly. For instance:

‍

With this setup, emails are distributed between `mail1.example.com` and `mail2.example.com`, offering balanced load and redundancy.

Remember, when setting up MX records, you should always point to a domain name, not an IP address. The DNS system will resolve the domain name to its corresponding IP address.

Using the `dig` command, you can query the MX records for a domain to check your setup. The command would look like this:

‍

The output will show you the domain name, the TTL, the MX type, the priority, and the mail server.

MX records are fundamental for email functionality, guiding your emails to the right place while offering options for redundancy and load balancing. They work hand-in-hand with other DNS records, like TXT for enhanced security, making sure your emails get where they need to go, efficiently and securely.

TXT (Text) record

TXT records, or text records, add flexibility to DNS. They can store all kinds of arbitrary text. Historically, people used them to keep human-readable notes about servers and the organizations they belong to.

For example, a domain called `example.com` might have a TXT record that says, "This domain is used for documentation purposes." Here's how that would look in a DNS TXT record:

‍

This string of text, although freely chosen, doesn’t follow a particular standard. It's just a string of text that anyone can read and understand.

But TXT records aren’t just for humans. They can also store machine-readable data. This is incredibly handy for things like email verification, security policies, and more. 

Take the Sender Policy Framework (SPF) for example. To specify which mail servers are allowed to send emails on behalf of your domain, you’d add a TXT record like this:

‍

This record says, “Only these IP addresses are allowed to send emails for example.com.” It's a great way to combat email spoofing.

Another common use of TXT records is for Domain-based Message Authentication, Reporting, and Conformance (DMARC). DMARC helps email receivers determine if an email claiming to come from your domain is authentic. Here’s an example of how that might look:

‍

In this case, the DMARC policy is set to “none,” meaning it’s in monitoring mode, and all reports should be sent to `dmarcreports@example.com`.

Sites often use TXT records for domain verification purposes too. For example, Google or Facebook might ask you to add a TXT record to verify that you own the domain. 

It’s also common to see TXT records used in custom email services. For instance, Amazon Simple Email Service (SES) might ask you to add a record like this for domain verification:

‍

In this example, `pmBGN/7MjnfhTKUZ06Enqq1PeGUaOkw8lGhcfwefcHU=` is a unique token that Amazon SES uses to verify your domain.

And for something like Brand Indicators for Message Identification (BIMI), which helps to display your brand logo next to your email messages, you might add a TXT record like this:

‍

This tells email clients where they can find your brand logo and its certification.

Overall, TXT records give you a lot of versatility. Whether you're adding human-readable notes, verifying a domain, or enhancing email security, they can adapt to your needs.

NS (Name Server) record

NS records are the ‘road signs’ that guide DNS queries to the right place. When someone types a domain name into their browser, an NS record helps find the authoritative DNS server for that domain.

If you own the domain example.com, to let DNS resolvers know which servers are authoritative for your domain, you’d set up NS records. A couple of them might look like this:

‍

Here, example.com has two name servers, ns1.example.com and ns2.example.com. The `3600` represents the Time-to-Live (TTL), measured in seconds. This determines how long DNS resolvers should cache this information.

NS records allow your domain to function correctly on the internet. Without them, resolvers wouldn't know where to go to get the IP address of your domain. The chain of lookups would break. In simpler terms, no one would find your website.

NS records are also pivotal for subdomains. Let's say you have a subdomain blog.example.com. You'd need to set up NS records for that as well, possibly pointing to different name servers:

‍

This way, any queries for blog.example.com are directed to ns3.example.com and ns4.example.com.

A convenient feature of NS records is their redundancy. Typically, you’ll have multiple NS records for each domain. This ensures that if one name server goes down, others can still handle the requests. 

PTR (Pointer) record

Pointer records help map IP addresses to domain names in the DNS. It's like a reverse lookup. While most DNS records map a domain name to an IP address, PTR records do the opposite.

Think about what happens when you need to find out the address behind a phone number. A PTR record is similar but for IP addresses and domain names. They store the domain name associated with an IP address. This comes in handy, especially for email servers.

Here's an example: you have an IP address, say `10.0.0.1`, and you want to know the domain name linked to it. The PTR record might look like this:

‍

This record tells us that `10.0.0.1` maps to `mailserver.example.org`. The `3600` means the DNS resolver should cache this info for 3600 seconds, or one hour.

Creating these records requires a few steps. For IPv4 addresses like `10.0.0.1`, you reverse the order of the octets and add `.in-addr.arpa` at the end. So `10.0.0.1` becomes `1.0.0.10.in-addr.arpa`.

Now let's talk about IPv6. They use a different format. Imagine you have an IPv6 address like `2001:1000::12ab`. First, expand it to `2001:1000:0000:0000:0000:0000:0000:12ab`, then convert it to `200110000000000000000000000012ab`. Reverse the hex digits, and you get `ba210000000000000000000000011002`. Insert dots between each digit, resulting in `b.a.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.1.0.0.2.ip6.arpa`.

The PTR record then looks like this:

‍

PTR records are essential for email delivery. Email servers often check these records to verify the legitimacy of the sender's IP address. This is called Forward-confirmed reverse DNS (FCrDNS). It means having both forward (A or AAAA) and reverse (PTR) DNS records matching. 

If an email server at `mailserver.example.org` has an A record pointing to `10.0.0.1`, then the PTR record for `10.0.0.1` should point back to `mailserver.example.org`.

FCrDNS adds a layer of security, making it harder for spammers to fake email addresses. So, while not every domain needs a PTR record, they are crucial for reliable email transmission.

SRV (Service Locator) record

SRV records are like the GPS for your web services. They tell clients where to find specific services. So, if you need to find a coffee shop, a SRV record would be the equivalent of a map pointing you to the exact location and even telling you which door is the best to enter. 

In the DNS world, these records provide the hostname and port number for servers offering specific services.

The format for a SRV record looks like this:

‍

The `_service` is the symbolic name of the desired service. For instance, it could be `_sip` for Session Initiation Protocol. The `_proto` part specifies the transport protocol, usually either TCP or UDP. 

The `name` is the domain name for which the record is valid, like `example.com.` The `ttl` is the Time-to-Live, indicating how long the record should be cached. `IN` is the standard DNS class field, always set to `IN` for the internet. 

The `SRV` means it's a Service Locator record, while the `priority` determines the precedence, with lower values meaning higher priority. The `weight` is a relative value that affects load balancing. The `port` specifies where the service can be accessed, and the `target` is the canonical hostname of the machine providing the service.

Let's illustrate with an example:

‍

This tells us that for the SIP service over TCP, the server is `sipserver.example.com` and it listens on port 5060. The priority is 0, the highest, and it has a weight of 5.

SRV records have an interesting approach to handling high service availability. If multiple records have the same priority, the weight field determines the proportion of traffic each server should handle. For instance:

‍

Here, `bigbox.example.com` handles 60% of the requests, while `smallbox1.example.com` and `smallbox2.example.com` share the remaining 40% equally. If all the servers with priority 10 are unavailable, the `backupbox.example.com` with a priority of 20 takes over.

SRV records are especially useful for various standardized communication protocols like SIP, XMPP, and even Minecraft servers. They play a key role in Microsoft's ecosystem, helping Windows clients locate domain controllers and Exchange Autodiscover services. 

For example, Outlook 2007 uses SRV records to find the Exchange Autodiscover service, ensuring email is set up correctly.

SOA (Start of Authority) record

SOA records are like the administrative nerve center of a DNS zone. They contain essential information that helps manage zone transfers, ensuring that DNS servers stay in sync.

Imagine you have a domain like `example.com`. At the top of its DNS zone, you'd place an SOA record. This record contains the serial number, which increments with every change you make. When a secondary DNS server sees a higher serial number, it knows to fetch the updated data from the primary server. 

Here’s an example of such an SOA record:

‍

In this record, `ns1.example.com` is the primary master name server. `admin.example.com` is the email address of the administrator, written in a special format where the "@" is replaced by a dot. If the email were `admin@example.com`, it would be encoded as `admin.example.com.`

The SOA record also includes various time settings. The `Refresh` field tells secondary servers how often to check for updates—in this case, every 7200 seconds (or 2 hours). 

The `Retry` field, set to 3600 seconds (or 1 hour), defines how long a secondary server should wait before retrying if the primary server doesn’t respond. 

The `Expire` field, set to 1209600 seconds (or 2 weeks), dictates how long secondary servers should keep trying before considering the data stale and stopping to serve it. 

Lastly, the `Minimum TTL` field, set to 3600 seconds (or 1 hour), defines the caching time for negative responses (like non-existent domain queries).

The structure of an SOA record is standardized but offers flexibility for different setups. For instance, the serial number can follow various conventions. It might simply increment with each change, start at 1 and go up, or use a date-based format like `2024081910` to indicate the 10th change on August 19, 2024.

Here’s another example in a different format:

‍

In this case, `ns2.example.com` is the primary master server, and `hostmaster@example.org` is the admin email. The `Refresh` time is set to 86400 seconds (or 24 hours), and the `Expire` time to 3600000 seconds (or approximately 42 days). This setup might be suitable for a smaller, stable zone that doesn't change often.

SOA records are required for every DNS zone and are crucial for efficient DNS management and ensuring that all your servers are on the same page.

SPF (Sender Policy Framework) record

SPF records ensure the right servers are sending emails for your domain. Think of them as a list of approved email senders. When someone receives an email from your domain, the receiving server checks the SPF record to see if the sender is legit.

An SPF record starts with the `v=` element. This indicates the version of SPF you're using, which is almost always `spf1`. After that, you add mechanisms that specify which hosts can send mail. Here's an example:

‍

Breaking it down, `v=spf1` is the version. The `a` and `mx` mechanisms tell the server to accept emails from the domain's A and MX records. The `ip4:203.0.113.1` part allows a specific IPv4 address to send emails. 

The `include:_spf.google.com` mechanism means that Google's SPF rules also apply. The `~all` at the end indicates a soft fail for any servers not listed. This setup helps protect your domain from spoofing by unauthorized sources.

Let's dive into these mechanisms a bit more. The `a` mechanism means any IP listed in the A record of your domain is allowed to send emails. The `mx` mechanism extends this to your MX records, typically your mail servers. 

For specific IPs, you use `ip4` or `ip6` for IPv4 and IPv6 addresses, respectively. If another service sends emails on your behalf, like Google, you can use the `include` mechanism to pull in their SPF record.

Modifiers are another part of SPF records. They provide extra instructions. For example, the `redirect` modifier lets you point to another domain's SPF record, useful if you manage multiple domains and want consistent SPF settings. The `exp` modifier offers an explanation when an email fails the SPF check. Here's how you might use a redirect:

‍

This tells the receiving server to use `_spf.example.com`'s SPF record for validation. It's a clean way to manage multiple domains without duplicating SPF entries.

When adding SPF records, remember they should be placed in a TXT record. While there used to be a specific SPF record type, it's now deprecated. Always use TXT records for SPF entries. Like this:

‍

You can only have one SPF record per domain. So, if you need multiple mechanisms, they all go into that one record. You might have to get creative to stay within the limits, especially if using several third-party services.

If an SPF record has too many mechanisms that require DNS lookups (like `include`, `a`, `mx`, `ptr`, and `exists`), it can exceed the limit of 10 DNS lookups. This can cause issues with SPF validation. Always keep an eye on this when configuring your SPF record.

Finally, remember that setting up SPF records properly is crucial for email deliverability and security. It helps ensure your emails are recognized as legitimate, reducing the chance of them being marked as spam.

DKIM (Domain Keys Identified Mail) record

DKIM records are really just specialized TXT records that help to authenticate emails. When you use DKIM, you are essentially leveraging public and private key pair encryption to ensure that emails come from who they say they do.

So, how does it work? Think about how easy it is to spoof an email, making it look like it came from someone else within your company or a reputable source. With DKIM, you add a digital signature to our email headers. This signature is created using the private key of our key pair. 

When the email reaches the receiving server, it checks the DKIM record to find the public key. It then uses this public key to verify the digital signature in the email header. If everything checks out, the email is considered legitimate. 

Here’s what a DKIM record might look like:

‍

In this example, `mail._domainkey.example.com` is the DKIM record name. The `3600` is the TTL, and the TXT value contains important information like the version (`v=DKIM1`), the key type (`k=rsa`), and the public key (`p=...`).

‍

Creating a DKIM record depends on the DNS service you use. In Men&Mice's Micetro, for example, you would open the Web UI, navigate to the DNS zone where you want to add the record, and then create a new TXT record with the necessary details. This usually includes the name, TTL, and the value with the public key and other optional information.

To give a concrete example, let’s say you need to set up a DKIM record for your domain `example.com`. Here’s how it might look:

‍

In this setup, `selector1` is the DKIM selector specified in the email header. It tells the receiving server to look up the public key at `selector1._domainkey.example.com`.

DKIM also works well with other email security features like SPF and DMARC. While SPF specifies which mail servers can send email on behalf of your domain, and DMARC helps email receivers determine if an email is authentic, DKIM adds a layer of cryptographic assurance.

DMARC (Domain-based Message Authentication, Reporting & Conformance) record

DMARC records work in tandem with SPF and DKIM to give you a robust shield against fraudulent emails. To set up a DMARC record, you'd typically add a TXT record to your DNS. 

If you've got the domain `example.com`, your DMARC record might look like this:

‍

In this example, `_dmarc.example.com` is the record name. The `3600` is the TTL, telling DNS resolvers to cache this record for an hour. The TXT value holds all the magic ingredients.

Here’s the breakdown. `v=DMARC1` specifies the DMARC protocol version, which is always "DMARC1". The `p=reject` policy instructs receiving mail servers to reject emails that fail DMARC checks. This is the most stringent policy and ensures maximum protection against spoofing.

The `rua` tag stands for "reporting URI for aggregate data". It directs where to send aggregate reports, providing a big-picture view of email authentication results. In this case, it's `mailto:dmarc-reports@example.com`.

The `ruf` tag is for "reporting URI for forensic data". Forensic reports give you detailed information about individual email transaction failures. These are sent to `mailto:forensic-reports@example.com`.

Finally, `pct=100` sets the percentage of your emails subjected to the DMARC policy. Setting it to 100 means all your emails will follow the DMARC policy.

You can also specify a subdomain policy using the `sp` tag. It ensures consistency in DMARC application across your subdomains. Suppose you want a less strict policy for subdomains; you could set it like this:

‍

Here, `sp=quarantine` means emails that fail DMARC checks on subdomains will be quarantined instead of rejected.

DMARC records can also include `fo` (forensic options) for more control over forensic reports. For instance, to receive reports for every message that fails DMARC, set `fo=1`:

‍

Setting up DMARC goes hand-in-hand with SPF and DKIM. While SPF lists the authorized mail servers, and DKIM provides a signature, DMARC pulls everything together. It validates the alignment between SPF, DKIM, and the "From:" address, ensuring an email is truly from the claimed domain.

By adding a DMARC record, you're telling other mail servers how to handle unauthenticated emails from your domain. It enhances your domain's credibility, making sure your genuine emails get through while keeping fraudsters at bay.