Privacy and Security

Enabling DNS over TLS (DoT) in Unbound offers an immediate way to increase privacy by encrypting DNS queries, preventing intermediaries from passively monitoring or manipulating DNS traffic. To configure this option, you can modify the unbound.conf file by specifying parameters that enable TLS on a dedicated port, typically 853. You'll need to generate or obtain a valid TLS certificate and key pair, placing them in a secure location, such as /etc/unbound/ssl, and then include lines similar to the following:

tls-service-key: "/etc/unbound/ssl/ unbound_tls.key"
tls-service-pem: "/etc/unbound/ssl/ unbound_tls.crt"

under the server: section. Additionally, do-tls: yes and interface: 0.0.0.0@853 will tell Unbound to listen for TLS-encrypted DNS queries on the appropriate interface. On systemd-based Linux distributions, reload the configuration with systemctl reload unbound, and then verify connectivity via a DNS testing client like kdig or drill, to ensure that your service properly encrypts traffic. For those deploying Unbound in cloud environments, remember to adjust your firewall settings (using tools like UFW or firewalld) to open port 853 only to trusted IP ranges, thereby blocking unauthorized access to your encrypted DNS service (Figure 5).

Figure 5: Example unbound.conf snippet enabling DNS over TLS (port 853).

Secure

Along with encrypting DNS traffic, blocking malicious domains is a practical way to protect systems from known threats such as phishing sites, botnet command-and-control servers, and spyware endpoints. One approach is to integrate custom blocklists directly into unbound.conf or a dedicated configuration include file. You can specify domains to refuse by using directives like:

local-zone: "badsite.example" refuse

(as shown in Figure 6) or create more scalable lists by scripting the generation of local-data statements for each malicious domain. If you maintain your blocklists in a version-controlled repository or fetch them from reputable external sources, you can automate updates with cron or Ansible playbooks, ensuring that new threats are regularly added to the list. After adding or updating the blocklist directives, reloading Unbound confirms that the malicious domains are immediately blocked. Because each refused query returns a response indicating that the domain does not exist, unsuspecting clients are protected from inadvertently reaching harmful destinations. In high-volume environments, it could be beneficial to store blocklists in memory and periodically prune outdated entries to preserve performance.

Figure 6: Creating a custom blocklist rule.

Strict query filtering and comprehensive logging policies further tighten security by controlling what DNS information is processed and by capturing detailed records for future auditing. For instance, if you require your resolver to serve only internal domains, you can employ access-control directives to limit resolution requests to specified internal ranges and local-zone statements to define how certain queries should be handled. This granular approach prevents accidental or malicious queries from leaving your trusted network.

The logging configuration in unbound.conf can specify different verbosity levels, letting you track routine lookups for troubleshooting or elevate the logging detail when investigating suspicious activity. By default, Unbound outputs logs to syslog, but you can redirect them to a dedicated file, which might be more convenient for parsing with tools like Logstash or Splunk. Keep an eye on the log rotation policies in /etc/logrotate.d to avoid filling disk space in busy or long-running deployments, especially in containerized platforms where storage might be limited.

A well-hardened Unbound setup also addresses the risk of DNS amplification attacks, which attackers can exploit by sending forged requests that produce large responses to overwhelm a target. Resource controls in unbound.conf help mitigate this risk by rate-limiting requests or responses, ensuring that your server cannot be abused as a reflector. For instance, setting a value for do-ip4: yes in combination with interface-automatic: no enforces stricter boundaries on which interfaces handle DNS queries.

Meanwhile, directives like unwanted-reply-threshold can help identify and block abnormal traffic patterns, and an appropriately configured max-udp-size and so-reuseport can distribute load across CPU cores while preventing excessive resource consumption. Administrators managing infrastructures over SSH in cloud environments should further bolster these defenses by enabling network-level restrictions, such as only allowing inbound DNS queries on private subnets or from known IP addresses. Automation suites like Ansible make these protections reproducible and straightforward to roll out at scale, ensuring that each newly provisioned resolver adheres to the same stringent security configurations. By blending DNS encryption, dynamic blocklists, strict filtering, comprehensive logs, and resource limits, Unbound can serve as both a robust gatekeeper for critical DNS services and a high-performing component in a multilayered security architecture.

Summary

This article explored the steps for deploying Unbound as a secure, high-performance DNS resolver on a variety of Linux distributions. By carefully tuning unbound.conf, specifying network interfaces, and enforcing access controls, administrators can limit exposure to unwanted queries and ensure that the resolver only services approved subnets or hosts. The addition of DoT encryption and custom blocklists addresses privacy and threat mitigation at the network edge, shielding users from data interception and redirecting malicious domains to a dead end. This article also looked at how strict query filtering, logging policies, and resource controls work together to keep potential DNS amplification attacks at bay while preserving the responsiveness of your environment. These measures underscore the resilience of an Unbound-based architecture, making it suitable for everything from small office setups to large cloud environments supporting diverse, geographically distributed workloads.

The Author

Marcin Gastol is a senior DevOps engineer and Microsoft Certified Trainer with extensive experience in Azure technologies and teaching various IT subjects. He writes about multiple IT topics on his blog, https://marcingastol.com/.