Import 16,024+ AI domains into pfBlockerNG's DNSBL engine. Transparent DNS-layer blocking for every device on your network — no per-client setup required.
Open-source firewalls on commodity hardware with full feature parity to commercial appliances. No per-seat licensing or vendor lock-in.
Full control over blocking mechanisms. Enforce DNS-level, IP-level, and proxy-level policies simultaneously across home labs to multi-site enterprise deployments.
pfBlockerNG's DNSBL engine instructs Unbound to return a sinkhole address for any blocked domain. Every device using pfSense as its DNS resolver gets AI tools silently blocked — no client software, browser extensions, or proxy configuration needed.
pfBlockerNG ships with ad-blocking and malware feeds, but nothing for AI tools. Our feed fills that gap with 16,024+ classified domains, updated daily from 102 million scanned domains.
Every client covered automatically. If it resolves DNS through pfSense, AI domains are sinkholed.
pfSense, OPNsense, and pfBlockerNG are all free. Only the domain feed subscription has a cost.
Stack DNS sinkholing, IP firewall rules, and Squid proxy ACLs for defense in depth.
The devel branch includes DNSBL support, Python-mode processing, and the block page web server. The standard pfBlockerNG package lacks DNSBL entirely.
Navigate to System > Package Manager > Available Packages.
Search pfBlockerNG-devel and click Install.
Access via Firewall > pfBlockerNG and run the setup wizard.
# Install pfBlockerNG-devel from the pfSense shell pkg install pfSense-pkg-pfBlockerNG-devel # Verify installation pkg info | grep pfBlocker # Expected output: pfSense-pkg-pfBlockerNG-devel-3.x.x # Enable pfBlockerNG via command line # Navigate to Firewall > pfBlockerNG in the web UI to complete setup # Or configure via /cf/conf/config.xml if scripting the deployment
Under Firewall > pfBlockerNG > General, enable both pfBlockerNG and the DNSBL module.
Choose an unused LAN IP (e.g., 10.10.10.1). This sinkhole address is returned for blocked domains and serves the block page.
The standard pfBlockerNG package does not include DNSBL functionality. You must install pfBlockerNG-devel for DNS-based blocking. The devel branch is stable and is the recommended version by the pfBlockerNG maintainer for all production deployments.
pfBlockerNG's DNSBL engine consumes external domain lists and converts them into Unbound overrides that sinkhole matching queries.
Navigate to Firewall > pfBlockerNG > DNSBL > DNSBL Groups, click Add, and configure the feed source below.
Set to Unbound — creates local-zone overrides resolving to the DNSBL VIP sinkhole.
Go to pfBlockerNG > Update, select Force > DNSBL, click Run to pull the initial feed.
Set to once per day. Our feed updates daily — 24-hour refresh keeps you current without excess polling.
# Test that AI tool domains resolve to the DNSBL sinkhole # Run from any client on the LAN, or from the pfSense shell # Query a known AI tool domain against the pfSense resolver dig @192.168.1.1 chat.openai.com +short # Expected: 10.10.10.1 (your DNSBL VIP sinkhole address) dig @192.168.1.1 claude.ai +short # Expected: 10.10.10.1 dig @192.168.1.1 midjourney.com +short # Expected: 10.10.10.1 # Verify a non-AI domain resolves normally dig @192.168.1.1 google.com +short # Expected: normal Google IP (e.g., 142.250.x.x) # Check pfBlockerNG DNSBL statistics pfctl -t pfB_DNSBLIP -T show | wc -l # Shows the number of IPs in the DNSBL sinkhole table
chat.openai.com) resolve to your DNSBL VIP sinkhole addressgoogle.com) resolve normally through upstream DNSpfctl -t pfB_DNSBLIP -T show shows entries in the sinkhole tablepfBlockerNG generates Unbound local-zone overrides. Instead of resolving the real IP, Unbound returns the sinkhole address — the connection is killed before a TCP handshake occurs.
pfBlockerNG manages the Unbound integration automatically. No manual config file edits needed. Understanding the mechanism helps with troubleshooting.
The generated Unbound configuration entries look like this:
OPNsense lacks pfBlockerNG, but achieves the same result. Use a script to generate an Unbound include file with local-zone and local-data directives, then reference it from Services > DNS Resolver > Custom Options.
The following script generates Unbound overrides directly — useful for OPNsense or pfSense deployments without pfBlockerNG.
#!/bin/sh # Generate Unbound override file from the AI Tools Blocklist domain list # Useful for OPNsense or pfSense without pfBlockerNG SINKHOLE="10.10.10.1" FEED_URL="https://feeds.aitoolsblocklist.com/v1/dnsbl/domains.txt" OUTPUT="/var/unbound/ai_tools_blocklist.conf" # Download the domain list fetch -q -o - "$FEED_URL" | while read domain; do # Skip empty lines and comments case "$domain" in ""|"#"*) continue ;; esac echo "local-zone: \"${domain}.\" redirect" echo "local-data: \"${domain}. 300 IN A ${SINKHOLE}\"" done > "$OUTPUT" # Add include directive to Unbound config if not already present CONF="/var/unbound/unbound.conf" if ! grep -q "ai_tools_blocklist.conf" "$CONF"; then echo "server:" >> "$CONF" echo " include: /var/unbound/ai_tools_blocklist.conf" >> "$CONF" fi # Restart Unbound to apply changes service unbound restart LINES=$(wc -l < "$OUTPUT") echo "AI Tools Blocklist loaded: $((LINES / 2)) domains sinkholed"
After applying overrides, verify with a DNS query from any LAN client. Blocked domains should resolve to the sinkhole IP; all others resolve normally.
Clients using hardcoded IPs, DNS-over-HTTPS, or external resolvers bypass the DNSBL sinkhole. IP-level blocking via pf firewall aliases drops traffic at the packet filter — regardless of DNS.
Many AI services share Azure/Cloudflare IP ranges with non-AI services. IP blocking works best for independent AI startups on dedicated infrastructure. Use DNSBL as the primary layer.
The following script resolves AI tool domains to IP addresses and generates a pfBlockerNG-compatible list.
#!/bin/sh # Resolve AI tool domains to IP addresses for pfBlockerNG IP blocking # Creates a pfBlockerNG-compatible IPv4 list DOMAIN_LIST="/var/db/pfblockerng/ai_tools_domains.txt" IP_OUTPUT="/var/db/pfblockerng/ai_tools_ips.txt" TEMP_FILE="/tmp/ai_resolve_tmp.txt" # Download latest domain list fetch -q -o "$DOMAIN_LIST" \ "https://feeds.aitoolsblocklist.com/v1/dnsbl/domains.txt" # Resolve each domain and collect unique IPs > "$TEMP_FILE" while read domain; do case "$domain" in ""|"#"*) continue ;; esac drill "$domain" A 2>/dev/null | \ awk '/IN[[:space:]]A[[:space:]]/ {print $NF}' >> "$TEMP_FILE" done < "$DOMAIN_LIST" # Deduplicate, remove RFC1918 and shared hosting IPs sort -u "$TEMP_FILE" | grep -vE '^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.)' \ > "$IP_OUTPUT" IP_COUNT=$(wc -l < "$IP_OUTPUT") echo "Resolved ${IP_COUNT} unique IPs from AI tool domains" # Reload pfBlockerNG to apply the updated IP list /usr/local/bin/php /usr/local/www/pfblockerng/pfblockerng.php update 2&>1
To use this list, navigate to Firewall > pfBlockerNG > IPv4 and create a new alias group pointing to the output file. Set the action to Deny Both.
Best practice: Use DNS-based blocking (DNSBL) as the primary enforcement layer and IP-based blocking as a supplement. DNSBL is precise — it blocks exactly the domains on the list. IP-based blocking can cause false positives when AI services share IP space with unrelated services on CDN infrastructure.
DNS blocking prevents resolution but doesn't inspect traffic. Squid adds URL-path-level control and richer logging for environments needing deeper visibility.
Squid reads the SNI header in the TLS ClientHello to determine the target domain. Blocks the connection before decryption — no certificate management overhead.
Install from System > Package Manager. Enable transparent HTTP proxy on LAN. For HTTPS, enable Splice All mode to read SNI without decrypting.
Populate the ACL file by downloading the blocklist. Squid's dstdomain ACL expects one domain per line, prefixed with a dot for wildcard subdomain matching.
#!/bin/sh # Download AI tools domain list and format for Squid ACL # Schedule via cron: 0 4 * * * /usr/local/bin/update_squid_ai_acl.sh ACL_FILE="/var/squid/acl/ai_tools_domains.txt" FEED_URL="https://feeds.aitoolsblocklist.com/v1/dnsbl/domains.txt" TEMP="/tmp/ai_squid_acl_tmp.txt" # Download and prepend dot for wildcard subdomain matching fetch -q -o - "$FEED_URL" | grep -v '^#' | grep -v '^$' | \ sed 's/^/./' > "$TEMP" # Validate the download before replacing the active ACL LINES=$(wc -l < "$TEMP") if [ "$LINES" -gt 1000 ]; then mv "$TEMP" "$ACL_FILE" # Reload Squid to pick up the updated ACL squid -k reconfigure logger "AI Tools Blocklist: Squid ACL updated with $LINES domains" else logger "AI Tools Blocklist: Download failed or too few domains ($LINES), skipping update" rm -f "$TEMP" fi
pfBlockerNG DNSBL alone is sufficient for most deployments. Add Squid only if your threat model includes DNS bypass scenarios or you need per-request logging.
A stale blocklist leaks. New AI tools launch daily — last week's list is already missing domains.
pfBlockerNG's built-in scheduler handles automatic updates under Firewall > pfBlockerNG > Update > CRON Settings. Set DNSBL updates to daily. For tighter control, use a custom script with validation and rollback.
#!/bin/sh # Custom update script for the AI Tools Blocklist on pfSense # Includes download validation, backup, and logging # Schedule via cron: 0 3 * * * /root/update_ai_blocklist.sh FEED_URL="https://feeds.aitoolsblocklist.com/v1/dnsbl/domains.txt" DEST="/var/db/pfblockerng/dnsbl/ai_tools_domains.txt" BACKUP="/var/db/pfblockerng/dnsbl/ai_tools_domains.bak" LOG="/var/log/ai_blocklist_update.log" MIN_DOMAINS=5000 TIMESTAMP=$(date "+%Y-%m-%d %H:%M:%S") # Backup current list before updating if [ -f "$DEST" ]; then cp "$DEST" "$BACKUP" fi # Download new list fetch -q -o "$DEST.tmp" "$FEED_URL" RESULT=$? if [ "$RESULT" -ne 0 ]; then echo "[$TIMESTAMP] ERROR: Download failed (exit code $RESULT)" >> "$LOG" exit 1 fi # Validate download - check minimum domain count NEW_COUNT=$(grep -cvE '^(#|$)' "$DEST.tmp") if [ "$NEW_COUNT" -lt "$MIN_DOMAINS" ]; then echo "[$TIMESTAMP] ERROR: Only $NEW_COUNT domains (min: $MIN_DOMAINS), keeping previous" >> "$LOG" rm -f "$DEST.tmp" exit 1 fi # Deploy the new list mv "$DEST.tmp" "$DEST" echo "[$TIMESTAMP] SUCCESS: Updated to $NEW_COUNT domains" >> "$LOG" # Force pfBlockerNG to reload DNSBL /usr/local/bin/php /usr/local/www/pfblockerng/pfblockerng.php update 2>&1 >> "$LOG" echo "[$TIMESTAMP] pfBlockerNG DNSBL reload complete" >> "$LOG"
For OPNsense or manual Unbound setups, the update script should regenerate the Unbound override file and restart the resolver instead of calling pfBlockerNG.
Blocking is half the value. The other half is visibility: which users, which tools, how often, and whether the blocklist is working.
View blocked queries at pfBlockerNG > Alerts > DNSBL. Each entry shows timestamp, client IP, and blocked domain. One-click whitelisting for false positives.
Customize under pfBlockerNG > DNSBL > Webserver Config. Explain your AI policy and include an exception request link to reduce helpdesk tickets.
Forward logs via Status > System Logs > Settings to Splunk, Elastic, Wazuh, or Graylog. Build per-user AI access dashboards.
Forward DNSBL events to your SIEM for automated alerts when block volume spikes — signaling a new AI tool trending in your organization.
Generate monthly reports of block events, top domains, and category breakdowns for SOC 2, ISO 27001, and HIPAA audits.
The AI Tools Database includes metadata per domain — category, risk level, first-seen date — that enriches SIEM events beyond simple block/allow signals.
OPNsense doesn't support pfBlockerNG. Use its native Services > Unbound DNS > Blocklist plugin — it functions identically, downloading domain lists and sinkholing matches.
Enable the blocklist feature and add the AI Tools Blocklist feed URL as a custom source. OPNsense downloads, parses, and generates Unbound overrides automatically.
Use Firewall > Aliases with URL Table type aliases. Point at a hosted IP list, set the refresh interval, and reference the alias in firewall rules.
Both platforms consume the same plain-text domain feed. No conversion needed when switching between pfSense and OPNsense.
Tell us about your pfSense or OPNsense deployment and we will configure a DNSBL feed tailored to your blocking requirements.
Tell us your requirements and we will prepare a tailored domain feed for your organization.