INTRODUCTION

In this document, I try to identify and explain with case usage and technical information every major DNS record in use today, hoping that I never forget what the fuck they are.

Configuration examples are written in a dual-format showing how to configure them within Cloudflare or a self-hosted installation of BIND.

DISCLAIMER: I am by no means a seasoned professional. This document was written with the primary purpose of helping myself learn DNS records in the fastest way possible by way of researching every little nuance and how I could exploit it for my gain. I have based everything I’ve written from multiple websites, my own experiences, and the pleasure of learning.

Why do I say this? Because you should always base your knowledge from multiple sources, including when I’m the one writing it. Make sure you know everything there is to know as humans make mistakes or miss essential things without noticing.

TTL

See this cloudflare document | RFC 3443

Each of the examples in this document contains “TTL” used frequently as a placeholder acronym for a parameter that might be unknown to anyone reading this. For this reason, I’m going to briefly introduce what TTL is and what it does within a DNS record scope.

“Time-to-live” is the full name behind the TTL acronym, and it defines the amount of time (or network hops) a packet of information is to be residing inside a network before being discarded, in our case it is the time defining validity of everything that is cached by our DNS system.

Within DNS systems it is essentially a time bomb strapped on the back of each packet stored that is to tell us until when that piece of information is to be considered valid and when we should ask for a new one, this is a security measure because DNS systems should always be as bleeding-edge as possible and having outdated information could create huge problems.

DNS RR & RR CLASSES

See RFC 1035 for DNS | RFC 1035 Section 3.2.4 for RR CLASSES | RFC 1035 Section 3.3 for the RR standard

What we call “DNS RR” is the acronym for “Domain Name System Resource Records,” commonly called “DNS Records.”

A “Resource Record” is the grouping of information relative to every single DNS Record to make it easier to use and configure within a DNS System.

Notably, the A Record IPv4 host address, the AAAA Record IPv6 host address, the CNAME alias, and the MX Record mail exchanger are the most famous ones.

Here’s a full list of all DNS RRs, their definition within RFC and function on Wikipedia.

As specified in RFC 1035 these are the RR Classes in use today:

CLASS fields appear in resource records.  The following CLASS mnemonics
and values are defined:

IN              1 the Internet

CS              2 the CSNET class (Obsolete - used only for examples in
                some obsolete RFCs)

CH              3 the CHAOS class

HS              4 Hesiod [Dyer 87]

They contain the data to be used by RRs, the IN class is the widespread one and generally what is in use everywhere on the internet.

Specifying it isn’t required, when a class isn’t specified the IN class is automatically assumed.

ROOT DNS RECORDS

What we call “root records” usually defined as <root> or with a single dot are servers residing around the world of which every (correctly) configured DNS server reference to files such as the “root file,” “hints file” or “cache file.” They are the topmost level within the domain name system hierarchy.

When trying to find a domain name (except when they already have the closest copy cached), a DNS server always asks the root domains first and receives a reply with the authoritative nameservers for the next level within the hierarchy. The nameserver replies for the TLD of your requested domain, and the processes continue similarly until the final destination is found and sent back to the client.

This process is called recursion.

Recursion and iteration are computer science terms that describe two different methods to solve a problem. In recursion, a program repeatedly calls itself until a condition is met, while in iteration, a set of instructions is repeated until a condition is met.

In our case, a recursion DNS request would be like a DNS server collaborating with other DNS servers to find your requested IP. Instead, an iterative request would make it, so the instructions are always the same, and DNS servers would only talk to the relative other DNS servers that are authoritative for your specific request, without ever going outside of this scope.

A & AAAA

The most common DNS records point an A record to an IPv4 address and the AAAA record to an IPv6 address.

Cloudflare:

A <NAME> <IPv4 ADDRESS>

BIND:

<NAME> IN A <IPv4 ADDRESS>

The name part can specify “root” (defined as @), which points your primary domain name to a server, otherwise it can also be used to point subdomains to other servers, differentiating them from your main A record server.

As an example, one A record with name “wise.wtf” and IPv4 address set for “56.76.182.230” points every access to that name to the specified IPv4 address.

Everything inside a network identified via an IP Address is easily forgettable, so A and AAAA records help humans access and remember them via mnemonic domain names. This record instructs a DNS system on how to translate them.

CAA

See RFC 6844 | Let’s Encrypt ISRG CPS v2.7 | Let’s Encrypt CAA Documentation

The CAA record specifies if any third-party SSL issuers are authorized to issue SSL certificates for your domain. When this record is absent, anyone is free to do it. When it’s present, the relative CA verifies the CAA record to check if they can issue a certificate.

It is intended to avoid unintended certificate miss-issuing.

It is usually a good idea to configure to avoid any problems related to issuing certificates for your domain, and I recommend you configure them if you plan on using them for Let’s Encrypt.

You can set them for an entire domain, or its subdomain, the CA checks all versions of this record starting from the bottom, so a subdomain would take precedence, in case you set it for your entire domain then all subdomains are automatically accepted also.

CAA records also follow CNAME records, so when a CA is trying to figure out a CAA record, and it finds a CNAME record it requests the CAA records for the final actor in the CNAME chain.

The record is structured this way:

Cloudflare:

CAA <FLAG> <TAG> <VALUE>

BIND:

wise.wtf. 1 IN CAA 0 issue "letsencrypt.org"

flagsare usually not configurable, even services such as Cloudflare default them to 0 since it must be an integer between 0 and 255. They have a specific meaning depending on the integer, as specified by this RFC-6844 section.

tags are of 3 types:

  1. issue (specified as “allow only specific hostnames” on Cloudflare): it authorizes the CA to issue any certificate for the specified hostname.
  2. issuewild (specified as “allow only wildcards” on Cloudflare): it authorizes the CA to issue wildcard certificates EXCLUSIVELY.
  3. iodef tells a CA where it may report violations defined with HTTP: or HTTPS: protocols or a mailto: directive.

value is the hostname of the third-party certificate authority authorized to issue certificates for your domain.

So, for example:

CAA 0 issue letsencrypt.org allows Let’s Encrypt to issue any certificate for my domain.

CERT

See RFC 4398 | RFC 6944 | RFC 4034 - Appendix B

The CERT record stores certificates and CRL (certificate revocation lists) to verify the authenticity of the sending and receiving parties, and CRLs identify revoked certificates or anything that is no longer considered valid—commonly used for secure email systems.

They are composed as follows:

CERT <NAME> <TTL> <CERT TYPE> <KEY TAG> <ALGORITHM> <CERTIFICATE>

  1. name can be @ for root or a name for a subdomain.

  2. ttl is the regular time to live

  3. cert type is a number between 0 and 65535 as described in RFC 4398 in section 2.1:

       The following values are defined or reserved:
    
             Value  Mnemonic  Certificate Type
             -----  --------  ----------------
                 0            Reserved
                 1  PKIX      X.509 as per PKIX
                 2  SPKI      SPKI certificate
                 3  PGP       OpenPGP packet
                 4  IPKIX     The URL of an X.509 data object
                 5  ISPKI     The URL of an SPKI certificate
                 6  IPGP      The fingerprint and URL of an OpenPGP packet
                 7  ACPKIX    Attribute Certificate
                 8  IACPKIX   The URL of an Attribute Certificate
             9-252            Available for IANA assignment
               253  URI       URI private
               254  OID       OID private
               255            Reserved
         256-65279            Available for IANA assignment
       65280-65534            Experimental
             65535            Reserved
    
  4. key tag is a number between 0 and 65535 used to pick a specific CERT record efficiently. However, as stated in RFC 4034, Appendix B:

It is theoretically possible for two distinct DNSKEY RRs to have the same owner name, the same algorithm, and the same key tag. The key tag is used to limit the possible candidate keys, but it does not uniquely identify a DNSKEY record.

  1. algorithm specifies the cryptographic algorithm in use by the certificate, as specified by the DNS Security Algorithm Numbers registry, you have defined standards.

  2. certificate can contain the certificate itself, the CRL, the URL of a certificate or the fingerprint, and a URL.

These records are heavily used within the healthcare industry to deal with secure emails for confidential emailing of patient data to comply with HIPAA regulations.

CNAME

A CNAME record is an alias (not to mistake it for the ALIAS record) for another record, typically an A record.

They are composed as follows:

Cloudflare:

CNAME <NAME> <TARGET>

BIND:

<NAME> 1 IN CNAME <TARGET>

CNAME records must point to an already existing record. Otherwise, it won’t work.

They are used in situations where many different domains need to point to a central one, such as domains registered in many countries pointing to a .com or if an organization owns multiple domains and wants to point everyone to their main website.

Whenever a client unknowingly requests an address like www.example.com, a CNAME of example.com, a DNS resolver receives the request, tries to find the authoritative NS for that DNS zone, and the CNAME record, once found, is sent back to the client. The client then realizes the record is only an alias of something else and sends another DNS request for that domain. Repeating the entire process until the A record of example.com is sent along with its IP address, making the client connect to it.

DNSSEC: DNSKEY, DS, RRSIG, and NSEC

See RFC 4033 | RFC 4035 | RFC 4956

I guess it would be impossible for me to explain how DNSKEY records work without mentioning DNSSEC, so before I get into that, here’s a brief introduction:

DNSSEC is a secure implementation of the most insecure DNS system since it never asks for authorization; things like emailing become incredibly dangerous as they rely on DNS to route emails the correct way. Or in cases like this one in 2014 route them in the incorrect way, if not secured.

In short, a DNSKEY record is the public key tied with your domain that DNS resolvers can use to verify DNSSEC signatures.

DS records contain the hash of your DNSKEY, and NSEC records contain the denial-of-existence.

All of these records are used to enable and configure DNSSEC. If you’re on a third-party DNS service like Cloudflare, you can enable DNSSEC for your zone within the DNS control panel and then follow the instructions given for your registrar provided with all elements of the DS records.

If you host your nameserver (For example, BIND(Named)), you can follow this guide by DigitalOcean.

You can use Verisign’s DNSSEC Analyzer to test your domain or on dnsviz.

Here’s an example of a DNSSEC Authentication Chain starting from . (root zone) -> .wtf (TLD zone at registrar level) -> wise.wtf (My domain zone on Cloudflare)

DNSSEC Chain

You might also want to read this document on Medium by Christopher Makarem.

MX

See RFC 1035 Page 12 | RFC 7505 | RFC 5321

The fated MX (mail exchange) record specifies the mail server responsible for accepting mail and routing them following the SMTP protocol. There can be more than one, typically done for load distribution or backup.

Cloudflare:

MX <NAME> <MAIL SERVER> <PRIORITY>

BIND:

<name> 1 IN MX <priority> <hostname>

mail server identifies the hostname responsible for handling emails for its relative name (usually the root domain).

priority is what defines which record and the corresponding mail server are prioritized when an MTA looks up for MX records for any given domain. According to RFC 5321, the lowest number is the most preferred.

A backup mechanic to this would be using another mail server in your DNS zone with a higher numbered priority so that it wouldn’t typically be used to route emails, but in the case of outages with the primary ones, it would be, ensuring continuity with your mailing service.

A load-balancing mechanic could be introducing multiple MX DNS records with the same priority so that the SMTP protocol is charged with evenly spread routes for its moving emails across all mail servers found with equal priority. Another method would be when a single host returns multiple IPs, giving the DNS system more work to figure out which IP to deliver to the SMTP-sender query, using with mechanisms such as DNS round robin and numerous other.

You can use MXTOOLBOX - MX Lookup tool for testing your MX records and SMTP against errors.

NS

See RFC 1035

The NS record is undoubtedly the most used one. It defines which nameserver is authoritative for any specific domain DNS zone, which in extension it’s the server that contains all DNS records. There can be multiple NS records set-up for backup purposes.

Cloudflare:

NS <NAME> <HOST>

BIND:

<NAME> (Or usually nothing to assume root domain) IN NS <HOST>

name identifies your domain or subdomain, and host defines which nameserver (written as a hostname) is handling DNS records for your domain.

PTR

A PTR record is how we define the pointer DNS record. Its function is to resolve an IP Address into a domain or hostname. An A record but on the reverse.

They are particularly useful in outgoing mail servers because most providers might reject mails coming from domains with unmatching A record or missing PTR records.

SPF

See RFC 4408 | RFC 7208

SPF falls under the TXT records umbrella, but it deserves an honorable mention.

This record prevents email spoofing. It prevents bad people from sending emails as if they were you. Recipients of your emails will know which IPs or hostnames are allowed to send emails from your domain.

SPF is obligatory in domains that handle mail servers because most providers would outright block mails coming from you without one. DMARC authentication also uses this record.

Usually, they are set-up with a TXT record, because the SPF record itself is deprecated.

Cloudflare (using the TXT record):

<TXT> <NAME> <CONTENT>

BIND

<DOMAIN> 1 IN TXT "v=spf1 mx a -all"

Now, v=spf1 mx a -all is the “mechanism” part which defines the record’s qualifiers and modifiers.

  • + Pass, an IP that matches a modifier with this qualifier, will pass SPF.
  • - Fail, an IP that matches a modifier with this qualifier will fail SPF.
  • ~ SoftFail, an IP that matches a modifier with this qualifier, will soft fail SPF, which means that the host should accept the mail and mark it as an SPF failure.
  • ? Neutral, an IP that matches a modifier with this qualifier, will neither pass or fail SPF.

Modifiers are what define how the SPF record behaves regarding any action our mail server starts.

  • a will check if the IP address of the mail server matches with the A record set for the domain. So a sending IP that matches the A record will pass SPF checks.
  • mx is consequentially the same as the a modifier, but it will execute checks on the mx record(s) set for the domain. If the sender’s IP matches the records for the mx records of your domain, it will pass SPF checks.
  • include enables the administrator to add specific hostnames or IPs to pass SPF checks for their particular domain(s).
  • all will pass everything that gets through SPF checks—usually configured with the SoftFail qualifier, so that every mail passing through SPF will be marked as SPF failure but still delivered.

Some other includes:

  • ip4
  • ip6
  • exists
  • redirect
  • exp

Sending an email FROM wise@wise.wtf to someone@example.com would make the example.com mail server check for TXT DNS records of wise.wtf and compare it against every SPF step described above. If nothing fails the checks, then the email will be delivered.

SRV

See RFC 2782

You can use the SRV record to specify the hostname and port number of servers delivering a specific service. It is particularly useful to help mail clients know the mail protocols of your mail server and automatically input the correct configuration. If, for some reason, you aren’t using autodiscover and autoconfig records for your mail server hostname.

Cloudflare:

<SRV> <NAME> <_SERVICE> <PROTOCOL> <PRIORITY> <WEIGHT> <PORT> <TARGET>

BIND:

_<service>._<protocol>.<name>. 1 IN SRV <priority> <weight> <port> <content>.

_imaps._tcp.mail.wise.wtf. 1 IN SRV 0 1 993 mail.wise.wtf.

Every single name written in a BIND’s configuration will automatically append the origin domain to the end. For example: writing “mail” will automatically append the origin domain, creating “mail.wise.wtf” In this BIND’s example, not using the final “dot” at the end of “mail.wise.wtf.” would make it so that it is counted as “mail.wise.wtf.wise.wtf.” So always remember to put dots to let BIND know when a name is already complete.

If we look at BIND’s configuration, we notice how it works from how I wrote the record. It would tell any mail client looking for my imaps service that it is on mail.wise.wtf and that the port is 993. Setting target to a single dot explicitly informs every client of a disabled service.

Regarding priority and weight, as defined in RFC 2782:

The priority of this target host. A client MUST attempt to contact the target host with the lowest-numbered priority it can reach; target hosts with the same priority SHOULD be tried in an order defined by the weight field. The range is 0-65535. This is a 16-bit unsigned integer in network byte order.

For weight:

A server selection mechanism. The weight field specifies a relative weight for entries with the same priority. Larger weights SHOULD be given a proportionately higher probability of being selected. The range of this number is 0-65535.

Meaning that these two parameters are used in cases where multiple servers are present, and a client needs to know which one to prioritize when looking for SRV records.

SSHFP

See RFC 4255 | RFC 6954 | RFC 7479

The Secure Shell Fingerprint DNS record identifies SSH keys associated with a hostname within your domain. And protects it from attacks such as MITM and anything that could compromise your SSH connection by warning you of modified identities.

Cloudflare:

SSHFP <NAME> <ALGORITHM> <TYPE> <FINGERPRINT>

BIND:

<HOST> 1 IN SSHFP <ALGORITHM> <TYPE> <FINGERPRINT>

Algorithms can be:

  1. RSA
  2. DSA
  3. ECDSA
  4. Ed25519

Types can be:

  1. SHA-1
  2. SHA-256

This record can be generated on your host machine with the command ssh-keygen -r my.domain.com which will output all necessary records already formatted to be used in your DNS records.

Check out StackExchange for more information

TXT

See RFC 1464

By definition the most flexible of DNS records. TXT records can be used in a number of ways, the most famous being spf (as I explained earlier), dkim, dmarc and MTA-STS for email security purposes. It can also contain arbitrary, humanly readable pieces of data related to a specific domain within its DNS records.

Want to support me?

Find all information right here

You can also support me here:

Credits

  • My mom