How The Social Dork Builds a Pi-hole Ad Blocker with ZimaBoard 2

Thank you to The Social Dork | Cyber Security for sharing a Pi-hole and Tailscale project that filters DNS requests at home and from a phone away from home. ZimaBoard 2 runs the services, Pi-hole checks requested domains, and Tailscale provides a private connection back to the server. Watch the original YouTube walkthrough for the complete demonstration.

Watch before reading: This eight-minute video is useful if you want to understand where network-level ad filtering fits before changing your household DNS settings. The creator installs Pi-hole in ZimaOS, tests a Windows client, adds blocklists, and then connects a phone through Tailscale.

The useful result is a reusable DNS filtering service. The creator demonstrates fewer visible ads on a sample website and query activity from the remote phone. Those observations show the filtering path working in that setup; they do not establish that every advertisement, tracker, or malicious connection will be blocked.

Understand what Pi-hole filters before choosing the hardware

The explanation begins with a website that loads content from several domains. Pi-hole receives the client’s DNS requests and checks the requested names against its configured policy. Allowed names can be resolved through an upstream resolver; blocked names receive a blocking response. The important control point is the DNS query, before the client tries to retrieve content from that domain.

That scope also sets the limit. A DNS filter cannot distinguish an advertisement from wanted content when both use the same hostname. Clients that use another resolver can bypass the chosen path. Treat the video’s “block all ads” title as the project’s motivation, rather than a universal result. Browser content filtering and DNS filtering work at different layers and can complement each other.

Follow one lookup through the system before changing an entire network. A client asks for a hostname; Pi-hole applies its policy; a permitted request may reach the upstream resolver; the answer returns to the client. The subsequent web connection is a separate flow. This explains why a blocked-domain counter is useful evidence of DNS activity but does not measure every connection an application makes.

Give the DNS service a stable place on the home network

The Social Dork uses ZimaBoard 2 and installs Pi-hole through the ZimaOS app store shown in the video. The creator also mentions an existing laptop as an alternative host. The practical requirement is a machine that can remain available whenever clients depend on it for DNS; the demonstration does not establish a reason to buy the largest memory option just for filtering.

Connect the host, give the DNS endpoint a stable address or DHCP reservation, and confirm that the service is reachable from a test client. Container networking and port mappings affect which address clients should use. Verify that your installation actually answers DNS queries at that endpoint instead of assuming that an accessible administration page proves the DNS service is ready.

Record the addresses before changing a client

In a container installation, check both TCP and UDP DNS service reachability. Pi-hole’s official Docker example exposes both protocols on port 53 and persists its configuration directory. Those details matter even when an app store hides the container setup behind an Install button. Read the actual app configuration before changing a host service that may already use the same port.

The video shows installation from the creator’s ZimaOS app store. Your current app version and network mode can differ. Preserve the settings that explain how the app reaches the network: its address, published ports, storage location, upstream resolver, and restart behavior. That small record makes a later migration or reinstall easier to verify.

Test one client before changing DNS for the household

In the walkthrough, a Windows laptop stays on the home Wi-Fi while its IPv4 DNS setting is changed to the Pi-hole address. The creator then checks query activity. This is a manageable first test: if browsing stops, only that client needs to be restored while the rest of the household keeps its existing configuration.

For wider coverage, Pi-hole’s post-installation guide explains how DHCP can advertise the Pi-hole DNS address to clients. Renew the client’s lease or reconnect, then check which resolver it actually uses. Review IPv6 DNS and any browser or operating-system encrypted-DNS settings as well; changing one IPv4 field does not prove that every lookup follows it.

A second unfiltered resolver can also undermine the expected result. Clients may use another configured resolver rather than keeping it strictly as an emergency fallback. Decide whether continuity or consistent filtering is the priority, and test the behavior when the Pi-hole host is unavailable. Keep a record of the original settings so that a DNS experiment remains easy to reverse.

Use a repeatable local test

1. Write down the laptop’s current DNS configuration and the intended Pi-hole endpoint.
2. Send a permitted lookup explicitly to Pi-hole, then find the matching query in its log.
3. Test a domain that appears in your own active denylist and confirm its blocking result.
4. Set the client’s ordinary DNS preference to Pi-hole and repeat the test without explicitly choosing a resolver.
5. Browse a few normal services, including a sign-in flow, before rolling the change out through DHCP.

For example, nslookup example.com PIHOLE_LAN_IP tests a named resolver; replace PIHOLE_LAN_IP with your server’s address. That explicit query checks the endpoint itself. A subsequent nslookup example.com checks the system’s ordinary resolver path. Neither test alone proves that a browser with its own DNS settings follows the same route, so inspect a fresh request from that application too.

When looking for a failure, separate address reachability from name resolution. A device can remain connected to Wi-Fi and still fail to open sites because its DNS endpoint is offline. Keep the original client settings available until the new resolver works consistently. After a DHCP change, renew a lease or reconnect and inspect the settings the client actually received.

Add blocklists in a way you can troubleshoot

The creator next imports additional blocklists and shows the blocked-domain total increasing. That number describes the policy database, rather than the quality of the browsing experience. A larger list can include more unwanted domains, but it can also interfere with sign-in flows, media players, or other features that depend on a shared service.

Add a maintained list at a time, refresh the filtering database, and retest the services you actually use. When something fails, use the query log to identify the affected name and test a narrowly scoped allowlist entry. Pi-hole’s domain database documentation explains how allow and deny entries interact. Avoid solving a single broken login by broadly allowing an unrelated collection of domains.

Keep the reason for a new list or exception with the change. A sensible policy should survive a week of ordinary use, not just a single successful screenshot. If you maintain the filter for other people, give them a way to describe a broken service and the approximate time it failed. That is more actionable than a general report that “the internet is down.”

Use Tailscale to reach the same filter away from home

The second half adds Tailscale to the server and a phone. In the tailnet DNS settings, The Social Dork enters the server’s Tailscale address as a nameserver, then connects the phone and checks Pi-hole activity again. The DNS endpoint stays at home while the authorized phone can reach it over the private network.

Tailscale’s official Pi-hole integration walkthrough provides the current setup details. Confirm that Pi-hole accepts queries arriving over the intended private interface and that tailnet access policy permits DNS traffic. Where you want supported clients to prefer the configured tailnet nameserver, review Tailscale’s DNS override behavior and verify the setting on the actual client.

Using a home DNS resolver through Tailscale does not automatically send all web traffic through the home connection. Full internet egress through a home exit node is a separate configuration. This project only needs a private route to the DNS service; it does not require exposing a public DNS resolver or its administration page to the internet.

Validate the private DNS path in stages

1. Confirm that the server and phone are enrolled in the intended tailnet and can reach each other.
2. Add the reachable Pi-hole endpoint as the intended tailnet nameserver.
3. Review the client’s use of Tailscale DNS and the nameserver override setting for the behavior you want.
4. Check that the Pi-hole listener and access policy accept DNS from that private path.
5. Disconnect home Wi-Fi and repeat a permitted and blocked lookup from the phone.

A listener configured to accept only a particular local network can explain why home clients work while a Tailscale client fails. Pi-hole’s DNS listener configuration reference describes the available modes. Choose a mode compatible with your container and private network, while keeping inbound access limited to the intended clients. Broad listener settings need an equally clear firewall boundary.

Also distinguish DNS settings from internet egress. A nameserver can filter lookups without becoming an exit node. If you separately enable an exit node, check its DNS behavior again; Tailscale documents that interaction in its DNS and nameserver reference. A successful test on home Wi-Fi is not a substitute for testing the same phone on mobile data.

Make the final test about the path, not a counter alone

Repeat the test from a different connection, such as mobile data with Wi-Fi turned off. Check that a fresh lookup from the phone appears in Pi-hole, that a permitted site still opens, and that the selected blocked name receives a filtering response. A growing total alone can include requests from other devices; use the relevant client and timestamps to connect the observation to your test.

The next step in this creator’s series is an OPNsense firewall with Pi-hole DNS for wireless clients. For a broader example of organizing applications and remote access, kabuto’s modular homelab build shows how those services can fit into a maintained physical setup. Start with one working client, then expand the filtering policy after the local and remote paths are verified. Return to The Social Dork’s Pi-hole and Tailscale demonstration for the original sequence.

Troubleshoot the first failed layer

Treat the service as a household dependency once other devices use it. Back up its configuration, retain a working set of policy sources, and test an update with one client first. After a host restart, check a permitted lookup and a denied lookup again. An application icon returning to the dashboard is only the start of that verification.

Pi-hole’s container configuration documentation explains persistence and networking options. Keep that operational record with your own chosen configuration rather than relying on a screenshot of someone else’s address.

FAQ

Will Pi-hole remove every YouTube advertisement?

DNS filtering cannot reliably separate wanted video and advertising when they share a hostname. Judge this project as domain filtering, and verify the particular applications you use rather than promising an ad-free result everywhere.

Does every household device need Tailscale?

Home devices can use a reachable LAN Pi-hole endpoint through their DNS settings. In this project, Tailscale provides the private connection for devices that need the same resolver while away from home.

Do I need a Tailscale exit node for this setup?

Not just to reach the private DNS service. An exit node changes the internet traffic route and is a separate configuration with its own DNS behavior.

Why does the Pi-hole page open while DNS fails?

The web interface and DNS service use different ports and may have different container mappings or access rules. Test a DNS query to the intended address directly and check the matching log entry.

Why can another DNS server bypass the filter?

Clients do not necessarily treat a second configured nameserver as an emergency-only fallback. If consistent filtering matters, verify all advertised resolvers and the client’s actual behavior.

What should I save before updating the app?

Save the working app configuration, persistent data locations, policy sources, and the client settings used for a known-good test. After the update, repeat that test and confirm the settings survived.

Conclusion

The Social Dork’s project connects three decisions: where DNS runs, which clients use it, and how an authorized phone reaches it from another network. A useful deployment makes those decisions visible and testable. The strongest evidence is a matching client lookup, the expected policy response, and ordinary browsing that still works.

Start with one client, expand to DHCP after the local test succeeds, and validate Tailscale from a genuinely separate connection. Then maintain the filter as a service the household relies on. Keep the original Pi-hole and Tailscale video available for the creator’s sequence, alongside the current official documentation for your installed versions.