Sign in Subscribe
DNS

DNS Record Types

DNS is the easiest and hardest system to use in info tech.

Forthright

• 9 min read

Domain Name Systems is the translation of domain names or easy-to-remember phrases we humans can use, into Internet Protocol address or other information computers use. There are many types but we'll overview then deep dive into what we need regarding this website.

Overview

A Record

This record maps your domain name to an IPv4 address. For example, if your mail server is at mail.yourdomain.com, the A record ensures that when someone looks up mail.yourdomain.com, they get the correct IPv4 address. Without this, other servers won’t know where to send emails addressed to your domain.

AAAA Record

Similar to the A record, but for IPv6 addresses. As the internet transitions to IPv6, having an AAAA record ensures your server is accessible via the newer protocol. If you only have an A record, users on IPv6-only networks won’t be able to reach your server.

PTR (Pointer) Record

This is the reverse of an A or AAAA record. While A and AAAA records map a domain name to an IP address, PTR records map an IP address back to a domain name. This is known as reverse DNS lookup. Many email servers use PTR records to verify that the server sending the email is actually associated with the domain it claims to be from. If the PTR record doesn’t match the forward lookup, some servers will reject your emails as potential spam. Your hosting provider must set this up for your server’s IP address, as it’s managed at the IP level, not the domain level.

CNAME (Canonical Name) Record

This creates an alias for your domain. For example, you might want webmail.yourdomain.com to point to the same server as mail.yourdomain.com. CNAME records must point to another domain name, not an IP address, and are useful for simplifying the management of subdomains.

MX (Mail Exchange) Record

This record specifies which mail servers are responsible for receiving emails on behalf of your domain. MX records also include a priority value, so if you have multiple mail servers, you can define which one should be tried first. Without MX records, other servers won’t know where to deliver emails sent to your domain.

TXT (Text) Record

TXT records hold text information, often used for email authentication methods like SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting, and Conformance). These help prevent email spoofing and improve deliverability by proving that your emails are authorized and not spam.

SRV (Service) Record

SRV records specify the hostname and port number for specific services, such as SIP or XMPP. For email, they’re less common but can be used to define services like autodiscover for email clients. They allow clients to automatically find the correct server for a given service.

TLSA Record

This record is used to associate a TLS/SSL certificate or public key with your domain. It’s part of the DANE protocol, which adds an extra layer of security by allowing email servers to verify your certificate via DNS. TLSA records are only trusted if DNSSEC is enabled on your domain, as it ensures the records haven’t been tampered with.

There are many more record types but these are the only ones you need to understand to implement what is talked about on this website.

Structures

Every DNS record has a Time To Live record. This determines how long the record should be cached by DNS resolvers. A shorter TTL means changes propagate faster, but it also means more frequent DNS queries. I will not be including the TTL in every record structure mentioned below because that would be redundant.

Structure of an A Record

An A record consists of a few key components:

  • Host: This is the domain or subdomain you’re creating the record for. For an email server, this might be something like "mail.yourdomain.com."
  • Value: This is the IPv4 address the domain or subdomain should point to. For example, "192.0.2.1."

Structure of an AAAA Record

Same as the A record but instead of IPv4, it's IPv6.

Structure of a PTR Record

  • Host: This is the IP address written in reverse order, with ".in-addr.arpa" appended for IPv4 or ".ip6.arpa" for IPv6. For example, if your server’s IPv4 address is "192.0.2.1," the PTR record’s name would be "1.2.0.192.in-addr.arpa." For IPv6, the address is reversed and each hexadecimal digit is separated by dots, ending with ".ip6.arpa." So, "2001:0db8::1" becomes "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa." This format allows DNS to handle the lookup in reverse.
  • Value: This is the domain name the IP address should resolve to. For an email server, this would typically be the fully qualified domain name (FQDN) of your mail server, such as "mail.yourdomain.com." This tells the world that the IP address belongs to your domain, which is crucial for email deliverability and authentication.

IPv4 Example: 

┌[ forthright@os ] ~
└➤ nslookup -q=a mail.forthright.engineer
Server:		2a01:4f8:151:34aa::198
Address:	2a01:4f8:151:34aa::198#53

Non-authoritative answer:
Name:	mail.forthright.engineer
Address: 85.215.154.38

┌[ forthright@os ] ~
└➤ nslookup -q=ptr 38.154.215.85.in-addr.arpa
Server:		2a01:4f8:151:34aa::198
Address:	2a01:4f8:151:34aa::198#53

Non-authoritative answer:
38.154.215.85.in-addr.arpa	name = mail.forthright.engineer.

IPv6 Example:

┌[ forthright@os ] ~
└➤ nslookup -q=aaaa mail.forthright.engineer
Server:		2a01:4f8:151:34aa::198
Address:	2a01:4f8:151:34aa::198#53

Non-authoritative answer:
mail.forthright.engineer	has AAAA address 2a01:239:3c6:bb00:1::1

Authoritative answers can be found from:

┌[ forthright@os ] ~
└➤ nslookup -q=ptr 1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.0.0.b.b.6.c.3.0.9.3.2.0.1.0.a.2.ip6.arpa
Server:		2a01:4f8:151:34aa::198
Address:	2a01:4f8:151:34aa::198#53

Non-authoritative answer:
1.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.0.0.b.b.6.c.3.0.9.3.2.0.1.0.a.2.ip6.arpa	name = mail.forthright.engineer.

Structure of a CNAME record

A CNAME record, or Canonical Name record, is used to create an alias for one domain name to another. It’s a way to point multiple domain names or subdomains to a single destination without needing to update each record individually if the destination changes. Here’s how it’s structured:

  • Host: This is the alias you’re creating—the domain or subdomain you want to redirect. For example, if you want "webmail.yourdomain.com" to point to your main mail server, you’d enter "webmail" here (or "webmail.yourdomain.com," depending on your DNS provider’s format). This is the name users or other services will use, but it’s just an alias, not the actual destination.
  • Value: This is the fully qualified domain name (FQDN) the alias should point to. For instance, if your mail server is at "mail.yourdomain.com," you’d enter that here. The key thing to remember is that a CNAME record must always point to another domain name, never directly to an IP address. So, it would point to "mail.yourdomain.com," not an IP like "192.0.2.1" or "2001:db8::1."

Structure of an MX record

An MX record, or Mail Exchange record, is specifically designed to direct email traffic for your domain to the correct mail servers. Here’s how it’s structured:

  • Host: This is the domain or subdomain the MX record applies to. For most setups, you’ll leave this blank or use "@" to represent the root domain (e.g., "yourdomain.com"). If you’re setting up email for a subdomain like "mail.yourdomain.com," you’d enter that subdomain here. This field tells the DNS system which domain’s email routing this record controls.
  • Value: This is the fully qualified domain name (FQDN) of the mail server responsible for receiving emails for the domain. For example, if your mail server is "mail.yourdomain.com," you’d enter that here. Importantly, this must be a domain name, not an IP address. The MX record doesn’t point to an IP directly—it points to another domain, which should have its own A or AAAA record resolving to the actual IP address.
  • Priority/Preference: MX records include a priority number, which determines the order in which mail servers should be tried. Lower numbers indicate higher priority. For instance, if you have two mail servers, you might set one to priority "10" and the other to "20." The sending server will attempt to deliver email to the server with the lower number first. If that server is unavailable, it will try the next one in line. This allows for redundancy and load balancing in your email setup.

Structure of a TXT record

A TXT record, or Text record, is a versatile DNS record used to store text-based information associated with a domain. While it can serve various purposes, it’s most commonly used for email authentication and verification. Here’s how it’s structured:

  • Host: This is the domain or subdomain the TXT record applies to. For general domain verification or email authentication (like SPF, DKIM, or DMARC), you’ll often use the root domain (represented as "@") or a specific subdomain (e.g., "_spf.yourdomain.com" or "mail._domainkey.yourdomain.com" for DKIM). This field defines where the text information is tied to in your domain hierarchy.
  • Value: This is the actual text string you want to associate with the domain. For email authentication, this might be a formatted string like:
    • SPF: "v=spf1 include:_spf.yourprovider.com ~all"
    • DKIM: "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..." (a public key)
    • DMARC: "v=DMARC1; p=none; rua=mailto:admin@yourdomain.com" The content here depends on what the TXT record is being used for, but it’s always plain text.
    • ATPROTO: "did=did:plc:7v3w2dnmgio36oougzz36iuw"
    • OpenPGP: "openpgp4fpr:77E7C602BA2308A7977FA66C38E15305953789D4"

Structure of an SRV record

An SRV record, or Service record, is used to specify the location of a service within your domain, such as a mail server, VoIP server, or other specialized services. It’s particularly useful for services that don’t use standard ports or when you want to provide redundancy and load balancing. Here’s how it’s structured

  • Service: This is the name of the service, prefixed with an underscore (e.g., "_sip" for SIP or "_imap" for IMAP). It defines which service the record applies to.
  • Protocol: This is the transport protocol used by the service, also prefixed with an underscore (e.g., "_tcp" for TCP or "_udp" for UDP). Together with the service name, it forms the beginning of the SRV record’s name, like "_sip._tcp.yourdomain.com."
  • Host: This is the full domain name where the SRV record is applied, combining the service, protocol, and domain (e.g., "_sip._tcp.yourdomain.com"). This tells DNS resolvers what service and protocol the record is for.
  • Priority: This number determines the order in which services should be tried, similar to MX records. Lower numbers indicate higher priority. For example, a priority of "10" will be tried before a priority of "20."
  • Weight: If multiple SRV records have the same priority, the weight determines how traffic should be distributed among them. Higher weights mean more traffic will be directed to that server. For example, a weight of "50" will get more traffic than a weight of "10" if both have the same priority.
  • Port: This is the port number where the service is running (e.g., "5060" for SIP or "143" for IMAP). This tells clients which port to connect to.
  • Target: This is the fully qualified domain name (FQDN) of the server hosting the service (e.g., "mail.yourdomain.com"). The target must have its own A or AAAA record pointing to its IP address.

Structure of a TLSA record

A TLSA record, or Transport Layer Security Authentication record, is used to associate a TLS/SSL certificate or public key with a specific domain and service. It’s a key part of the DANE (DNS-Based Authentication of Named Entities) protocol, which adds an extra layer of security by allowing clients to verify a server’s certificate directly through DNS. Here’s how it’s structured:

Certificate Usage: This is a single-digit number (0–3) that defines how the TLSA record should be used:

  • 0 (PKIX-TA): The certificate or public key must be issued by a trusted CA listed in the record.
  • 1 (PKIX-EE): The entire certificate must match the one presented by the server.
  • 2 (DANE-TA): The certificate must be issued by a CA whose public key is listed in the record.
  • 3 (DANE-EE): The exact public key or certificate must match what’s presented by the server.

Selector: This is a single-digit number (0 or 1) that specifies which part of the certificate is stored in the record:

  • 0: The full certificate.
  • 1: Just the public key.

Matching Type: This is a single-digit number (0–2) that defines how the certificate or public key in the record should match the one presented by the server:

  • 0: Exact match (full certificate or public key).
  • 1: SHA-256 hash of the certificate or public key.
  • 2: SHA-512 hash of the certificate or public key.

Name: This is the domain name and port the TLSA record applies to, formatted as "<port>.<protocol>.<domain>." For example, "_25._tcp.mail.yourdomain.com" for SMTP over port 25.

Value/Answer/Destination: This is the actual certificate, public key, or their hash, encoded in hexadecimal. For example, a SHA-256 hash might look like: "2b123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"

Closing

If you made it this far, you are further than most people in the information technology industry. There's a saying "it's always DNS" when infrastructure is having a problem they can't solve. It's important to know what these are so when you go to use them, you understand if something is wrong and you don't stress yourself out.