How Did We End Up Here?
Sending Files Over the Internet 
This page is a markdown file on a computer 
controlled by Deno Deploy 
. I uploaded this file to Github 
and Deno Deploy grabbed it and uploaded it to that computer. When you clicked the link to visit this post, your request traveled through several systems, just like my uploaded file, before reaching Deno’s computer. The file you loaded was sent as Network packets, which is what we call sections of data sent over the internet. These packets are usually structured according to a protocol, and these protocols serve different purposes. This website’s packets follow HTTPS and specifically form an HTTPS Response, which means the message they make when put together and handed to your browser is a website. Deno’s computer listens for packets that look like HTTPS Requests and responds to them. We call computers that do this Web Servers .
Where is Here? 
Computers need to be physically connected in some way in order to communicate. This physical connection is sometimes wireless 🛜, but nonetheless required to transmit and receive data over the internet. When multiple computers are physically connected, one is typically assigned to be a messenger and handles receiving and delivering all packets. This computer is called the Router , and just like the post office it assigns addresses called IP Addresses to each computer so they can receive packets destined for them 
. Once a computer is physically connected to a network, it can get one of these IP Addresses by sending out packets that constitute a DHCP Request. The router hears the request and responds with an address that other connected computers 
can use to send packets 
to the newly connected computer .
burst.deno.dev is a hostname, a human-readable & memorable label we give to computers. Hostnames are not IPs, which we know are required for this kind of connection... So how were you able to send packets to Deno’s Computer without knowing its IP? Just like the protocols for receiving website content from web servers, and being assigned IPs by routers, some computers called DNS Servers listen for hostnames in the form of DNS Requests so they can respond with the corresponding computer’s IP address. Every computer’s internet settings 
has an area where you can see and set which DNS Servers are used to “resolve” hostnames:
My iPad sets all DNS Request packets to be delivered to
75.75.75.75 and 3 other redundant addresses of Xfinity computers in case 75.75.75.75 is unreachable. This is because when my iPad got its IP from my Xfinity router , the router additionally set these 4 addresses as part of its DHCP Response. After the computer at 75.75.75.75 translates (resolves) burst.deno.dev 
34.120.54.55 (.eg), my iPad can craft HTTPS Request packets with that IP set as the destination IP. Handing these request packets to my router will properly retrieve website content from the IP resolved by this DNS. I’ll explain more about how Xfinity actually delivers 
these packets after addressing another pressing issue...
The Domain Name System 
How did 75.75.75.75 get burst.deno.dev’s IP in the first place?
All IPs that make up the internet are allocated by organizations called Regional Internet Registries, and are then leased to:
- Internet Service Providers like
Xfinity
- Hosting providers like
Google
- Or other companies like Deno Deploy
When your router assigns IPs, it does so from specific IP ranges that were built to avoid conflicting with all the other computers on the internet. Besides getting an IP, Deno has also registered deno.dev with Google since they keep track of all .devs.
To get the IP of burst.deno.dev, Xfinity’s DNS Server reached out to one of the 13 Root DNS Servers , whose IPs are well known just like 75.75.75.75, but also globally accessible (usually). Connecting to any 1 of these 13 servers will guarantee a DNS Response if that hostname really exists on the internet. These Root Servers send us to Top Level Domain (TLD) DNS Servers , in our case, one of Google’s computers that is responding to all requests for .dev hostnames. When Deno registered with Google, they told them to send all deno.dev requests to another DNS Server called an Authoritative Name Server, in this case also owned by Google, which is defined by its role; serving the final and most accurate record of burst.deno.dev’s IP. All other records, cached or otherwise, are considered non-authoritative. This Domain Name System :right_arrow: (Root) + (TLD) + (Auth) is sometimes referred to as the Phonebook of the Internet.
burst.deno.dev
burst.deno.dev’s IP can come from many places, as we will explore in the final section on alternatives to this traditional Root Nameserver-based DNS. For now, let’s continue exploring Recursive Name Servers like 75.75.75.75 and other Public DNS Servers that cache and server authoritative records.
One of the most significant services ISPs provide other than selling IP Addresses is BGP, which is the method by which large networks work together to deliver packets to the right IPs even if the destination is on the other side of the world. The internet wouldn’t be the same without BGP + DNS, so I consider their combination, routing, the first wonder of the internet 
; allowing globalization by importing communication to computers.
Getting Here Safely
A large aspect of security is knowing your enemy 
and what they are capable of but also knowing the same about yourself . This post is so long because there are too many enemies on the internet who are all interested in stealing different valuables 
depending on what you have. I wanted this post to work for people with internet access issues different than my own, so what we are building today is customizable. I will show an example of modifying what we build, but for now, you’ll need to start thinking about what is valuable to you and consider what your enemies can do:
- Some enemies are simple and just want to steal our bank accounts
by stealing from people who have bank logins. This could be done by anyone by reading insecure packets. - Some enemies are craftier and want to mine crypto currency
by stealing from people with good GPUs. This could be done by anyone by editing insecure packets. - The worst enemies want to steal our education
by blocking people from accessing the internet. This could be done by anyone routing insecure packets by filtering them.
Not all VPNs function the same, so before we can even start building anything, I want to just scratch the surface of realistic threats & potential attacks. Let’s see how many vulnerabilities our simple connection has opened us up to. Network security is tricky because our enemy’s malicious computer could be hiding on any network at any step between us and burst.deno.dev. Let’s examine our DNS Request:
Vulnerabilities 
---
title: The Journey of a DNS Request
---
graph TD
Visitor[Your Computer] -->|1a - LAN| Router[Your Router]
Visitor -->|1b - LAN| Peer[Another Computer on LAN]
Peer -->|1b - LAN| Router
Router -->|2 - ISP Connection| ISP[Your ISP]
ISP -->|3a - ISP Network| ISPDNS[ISP’s DNS Server]
ISP -->|3b - ISP Network/IXE| PubDNS[Public DNS Server]
ISPDNS -->|4 - Response| ISP
PubDNS -->|4 - Response| ISP
LAN - This physical connection is typically the only one that you are responsible for:
- A router with no wireless security or old security (WPA2 / WEP) can easily be spoofed using a cheap Wi-fi chip ESP32 combined with the marauder software. This attack would mean that all our packets would be sent to another computer on the network that could edit them as they wish before sending them to the router.
- A similar attack can be done over wired connections in which another computer on the LAN accepts DHCP Requests and pretends to be a router. A standard solution to this MITM-type of attack over LAN is to have a program running that watches for suspicious activity on the network that a malicious computer would make and blocks that machine from the network. The idea of network owners watching and filtering behavior is an important technology that will come up again when we discuss internet censorship methods (below).
ISP Connection - We pay ISPs for security and reliability. In an old apartment of mine on the third floor of a house, there was a coaxial cable managed by Xfinity that was just a long wire nailed to the outside of the house. It disappeared into a hole under a window and appeared in my room. This is where the router was connected. One day, my internet cut out, and while I was on the phone with Xfinity, I remembered this wire, so I traced it along the side of the house to find it unscrewed to the wire that disappeared into the ground! I hung up & screwed it back in, and my internet was working again! Anyways, I was on the phone because this connection is something we pay for in America, so it is Xfinity’s responsibility to deliver the service they said they would (with many loopholes) when I paid for it. It’s not easy to become an ISP since Xfinity made deals with the owners of this property to use one of the limited number of internet lines laid under that house during its construction. Xfinity and other ISPs own a lot of wire that covers a lot of land, so it is about as expensive as starting a real estate company!
ISP Network / IXE -
- In America
, ISPs, like Xfinity, can legally inject ads into responses. ISPs can also throttle connections, which can be abused to block or degrade access to specific content. - In China
, ISPs and all Public DNS Servers must comply with the government to block DNS requests to sites banned by the State and log the personal information of any citizens making suspicious requests. - Turkey
and Iran 
block access to journalism critical of the government by interfering with DNS Requests looking for websites blacklisted by the State. The internet exchange is where ISPs hand off packets to each other. Each ISP has security and user privacy standards that will affect how our packet is treated.
- In America
Response - Responses will have to go back through all the same steps.
What Can We Do? 
Without any configuration, like my iPad, all my DNS Requests on my home LAN will be sent to 75.75.75.75 in plaintext, meaning the data is completely readable and editable. Luckily Taher Elgamal invented SSL which we now know and use as TLS. TLS puts the S in HTTPS, and it’s what makes it secure in contrast to using plaintext HTTP. Encryption is the second wonder of the internet enabling security by importing the ability to trust each other to computers. Content sent over HTTPS is encrypted, so only the web server it is destined for can read the request. HTTPS covers encrypting requests and responses after we figure out the web server’s IP, meaning our ISP can’t read or edit data between us and the web server with some exceptions... Let’s check them out as we try to secure our DNS Request:
2 common ways to protect DNS traffic is to turn your DNS Request into an HTTPS Request called DoH or encrypting your DNS with TLS called DoT. DoH is helpful in situations where DoT is blocked, as it hides DNS as if it were regular HTTPS traffic. DoH, DoT & HTTPS all fail if the destination IP is blocked since the ISPs have to be able to read the destination to be able to deliver the packet. We will have to think of alternative ways to connect to both web & DNS Servers...
A large problem in secure routing and, consequently internet censorship is that Root Nameservers do not support any encrypted DNS protocols like DoH or DoT, meaning DNS forces plaintext communication. Most Nameservers only offer DNSSEC, which ensures the integrity and authenticity of the DNS Records they serve, but nothing to secure the visibility of data over the connection leaving Authoritative DNS Requests especially vulnerable to censorship by anyone along the journey. There are only a few Public DNS Servers that support DoH or DoT. Using these rely on Google or Cloudflare to be secure providers while also creating an easily blockable bottleneck, dooming access to DoH and DoT to be blocked easily in some places. I won’t cover this in this post, but the currently accepted way to anonymously connect to a computer and have them anonymously send content back is by forgoing DNS to instead use Tor’s .onion routing. .onion routing provides anonymity and access to the internet behind heavy firewalls, excellently explained here, through features like Pluggable Transports and Bridge Relays.
When sticking with DNS 
in these scenarios with high internet censorship, the goal is to securely connect to a computer that has free access to the internet, often called a proxy . I will offer an example of how we can modify the proxy to fit your needs. This encrypted proxy is the beating heart 
that constitutes the VPNs like the one we will be building. The rest of this article relies on encrypted traffic and is completely useless in situations where all encrypted traffic is blocked, like North Korea probably. Realistically, the easiest way to get internet in North Korea would be if a South Korean could just throw a wire across the line and have a North Korean catch it and wire it up to all their friends and family houses. Routing is a physical problem, and both of our goals will be to connect (in any way) to a proxy with the level of internet security and freedom that we each need. Let’s examine some proxy setups and think of one that works for you...
What We Will Do 
To move on, by now, you must have some enemies in mind so you can follow these building sections with a specific defense system in mind. The internet is always changing, so if you still can’t think of an enemy, just copy my setup so that you have something ready and adaptable if one appears. The 2 building blocks 
of our customizable VPN are:
- An end-to-end encrypted connection between 2 nodes . All communication between them is private, including any requests, responses, and destinations. This is the VPN, and to make it, we will be using a software called tailscale that uses the WireGuard protocol to create encrypted connections between computers.
- A Recursive Name Server that caches DNS so we only have to rely on ourselves, root nameservers, and our connections to them. This is the DNS Server; we will use pihole + unbound. Pihole will handle DNS Caching, filtering, and hosting custom DNS Records. Unbound will communicate with root servers and verify the DNSSEC of the responses.
The The Journey of a DNS Request only covered getting a DNS Request from a Recursive Server. Since we will be running our own Recursive Server just like those Public DNS Servers and Xfinity’s, let’s take a deeper look 
at what our setup and what the Recursive Server will be responsible for exactly:
---
title: The Journey of a (Authoritative) DNS Request
---
graph LR
Visitor[Your Computer] -->|1 - VPN| RecurDNS[Recursive DNS Server]
RecurDNS -->|2 - where burst.deno.dev?| RootDNS[One of the 13 Root Nameservers]
RootDNS -->|3 - .dev is over there -> IP| RecurDNS
RecurDNS -->|4 - where burst.deno.dev?| TLDDNS[Google’s TLD Nameserver handling .dev]
TLDDNS -->|5 - burst.deno.dev is over there -> IP| RecurDNS
RecurDNS -->|6 - where burst.deno.dev?| AuthDNS[Google Authoritative Nameserver handling burst.deno.dev]
AuthDNS -->|7 - burst.deno.dev is over there -> IP| RecurDNS
If the IP of the Root Nameserver, TLD Server, Authoritative Server, or end Web Server is blocked, you are cooked 
. You will have to send your request to a proxy that can communicate with these servers . I am using the VPN to securely carry requests I make over 5G and public free Wi-fi to my house. The enemy I am protecting myself from are people on networks outside my house (1b) that could block me or edit my data. DNS Requests will go to our recursive server, which visits root nameservers to cache authoritative results. This setup most notably trusts:
- Xfinity: to not log, block, or modify my plaintext authoritative requests over trusting random public networks and their security measures.
- Public Network Owners: to not flag and block me for tunneling behavior.
DNS Records, HTTP/S Communication, and any other internet activity will be completely encrypted until it reaches the proxy at my house and then unencrypted by one layer so my request can go through my router normally as if I was at home. I’ll still be relying on Xfinity’s network to deliver my plaintext DNS Requests to Root Nameservers and beyond, but pihole will filter some connections to some ad content servers and tracker websites that collect data as you visit them. Additionally, using unbound effectively circumvents any reliance on Xfinity’s 75.75.75.75 server which pihole recommends. This setup is a VPN-to-Recursive-Server but let’s see how we can rearrange this for your enemies:
This combination, of a VPN to a proxy that has trustable access to the needed resources, is a pattern that can be adapted for other scenarios. Here are some examples that grow increasingly worse in what is blocked:
- Root Nameserver: If you can’t trust your ISP to allow connections to Root Nameservers, use a Public DoH/DoT, which acts like an encrypted proxy to Root nameservers. This shifts trust from your ISP to a third-party resolver like Google or Cloudflare, but the ISP can still block access to these proxies by filtering their IPs or traffic patterns. (DoH)
- DoH/DoT: If your ISP blocks DoH/DoT providers, you can use a VPN to tunnel traffic to a computer outside your ISP’s network that can access Public DNS Servers. (VPN-to-DNS)
- Specific IPs, If your DNS is coming back fine but access to the web server is blocked, you’ll need to VPN to a computer that can access that server. (VPN)
- VPNs: Don’t use a VPN to connect to the proxy; just connect using DoH/DoT & HTTPS. For example, the Private DNS option on Android uses DNS-over-TLS (DoT) on port 853 to securely send DNS requests to a specified DNS server. In this case, it would be useful to use stunnel to accept DoT requests and forward them to a DNS Server available to the proxy like the pihole + unbound setup. I will try to include this as an example of a modification to our system. (DoT / HTTPS)
- Network Behavior: If traffic to 853 is too suspicious and could be potentially blocked you have to use DoH to make DNS requests look like website requests. This post contains no instructions on accepting DoH on port 443. If you need this method, set up cloudflared on a proxy that can connect to Cloudflare, or use coredns to accept requests on 443 and forward them to pihole + unbound. (DoH / DoH-to-DNS)
- VPN + Network Behavior: If VPNs are blocked, you could alternatively use a third item that unfortunately won’t be covered in this post either: an HTTPS Proxy. This setup is a bit difficult, so I recommend setting up 2 separate proxies for DNS and HTTPS, respectively, using something like squid to proxy HTTP requests. In places where VPNs are banned, you will be flagged for sending all your traffic to the same 1 or 2 IPs constituting tunneling behavior. At this point, you will need multiple HTTPS proxies and multiple DNS proxies, or better yet, proxies behind IPs of seemingly normal websites, like hiding an HTTPS Proxy in a Minecraft server so it looks like you are just connecting to a Minecraft server. Creative solutions like this protect against being blocked on networks with strict policies by obfuscating the quantity and variability of requests. (HTTPS Proxy/s)
Some companies offer free access to computers that might be available depending on where you live that can be used to follow the rest of this guide and build multiple proxies to a “safe” networks where connections are unblocked and unmonitored. Tailscale also offers integration with Mullvad VPN turning our setup into a VPN to redundant proxies setup skipping reliance on local ISPs (1-3a). All of us have to trust someone at some point since Root Nameservers don’t support encryption. The unavoidable and driving fact of this whole post is that none of us alone knows where all of the rest of us are (no one has all the DNS Records), and none of us can get to each other alone. No one has a directly wired connection to burst.deno.dev, so we all have to work together to get here.
By combining these methods, you can create systems to navigate through restrictive firewalls. You have to know what you are fighting 
to make a setup that works. If nothing works, I am sorry, and I hope the final section of this post gives you some hope for a censorship-resilient future 
, where encrypted redundant proxies are ample.
VPN Building 
Step 1: Tailscale VPN
First I installed 
tailscale on my Raspberry Pi 4 B
and started it using:
$ tailscale up --accept-dns=false --advertise-exit-node
$ ip address
On my Pixel 6 I downloaded the tailscale app and set some network settings:
- Private DNS to Automatic or Off (I couldn’t find a difference).
- VPN to Always-on VPN and Block connections without VPN.
- In the WiFi connection settings I have Static DHCP with the pi’s tailscale ipv4 address since it only takes ipv4s.
- In the tailscale app, I set my pi as the
exit-node.
Tailscale now starts when my pi boots and tunnels all traffic from any other device that has it set as the exit-node. This means that all the internet traffic on my phone is first encrypted and sent to my pi, which is then handed to my router normally. The pi won’t use the Tailscale DNS since we are hosting our own DNS Server. Now, we have an effective encrypted proxy. You can tap out at this point if you trust the proxy’s ISP and their DNS Servers. If you are continuing, in the tailscale admin panel under DNS, set the IP of the exit-node as a Global Nameserver.
Step 2: Pi-Hole + Unbound
Containers 
I 
containers for their security, diversity, and portability. Containers can get very complex, but the basic idea for us today is that they are like mini OS environments that run inside your OS. These environments can easily be customized and managed. Creating separate computing environments helps keep things simple and efficient:
Let’s say my pi is using 
Python 3.12 located at /usr/bin/python; I won’t have to mess with this binary or path at all if pihole asks for, say, Python 3.10. Instead, the alternate Python version will only be installed inside the container and found when pihole tries to run $ python. Let’s say tomorrow, after running pihole, I wake up and decide I want to maintain a Mailing List. Well then, of course, I would pretty much have to run mailman2, which requires an ancient 
deprecated Python 2.7.9, which would really cause issues with any softwares on my pi depending on $ python.
Containers typically have less overhead than Virtual Machines: because they don’t emulate hardware or run a separate kernel (OS + Services). Poorly optimized containers can have performance issues that make them less efficient than well-optimized VMs. If used properly, however, people have reported being able to run over 50+ containers simultaneously on a Pi 4. The finesse of a container comes from its special ability to choose which dependencies it should get itself and which dependencies to reuse from the host machine. Pihole might need a different Python version, but it could, for example, reuse my pi’s Raspbian kernel functions to read files.
The details of how containers work and their optimizations are beyond the scope here, container technology runs very deep, so for today I give you permission to imagine them as tiny custom linux envs. Containers make it easy to slowly build up and test the custom environment needed by each software. Still, there is always the option to just install pihole like other software on your computer or phone... if you’re not worried about your environment! It would be a really funny alternate setup to install pihole + tailscale on an 
Android and leave it on a train 
to act as constantly moving exit-node proxy .
You can run containers on Windows 
using a Linux kernel from WSL, and on macOS using a Linux kernel provided by Lima. At the minimum, I recommend having a wired (not wireless) connection to the internet on the proxy
hosting the DNS software. The code blocks below are intended for Linux, but they should work anywhere, and I’ll try to include alternate OS instructions when I can. Let’s gather all the tools we will need to run containers:
- First, we will need podman. (Other OSes) (Raspbian):
$ sudo apt-get -y install podman
- Next, to make working with podman simple, we will be using
podman-composeto run scripts we will use to configure the containers. (Other OSes & Alternate Methods) (Raspbian):
$ sudo curl -o /usr/local/bin/podman-compose https://raw.githubusercontent.com/containers/podman-compose/main/podman_compose.py
$ sudo chmod +x /usr/local/bin/podman-compose
- Finally, let’s just make sure that everything is working fine. (All OSes):
$ podman-compose -v
# Expected Output:
# podman-compose version xxx
# podman version xxx
Computer Security
Hackers are crafty, and it’s hard to tell where attacks might come from. Instead of losing to infinite attacks and their infinite solutions, let’s always focus on the biggest threats. Pi-Hole is open-source software, meaning anyone could analyze its code and potentially discover vulnerabilities to exploit, such as gaining shell access on the computer running the software. Using rootless containers would be beneficial here because a shell exploit would not grant the attacker full root access to the host, only access to the container, which has its own very limited user, which wouldn’t let them do much except change the contents of the container. In this case, gaining access to pihole or unbound containers could be dangerous because the content being changed would be the DNS configuration files, possibly mixing up DNS requests to send us to a malicious computer’s IP. There are many ways to hide servers, but in a later section, we will cover how to further defend against this risk by limiting who can access pihole over the internet to prevent malicious actors from even trying this.
Another way to mitigate the risk of a pihole hack is to simply take a look at this list of people. If you can’t trust the 221+ people who wrote pihole, you can spend 10 minutes checking their code for crazy hax, or ask software to scan it and look for vulnerabilities. If you’re paranoid, show your worth and rewrite the whole thing using 
Vim in assembly yourself. The same people who could find an exploit in pihole could very well also just submit it as a patch and become a contributor 
#opensourcegang. Security, again, is fundamentally about understanding your adversary: if you don’t know your enemy, you won’t know what to defend against. If your enemy is Nintendo, then do not post any of your team’s personal information online because they will find you anywhere in the world. If your enemy is Open AI... run. Real security however is not about attaccs and haxors its about trust. The prevailing philosophy of modern network security isn’t about preventing enemy attacks. It’s about not even letting them get the chance by trusting no one. This is great; you can build a whole OS on your own, trusting no one, but after making software, everyone arrives at the same next step; how do I share this? Thus, at some level, the internet forces us to embrace trusting relationships 
.
Building the Containers
I started by combining the compose scripts for pihole and unbound. These containers are for ARM Computers so you might have to change the image link and edit some configurations below depending on your CPU architecture and the container image you use. On Linux, you can check your CPU by running $ lscpu and filter by your architecture while looking for container images. Compose scripts describe to podman how you want your containers brought up. There are a couple of important pieces, so let’s take a look at our docker-compose.yml file:
# Podman Compose configuration for rootless setup
networks: # Makes a container network (think virtual router)
hole_net:
driver: bridge
enable_ipv6: true
ipam:
config:
- subnet: "192.168.2.0/24"
- subnet: "fd14:d095:b9ef:80f2::/64"
services:
unbound:
container_name: unbound
image: docker.io/klutchell/unbound:latest
dns:
networks:
hole_net:
ipv4_address: 192.168.2.2 # Set Unbound's IP
ipv6_address: "fd14:d095:b9ef:80f2::2" # Set Unbound's IPv6
restart: always
pihole:
container_name: pihole
image: docker.io/pihole/pihole:latest
ports:
- "53:53/tcp" # Map DNS TCP to unprivileged port
- "53:53/udp" # Map DNS UDP to unprivileged port
- "20080:80/tcp" # PiHole's Admin interface port (website)
environment:
TZ: 'America/Detroit'
WEBPASSWORD: '' # Set your PiHole password
DNSMASQ_LISTENING: 'all'
PIHOLE_DNS_: "192.168.2.2#53;fd14:d095:b9ef:80f2::2#53"
# ^Forward DNS to Unbound^
volumes:
- './etc-pihole:/etc/pihole'
- './etc-dnsmasq:/etc/dnsmasq.d'
networks:
hole_net:
ipv4_address: 192.168.2.3
ipv6_address: "fd14:d095:b9ef:80f2::3"
dns:
- 192.168.2.2
- fd14:d095:b9ef:80f2::2
depends_on:
- unbound
restart: always
We don’t need to use unbound’s redis integration for caching DNS requests because this will be taken care of by pihole’s FTLDNS “Faster Than Light DNS” which includes a caching feature. Running the the official Pi-Hole compose scripts causes issues due to podman’s aardvarkdns taking up port 53 on the host. Aardvark is a DNS Server that helps translate container names into their virtual IP addresses. Computers can be associated with multiple IPs and hostnames that can be used to find them on different networks, as we are doing with tailscale. We don’t have to deal with this this aardvark issue since we are using rootless containers that bind to 53 just fine.
Mounting an unbound.conf is useful if you want to override the container’s default unbound.conf. It has notably been customized to; run smoothly in a container and also use DNSSEC to validate authoritative requests. The container maintainer also provides some example unbound.confs that customize unbound in different ways. To mount one of these .confs into the container, create /unb-conf/unbound.conf and paste in the conf, and then add this to the unbound section of the compose:
volumes:
- type: bind
read_only: true
source: ./unb-conf/
target: /etc/unbound/custom.conf.d/
The pihole folders should create themselves, but you can make them manually if needed using mkdir etc-pihole etc-dnsmasq, but be mindful of the rwx permissions since rootless containers don’t have many.
stunnel (optional)
If you want to accept DoT on port 853 and have the DNS Requests forwarded to pihole + unbound add another service:
stunnel:
container_name: stunnel
image: docker.io/chainguard/stunnel:latest-dev
ports:
- "853:1853/tcp" # DNS-over-TLS port
volumes:
- ./stunnel-conf:/setup:rw
- ../certs/records-key.key:/certs/records-key.key:ro
- ../certs/records-cert.crt:/certs/records-cert.crt:ro
- /etc/ssl/certs/ca-certificates.crt:/etc/ssl/certs/ca-certificates.crt:ro
networks:
hole_net:
ipv4_address: 192.168.2.4
ipv6_address: "fd14:d095:b9ef:80f2::4"
command: "/setup/dot.conf"
depends_on:
- pihole
Use any guide to make self-signed certificates using OpenSSL and edit the compose to mount the .key and the .crt. Then make a dot.conf file with the following (adjusted for mounts):
pid = /setup/stunnel-dot.pid
syslog = yes
foreground = yes
debug = 7
[dot]
accept = :::1853
sslVersion = all
ciphers = HIGH:!aNULL:!MD5:!RC4
connect = 192.168.2.3:53
TIMEOUTconnect = 10
TIMEOUTidle = 60
TIMEOUTclose = 30
cert = /certs/records-cert.crt
key = /certs/records-key.key
CAfile = /etc/ssl/certs/ca-certificates.crt
Using DoT would effectively encrypt DNS queries until they reach the proxy, skipping our need for a VPN (tailscale). This is just a small example of how to modify our setup from VPN-to-Recursive-Server DoT-to-Recursive-Server. This setup alone isn’t any better on networks with strict tunneling policies. Rather, the DoT setup is more repeatable, making it easier to set up redundant proxies in these scenarios. With stunnel in the compose you can follow the rest of the guide normally.
Running & Stopping 
+ 
Since we aren’t using rootful containers, podman-compose raspbian will give us a hard time starting pihole on port 53 which is the special privileged default DNS port. There are many ways to set up Linux environments that depend on your enemies. I find no security-related difference between letting pihole use 53 or mapping pihole to 1053 and then forwarding all 53 requests to 1053, so I won’t set up port forwarding. Here’s how to start the softwares:
# Skip next line if not on Linux:
$ sudo sysctl -w net.ipv4.ip_unprivileged_port_start=0
# -- Repeat this section --
$ podman-compose --verbose up -d # Running
$ podman logs pihole # use logs -f to follow
$ podman logs unbound
$ podman-compose --verbose down # Stopping
# -- Edit the compose and repeat^ --
# Skip next line if not on Linux:
$ sudo sysctl -w net.ipv4.ip_unprivileged_port_start=1024
$ podman ps # Check that both containers started fine
Automating (Linux) 
Automating 
this process after reboot is a little more tricky, but this is the desirable setup for any server: things happen, computers crash 
and shutdown 
. It’s best to make sure everything is easy to get back up again. This setup has lower unprivileged ports on boot, so a very specifically timed attack could start a user process on a privileged port before we set the limit back to 1024. Adding Linux capabilities in the compose didn’t work, so we will have to ensure the limit is 0 when our containers run and 1024 after. Please adjust this system configuration automation section for your own distribution and setup, as some files might be located differently, and commands might work differently.
- First, we have to set the unprivileged ports to 0 in
/etc/sysctl.d/99-sysctl.confso that on boot, podman-compose can start pihole:
net.ipv4.ip_unprivileged_port_start=0
- Next, we will start our rootless containers on boot. I used this article to understand podman-compose’s relationship with systemd since this command is pretty undocumented, but the article tries to cover some behavior across distros. In the folder with the
docker-compose.ymlrun:
$ podman-compose systemd
$ systemctl --user enable --now 'podman-compose@pihole'
- We have created a user unit file that describes to systemd how we want pihole to start on boot. After a reboot with this service enabled, you can see if it started ok and check the logs using:
$ systemctl --user status 'podman-compose@pihole' # Startup status
$ journalctl --user -xeu 'podman-compose@pihole' # Logs
- Now we'll have systemd start user services without the user having to login:
$ # Starts <user>'s systemd services on boot:
$ sudo loginctl enable-linger <user>
- The problem is now that our unprivileged ports are set to 0. To fix this, I just made another user unit file that runs after podman-compose@pihole at
~/.config/systemd/user/unpriv.service:
[Unit]
After=podman-compose@pihole.service
Requires=podman-compose@pihole.service
[Service]
Type=oneshot
ExecStart=/usr/bin/sudo /sbin/sysctl -w net.ipv4.ip_unprivileged_port_start=1024
RemainAfterExit=yes
[Install]
WantedBy=default.target
And you’ll want to enable this service: systemctl --user enable --now unpriv.service
Firewall 
Now, on boot, pihole is listening for DNS requests on port 53. In the configuration below, we will turn off pihole’s security filtering, so let’s build some of our own. First, install ufw (probably sudo apt install ufw) and then make a file at ~/ufw.sh with the following contents:
#!/bin/bash
ufw disable
echo "y" | ufw reset
ufw default deny incoming
ufw default allow outgoing
# Allow SSH from LAN and Tailscale
ufw allow in on eth0 to any port 22 proto tcp
ufw allow in on tailscale0 to any port 22 proto tcp
# Allow Pi-hole Admin Panel from LAN and Tailscale
ufw allow in on eth0 to any port 30080 proto tcp
ufw allow in on tailscale0 to any port 30080 proto tcp
# Allow DNS (Ports 53 TCP/UDP)
ufw allow in on eth0 to any port 53 proto tcp
ufw allow in on eth0 to any port 53 proto udp
ufw allow in on tailscale0 to any port 53 proto tcp
ufw allow in on tailscale0 to any port 53 proto udp
ufw allow in on podman1 to any port 53 proto any
ufw allow out on podman1 to any port 53 proto any
# Allow communication between the Podman network and the host
ufw route allow in on podman1 out on eth0 proto any
ufw route allow in on eth0 out on podman1 proto any
ufw route allow in on podman1 out on tailscale0 proto any
ufw route allow in on tailscale0 out on podman1 proto any
# Deny Comcast IPv6 DNS servers
ufw deny out to 75.75.75.75
ufw deny out to 75.75.76.76
ufw deny out to 2001:558:feed::1
ufw deny out to 2001:558:feed::2
echo enabling
ufw enable
ufw reload
ufw status verbose
This allows packets over ethernet and the tailscale network to go SSH, DNS, and the pihole Admin website, which we will use in the next section. Adjust the interface names from your own connections that you can typically see by running ip address. For good measure, I also just filter any requests to my ISP’s DNS in case they sneak 
some DHCP in... mannnnnngg its so expensive 
but I need to get my own router or managed switch so I can control DHCP. Anyways, run these commands to start, debug, stop, and automate the firewall in the folder that ufw.sh is in:
$ sudo ./ufw.sh # Start the firewall
$ sudo dmesg | grep UFW # Check ufw's block logs
$ sudo ufw disable # Stop the firewall
# -- Edit the rules and rerun the script (Start).
$ sudo systemctl enable ufw # Automate ufw on boot
After rebooting give podman a second to start everything back up again, and then make sure everything went right by running:
$ sudo sysctl net.ipv4.ip_unprivileged_port_start # Shows 1024
$ sudo ufw status # Shows Firewall rules
$ podman ps # Shows Container status (should be 2)
Configuration
The compose file above forwards pihole’s port 80 to the proxy host’s 20080. Verify that pihole is running by visiting <proxy ip>:30080/admin in a web browser. You should be greeted with an admin portal where you can log in using WEBPASSWORD. After logging in, there are a couple settings we will need to modify:
Under Settings > DNS > Upstream DNS Servers, we will have to tell pihole where to find unbound. The upstream DNS Server should be set by the compose file, but if it isn’t, set it as:
unbound_IP#unbound_port.To support DNS requests over the tailnet, we will have to disable the hop-based filtering in Interface Settings right under the Upstream DNS Server section, but don’t worry if you followed the firewall section.
I found that DNSSEC worked properly when unchecked and improperly when checked, probably because it is unbound’s responsibility, but you are welcome to do your own research. Check the first 2 options under Advanced DNS Settings for speed and security unless you have another setup you are going for.
Go to Adlists and paste URLs of ad block lists. Here are some examples.
If everything is working, you’ll want to edit /etc/resolv.conf on your host proxy to:
nameserver 127.0.0.1
so that all local DNS Requests go through pihole. This completes the setup and ensures requests over the tailnet are fed into pihole + unbound 
wahoo! 
What’s next...
This article won’t particularly help with the United States Government’s TikTok ban. The U.S. won’t mess with DNS directly because that would be blatantly oppressive and cause backlash from a larger computing community that isn’t impacted by the removal of TikTok. Instead, they’ll pressure Apple, Google, and ByteDance, the organizations with the actual power over people, to take the app off the app store and make it non-functional. There are alternative app stores on iOS and Android, but most normal phone users won’t try this, and social platforms know this, so ByteDance will do any jig the U.S. asks them to not be banned. Their power doesn’t come from small abilities like DNS manipulation or App Store Removals but rather from our human reliance on them, these monopolistically controlled capitalist centralized systems.
The path forward is about rethinking 
our use of the infrastructure of the internet. The Ethereum Name Service built on Ethereum offers a flawed, yet hopeful glimpse into the future where reliance on centralized entities like root nameservers, Apple, Google, and their cozy government partnerships is no longer a given. Instead of trusting organizations that can dictate access to apps and services, we could store DNS records on blockchains governed by decentralized protocols, making them immutable, censorship-resistant, and globally accessible. With ENS, there is no 1 DNS Server or company to rely on that’s blockable.
Getting There Safely 
Software developers who care need to build awareness of censorship and its methods. A culture shift is needed with dedication to building encrypted peer-to-peer (P2P) networks and applications that bypass traditional DNS and ISP filtering entirely. ByteDance wouldn’t have to play these political games if their application was built to be more resilient against censorship like Mastodon with their use of decentralization. Since these softwares gave their users governance over the platform, the company does not have the power to just “shut it down”, even under financial pressure. There is nothing the developers can do; if the creator of Mastodon is arrested they would be physically not be able to give officials the user data they were looking for because they don’t have access. Users own what they post and are responsible for it, not the thousands of builders, maintainers, and investors!
Despite all this, I’m still relying on Deno Deploy and its ISP to provide this article for free. That’s the unfortunate truth of decentralization today: it’s expensive because it’s new, so it’s hard to prove it’s a good investment 
. The infrastructural and economic incentives for truly decentralized systems are starting to take shape like the FDA’s DSCSA 
, but these systems aren’t really impacting people yet, so as a society we haven’t experientially understood the alternative that decentralized systems offer. Similar to the unfathomable earthshaking impact the printing press had, it’ll take time for people to adapt and know when to benefit from using this new system of interacting with knowledge over traditional centralized systems. While ENS does offer a decentralized alternative, domain registration alone would cost me ~120$ which would only direct DNS Requests to burst.deno.dev which is hosted redundantly but not decentralized. Hosting a truly decentralized website would be even more expensive due to the cost of computing space to run Deno on decentralized computers . Money is not the enemy; it costs money to make sound systems. ENS is just an example; the real beauty of decentralization is its permissiveness. If you don’t like ENS or how $ENS holders govern their system, you can fork it 
. Build your own decentralized DNS, software or network. Experiment. Learn from Mastodon, Ethereum, and the DSCSA. Fail. Try again. The goal isn’t perfection; it’s progress towards a decentralized future.
The U.S. government originally released .onion routing technology to obscure military traffic by mixing it with civilian use. ISPs fill our DHCP Responses with redundant addresses in case of connection failures. Why can’t we take those same principles and flood ISP networks with encrypted, decentralized traffic to create a world where tracking, blocking, or censoring becomes the exception, not the rule? Let’s build infrastructure that relies on proxied networks and one day platforms will exist that are big enough for someone like me to host a decentralized un-censorable website for free!
A world where you control your data, your domains, and your applications without needing the approval of corporations or governments shouldn’t sound like a utopian ideal. So, let’s encrypt and decentralize everything, encrypt traffic for no reason, and rotate between redundant nodes for no reason. Every byte of decentralized traffic helps build an uncensorable internet. Let’s move towards a decentralized future and build an internet that belongs to its participants, builders, and maintainers, not just a privileged few with enough money. :)