Table of contents
This is Part 2 of my previous article: Decoding DNS — Understanding and Troubleshooting DNS Fundamentals. It dives head first into the fundamentals of DNS and how it serves as a critical system for navigating the internet and your homelab's network.
In this article, I'll be going into more specific detail about how private you can maintain proper DNS traffic, why you would want to take the time to anonymize your queries, and mitigating popular attacks against DNS servers or systems in general.
Many might assume that it's harmless for servers or endpoints to have clear, plaintext visibility into your internet browsing plans. However, unless adequately secured, this visibility could expose you to certain risks if shared openly with anyone else on your network or with individuals remotely monitoring your browsing activity. A potential attacker, for instance, could maliciously manipulate your DNS queries, using redirection or spoofing tactics to cause you to enter your banking credentials into a fake website, or give up private information into a seemingly legitimate website. This could also lead to downloading harmful software such as malware, ransomware, or other types of Remote Access Trojans (RATs) or worm-based threats.
Understanding DNS Security
A lack of DNS security could leave you vulnerable to attacks that exploit weaknesses in DNS communication. With DNS queries often going unencrypted, the destination of your online navigation is potentially visible to prying eyes. It's important to understand that, without proper protections, this transparency can open the door to nefarious activities that could affect your system. Enhancing your DNS security can help prevent these threats, protecting you from unwelcome intrusions and potentially harmful software.
Domain Name System Security Extensions (DNSSEC) is a set of protocols added to DNS to address its inherent vulnerabilities, particularly its susceptibility to DNS spoofing or cache poisoning. DNSSEC adds authenticity and integrity to the DNS process by utilizing asymmetric cryptography to sign outbound DNS data.
When a zone (see resolver) is DNSSEC-enabled, the zone data is signed using a private key to generate a set of DNSSEC records. These records are then served alongside the normal DNS records. The corresponding public key, used to validate the signatures, is also made available as a DNSSEC record, but this itself is signed by the parent zone's private key. This chain of trust continues up to the root DNS servers, which are implicitly trusted.
When a DNS resolver receives DNSSEC data, it can use the public keys to validate the signatures, checking that the data hasn't been tampered with in transit, and that it comes from the correct source. If validation fails, the resolver can discard the data, protecting against forged or tampered DNS data.
To be clear: DNSSEC does not encrypt or even hide DNS data—queries are still sent in plaintext. DNSSEC serves to strictly validate DNS queries came from the original source without changing.
DNS over TLS (DoT) / DNS over HTTPS (DoH)
Traditionally, DNS queries have been transmitted in plaintext, a fact that has several security and privacy implications. Any entity monitoring network traffic can view and potentially manipulate DNS queries and responses. To address these vulnerabilities, two key protocols have been developed: DNS over TLS (DoT) and DNS over HTTPS (DoH).
DNS over TLS (DoT)
DNS over TLS, also known as DoT, is a security protocol that provides privacy for DNS queries by encrypting the data between the DNS client and the DNS resolver. DoT uses the Transport Layer Security (TLS) protocol, which is widely used on the internet to secure communications. By leveraging TLS, DoT protects DNS queries from eavesdropping and manipulation by encrypting the entire DNS conversation from the client to the server.
However, DoT uses a distinct port (port 853), which can make its traffic subject to blocking or filtering by network operators who don't recognize or support it.
DNS over HTTPS (DoH)
DNS over HTTPS, or DoH, offers similar security advantages by encrypting DNS queries, but it does so within standard HTTPS traffic on port 443, making it indistinguishable from regular secure web traffic. This can provide additional privacy benefits, as it's more difficult for outside observers to identify or block DNS queries specifically as the DNS traffic would merge with your computer's standard HTTPS traffic.
DoH is designed to be compatible with existing web infrastructure as it sends DNS queries and gets responses over HTTPS protocol. This design can be particularly advantageous in environments where internet censorship is prevalent, as blocking DoH would require blocking all HTTPS traffic.
Both DoT and DoH provide valuable enhancements to DNS security by preventing eavesdropping and tampering of DNS traffic. However, they do not inherently validate the authenticity of DNS responses; for that, DNSSEC is still needed. Also, while these methods enhance privacy from network observers, they centralize the DNS resolution to fewer providers, which could raise different privacy considerations depending on the trustworthiness of the DNS resolver provider. At the end of the day, the authoritative DNS server will have to decrypt the final DNS request.
In summary, DNS security requires a multi-pronged approach: DoT or DoH to secure the transport of DNS queries, and DNSSEC to ensure the integrity and authenticity of DNS data. A combination of these technologies forms the basis of a secure DNS strategy and would anonymize most DNS requests, as long as the upstream resolvers support these means of communication.
While fundamental to internet operation, the DNS protocol contains inherent vulnerabilities. Its initial design didn't prioritize security, giving rise and leaving it exposed to threats like DNS spoofing, cache poisoning, and man-in-the-middle attacks.
Below are some of the most common DNS attacks that are in use:
DNS Spoofing / Cache Poisoning
DNS Spoofing and DNS Cache Poisoning are types of DNS attacks where an attacker diverts traffic intended for a specific IP address to a different IP address that they control or modifies local cache contents to redirect traffic to another source. This is done by contaminating a DNS resolver's cache with incorrect information maliciously or by forcing a system to acknowledge a fraudulent DNS address.
In the conventional DNS resolution process (going back to my first article above) a DNS resolver that doesn't have a needed mapping in its cache will query upstream DNS servers to find the IP address for a specific domain name. The DNS resolver caches the answer for a period specified by a Time-To-Live (TTL) parameter in the DNS response to improve performance and reduce load on the DNS infrastructure.
The attacker seeks to insert a false address record for an Internet domain into the DNS resolver's cache. This is usually achieved by getting the DNS resolver to query for a domain the attacker controls, and including the spoofed entry in the DNS response.
Attacks like this can have serious implications, including traffic interception, website impersonation, and unauthorized network access, making DNS Spoofing a significant threat to online security and privacy. The attacker can lead you to a fake website, stealing valuable personal information.
Mitigation techniques include using DNSSEC to cryptographically verify the authenticity of DNS data, using hardened local DNS resolvers that are resistant to cache poisoning, or setting a very low TTL to constantly request new information, which could impact performance.
Man-in-the-Middle (MITM) Attacks / Hijacking
Another form of prominent spoofing can take place in the form of a Man-in-the-Middle (MITM) attack, a common vector for adversaries to manipulate network communications. A MITM attack is a form of eavesdropping where the attacker intercepts and potentially alters the communication between two parties without their knowledge. This can be performed in a number of ways—I won't go into much detail about that here.
If successful, the attacker can intercept DNS queries from the client, and send back fraudulent DNS response packets before the legitimate response from the actual DNS server reaches the client. The client, assuming the response is legitimate, caches the fraudulent DNS record and uses it for subsequent requests.
The DNS response packets from the attacker must satisfy certain conditions to be accepted by the client. The source IP must match the IP of the DNS server the client believes it is communicating with, the destination IP and port must match those of the original client's request, the transaction ID of the response must match that of the client's request, and the domain name in the question section of the DNS response must match the domain name in the client's request.
DNS Hijacking is in a similar vein to what is experienced in a MITM attack, without the overhead of monitoring and forwarding traffic. Hijacking ultimately redirects traffic from one domain to another without the users knowledge or consent by modifying records on the server, instead of manipulating cached credentials.
Mitigations for this type of attack can primarily include implementing secure protocols for DNS resolution such as DoT or DoH. DNSSEC can also be effective, providing a mechanism to verify that DNS responses have not been tampered with in transit. One can also look into the DNS-based Authentication of Named Entities (DANE) protocol, alongside DNSSEC, to ensure that the traffic arrives to the authoritative resolver with a valid issued signature for their TLS/SSL communications. DNSSEC will only ensure that the queries are being signed with a signed certificate, but will not act as a Certificate Authority (CA) to determine if the incoming certificate was valid or issued correctly—this is where DANE comes in.
Flooding & Amplification
DoS / DDoS
Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks are very common attack vectors by most threat actors. In these cases, DNS servers are pummeled with a constant stream of fraudulent requests, forcing the server to spend resources responding to invalid queries, ultimately bringing the server to it's knees or, in the worst case, a grinding halt.
Flooding is a type of DDoS that coordinates to strictly consume the resources of a DNS server in a particular way, making it unable to respond to legitimate requests. There are various types of DNS flooding attacks, such as subdomain attacks, NXDOMAIN (NXD) attacks, which is an attack that floods the server with requests to addresses that purposefully do not exist, and Phantom Domain attacks, in which the attacker requests numerous seemingly valid domain names that were purposefully deployed to respond slowly or never at all, lengthening response times. After some point, the requesting DNS server may consume its cached storage limit, waiting for the fake domains to respond, ultimately killing the server.
In this attack, a threat actor sends a small query to a DNS server while spoofing the IP address of the targeted victim. The DNS server, often misconfigured to accept queries from anyone (typically labeled an "open resolver"), responds with a much larger payload. Since the victim's IP address was used, the response is sent to them instead of the attacker. With multiple such requests, the victim's network can become overwhelmed by the unexpected influx of data, potentially causing service disruptions.
Mitigating these kinds of attacks can be done on numerous layers, even as close as the Application layer, but mainly this is performed at the Network or Transport layer. Firewalls can be put in place to attempt to block DoS/DDoS attempts, or proxies can be implemented to filter traffic requests to load balanced services. Redundant DNS servers should be configured as fall-back servers in the event that these attacks successfully inundate primary or upstream resolvers. To combat NXD attacks, it's important to consistently monitor DNS logs to ensure rogue IPs or domain names are not attempting to query fake addresses, and if so, blacklist the addresses originating those requests. Increasing TTL parameters on authoritative servers may ensure that they'll remain valid for some time in the event the servers are knocked offline, but could open up cache poisoning vulnerabilities if not secured.
Probably the most destructive of the attempts to combat while attempting to secure your servers, DNS Tunneling targets individual users or systems by routing malicious payloads, unsuspectedly and through DNS traffic, to their systems.
This is one of the more complicated attacks, and requires a couple moving parts to get working right while simultaneously remaining undetected. It's typically performed by large threat actors (namely APTs) to initiate ransomeware attacks or implement Command and Control (C&C/C2) streams to their remote locations. Typically malware is installed on the affected user's machine via phishing campaigns, drive-by downloads, or exploiting system vulnerabilities.
Once the malware is installed on a user's system, it sets up a covert connection back to the C2 server. This connection is often masked to elude detection systems, blending its communication within legitimate network traffic on common ports. With the connection established, the malware lies in wait for commands from the C2 server. These instructions can initiate a broad spectrum of malicious activities, from data exfiltration to launching additional attacks within the network. In some cases, the infected machine may be added to a botnet, a network of compromised devices used to amplify the impact of cyberattacks such as DDoS.
This multi-layered attack strategy presents significant challenges to defenders due to its complexity and the use of common network protocols to mask malicious activities. Therefore, a strong defense requires a multi-faceted approach, encompassing robust endpoint protection, network monitoring, user education, and incident response capabilities.
Mitigation attempts for this are advanced enterprise-grade solutions. Implementations like: DNSSEC, DoH/DoT, Secure Web Gateways, perimeter and endpoint firewalls, Intrusion Detection Systems (IDS) / Intrusion Prevention Systems (IPS), SIEM/log pattern monitoring, traffic filtering, deep packet inspections, VLAN segregation, heuristic analysis, outbound rate-limiting, etc.
Thank you for taking the time to sit through this not-so-short series about the fundamentals of DNS, and now with this second installment, all about securing your DNS, hopefully implementing secure practices that maintains the security of your servers.
In future articles, I may go into detail about my own DNS security and structure that I currently implement in my personal homelab. 😉
I will say, I currently implement a containerized Pi-Hole for general adblocking and custom DNS routing while utilizing DNSSEC on my primary DNS server, configured with recursive DNS services via pfSense using Unbound as my upstream, DoT enabled and finally configured Cloudflare as my authoritative. My DNS requests are secure to an extent. I need to implement local DANE services to be truly secure, but I'll worry about that when I get closer to securing my own local CA for my other servers and SSL needs.
Let me know if you'd me to go into detail about other computing topics and subscribe to my newsletter for more informative articles and upcoming homelab adventures!
Did you find this article valuable?
Support Justin Carver by becoming a sponsor. Any amount is appreciated!