After having roamed around infosec in general last week, this post gives some advice on how to gain additional privacy by changing your IPFire's DNS configuration. DNS happens to be a very basic thus quite important protocol of today's internet, but is still being considered a low-risk one when it comes to security and privacy.

DNSSEC - love it or loathe it, it is here to stay

If you are familiar with IPFire, you might have noticed DNSSEC validation is mandatory, since it defeats entire classes of attacks. We receive questions like "where is the switch to turn off DNSSEC" on a regular basis, and to say it once and for all: There is none, and there will never be one. If you are running IPFire, you will be validating DNSSEC. Period.

Another question frequently asked is why IPFire does not support filtering DNS replies for certain FQDNs, commonly referred to as a Response Policy Zone (RPZ). This is because an RPZ does what DNSSEC attempts to secure users against: Tamper with DNS responses. From the perspective of a DNSSEC-validating system, a RPZ will just look like an attacker (if the queried FQDN is DNSSEC-signed, which is what we strive for as much of them as possible), thus creating a considerable amount of background noise. Obviously, this makes detecting ongoing attacks very hard, most times even impossible - the haystack to search just becomes too big.

Further, it does not cover direct connections to hardcoded IP addresses, which is what some devices and attackers usually do, as it does not rely on DNS to be operational and does not leave any traces. Using an RPZ will not make your network more secure, it just attempts to cover up the fact that certain devices within it cannot be trusted.

Back to DNSSEC: In case the queried FQDNs are signed, forged DNS replies are detected since they do not match the RRSIG records retrieved for that domain. Instead of being transparently redirected to a fradulent web server, the client will only display a error message to its user, indicating a DNS lookup failure. Large-scale attacks by returning forged DNS replies are frequently observed in the wild (the DNSChanger trojan is a well-known example), which is why you want to benefit from validating DNSSEC and more and more domains being signed with it.

Since DNSSEC also introduces authentic denial of existence, it enables some improvements such as aggressive NSEC (RFC 8198), where a resolver attempts to determine if a queried record can exist at all according to DNSSEC signatures. If not, there is no need to bother the public DNS infrastructure, thus returning NXDOMAIN to the client faster, which is especially useful for crappy devices or applications (such as Chromium) querying the same non-existent FQDNs over and over. Needless to say, IPFire comes with common DNS hardening techniques not depending or related to DNSSEC as well, such as cache poisoning prevention or malicious resolvers trying to strip out DNSSEC information.

Do not confuse DNSSEC with DNS over TLS or DNS over HTTPS

While DNSSEC introduces trustworthiness to the Domain Name System, it does not make it more confidential. Despite being unable to tamper with your DNS traffic, an attacker is still able to see which resources are queried. In most cases, those match the web sites visited afterwards, effectively leaking your browser's history up to the "slash" in the URLs, as Michael explained earlier this year.

Unfortunately, DNSSEC and DoT or DoH are regularly mixed up, especially in mass media coverage.

In case you have to combat against a more sophisticated attacker, keeping the list of (frequently) visited web sites confidential might be a good idea to make watering hole attacks more harder, where an attacker tries to inject malware into sites you are likely to visit in future (the NotPetya wiper was distributed that way, causing massive damage especially in Ukraine).

Either way, one might want to hide its DNS traffic from anybody barely able to run a tcpdump on the wire. This includes your ISP, which is why the author would like to stress not using your ISPs resolvers once again.

Choose DoT resolvers wisely

Since using DNS over TLS requires selecting some resolvers capable of TLS, one has to think about which their various aspects of when selecting them (a list of known public resolvers is available from the wiki).

For privacy reasons, it is best to stay away from big resolvers run by profit-oriented companies, such as Google, Cloudflare, Quad9 and others. They do not sell cookies, and they do not provide service for free. If you do not pay with money, you almost certainly pay with your data.

At least in Europe¹, there are quite some public DoT resolvers run by non-profit organisations, of which some are engaged in protecting peoples' privacy. Those might be less untrustworthy, but make sure to check their terms and conditions, e.g. for logging policies.

However, in the end, somethings got to give. Even if a resolver operator looks fine, there is usually no way of telling whether or not it does maintain any logs, deletes them properly or has good security practices in place.

To minimise potential damage of data breaches or security incidents, it is therefore recommended to choose at least four DoT resolvers operated by different parties and located in different countries. Depending on legal issues and local adversaries, one might want to entirely avoid resolvers located in the same country as the IPFire machine(s) administered.

"The logs, the logs. All the answers are in the logs."

This quote from Postfix author Wietse Venema does not fully apply to IPFire users, as its DNS resolver, Unbound, is configured not to log queries or even DNS replies. However, it does log DNSSEC validation failures (i.e. queries responded with SERVFAIL), which usually indicate network outages, DNS zone configuration errors, or manipulation attempts by active attackers.

To notice the latter, consider monitoring such events. Depending on your environment, there might be false positives, especially with unstable or overloaded internet uplinks, but in case your banking site fails to validate, things become worth a closer look.

This post assumes all of the clients located behind an IPFire systems are solely using its DNS resolver and are unable to bypass it. This is not always true - for example, some IoT devices come with hard-coded DNS resolver settings -, and some firewall rules are required to enforce this.

This and a secure firewall configuration in general are the topics of the upcoming post.