DNS Data Storage

Early in the course, we talked about name resolution and how it resolved can find the authoritative answer to a query via a series of iterative requests against servers down for domain name hierarchy.
Obviously, those servers must store that kind of information somewhere to be able to respond to the DNS queries.
And so, in this section, we will study the way the DNS data is stored and organized in name servers.
Again and again throughout the course, we have been referring to the DNS as a globally distributed. collection of databases.
This principle extends to DNA storage as well, since the DNS data is stored in a database that is known as a Zone.

There are two types of zones:

• Forward Lookup Zone: Used for resolving names to IP addresses, and it's the zone where most of the DNS data is stored.
• Reverse Lookup Zone: The reverse lookup Zone, on the other hand, mainly stores information used for reverse name resolution.

Each of these zones is a collection of what we called as Resource records (RRs), and just like the records of any database, various sets of fields organized in rows.
There are many types of resource records and DNS, and each resource record type contains a specific set of data.

Common RR Format

• Name of the Record
• Type of the Record
• Class of the Record
• TTL value
• Resource data length
• Resource data

Types of Resource Record

State of Authority (SOA)

• The SOA record indicates the beginning of his own, and it should be the first resource record specified in any zone file.
• There can be only one Start of authority record per zone.

Format

The format of the set of authority record is as follows.

<domain name> <TTL> <class> SOA <m-name> <r-name> (
                         <serial number>
                         <refresh interval>
                         <retry interval>
                         <expire interval>
                         <minimum>
)

• We have the domain name, followed by a time to live value, followed by the resource record class, which, should be in standing for internet in 99 percent of cases.
• Then we've got the resource record type start up authority in this case, then we have the m-name field, which is the name of the primary authoritative name server for the zone.
• And it is this name server that secondary DNS servers receive updates from in relation to the zone.
• I know we haven't talked about primary and secondary name servers yet, as those are concepts, we will explore in the configuration section.
• For now, just make a note of the m-name field represents the primary name server for the zone.
• Next, we have the r-name field, which signifies the email address of the administrator responsible for the zone.
• Although the value represents an email address, you will be surprised to learn that there is no @ sign in it, as far as the start of Authority rack is concerned in this case.
• Info.example.com is the same thing as info@example.com 
• And then within a pair of brackets, we have the serial number, which is the version number of the zone, and it is incremented by one, every time a change is made to the zone file.
• Then the refresh interval, the retry interval and the expire interval have to do with primary and secondary name service.
• And finally, we have the minimum field. 
• The historical purpose of this parameter was to hold the default TTL value for records without an explicit time to live value defined.
• But nowadays, the minimum parameter represents the TTL value for negative caching.
• If you remember back in our section on caching, we said that negative answers are cached with a different TTL, and that different kind of TTL is no other than this very parameter.

To query the start of authority record, we can use a tool like Dig (for Linux machine) and nslookup (for window machine).
On window machine on command prompt:

nslookup -type=soa <hostname/IP address>

Name Server (NS) Record

• The NS records point to the authoritative name server of his own, and it is these name servers that hold the actual DNS information for a domain so that domain can be accessible to internet users.
• If a domain, such as example.com doesn't have any NS records configured in its zone.
• There wouldn't be any references to that domain name servers, which means that mean the .com TLD server contacted would not be able to return a list of name server, for example .com which in turn means that nobody would be able to browse to that domain.
• In other words, it is the NS records that ensure the availability of a domain.
• Because of that reason, every zone must have at least two NS records, of which each one points to a different name server for redundancy.
• That way, if one name server goes down or becomes unavailable, DNS queries can go to a different name server.
• To that end, name servers also typically reside in topological separate networks for further resiliency.

When it comes to registering a domain, many DNS service providers by default provisioning sets of 4 name servers, and they will be listed as:

• ns1.example.com
• ns2.example.com
• ns3.example.com
• ns4.example.com

Format

<domain name> <TTL> <class> NS <nameserver’s hostname>

• Its syntax consists of a domain name such as example.com, a TTL value and resource record class, which in 99 percent of cases should be in for internet.
• And then resource record type, in these case NS record and finally the name servers hostname such as ns1.example.com

Querying the NS record with a tool like Dig or Nslookup
On a Windows machine.

nslookup -type=ns <hostname/IP address>

Address Records (A)

• A resource record that stores the association between a domain name and IP address is the address or A record.
• A record is that primary record in DNS and it is queried in forward looking requests.

Format

<domain name> <TTL> <class> A <IPv4 address>

It simply contains a domain name, TTL value, a resource record class, a resource record type, which in this case is A and an IPv4 address.

Querying the A record on a Windows machine.

nslookup -type=a <hostname/IP address>

Quad-A Record (AAAA)

• The cousin of the A record is a Quad-A record, which stores a domain name and a IPv6 address.
• The reason why it's represented by 4A is to signify that the value stored in it is four times as big as the one stored in the A record.
• Considering that an IPv4 address has 32 bits and, IPv6 address has 128 bits.

Format

<domain name> <TTL> <class> AAAA <IPv6 address>

Its format is very similar to that of the A record, as it consists of a domain name, a TTL value, resource record class, resource record type, which in this case is AAAA and finally, an IPv6 address.
It is important to note that it is perfectly possible for A record and AAAA record to point at the same domain, in cases where dual stack is required.

Querying the AAAA record on a Windows machine.

nslookup -type=aaaa <hostname/IP address>

Pointer Record (PTR)

• As we know from previous section, however, DNS also supports reverse resolution for situations where we have an IP address and want to resolve it to its associated name.
• There is also record that allowed this to happen is a Pointer record, i.e., PTR. which points an IP address to a host name.

Format

<reverse domain name> <class> PTR <domain name>

The formats of the point of record features, a reverse domain name which release the IP address we have in reverse format, followed by the .in-addr.arpa which, if you remember from our section on reverse name resolution, is a special domain representing the numerical hierarchy of DNS that covers the entire IPv4 address space.
Then we have a resource record class, a resource record type, which is PTR, pointer record in this case.
And finally, the FQDN of the domain name that the IP address points to.

• The same principles apply to PTR records storing IPv6 address as well, with the main difference is being that the domain appended to the reverse IPv6 address is not .in-addr.arpa but .IP6.arpa which is a different namespace under the dot arpa TLD.
• As they are designed to facilitate reverse name solution, pointer record is placed inside the revers lookup zone, which is something we're going to see in more detail in the configuration section.

Querying the PTR record on a Windows machine.

nslookup -type=PTR <hostname/IP address>

Canonical Name Record (CNAME)

• We are going to discuss yet another resource record type, which makes a frequent appearance in DNS configuration, troubleshooting and name resolution, and it is the CNAME record.
• C name stands for canonical name, which is a real name of an object referenced by an alias. In other words, this record basically maps one domain name to another.

Format

<alias> <class> CNAME <TTL> <canonical name>

It consists of an alias such as www.example.com, a resource record class which is in for internet in 99 percent of cases.
A resource record type, CNAME in this case, a TTL value and a canonical name or the real name that www.example.com points to, which is example.com.

Querying the CNAME record on a Windows machine.

nslookup -type=cname <alias>

Use Cases of CNAME

• Map subdomains to their apex domain such as www.example.com to example.com
• Redirect multiple TLDs to the same second level domain.
• For example, if you have mydomain.com.au and mydomain.com.nz, they both can be directed to mydomain.com
• Validate ownership or control of a domain.

Restrictions

• A CNAME record must always point to another domain name and never directly to an IP address.
• A CNAME record cannot point to an NS or MX record.
• A CNAME record cannot co-exist with another record for the same name.

Best Practice

• A CNAME can point to another CNAME, a mechanism that is known as CNAME chaining. However, this is not recommended as it requires multiple DNS lookups before the internet domain can be loaded, which slows down the name resolution process and in turn, impacts user experience. It is considered best practice, therefore, not to use the CNAME chaining, and point CNAME records directly to canonical names.

Text Record (TXT)

The DNS ‘text’ (TXT) record lets a domain administrator enter text into the Domain Name System (DNS). The TXT record was originally intended as a place for human-readable notes. However, now it is also possible to put some machine-readable data into TXT records. One domain can have many TXT records.

Example of a TXT record:

example.com	record type:	value:	TTL
@	TXT	This is an awesome domain! Not spammy.	32600

Format

<domain name> <class> TXT <TTL> <textual data>

Format of the text record is probably the easiest one to remember, as it consists of a domain name, a resource record class, a resource record type, which in these cases is TXT, and time to live value and some textual information.

• Interestingly, even though the official format for storing data in a record theoretically involves using attribute value pairs limited by an equal sign and enclosed by quotation marks.
• Domain administrators are still able to use their own formats, which is a testament to the flexibility of the text record.
• The data that can be placed inside its value could be any text that the administrator wants to associate with their domain.
• Though the value of this record was originally intended as a place for human readable notes, it is now possible to put machine readable data as well.
• It is also perfectly possible for one domain to be associated with many TXT records.

Querying the TXT record on a Windows machine.

nslookup -type=txt <domain name>

Use Cases

• Associating domains with textual data
• Proving domain ownership
• Strengthening email security

Mail Exchange Record (MX)

• We're going to have a look at yet another very common record in DNS, which is known as mail exchange record (MX).
• Just like every other record in the DNS database, the MX record, too, serves as a mapping between two values.
• More specifically, the MX record maps a domain to an email server.
• Email has always been heavily reliant on DNS, perhaps more so than any other TCP IP based application, and MX records provide the necessary infrastructure for it to work.

Format

<domain name> <class> MX <TTL> <preference-value> <email-server>

It consists of a domain name, a resource record class, a resource record type which obviously is MX, the time to live value, the preference value, and the hostname of an email server.

• The first question that comes to mind when inspecting the format of the MX record is why does it not feature the @ symbol?
• Shouldn’t it be primaryemail@www.example.com instead of primaryemail.www.example.com
• Well, as e-mail clients, whenever we send an email to any recipient, we use the @ sign as a means to separate the mail server from the domain it is meant to receive emails for.
• For instance, support@example.com.
• As well as the name servers are concerned. the names of mail servers inside their MX records are configured with dots and not @.
• Another interesting part of the MX record is the preference value.
• The preference value allows a DNS administrator to specify multiple e-mail service so that if the first server specified is down, emails will be forwarded to the backup email server, thus achieving redundancy. 
• The lower the preference value of the email server, the higher the priority of that server will be. It is also possible to specify multiple backup email servers too.
• Finally, somebody might say, okay, that is all well and good, but how can the authoritative name server know of the email server’s location?
• Shouldn't there be an additional record that in turn maps the hostname of that server to an IP address? And the answer is yes.
• A record would indeed need to be defined alongside the mixed record so that the name server can forward email to the correct endpoint.
• Additionally, A records would typically be created for as many email server the domain is associated with.

Querying the MX record on a Windows machine.

nslookup -type=mx <domain name>