Introduction
Are you familiar with DNS resource records and their critical role in keeping the internet running smoothly? In my previous article, I explained how DNS works to help us navigate the web, but now it's time to dive deeper into the specific pieces of the puzzle that make it all happen. DNS resource records (RRs) are essential components of the DNS system that provide crucial information about domain names and IP addresses. In this article, we'll explore what RRs are, how they work, and why they're so important to the functioning of the internet. So buckle up and get ready for a fascinating journey into the world of DNS resource records!
What is a resource record?
A resource record (RR) is an entry in the DNS (Domain Name System) database that contains information about a specific domain name or IP address. Each RR includes various data fields, such as the domain name, time to live (TTL), record class, record type, and data.
The format of a resource record typically consists of the following five fields:
Name: This field specifies the domain name to which the record pertains. It can be represented as an FQDN (Fully Qualified Domain Name) or a relative domain name.
TTL: The Time to Live field specifies the time in seconds for which the record can be cached by DNS servers before it must be refreshed.
Class: The record class field indicates the type of network protocol used, usually either IN (Internet) or CH (Chaosnet).
Type: The record type field specifies the type of resource record, such as A (Address), MX (Mail Exchange), NS (Name Server), or CNAME (Canonical Name).
Data: The data field contains the specific information associated with the resource record, such as an IP address, mail server address, or domain name alias.
Here is an example of a resource record in its typical format:
example.com. 3600 IN A 192.168.1.1
This record specifies that the domain name "example.com" has an IP address of "192.168.1.1", with a time-to-live value of 3600 seconds, a record class of IN (Internet), and a record type of A (Address).
Basic DNS Record Types
A Record
An A record links a domain name to the IPv4 address of the machine hosting the domain. It is used to determine a computer's IP address when it is online. The initials of an A record stand for "address." Whenever you access a website, send an email, or perform nearly any other action on the Internet, the address you type is a string of words joined together by dots.
Let's consider an example where you run a website and a web server with an associated IP address hosts that website. You have also purchased a domain name for your website. The A record comes into play when you want to connect the domain name with the associated IP address. It associates your domain with the IP address of your server, enabling users to connect and load your website without having to remember and type in the website's actual IP address. Here is an example:
webserver.example.com. 3600 IN A 192.168.1.1
When a user's web browser receives the request, a DNS resolver query is automatically sent to complete the task. However, this is just the simplest use case of an A record. Another common scenario is load balancing. Load balancing involves distributing workloads across multiple resources, such as servers or computers, to improve performance, prevent overload, and reduce the risk of sudden downtime. We can use A records to load balance traffic across multiple web servers. Suppose you have several web servers hosting your website, each with a different IP address. In that case, you can create multiple A records for the same domain name, each pointing to a different IP address. When a user types in your domain name, their browser will randomly or based on a pre-applied algorithm choose one of the IP addresses to send the request to, effectively distributing the load across all the web servers. We will discuss load balancing in more detail in a later article.
Potential Security Risks of Using an A record
Securely managing A records is essential in mitigating potential attacks such as DNS cache poisoning and hijacking. DNS cache poisoning involves an attacker inserting a malicious DNS record into a DNS cache by spoofing DNS responses. As a result, a DNS resolver is directed to a malicious website instead of the legitimate website that the user intended to access. A records are often targeted in DNS cache poisoning attacks as they are used to map domain names to IP addresses.
DNS hijacking is another attack in which an attacker takes control of a DNS domain or subdomain by changing its associated DNS record. This can be achieved by compromising a DNS server or using a phishing attack to obtain login credentials for a DNS management console. In DNS hijacking attacks, attackers can modify A records to redirect users to a malicious IP address.
To mitigate these threats, it is recommended to use strong authentication methods to secure access to DNS servers and A records. Regularly reviewing and updating A records is also necessary to ensure their accuracy and to detect any unauthorized changes.
CNAME Records
CNAME records, canonical name records are a type of DNS resource record that maps a domain name to another domain name, effectively creating an alias or a nickname for the target domain name. An excellent analogy to understand CNAME records could be a person who goes by different names in different contexts. For example, a person named John may go by the nickname "Johnny" among friends, but use the full name "John Doe" in professional settings. Similarly, a web server may have a canonical domain name, such as "webserver.example.com", but also be accessible via an alias or nickname, such as "www.example.com".
www.example.com. 3600 IN CNAME webserver.example.com.
webserver.example.com 3600 IN A 192.168.1.1
So, when someone types www.example.com into their web browser, their computer will look up the IP address for webserver.example.com using the A record and use that to connect to the web server. A common example of how CNAME records can be used is creating a CNAME record for "www" that points to the domain name of a web server.
www.example.com. 3600 IN CNAME example.com
Note that the left-hand label is an alias for the right-hand side, which is a canonical name.
Best practices for using CNAME record
CNAME records must always point to another domain name and never to an IP address.
CNAME records that point to other CNAME records should be avoided as they can create unresolvable loops.
foo.example.com. CNAME bar.example.com. bar.example.com. CNAME foo.example.com.Avoid using CNAME records in conjunction with other types of DNS resource records, such as MX or NS records, as this can cause compatibility issues with some protocols.
example.com. MX 0 foo.example.com. foo.example.com. CNAME host.example.com. host.example.com. A 192.0.2.1
Potential security risks of using a CNAME record
Apart from DNS hijacking and DNS cache poisoning which is also a common security threat to a CNAME record, another potential risk is the subdomain takeover: This occurs due to a dangling CNAME DNS record. A dangling CNAME DNS record is a type of DNS misconfiguration that occurs when a CNAME record points to a domain or hostname that does not exist. In other words, the CNAME record is "dangling" because it points to nothing.
For example, suppose a CNAME record is created to alias the hostname "www.example.com" to "webserver.example.org", but the domain "webserver.example.org" does not actually exist. This would create a dangling CNAME record that could cause issues with DNS resolution and website access. These CNAME records can be used to take over subdomains by pointing them to a different domain controlled by the attacker in what is known as the subdomain takeover.
Hosting services providers e.g. Azure may guide to preventing this security loophole. This article also provides details on testing for subdomain takeover.
MX Records
MX (Mail eXchanger) records are a type of DNS resource record that is used to specify the mail server responsible for accepting email messages for a particular domain name.
When a mail server needs to deliver an email message to a particular recipient's email address, it first needs to determine the MX record for the recipient's domain name. This is done by performing a DNS query for the MX record associated with the domain name in the email address.
The MX record contains two pieces of information: the priority of the mail server and the host of the mail server. The priority value is used to indicate the order in which mail servers should be tried if the first one is unavailable where lower values indicate higher priority. The host value is used to specify the actual mail server that is responsible for accepting email messages.
An example of a single configuration of an MX record is:
Domain TTL Class Type Priority Host
example.com. 500 IN MX 10 mail.example.com.
In this case, all email messages for the domain "example.com" would be delivered to the mail server at "mail.example.com". However, having a single mail server can be a single point of failure - a component or system in a network or infrastructure that, if it fails, will cause the entire system to fail - so it's a good idea to have some redundancy or failover mechanisms in place to ensure reliable email delivery.
If there were additional MX records for "example.com", they would be listed in order of priority, like this:
Domain TTL Class Type Priority Host
example.com. 500 IN MX 10 mail.example.com.
example.com. 600 IN MX 20 backupmail.example.com
It is also possible to use MX records as a simple form of load balancing, by assigning multiple mail servers with the same priority. Here's an example of how this could be done:
Domain TTL Class Type Priority Host
example.com. 500 IN MX 20 mail.example.com.
example.com. 600 IN MX 20 backupmail.example.com.
In this example, there are two mail servers listed with the same priority value of "20". When a mail client needs to send an email to "example.com", it will randomly select one of the two mail servers to deliver the message. This can help distribute the load across multiple servers and provide some redundancy in case one of the servers becomes unavailable.
However, this form of load balancing is not very sophisticated and doesn't take into account factors like server load or availability. More advanced load balancing techniques like round-robin DNS or dedicated load balancers should be used for high-traffic or mission-critical services. I will discuss load balancing in a later article.
Potential security risks for using MX Records
Attackers can find out information about your email server or security solution by looking at your MX records. This information can help them create targeted phishing or malware attacks that take advantage of any weaknesses in your email security. For instance, if they know you use a security solution called Proofpoint, they might try to trick you into clicking on a bad link or attachment by making their message look like it's from Proofpoint. To protect yourself, it's important to keep your email server and security solution up-to-date and educate your users about how to recognize and report suspicious emails.
Attackers can create fake domains that look like yours, such as googleco.com and set up their email servers to send fake emails that appear to come from your domain, like info@googleco.com. This can harm your reputation, cause customers to lose trust in you, and even result in financial loss. To avoid this, it's important to watch out for any fake domains that resemble yours and take legal action if needed. You can also use special technologies to verify that your emails are authentic and prevent fake emails from being sent.
Advanced DNS Record Types
TXT Records
TXT records are a type of DNS (Domain Name System) record that is used to store text information in a domain's DNS zone file. They are often used to provide additional information about a domain or to verify ownership of a domain.
TXT Records can be used to implement DNSSEC (Domain Name System Security Extensions), DMARC (Domain-based Message Authentication, Reporting & Conformance), MTA-STS (Mail Transfer Agent Strict Transport Security), and BIMI (Brand Indicators for Message Identification). These are all methods to enhance the security and authenticity of email messages and domains. A TXT record can also be used to store other types of information, such as a company's contact information, copyright information, or other metadata.
AAAA Records
AAAA Records are resource records that map a domain name to an IPv6 address, which is a 128-bit address used by the latest version of the Internet Protocol.
For example, an AAAA record for the domain example.com might look like this:
example.com. 86400 IN AAAA 2001:0db8:85a3:0000:0000:8a2e:0370:7334
AAAA records are important for ensuring that users can access websites and other Internet resources that are hosted on IPv6-enabled servers. As more and more devices are connected to the Internet, the use of IPv6 is becoming increasingly important to ensure that there are enough addresses available for all of these devices.
SRV Records
SRV Records are resource records that are used to specify the location of a service inside an infrastructure. For example, if you have a web server in the infrastructure, by using an SRV record, you can specify the protocol, service, and domain name and then define the service location.
An example of an SRV record is:
_sip._tcp.example.com. 3600 IN SRV 10 100 5060 sipserver.example.com.
This record indicates that the service name is SIP (Session Initiation Protocol), the protocol is TCP (Transmission Control Protocol), the domain name is example.com, the TTL (Time to Live) is 3600 seconds, the priority is 10, the weight is 100, the port number is 5060, and the target hostname is sipserver.example.com. This means that clients looking for a SIP service over TCP for example.com should connect to sipserver.example.com on port 5060 with a preference for lower priority values and higher weight values among other SRV records with the same service and protocol.
NS Records
NS (Name Server) records are DNS records that are used to list authoritative DNS servers for a particular domain. Name servers are responsible for storing and providing DNS information for a domain, such as the IP addresses of the servers associated with that domain. A domain often has multiple NS records which can indicate primary and backup name servers for that domain.
For example, an NS record for the domain example.com might look like this:
example.org. 86400 IN NS a.iana-servers.net.
example.org. 86400 IN NS b.iana-servers.net.
Conclusion
DNS records are made up of different types of DNS resource records. These record types specify different information about a domain name, such as its IP address, alias, mail server, service location, and more. In this article, we explained the basic and advanced record types and how they help us manage or secure our DNS records. This article does not cover all the record types that exist, but it gives us a good foundation to understand the more complex ones. In the next article, we will discuss how to monitor our servers and web applications and why it is important for our system performance.
References
DNS Security: Defending the Domain Name System" by Allan Liska and Geoffrey Stowe
DNS and BIND by Cricket Liu and Paul Albitz
Mastering Active Directory - Second Edition” by Dishan Francis
https://support.dnsimple.com/articles/a-record/
https://en.wikipedia.org/wiki/CNAME_record
https://en.wikipedia.org/wiki/MX_record
https://fraudwatch.com/email-security-mx-records/
https://www.cloudflare.com/en-gb/learning/dns/dns-records/dns-ns-record/