How Pi-hole Works

Pi-hole acts as a forwarding DNS server, which means if it doesn’t know where a domain is, it has to forward your query to another server that does. When you install Pi-hole, it knows where the ad-serving domains are (because you tell it), so it doesn’t forward those requests. But it doesn’t know where legitimate sites are. Thus these requests are forwarded to an upstream, recursive server.

These servers also don’t know where the real Website exists unless they have been asked to find it before. The only DNS servers that truly know where a domain is is an authoritative DNS server. For now, we don’t need to know what an authoritative DNS server is, just that it’s the single source of truth for a domain’s real IP address.

So when you have a Pi-hole in use on your network, the flow of traffic goes like this:

1. Your client asks the Pi-hole Who is pi-hole.net?
2. Your Pi-hole will check its cache and reply if the answer is already known.
3. Your Pi-hole will check the blocking lists and reply if the domain is blocked.
4. Since neither 2. nor 3. is true in our example, the Pi-hole forwards the request to the configured external upstream DNS server(s).
5. Upon receiving the answer, your Pi-hole will reply to your client and tell it the answer of its request.
6. Lastly, your Pi-hole will save the answer in its cache to be able to respond faster if any of your clients queries the same domain again.

The Concern With Upstream Servers

The concern with the existing method lies in step 4. In today’s world, these upstream servers are known as Google, OpenDNS, and CloudFlare, amongst others. They advertise themselves as free private DNS servers, but how do you know for certain they are keeping their promise that your information is truly private?

Furthermore, from the point of an attacker, the DNS servers of larger providers are very worthwhile targets, as they only need to poison one DNS server, but millions of users might be affected. For example, instead of your bank’s actual IP address, you could be sent to a phishing site hosted on some island. This scenario has already happened and it isn’t unlikely to happen again…

So What Is The Difference Between A Recursive DNS Server and An Authoritative DNS server?

The first distinction we have to be aware of is whether a DNS server is authoritative or not. If I’m the authoritative server for, e.g., pi-hole.net, then I know which IP is the correct answer for a query. Recursive name servers, in contrast, resolve any query they receive by consulting the servers authoritative for this query by traversing the domain. Example: We want to resolve pi-hole.net. On behalf of the client, the recursive DNS server will traverse the path of the domain across the Internet to deliver the answer to the question.

What Is The Solution?

Operating your own local, recursive DNS server. Think of it as running your own Google or CloudFlare DNS service. It can run on the same device you are already using Pi-hole for and there are no additional hardware requirements.

This changes the six step procedure mentioned previously to this 12 step process:

How Pi-hole Works With FTLDNS and Unbound

1. Your client asks the Pi-hole Who is pi-hole.net?
2. Your Pi-hole will check its cache and reply if the answer is already known.
3. Your Pi-hole will check the blocking lists and reply if the domain is blocked.
4. Since neither 2. nor 3. is true in our example, the Pi-hole delegates the request to the (local) recursive DNS resolver.
5. Your recursive server will send a query to the DNS root servers: “Who is handling .net?”
6. The root server answers with a referral to the TLD servers for .net.
7. Your recursive server will send a query to one of the TLD DNS servers for .net: “Who is handling pi-hole.net?”
8. The TLD server answers with a referral to the authoritative name servers for pi-hole.net.
9. Your recursive server will send a query to the authoritative name servers: “What is the IP of pi-hole.net?”
10. The authorative server will answer with the IP address of the domain pi-hole.net.
11. Your recursive server will send the reply to your Pi-hole which will, in turn, reply to your client and tell it the answer of its request.
12. Lastly, your Pi-hole will save the answer in its cache to be able to respond faster if any of your clients queries the same domain again.

Step 4 is where the major change happens. The steps that follow are what the upstream servers would normally handle (along with any data tracking they may or may not be doing).

Recursion is more involved than just asking some upstream server. This has benefits and drawbacks:

Benefit

Privacy – as you’re directly contacting the responsive servers, no server can fully log the exact paths you’re taking, as e.g. the Google DNS servers will only be asked if you want to visit a Google website, but not if you visit the website of your favourite newspaper, etc.

Drawback

Traversing the entire path may be slow, especially the first time you visit a website. While the bigger DNS providers always have answers for commonly used domains in their cache, you will have to transverse the path if you visit a page for the first time time. A first request to a formerly unknown TLD may take up to one second (or even more if you’re also using DNSSEC). Subsequent requests to domains under the same TLD usually complete in < 0.1s. Fortunately, your Pi-hole does efficient caching to minimize the number of queries that will actually have to be performed.

Setting It Up

This blog post won’t go into detail about how to set it up, for that, we have an article you can follow (at this time you’ll need to be participating in our beta test of FTLDNS).

But once complete, you’ll be able to do something like this instead of setting Google as your upstream DNS provider.

Interested in this?

FTLDNS is currently in beta, so we hope you’ll check it out and also help support our endeavors with our one-time fundraising goal of $100,000.

FTLDNS is out of beta and part of Pi-hole v4.0.