Domain Name System (DNS)

Anyone who uses the web has used DNS. In its simplest form, the Domain Name System protocol consists of tables of information that associates one value to another. Each of the sets of values contained within these systems are known as records. We will go over all of the most common record types and what their purposes are shortly.

When we think about DNS, we should be thinking about our conveniently placed URL bar at the top of our browser where we type in the name of the site that we are trying to visit. Once we find a website that we like, the name of the site tends to stick with us and that's what we type into the URL bar in order to return the next time we want to visit. The name of the site is commonly referred to as the domain name. We navigate using this domain name because it's easy to remember. Our computers and network connected devices don't use this domain name but, instead, rely on IPv4 & IPv6 addresses in order to surf the web or communicate with another machine. Computers like numbers, not fancy domain names like shroudsec.com. When we type shroudsec.com into our browser, before we can navigate to the website, our machine has to make a DNS Query to a Domain Name System in order to determine what the associated IPv4/IPv6 addresses are. This leads us to our first record type, an A record.

An A record maps a domain name to an IPv4 address. Google is always great to use as an example. Upon searching for google.com, the browser would make a DNS Query to a DNS server who might respond with the IPv4 address of 142.250.191.238 which is the server that is hosting Google's website. So essentially, google.com=142.250.191.238. One value is what you would use to search for the website while the other value is what your computer is actually searching in the background. If you would like to get some hands on experience converting domain names into IP addresses, open up a terminal and try a couple of these commands: In windows, open up a CMD terminal and try either ping <domain name> or tracert <domain name>. Ping is commonly used to test connectivity to the internet or a particular system and tracert goes a step further to track each connection/hop to a system.

An AAAA record maps a domain name to an IPv6 address. An IPv6 address looks something like this: 2001:0db8:85a3:0000:0000:8a2e:0370:7334. IPv6 addresses are 128 bits and provide up to 3.4 x 10^38 different addresses. That's 340 undecillion! IPv4 addresses only allowed for roughly 3.4 billion different addresses. The development of IPv6 was to combat the limited amount of available IPv4 addresses and the number of internet connected devices. In 2021, the world population stood at roughly 7.9 billion. If each of these individuals has a smartphone, a computer, and some type of smart device (streaming device, smart watch, tablet, etc.), we could assert that each individual has at least 3 internet connected devices. That would bring the total number of necessary IPv4 addresses to 23.7 billion, far exceeding availability. We make this generalization based on the knowledge that there are individuals that own 0 smart devices and there are individuals who own far more than 3. The transition from IPv4 to IPv6 was intended to commence long ago but, with the implementation of Network Address Translation (NAT), we have been able to work within the bounds of IPv4 for much longer.

A CNAME record is a canonical name record, hence the name. These records map one domain name to another. An easy to understand example of this would be a CNAME record that maps shroudsec.com to www.shroudsec.com. The simplest function of this would be to make it so that a user could enter in the domain name in multiple forms and still reach the desired location.

An MX record maps a domain name to a particular mail server that handles the mail for that domain name. Depending on the size of the organization/domain, there will typically be more than one MX record. One MX record would map to the primary mail server, the next mapping to a secondary mail server and so on. Typically these will be represented with a numbering system. The lower the number, the more primary the mail server. As an example, if we wanted to send an email to someone with the address: user@shroudsec.com, there might be multiple MX records in the DNS. The most primary MX record would be mapped something like:

shroudsec.com - MX - Priority: 10 - mailserver1.shroudsec.com

The secondary MX record might be mapped something like:

shroudsec.com - MX - Priority: 20 - mailserver2.shroudsec.com

The reasoning for the multiple servers and priorities is to create redundancy and ensure that emails are received by one of the mail servers should something go wrong or cause the email not to reach the primary server. Another common way to tier the MX records is to give them equal priority, therefore load-balancing the receipt of emails to each server.

A PTR record is the exact opposite of an A record or AAAA record. A PTR record maps IP addresses to domain names. After learning how A records are used with DNS, it may be a bit challenging to understand why this type of record would be necessary. PTR records are used for Reverse DNS Lookups. The most common use for this record and easiest way to understand its functionality is in the case of email spam filtering. As we learned with an A record, internet connected devices communicate using IP addresses. On its way to your inbox, an email goes through multiple points and addresses in order to reach the server that is hosting your emails. These different locations are communicating using IP addresses. As the email reaches its final destination, the server could just let the email right on through to your inbox. Can you see the issue with this? How many spam and phishing emails do you receive each day? Rather than simply allowing the email through to your main inbox, the mail server can use a PTR record to check that the IP address associated with the email actually maps to a legitimate domain. With a proper PTR record in place, a valid email would be allowed to pass into the main inbox while an invalid email might be blocked or sent to the spam inbox.

A TXT record is a record that simply stores textual data about a specific domain. This could serve multiple purposes but nowadays is often used to store human readable data. In the early days of DNS, the TXT record format was typically a key=value pair. In its current context, it is often used as a place to store notes of all different varieties. There are quite a few historical examples of TXT records being used as a place to store credentials or other sensitive information. This is always a worthwhile record to examine when searching the available DNS records. A lazy system administrator might populate a TXT record with data such as: "The admin password for shroudsec.com is 123456password" or "id=admin&passwd=123456password". If that same administrator ever forgot the credentials (because they're so overly complicated and secure), they could simply query the DNS TXT record and voilà!

DISCLAIMER: These last 2 record types that we will talk about are a bit harder to wrap your head around but they play a huge part in the functionality and security of DNS.

An NS record is a NameServer record. This record maps a domain name to the authoritative nameserver for that domain. A nameserver is where the DNS records are stored for a particular domain. In todays world of uptime, continuity, and redundancy, almost all domains have multiple nameservers. Rather than having one end-all place where all the records are stored, we may have 3 or 4 so that we have a failsafe if anything were to happen to our primary nameserver. Similar to the tiering of MX records, nameservers can be categorized as primary and secondary servers. Typically the primary server will push duplicate records to the rest of the secondary servers. As an example, if we were employing 4 nameservers (1 primary & 3 secondary), the primary nameserver DNS records would be copied to all 3 of the secondary nameservers. In the case of some type of outage or system catastrophe, the secondary nameservers would be able to function in place of the primary and we would not lose access to our records.

An SOA record is a Start of Authority record. This record contains an array of important information about the particular domain/zone. This is the first mention of a zone. All we need to know for now is that a zone can represent one domain, multiple domains, or domain(s) and subdomain(s). For simplicity's sake, we will continue with the example of our zone just representing the single domain: shroudsec.com. Contained within the SOA record are multiple fields and their associated values relating to: the primary nameserver (MNAME), the email address of the zone administrator (RNAME), a serial number (SERIAL), secondary nameserver refresh rates (REFRESH), secondary nameserver retry rates (RETRY), secondary nameserver expiration rates (EXPIRE), and time to live for the SOA record (TTL).

The MNAME key maps to the domain name of the primary nameserver.

The RNAME key maps to the email address of the administrator for that particular zone. For shroudsec.com (the only domain in this zone) the administrator would be represented by admin.shroudsec.com.

The SERIAL key maps to the serial number for that particular SOA record. When this serial number changes, it alerts secondary nameservers that they need to update their zone file to properly reflect the change of the record(s) that was made in the primary nameserver.

The REFRESH key maps to the amount of time (seconds) that secondary nameservers should wait between querying the primary nameserver to see if any changes have been made to the SOA record (SERIAL).

The RETRY key maps to the amount of time (seconds) that secondary nameservers should wait between querying the primary nameserver when the primary nameserver is being non-responsive.

The EXPIRE key maps to the amount of time (seconds) that secondary nameservers will stay active (respond to zone queries) when the primary nameserver has become non-responsive.

The TTL key maps to the amount of time (seconds) before the SOA record itself is refreshed. All record types have this metric.

Now that you have read through all of this and are trying to see how it all ties together into the functionality of DNS on the internet, I strongly recommend you give Wireshark a try. Wireshark is an open-source network protocol analysis tool. The easiest hands-on analysis that you can do is to open up your browser of choice in conjunction with opening up the Wireshark software that you just downloaded. Begin capturing packets in Wireshark and, in sequence, search shroudsec.com in your browser. As soon as the website loads into your browser, you can go ahead and stop capturing packets (the red shark fin in the upper left hand corner). Chances are that your packet capture grabbed way more information than you're comfortable looking at but that's ok. If you look on the right hand side of the packet capture, you should start to see some familiar words (different record types). You can see how each of the record types is queried and in what sequence. We will dig deeper into this in the next article where we use Wireshark to analyze network communication and the different protocols involved.