Ctrl.blog

Allowing remote connections

By default, Knot Resolver will only allow connections from the local system. This is useful if you intend to use it as a caching server for a single device. However, you’ll get the best performance by sharing the same DNS cache between all the devices in your network. It can also be beneficial to also setup local caches on laptops and devices that roam between different networks.

Update (2020-06-26): This section previously discussed how to manage Knot’s systemd activated socket (kresd.socket.) However, that has been deprecated since Knot Resovler version 5 and has been removed from the tutorial. The tutorial has been updated to include new instructions.

You must configure a new net.listen directive and specify the IP address you want Knot to listen to incoming connections on. Open up /etc/knot-resolver/kresd.conf in your favorite editor and include the following configuration. Adjust the IP to the server’s LAN or WAN address depending on which networks you want it to accept DNS queries from.

-- listen to local connections
net.listen(net.lo, 53)
-- listen to connections on this IP
net.listen('198.51.100.1', 53)

The last step required is to poke a hole in your firewall for incoming connections. The below are example commands that create permissive rules with FirewallD or UFW. You should adjust these to only allow connections from your local network unless you want Knot Resolver to be available on the public internet.

# Add DNS to default FirewallD zone (CentOS, Fedora Linux)
firewallctl zone "" --permanent add service "domain"

# Add DNS to (Ubuntu)
ufw allow "domain"

Tweaking the default configuration

You can find extensive documentation on optional modules and their configuration in Knot Resolver Modules documentation.

If you don’t want to read through all that documentation; I’ll suggest a configuration that improves reliance, improves security and performances, and improves compatibility.

Open up /etc/knot-resolver/kresd.conf in your favorite editor and include the following configuration:

-- SPDX-License-Identifier: CC0-1.0

-- Enable optional modules
modules = {
  'policy',
  'hints',
  'serve_stale < cache',
  'workarounds < iterate',
  'stats',
  'predict'
}

-- Forward queries to Quad9
policy.add(policy.all(policy.FORWARD({'9.9.9.9', '2620:fe::fe', '149.112.112.112'})))

-- Cache size
cache.size = 150 * MB

-- Prefetch learning (20-minute blocks over 24 hours)
predict.config(20, 72)

-- Enable DNSSEC validation
trust_anchors.file = '/etc/knot-resolver/root.keys'

Most of the above configuration is straightforward, but I’ll explain what the configuration changes do in more details.

The first set of changes load some additional modules in a specific order to enable additional features. For example, the workarounds module is loaded before the core iterate module. The workarounds module contains a set of hotfixes to ensure compatibility with DNS servers with known compatibility problems with modern DNS standards.

The policy module can be used to manipulate request handling. I’ve set uncached requests to be forwarded to the IPv4 and IPv6 addresses of Quad9. Quad9 is a security-enhanced public DNS server that proactively blocks domains used to communicate with botnet and other malicious activity that promises to not log any requests from users. Quad9 will act as an intermediary caching proxy which will significantly improve performance of most DNS queries. If you remove this directive, Knot Resolver will have to resolve the whole DNS chain from the root servers and down to the queried domain’s DNS servers. This is significantly slower than using an intermediary caching provider.

The serve_stale module allows expired entries to be served from the cache for some additional time when the upstream DNS server is unable to respond to queries. This can help mitigate the impact on you with regards to the websites you visit the most during a large scale distributed denial of service (DDoS) attack against critical DNS infrastructure (as we’ve witnessed again and again in recent years.)

The stats and predict modules work together to identify usage patterns and preemptively refresh expired queries from the cache. We all have patterns for when in the day we check our email and specific websites. So too do many of the internet-of-things devices we have in our homes. Knot Resolver may end up sending some unnecessary requests for this feature to work. However, in my experience its quite good at deciding which domains it should keep up-to-date in its cache and when it should stop updating domains I no longer visit.

Lastly, Knot Resolver is configured to validate DNSSEC. Domain owners can cryptographically sign their domains in a way that a validating resolver (such as Knot Resolver) can ensure that a third-party hasn’t modified or hijacked the domain. In Fedora Linux, this just requires this line to be present.

-- SPDX-License-Identifier: CC0-1.0

-- Forward queries encrypted to Quad9 over TLS
policy.add(policy.all(policy.TLS_FORWARD({
  {'9.9.9.9', hostname='dns.quad9.net', ca_file='/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem'},
  {'2620:fe::fe', hostname='dns.quad9.net', ca_file='/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem'},
  {'149.112.112.112', hostname='dns.quad9.net', ca_file='/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem'}
})))