DNS Sinkhole
Design
The objective of this project was to deploy a DNS sinkhole on a Raspberry Pi 3 to intercept, block, and monitor domain requests at the network level. I chose Pi-hole as the primary tool due to its open-source community support and its ability to serve as a lightweight, recursive DNS server with a configurable blocklist engine. The intended use case was full-network telemetry and privacy enforcement to simulate the kinds of passive network controls seen in small enterprise or lab environments.
By intercepting DNS queries before they resolve externally, a sinkhole provides both insight and control over outbound traffic. It becomes a choke point where unwanted domains (ads, telemetry, malware callbacks) can be blackholed or redirected, effectively creating a zero-trust barrier at the DNS level. This design aligns with real-world defensive practices such as domain-based indicators of compromise (IOCs), encrypted DNS enforcement, and passive reconnaissance.
Development
I began by installing a headless Raspberry Pi OS (Lite) on the Pi 3 and configured secure remote access via SSH using key-based authentication. Once networking was stable, I installed Pi-hole through its official installation script, which allowed me to configure upstream DNS to Cloudflare and Quad9 for privacy and malware filtering, respectively. I hardened the Pi by disabling root login, removing unnecessary packages, setting a static IP reservation, and ensuring minimal exposed services.
I then integrated multiple curated blocklists and added custom rules for domains known to be associated with telemetry and tracking. For encrypted DNS, I configured Pi-hole to route queries through dnscrypt-proxy, preventing ISP-level sniffing of DNS traffic.
To validate its functionality, I conducted a series of test queries from client machines, confirmed sinkhole redirects using `dig` and `nslookup`, and reviewed Pi-hole's logs for DNS resolution patterns. I enabled Pi-hole’s query logging and long-term database features to allow for persistent insight across devices.
Deployment
The Pi-hole server was initially planned to connect via Ethernet, but had to use Wi-fi due to restricted space for a home lab. It was then configured as the primary DNS resolver at the router level. All network traffic was forced to route DNS queries through the sinkhole, with fallback options disabled to prevent bypass. I then monitored logs for DNS behavior across workstations, mobile devices, and IoT components. Blocked requests and suspicious patterns (such as periodic telemetry pings from smart TVs and phones) were immediately evident.
While the environment is a home network, the deployment mirrors enterprise DNS filtering practices on a small scale. From a red team perspective, it also serves as an opportunity to examine how attackers may attempt to bypass DNS inspection and to understand how beaconing behavior can be observed passively.
Lessons Learned
- Developed a deeper understanding of DNS protocol behavior, resolution paths, and TTL caching.
- Learned how to implement encrypted DNS (DoH/DoT) to prevent interception or tampering.
- Practiced basic hardening of a networked Linux appliance, including secure SSH, service trimming, and firewall rules.
- Observed real-time telemetry from consumer devices and gained experience in DNS log analysis.