Ansible-automated privacy protection on Raspberry Pi, built to protect Starlink users in Iran from identity correlation attacks.
Author: Iman Samizadeh Licence: MIT Repository: https://github.com/Iman/javid-mask
When a Starlink user in Iran accidentally visits an Iranian website, their identity can be exposed through cookies, browser fingerprints, or login sessions:
BEFORE (Normal Iranian ISP):
┌──────────────┐ ┌─────────────────┐
│ User │─────►│ Iranian Website │
│ Cookie: Reza │ │ (digikala.com) │
│ IP: Iran │ │ Logs: Reza=Iran │
└──────────────┘ └─────────────────┘
AFTER (Starlink - DANGEROUS):
┌──────────────┐ ┌─────────────────┐
│ User │─────►│ Iranian Website │
│ Cookie: Reza │ │ (digikala.com) │
│ IP: USA! │ │ Logs: Reza=USA!!│ ◄── RED FLAG
└──────────────┘ └─────────────────┘ "Reza has Starlink"
The risk: Iranian authorities can identify Starlink users by correlating:
- Same cookies/fingerprints + foreign IP = Starlink user identified
- Login sessions from foreign IPs = identity exposed
- Browser fingerprints (Canvas, WebGL) identify devices across IPs
This project provides three complementary architectures, each offering different levels of protection:
| Architecture | Sifter | Singleton | Triangle |
|---|---|---|---|
| Complexity | Simple | Moderate | Advanced |
| Primary Use | DNS Server | WiFi Gateway | VPN Gateway |
| WiFi Access Point | No | Yes | Yes |
| Proxy (VLESS/VMess) | No | Yes | No |
| VPN (WireGuard) | No | No | Yes |
| Traffic Encryption | DNS only | DNS only as shipped; full once you configure a proxy outbound in 3x-UI | Full (via VPN) |
| Exit IP | Your IP | Your IP | VPS IP |
| Kill Switch | No | No | Yes |
| VPS Required | No | No | Yes |
| DNS blocklists configured | 7 lists | 14 lists | 5 lists on the Pi, 16 on the VPS |
| Domains in those lists | about 535,000 | about 1,200,000 | about 460,000 on the Pi, about 3,258,000 on the VPS |
| Iranian domains | 131,652 | 131,652 | 131,652 |
| Iranian IP ranges | 1,805 CIDRs (Pi's own traffic) | 1,805 CIDRs | 1,805 CIDRs |
Every count here was measured on 2026-08-07, either from the files in this
repository or by downloading the blocklist URLs each architecture configures
and de-duplicating the result. For Sifter, Singleton and Triangle's Raspberry
Pi that is ansible/group_vars/all.yml; for Triangle's VPS it is the
gravity.db insert in triangle/ansible/roles/vps-pihole/tasks/main.yml,
which subscribes to a wider set than the Pi does.
Upstream lists change from day to day, so treat these as a snapshot: the
authoritative figure for a running deployment is the one its own Pi-hole
dashboard reports. Method and per-source results are in
Iranian Domain and IP Sources.
Two things the older versions of this document got wrong, and which are worth stating plainly:
- Triangle does not filter twice. A WiFi client's query is answered by the Pi's
Pi-hole and never reaches the VPS one; the VPS Pi-hole serves direct
WireGuard clients. The earlier "3.2M+ (double)" figure added the two nodes
together as if a single query passed through both. The two nodes do not even
carry the same lists: the Pi subscribes to the five in
triangle/ansible/group_vars/all.yml, the VPS to sixteen written straight intogravity.dbbyroles/vps-pihole/tasks/main.yml. - Sifter does not carry client traffic. See the note under Sifter.
The simplest architecture - a pure DNS server that all your home devices point to.
Best for:
- Users wanting minimal setup
- Protecting all devices on existing network
- DNS-level blocking only
Features:
- Pi-hole DNS filtering (7 blocklists, about 535,000 domains)
- Iranian domain blocking (131,652 domains, plus a
.irregex filter) - Iranian IP blocking (1,805 CIDR ranges) for the Raspberry Pi's own traffic
- DNS-over-HTTPS to Cloudflare, via cloudflared
- IPv6 disabled on the Raspberry Pi
Home Devices → DNS to Pi → Pi-hole → Cloudflared → Internet
↓
Iranian domains blocked
Sifter is a DNS server, not a gateway. net.ipv4.ip_forward is set to 0
and the nftables forward chain is policy drop, so no client traffic passes
through the Raspberry Pi. Two consequences follow, and neither was stated
before:
- The 1,805 Iranian IP ranges are enforced on the Pi's own outbound connections. Your other devices reach the internet through the router as usual, so a device that connects to an Iranian IP address directly, without a DNS lookup, is not stopped by Sifter.
- The IPv6 rules cover the Raspberry Pi only. A device that receives an IPv6 address and an IPv6 resolver from your router bypasses Sifter completely. If you use Sifter, disable IPv6 and router advertisements on the router itself.
Sifter's protection is the DNS layer. Singleton and Triangle carry client traffic and apply the IP blocklist to it.
View Singleton Documentation →
A self-contained WiFi access point with built-in proxy support for VLESS/VMess protocols.
Best for:
- Users needing isolated WiFi network
- Proxy protocol support (anti-DPI)
- Single-device deployment
Features:
- Isolated WiFi network (10.50.0.0/24), with client isolation on
- Pi-hole DNS filtering (14 blocklists, about 1,200,000 domains)
- Client DNS on port 53 redirected to Pi-hole, so a hardcoded resolver cannot be used to walk around it
- 3x-UI/Xray management panel for VLESS/VMess/Reality
- Iranian IP blocking (1,805 CIDR ranges) and Iranian domain blocking
- DNS-over-HTTPS to Cloudflare, via cloudflared
WiFi Clients → WiFi AP → Pi-hole → nftables → Internet
↓ ↓
DNS filtered Iranian IPs blocked
Singleton filters; it does not tunnel by default. The shipped sing-box configuration terminates its inbounds and sends traffic straight out the ethernet interface, so the exit address is still yours. Remote outbounds, including Reality, are configured by the operator in the 3x-UI panel after deployment. Until you do that, Singleton gives you DNS filtering, IP blocking and a separate WiFi network, not a different exit address.
A distributed architecture with WireGuard VPN tunnel to a VPS, providing IP masking and kill switch.
Best for:
- Maximum privacy protection
- Geographic IP masking
- ISP surveillance protection
Features:
- WireGuard VPN tunnel to a VPS
- Two Pi-hole instances on two paths, not two filters in series: WiFi clients are served by the Pi's Pi-hole (5 blocklists, about 460,000 domains), direct WireGuard clients by the VPS one (16 blocklists, about 3,258,000 domains)
- All WiFi client traffic exits via the VPS address
- Fail-closed forwarding: the only forward rule for WiFi clients sends them out
wg0, so if the tunnel is down the chain'spolicy dropstops them. A health check watches the tunnel as a second layer. - Iranian IP blocking (1,805 CIDR ranges) on both nodes, Iranian domain blocking on both Pi-hole instances
WiFi Clients → WiFi AP → Pi-hole → WireGuard → VPS → Internet
↓ ↓
DNS filtered Traffic exits via VPS IP
Direct WireGuard clients → VPS Pi-hole → Internet
| Leak Type | Sifter | Singleton | Triangle |
|---|---|---|---|
| Device DNS | Only devices you point at the Pi | Port 53 redirected to Pi-hole | Port 53 redirected to Pi-hole |
| DNS encryption upstream | DoH | DoH | DoH |
| Browser DNS-over-HTTPS | Not covered | Not covered | Not covered |
| IPv6 leak | Raspberry Pi only | No client IPv6 path | No client IPv6 path |
| Iranian domains | 131,652 | 131,652 | 131,652 |
| Iranian IPs | Pi's own traffic only | 1,805 CIDRs | 1,805 CIDRs |
| Cookie correlation | DNS layer only | DNS and IP layer | DNS and IP layer |
| WebRTC Leak | Browser, not covered | Browser, not covered | Browser, not covered |
| IP Masking | No | No | VPS IP |
| Kill Switch | No | No | Fail-closed forwarding |
| DPI Resistance | No | Reality is available but not configured by the playbook | WireGuard is identifiable by DPI |
Three caveats behind that table:
- Browser DNS-over-HTTPS defeats all three architectures. Firefox and Chrome can resolve names over HTTPS to their own provider. That traffic is indistinguishable from any other connection on port 443, so no firewall rule here can separate it. Turn browser DoH off on every device, or the DNS filtering does nothing for that browser.
- DPI resistance is not something these playbooks configure. Singleton installs 3x-UI, which can serve Reality, but the shipped configuration has no remote outbound; you set that up yourself. Triangle uses plain WireGuard, whose handshake has a recognisable shape and is routinely detected and blocked. Neither is an obfuscated transport as delivered.
- IPv6 on Sifter covers the Raspberry Pi, not your devices. Disable IPv6 and router advertisements on the router if you deploy Sifter.
All architectures protect at the network level (automatic), but some threats require browser configuration (manual):
NETWORK LEVEL (Automatic):
├── DNS filtering (Pi-hole)
├── Iranian domain blocking (131,652)
├── Iranian IP blocking (1,805 CIDRs; Singleton and Triangle carry client
│ traffic, Sifter applies it to the Pi's own traffic)
├── DNS encryption to the upstream resolver (DoH)
└── IPv6 blocking (Singleton and Triangle; Sifter covers the Pi only)
BROWSER LEVEL (User must configure):
├── DNS-over-HTTPS in the browser must be turned OFF
├── WebRTC leak prevention
├── Canvas/WebGL fingerprinting
├── Cookie management
└── JavaScript fingerprinting
Some users may ask if a MikroTik router can provide the same protection. While MikroTik is excellent networking hardware, it has critical limitations for this privacy protection use case:
| Feature | MikroTik | Raspberry Pi | Winner |
|---|---|---|---|
| DNS blocking (0.5M to 2.3M domains) | Roughly 100K ceiling | Bounded by RAM and storage | Raspberry Pi |
| Iranian domain blocking (131,652) | Insufficient resources | Full support | Raspberry Pi |
| DNS-over-HTTPS (DoH) | Limited (v7+ only) | Full (Cloudflared) | Raspberry Pi |
| VLESS/VMess Proxy | Not supported | Xray with Reality | Raspberry Pi |
| Reality Protocol (Anti-DPI) | Not supported | Full support | Raspberry Pi |
| WireGuard VPN | Supported | Full support | Tie |
| Filtering on two nodes | Complex | Easy (Pi + VPS) | Raspberry Pi |
| Iranian IP blocking (1,805 CIDRs) | Supported | Supported | Tie |
| Web Management | WebFig/WinBox | Pi-hole/3x-UI | Tie |
| Power Consumption | ~5W | ~10-15W | MikroTik |
| Cost | ~$50-100 | ~$80-120 (Pi 5 + SD) | Tie |
| Software Flexibility | RouterOS limited | Full Linux | Raspberry Pi |
1. DNS Blocklist Capacity
MikroTik devices have practical limits on DNS regex entries. The figures below are approximate and depend on the model and on available RAM, so check the specification for the device you own:
- Entry-level models: roughly 10,000 entries
- Mid-range models: roughly 50,000 entries
- High-end models: roughly 100,000 entries
Our use case requires:
- Pi-hole blocklists: about 535,000 domains for Sifter, about 1,200,000 for Singleton, and for Triangle about 460,000 on the Raspberry Pi and about 3,258,000 on the VPS
- Iranian domains: 131,652
- Total: roughly 0.6 to 3.4 million domains, depending on the architecture and, for Triangle, on which of its two resolvers you mean
2. No Proxy Protocol Support
MikroTik cannot:
- Run VLESS/VMess proxies
- Implement Reality protocol (anti-DPI)
- Act as Xray endpoint
- Provide application-layer obfuscation
3. DoH Limitations
- Only RouterOS v7+ supports DoH
- More complex configuration than Cloudflared
- Lower performance under heavy load
MikroTik is excellent for:
- Simple DNS filtering (thousands, not millions)
- WireGuard/IPsec routing
- Bandwidth management and QoS
- Enterprise networks with advanced switching
- Implementations needing IP blocking only
For our specific scenario (Starlink identity protection with million-domain DNS filtering, Iranian domains, and proxy obfuscation), Raspberry Pi is the only practical choice.
- Sifter - If you want DNS-only protection with minimal setup
- Singleton - If you want WiFi AP with proxy support
- Triangle - If you want maximum protection with VPN and kill switch
| Component | Minimum | Recommended |
|---|---|---|
| Raspberry Pi | Pi 3B+ | Pi 5 (4GB) |
| MicroSD Card | 16GB Class 10 | 32GB A2 |
| Ethernet | 100Mbps | 1Gbps |
| Power Supply | 5V 2.5A | 5V 5A (Pi 5) |
| VPS (Triangle only) | 512MB RAM | 1GB+ RAM |
- Raspberry Pi OS (Debian 13 "Trixie" or newer)
- ansible-core 2.10 or newer on the control machine. The roles use
ansible.builtin.*fully-qualified module names, which 2.9 does not understand, andansible.posix.sysctl, which needs theansible.posixcollection installed. - SSH access to the Raspberry Pi
javid-mask/
├── README.md # This file
├── README.fa.md # Persian documentation
├── LICENSE # MIT
├── iran_blocklist.txt # 1,447 domains; Singleton only, ships disabled
│
├── sifter/ # DNS-Only Architecture
│ ├── README.md
│ ├── README.fa.md
│ ├── ansible/
│ │ └── files/
│ │ └── iranian-ips.txt # 1,805 Iranian IPv4 CIDR ranges
│ └── diagrams/
│
├── singleton/ # WiFi AP + Proxy Architecture
│ ├── README.md
│ ├── README.fa.md
│ ├── ansible/
│ │ └── files/
│ │ └── iranian-ips.txt # same file, same contents
│ ├── scripts/
│ └── diagrams/
│
└── triangle/ # WiFi AP + VPN Architecture
├── README.md
├── README.fa.md
├── ansible/
│ └── files/
│ └── iranian-ips.txt # same file, same contents
└── diagrams/
The three copies of iranian-ips.txt are byte-identical (MD5
e63727a63ea3c3ed582720cffc242740). If you change one, change all three.
| Source | Type | Count | Licence | How it reaches the device |
|---|---|---|---|---|
| Regional Internet Registry delegated-extended statistics (RIPE NCC, ARIN, APNIC, AFRINIC, LACNIC), plus a two-witness overlay for Iranian operators registered abroad | IPv4 ranges | 1,805 CIDRs | Registry statistics are published public record | Shipped in this repository at <architecture>/ansible/files/iranian-ips.txt. Never downloaded at run time. Built by tools/build-iranian-ips.py. |
| bootmortis/iran-hosted-domains | Domains | 131,652 | MIT | Downloaded from the GitHub release during deployment, then on a schedule |
iran_blocklist.txt in this repository |
Domains | 1,447 | Mixed, see the file header | Copied to the Pi by Singleton only, and registered as a Pi-hole adlist only if iran_blocklist_enabled is set true. It ships false, so by default the file is present and not enforced. |
| liketolivefree/iran_domain-ip | Domains | 0 | No licence file | Configured, but the URL returns HTTP 404 and contributes nothing |
Counts measured 2026-08-07. Method: the iranian-ips.txt and
iran_blocklist.txt figures are non-comment, de-duplicated line counts of the
files in this repository. The bootmortis figure is the de-duplicated entry count
of the release asset downloaded on that date.
Two notes you should not skip:
liketolivefree/iran_domain-ipis broken and unlicensed. The URL configured in all threegroup_vars/all.ymlfiles,.../iran_domain-ip/main/domains.txt, returns 404; the repository has no file by that name. The download task ignores errors, so a deployment succeeds and silently adds nothing. The repository also carries no licence file, which is the same redistribution problem described below. It is listed here because it is still in the configuration, not because it works.herrbischoff/country-ip-blocksis no longer a source. It was removed from the IP list, from the download tasks, and from the cron jobs that were re-fetching it nightly. See the next section for why.iran_blocklist.txtis not simply an ad and tracker list, and it ships turned off. Measured 2026-08-07, its 1,447 domains are a mix: ad, tracker and analytics hosts, but also a large phishing component (179pages.dev, 26vercel.app, 23netlify.appand 19weebly.comthrowaway hosts among them) and 77.irdomains. It was audited on 2026-08-07 and 27 platform and service domains were removed, includingfacebook.com,youtube.com,twitter.com,t.co,bing.comandvimeo.com, which an upstream ad list had contributed and which have no business in a list shipped to users in Iran. Those 27 are now recorded insingleton/scripts/blocklist-exclusions.txtand re-applied on every regeneration, so the audit cannot be undone by re-running the generator.iran_blocklist_enableddefaults tofalse, so Singleton copies the file to the Pi and does not register it with Pi-hole until someone turns it on.
The general-purpose ad, tracker, malware and phishing lists differ per architecture and are listed in each architecture's own README. Measured on 2026-08-07 by fetching every configured URL and de-duplicating the parsed domains:
| Resolver | Where the subscription is declared | Configured | Reachable | Unique domains |
|---|---|---|---|---|
| Sifter | sifter/ansible/group_vars/all.yml, pihole_blocklists |
7 | 6 | about 535,000 |
| Singleton | singleton/ansible/group_vars/all.yml, security_blocklists |
14 | 12 | about 1,200,000 |
| Triangle, Raspberry Pi | triangle/ansible/group_vars/all.yml, security_blocklists |
5 | 5 | about 460,000 |
| Triangle, VPS | triangle/ansible/roles/vps-pihole/tasks/main.yml, the gravity.db insert |
16 | 14 | about 3,258,000 |
Triangle's two rows are two resolvers on two paths, not two layers on one path. Do not add them together.
Three configured URLs return no list at all. The download and insert tasks do not fail on this, so a deployment reports success and the coverage is simply absent. They are named here rather than counted:
| Dead URL | Result | Configured by |
|---|---|---|
mirror1.malwaredomains.com/files/justdomains |
HTTP 404, the service has been retired | Singleton, Triangle VPS |
zerodot1.gitlab.io/CoinBlockerLists/hosts_browser |
HTTP 403 | Singleton, Triangle VPS |
zerodot1.gitlab.io/CoinBlockerLists/hosts |
HTTP 403 | Sifter |
sifter/ansible/files/iranian-ips.txt,
singleton/ansible/files/iranian-ips.txt and
triangle/ansible/files/iranian-ips.txt are the same file: 1,805 IPv4 CIDR
ranges covering 11,008,000 addresses. All 1,805 entries are unique, well-formed,
strictly aligned networks with no host bits set. There are no IPv6 ranges and no
private ranges. Nothing is fetched from a third-party country IP list at run
time.
- The delegated-extended statistics files published by the five Regional Internet Registries (RIPE NCC, ARIN, APNIC, AFRINIC, LACNIC). These are the allocation records maintained by the registries that made the allocations, so they are the authoritative statement of which address ranges are Iranian. Iran sits in the RIPE NCC service region, so nearly all of the file comes from RIPE's file; the other four are checked so that ranges transferred between regions are not missed.
- A two-witness overlay for Iranian operators registered abroad. Several Iranian internet providers hold address space that a registry records as allocated to another country. Respina Networks (AS42337) is much the largest of them: an Iranian provider whose ranges are registered in the United Arab Emirates. A registry-only list drops all of it, and the device then reaches those Iranian services directly from its foreign exit address, which is the identity correlation this project exists to prevent. A range joins the overlay only when two independent sources both place it in Iran while the registry records it elsewhere. The two witnesses are the v2fly/xray GeoIP database and the iptoasn combined table. One source on its own is never enough: a single-source rule is how the pre-registry version of this list accumulated millions of addresses of foreign space.
Ranges that a registry records as allocated to a country other than Iran are removed unless both witnesses place them in Iran. Private, loopback, link-local, carrier-grade NAT, documentation, multicast and reserved space is removed unconditionally. So are ranges that a registry records as Iranian but that are announced today by a well known non-Iranian provider network: traffic to those terminates at the provider rather than in Iran, so dropping them costs the user access and buys no privacy.
The current file is the registry base plus that overlay, minus those carve-outs,
collapsed to the minimal CIDR set. Measured against RIPE's file on 2026-08-07:
the overlay contributes 176,896 addresses in 64 fragments that RIPE does not
record as Iranian, the largest being Respina's 5.160.0.0 and 46.209.0.0
space, and the carve-outs remove exactly two ranges that RIPE does record as
Iranian, 46.38.152.0/24 and 185.126.156.0/23, totalling 768 addresses.
That trimming is not tidiness. Blocking is not free. Every range in this file is traffic the user cannot reach, and a range wrongly labelled Iranian breaks a service the user needed while looking exactly like an ordinary network fault. The user has no reason to connect the failure to this device, so they do not report it and cannot work around it deliberately. What they do instead is turn the protection off, which is the outcome this project exists to avoid. For a privacy tool the cost of over-blocking is not inconvenience, it is abandonment. A narrower list that is correct is worth more than a wider list that is nearly correct.
The same argument applies in the other direction, and it is why the file is kept: a range that belongs to Iran but is missing from the list is a path by which a Starlink user's foreign address gets logged against their identity by an Iranian site. Both errors matter, which is why the source has to be the registries rather than a convenient aggregate.
The previous version of this file was derived from
herrbischoff/country-ip-blocks. That repository carries no licence file at
all. With no licence there is no grant of permission to redistribute its
contents, which is a problem for an MIT-licensed repository that vendors the
data. Its ranges were also never reconciled against the registry records. It has
been removed as a source and must not be cited as one again. The same test
applies to any replacement you are tempted by: if it has no licence, it cannot
ship here.
tools/build-iranian-ips.py is the generator. It writes all three copies from
the same bytes, so they cannot drift apart, and it refuses to write a file that
fails its own checks. See tools/README.md for the full description; the short
version is:
- Download the inputs yourself into one directory. Nothing is downloaded by the script, and nothing is downloaded at run time on the device, so the build stays reproducible and auditable.
https://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest
https://ftp.arin.net/pub/stats/arin/delegated-arin-extended-latest
https://ftp.apnic.net/stats/apnic/delegated-apnic-extended-latest
https://ftp.afrinic.net/pub/stats/afrinic/delegated-afrinic-extended-latest
https://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-extended-latest
https://iptoasn.com/data/ip2asn-combined.tsv.gz
plus a v2fly/xray GeoIP database containing the IR entry
- Validate without writing, then write:
python3 tools/build-iranian-ips.py --data-dir /path/to/sources \
--compare sifter/ansible/files/iranian-ips.txt --check
python3 tools/build-iranian-ips.py --data-dir /path/to/sources \
--compare sifter/ansible/files/iranian-ips.txt
-
Read the coverage table it prints. Uncovered space in a large Iranian network is the failure mode that matters most, and it is the one a registry-only rebuild reintroduces silently.
-
Re-run the playbooks. Nothing downloads the file, so an undeployed change is a silently stale deployment.
Background for anyone reading the script: the registry record layout is
registry|cc|type|start|value|date|status|opaque-id, where value is a count
of addresses, not a prefix length, and is not always a power of two. A record
therefore has to be expanded into a start and end address and then converted
into one or more CIDR blocks. Python's ipaddress.summarize_address_range()
followed by ipaddress.collapse_addresses() does both correctly.
You do not have to rebuild the file to audit it. Compare the address space it covers against today's registry records:
curl -fsSL -o ripe.txt \
https://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest
grep -c '|IR|ipv4|' ripe.txt
Run on 2026-08-07 against RIPE's file, which held 1,954 Iranian IPv4 records, all of them allocated or assigned: the registry's Iranian space totalled 10,831,872 addresses, the shipped file 11,008,000.
- 176,896 addresses in the shipped file, 1.61 percent of it, are not in RIPE's
Iranian set. That is the two-witness overlay described above, dominated by
Respina's
5.160.0.0and46.209.0.0space, which RIPE records against the United Arab Emirates. - 768 addresses of RIPE's Iranian space, 0.01 percent of it, are not in the
shipped file. That is exactly the two carve-out ranges,
46.38.152.0/24and185.126.156.0/23, which are registered to Iran but announced today by a non-Iranian provider network.
Both divergences are accounted for, which is the point of running the audit. An audit that shows a divergence you cannot account for means the file needs rebuilding. The direction that matters most is the second one: address space RIPE calls Iranian that the file does not cover is space the device will reach from its foreign address.
Network-level protection blocks Iranian connections, but browser-level threats require manual configuration:
about:config settings:
├── media.peerconnection.enabled → false (Disable WebRTC)
├── privacy.resistFingerprinting → true (Anti-fingerprinting)
├── network.dns.disableIPv6 → true (Disable IPv6 DNS)
├── network.trr.mode → 5 (Disable DNS-over-HTTPS)
├── geo.enabled → false (Disable geolocation)
└── privacy.trackingprotection.enabled → true
network.trr.mode → 5 is the important one for this project. With browser
DNS-over-HTTPS on, Firefox resolves names through its own provider over port
443, Pi-hole never sees the query, and every Iranian domain in the blocklist
resolves normally. Chrome's equivalent is Settings, Privacy and security, Use
secure DNS, off.
| Extension | Purpose |
|---|---|
| uBlock Origin | Ad/tracker blocking, WebRTC control |
| NoScript | JavaScript control |
| Cookie AutoDelete | Automatic cookie cleanup |
MIT Licence
Copyright (c) 2026 Iman Samizadeh
- Pi-hole: https://pi-hole.net/
- WireGuard: https://www.wireguard.com/
- 3x-UI/Xray: https://github.com/MHSanaei/3x-ui
- Cloudflared: https://developers.cloudflare.com/
- Iranian Domains: https://github.com/bootmortis/iran-hosted-domains (MIT)
- Iranian IPv4 ranges: the delegated-extended statistics published by RIPE NCC, ARIN, APNIC, AFRINIC and LACNIC, plus the maintainer's own operator research. See How the Iranian IP List Is Produced.
Maintainer: Iman Samizadeh Project: javid-mask (Starlink Privacy Protection Suite)