What you can do with the new DNS features in IPFire

by Michael Tremer, February 26, 2020, Updated February 27, 2020

IPFire 2.25 - Core Update 141 comes with many new features around DNS. We have cleaned up a couple of problems with the old design and we have added new functionality that will improve security. But it is up to you to make use of this now.

How can DNS data being used to spy on you?

Every time you try to access a website - for example ipfire.org - you will ask a DNS server for the IP address to connect to. They won't see anything past "the slash" in the URL, but that is not necessary to know what you probably have in mind to do. That DNS server now knows which bank you are with, where you work, where you do your online shopping, who is hosting your emails and many things more...

Although this data is not too interesting about one individual, it becomes very relevant when you are looking at many profiles. People who shop at a certain place or are with a certain bank might be high earners. People who shop at another place might have trouble to stay afloat financially. Now I know what advertisements I need to show to which group so that they will become my customers.

In short, your whole browser history tells a lot about you and you might be giving it away for free to the advertising industry or other parties who will use your data against you.

The default: Name servers from your ISP

We know for certain that some ISPs are selling their data to third parties for those purposes. They are profit-oriented companies and everything they do evolves around this simple principle.

So are some technical issues motivated by this very same reason: It is quite likely that your ISP name servers are quite slow. That is because running them costs money and they are not bringing any new customers. As long as websites open, the ISP has done their job.

Some even turn off TCP, because of its large overhead in bandwidth and memory consumption. Of course this is not RFC-compliant and can break DNSSEC. There are numerous other "offences" like redirecting users to an advertising page in case they mistyped a domain to earn more money that way.

In my personal opinion, the ISPs have done it too far.

Alternative Providers

But there are alternatives out there. Many organisations run free DNS servers to overcome the shortcomings of the ISPs. Those can be split into two groups:

  • Organisations that are often charities which have acknowledged that there is not too many free name servers out that and that there are users which need an alternative.
  • For-profit organisations like Google, Cloudflare, IBM, etc. which are tracking users.

There is a list on the IPFire Wiki with which ones are available and close to you.

Recursor Mode

I really like this feature, but for some reason it has a bad reputation in the project. When the web user interface has shown "local recursor" many people assumed that their DNS is broken. I do not know how they came to that conclusion because it must have been working as long as they had internet connectivity.

The difference here is that instead of contacting a large DNS recursor on the Internet, IPFire itself plays the role of the recursor:

Normally IPFire would send a DNS request for www.ipfire.org to your ISP's DNS server and wait for the response.

A recursor would split the DNS name into parts and resolve one at a time. In this example, it would try to find out who is a responsible name server for the org zone. Then it would contact that name server and ask for a name server that is responsible for ipfire.org and finally contact our own name servers and ask for the IP address of www.ipfire.org.

As you can see, there is no central authority in this process - one of the core design principles of the Internet. But if this is all so great, why are we all not using this all of the time?

There are some downsides to a local recursor: They can be slightly slower because of more steps to resolve a DNS query and they cause some other privacy problems. You ISP's name server is executing exactly the same for each query, but also caches responses. That means that there is a good chance that somebody else has already visited www.ipfire.org very recently and therefore the name server already knows the IP address and can send the reply quickly from the cache.

If you have a swift internet connection, you probably do not need to worry about this, but if you are connecting using a high-latency wireless link, you will probably feel DNS being a couple of milliseconds slower. Normally this is not noticeable.


As the recursor is not telling one upstream name server your full browser history, that privacy issue is gone. However, you will still tell the people from the org zone that you want to talk to ipfire.org. The people from the com zone will know that you want to talk to google.com and of course Google will know that you want to talk to them.

Although I personally do not see any problem with the latter case (because if you want to talk to Google, you will sooner or later send them an HTTP request), some people do not trust the operators of the top-level domains. If you can hide behind a public DNS recursor, those won't see who the request is coming from. But of course the operator of that DNS server will.

So in the end, the decision is up to you who you are going to trust and who not. But please note, that the recursor mode does not mean that your DNS is broken. It simply is another way with its own advantages and disadvantages.

TLS and how it can protect you from eavesdropping

Last but not least: DNS over TLS.

I have a huge problem with when some technology is being presented as solving a problem but it actually isn't. That seems to become more and more of a thing.

DNS over TLS is being presented as bringing back your privacy. Well. That is not entirely wrong. It has TLS in its name, so it must be very secure. The question that is not being answered is privacy against whom?

The simple fact is that you are opening a TLS connection to your DNS resolver which cannot be read by your ISP any more. It is encrypted. It is as simple as that.

But the other end obviously needs to decrypt the packets again to find our what you want from them. And so the operator of the DNS server has all the information that they would have with using UDP or TCP. They know who is asking for what website. See above for what that means.

Hence TLS should be used when you trust your DNS operator, but it does not mean that you do not need to trust them. There is no technical thing that makes it more difficult to spy on you.

To sum it all up...

It is all a trade off. I am sure you have figured this out by now that there was no clear advise in this post so far. I am always very reluctant to give some, because there is many things to consider before a decision is being made.

I will make an exception to this rule today and would like to strongly advise you to no longer use the DNS servers of your ISP. They are probably bad.

For any alternative it again makes sense to use DNS over TLS. Not many alternative providers offer this yet, but the number is growing fast because new implementations like this one in IPFire are creating demand. Which ones should you use? Here is the list on our wiki. Take your pick.

I would once again strongly consider to avoid sending your whole browser history to the big ones that are guaranteed to use it again you. Stay away from Google, Cloudflare, etc.

The new UI allows you to enter as many DNS servers as you like. Two is rather conservative and I would recommend to have at least four. The fastest one will always be used, so there is no downside in having a couple more in there, even if they are further away. You will get better resilience against a downtime, too.

We have given you a box full of tools now. It is on you to use it right!