I ditched Google’s DNS for a $20 Raspberry Pi, and I stopped handing my web history to third parties


Unless you’re typing in IP addresses by hand, every single time you visit a website, you perform a DNS lookup first. By default, your network probably points to a public DNS server, like your ISP’s server, Google’s 8.8.8.8, or Cloudflare’s 1.1.1.1. They’re convenient and fast, but it also means that a third-party gets an unredacted view of the websites you visit.

If you want to minimize the amount of information you give away to Google, you can swap out a public DNS server for an inexpensive Raspberry Pi running a Pi-hole and Unbound.

Your DNS server knows every website you visit

Your DNS lookup requests aren’t usually encrypted either

Isometric illustration of a self-hosting setup, with a laptop connected to black server towers, a router, a blue globe, a label with 'DNS' and a domain address. Credit: Lucas Gouveia/How-To Geek | Rvector/Shutterstock

Any time you connect to a website using a domain name, a DNS server somewhere in the world translates that domain name into an IP address that your computer uses behind the scenes to actually connect. Whatever DNS server you use has full visibility of every domain you enter into your browser, and if your DNS requests aren’t encrypted, anyone that intercepts your DNS requests can also view the websites you’re visiting. That is a lot of information to trust to a third party.

Your ISP can still see which IP address you’re connected to, which can then be linked to a domain, unless you’re using a VPN.

Fortunately, you can use an inexpensive Raspberry Pi Zero 2 W and a few open-source projects to address the issue.

A Pi-hole and Unbound can give you privacy and security

You don’t need to directly query a DNS server

A Pi Zero W in an aluminum case.

You do need a DNS server if you want to use domain names to connect to websites, but nothing says you actually need to directly ask the DNS server. Instead, you can build your own using a program called Unbound, which is a recursive resolver.

Unbound talks directly to the entire “DNS hierarchy,” which means it pulls data directly from the root server, TLD servers, the authoritative name servers. Basically, it asks all of the computers involved in linking domains to IP addresses for their information, and then saves that information locally. Whenever you need to access that domain in the future, you’ll be able to draw from Unbound’s saved result instead of asking Google or Cloudflare to connect you to the website.

Raspberry Pi Zero 2 W,png

Brand

Raspberry Pi

CPU

Quad-core 64-bit ARM Cortex-A53

Memory

512MB of SDRAM

The Raspberry Pi Zero 2 W is super tiny and super affordable, but it packs enough computing power for a variety of DIY projects. You can use it to create a handheld retro gaming console, for Klipper/Mainsail, a super compact home or media server, and more. 


You don’t need Google’s 8.8.8.8 server at all—everything required lives on your home network.

Additionally, Unbound is capable of using DNSSEC, which uses cryptography to verify that the DNS records you’re receiving have not been tampered with. Though it is rare, DNS poisoning has been used to reroute traffic from legitimate websites to malicious clones to steal sensitive information, like credit card numbers. Big DNS servers are appealing targets because successfully compromising one could affect tens of millions of people.

It isn’t likely to be a problem, but running your own tiny DNS resolver that double-checks the identity of a website makes you very resistant to that sort of attack.

A Pi-hole is a great natural combination with Unbound. A Pi-hole acts as a network-wide DNS “sinkhole.” When your devices ask to connect to a domain, the Pi-hole checks its blocklists. If the domain is known to run ads, trackers, or host malware, Pi-hole returns 0.0.0.0, which prevents you from ever connecting to the blocked domain in the first place.


A Raspberry Pi in a case lying on top of a Beelink Mini S12 Pro mini PC.


This Raspberry Pi project quickly became the cornerstone of my homelab

The hole shebang.

Because the filtering happens at the DNS layer, you don’t need to install software on every individual phone, smart TV, or IoT device in your house.

When used together with Unbound, you get two layers functioning in tandem. Everything on your network first communicates with the Pi-hole, which automatically blocks undesired domains. Once your traffic has been filtered by the Pi-hole, it gets forwarded to Unbound, which then links the domain name to the IP address for you and you connect.

There is no third-party required, and you can block a reasonable amount of malware before it ever has a chance to infect any devices. For a small one-time hardware cost and a miniscule amount of electricity, you have full control over your network. Once the local cache gets loaded, repeat lookups are almost instantaneous.

Setting up your Pi-hole and Unbound

One hour and a Raspberry Pi is all you need

To begin, flash Raspberry Pi OS Lite (64-bit) to a microSD card using the Raspberry Pi Imager and install it in your Raspberry Pi. Then, log into your router and assign the Raspberry Pi a static IP address—if it changes, everything will stop working.

With that set, SSH into the Raspberry Pi, install Pi-hole by running curl -sSL https://install.pi-hole.net | bashand then connect to the web dashboard to complete the setup. It is pretty hands-off—the installer is designed to be very user-friendly, and will walk you through the important parts.

After that is done, SSH in again and install Unbound using sudo apt install unbound. You need to make sure it is listening to the loopback address (127.0.0.1) on port 5335 and that DNSSEC is enabled. To do that, create the configuration file at “/etc/unbound/unbound.conf.d/pi-hole.conf” according to the Pi-hole instructions. It should look like this:

The Pi-hole Unbound configuration file open in Nano.

Now, you need to tell the two devices to actually talk to each other. Open up the Pi-hole dashboard and go to the settings, then set your upstream DNS to the custom entry 127.0.0.1#5335 and untick all other options, including Google’s 8.8.8.8. Leave Pi-hole’s DNSSEC disabled.

Finally, point your router’s DNS settings to the Pi’s IP address like you would normally for a Pi-hole.


There are a few tradeoffs

The Pi-hole and Unbound combination is great if you’re privacy minded, or if you’re a homelabber that can make use of the granular control. However, it does have a few drawbacks.

The first time you visit a fresh domain, the lookup will be slower than a public resolver because Unbound has to load everything once the first time. Subsequent visits are much faster, but that initial delay is something you’ll probably notice.

Additionally, remember that you are creating a single point of failure. If your Raspberry Pi gets thrown off a bookshelf by an inquisitive cat, your entire home network will lose internet access unless you have a backup resolver configured or until you fix the problem.



Source link

Leave a Reply

Subscribe to Our Newsletter

Get our latest articles delivered straight to your inbox. No spam, we promise.

Recent Reviews


U.S. CISA adds a flaw in Ivanti Endpoint Manager Mobile (EPMM) to its Known Exploited Vulnerabilities catalog

Pierluigi Paganini
May 07, 2026

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) adds a flaw in Ivanti Endpoint Manager Mobile (EPMM) to its Known Exploited Vulnerabilities catalog

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added a flaw in the Ivanti Endpoint Manager Mobile (EPMM), tracked as CVE-2026-6973 (CVSS score of 7.1), to its Known Exploited Vulnerabilities (KEV) catalog.

Ivanti warns customers of a high‑severity zero‑day vulnerability, tracked as CVE‑2026‑6973, in Endpoint Manager Mobile that is already being exploited.

“At the time of disclosure, we are aware of very limited exploitation of CVE-2026-6973, which requires admin authentication for successful exploitation.” reads the advisory. “We are not aware of any customers being exploited by the other vulnerabilities disclosed today.”

The flaw, caused by improper input validation, allows attackers with admin privileges to execute arbitrary code on systems running EPMM 12.8.0.0 and earlier. Customers are urged to patch immediately to prevent compromise.

Ivanti EPMM 12.6.1.1, 12.7.0.1, and 12.8.0.1 address the vulnerability. The vulnerability doesn’t affect Ivanti Neurons for MDM, Ivanti’s cloud-based unified endpoint management solution, Ivanti EPM (a similarly named, but different product), Ivanti Sentry, or any other Ivanti products.

According to Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities, FCEB agencies have to address the identified vulnerabilities by the due date to protect their networks against attacks exploiting the flaws in the catalog.

Experts also recommend that private organizations review the Catalog and address the vulnerabilities in their infrastructure.

CISA orders federal agencies to fix the vulnerability by May 10, 2026.

Pierluigi Paganini

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

(SecurityAffairs – hacking, US CISA Known Exploited Vulnerabilities catalog)







Source link