Configure your resolver once and 16,024+ AI-tool domains are sinkholed for every client — desktops, laptops, phones, and IoT devices. No proxy certificates, no browser extensions, no per-machine hosts files.
Every connection to an AI tool starts with a DNS query. If that resolution returns a sinkhole address instead of the real IP, the connection never happens — no data leaves the network.
No TLS handshake occurs. The block is invisible, instant, and comprehensive.
Covers every device that resolves DNS through your network — desktops, phones, IoT, guest networks, VPN split tunnels. Zero per-device setup.
Requires traffic to pass through the firewall. Misses devices on guest networks, IoT segments, or VPN split tunnels that bypass the inspection path.
Only covers the browser, only on managed machines. Doesn't block IDE plugins, mobile apps, or CLI tools that reach AI services directly.
Requires per-endpoint deployment and ongoing maintenance. Doesn't scale beyond a handful of managed devices.
Our feed publishes 16,024+ classified AI-tool domains at stable HTTPS URLs your resolver can poll on a schedule. New AI tools are classified within 24 hours and picked up on the next refresh automatically.
The sections below walk through configuration for each platform. If you run a resolver not listed here, the plain-text domain list (one domain per line) works with any DNS software that supports blocklist imports.
Pi-hole is the most widely deployed DNS sinkhole for home and small-business networks. Adding our AI Tools Blocklist takes two commands — one to register the list URL, one to update gravity.
Pi-hole expects adlists in plain-text format: one domain per line, no protocol prefix. Our feed publishes this exact format at a stable URL, and every subsequent gravity update pulls the latest version automatically.
Once gravity finishes rebuilding, every DNS query matching an AI-tool domain is blocked. Verify by running nslookup openai.com your-pihole-ip — the response should return 0.0.0.0.
Pi-hole v5+ supports group management, letting you block AI tools for some users while allowing others. Assign adlists to specific groups and assign clients by IP or MAC address.
# Create a group and assign the AI blocklist to it sqlite3 /etc/pihole/gravity.db "INSERT INTO 'group' (name, enabled, description) \ VALUES ('ai-blocked', 1, 'Users blocked from AI tools');" # Get the group ID (e.g., 2) and the adlist ID for the AI blocklist sqlite3 /etc/pihole/gravity.db "SELECT id FROM 'group' WHERE name='ai-blocked';" sqlite3 /etc/pihole/gravity.db "SELECT id FROM adlist WHERE comment LIKE '%AI Tools%';" # Link the adlist to the group (replace IDs as needed) sqlite3 /etc/pihole/gravity.db \ "INSERT INTO adlist_by_group (adlist_id, group_id) VALUES (3, 2);" # Assign a client to the group (by IP address) sqlite3 /etc/pihole/gravity.db \ "INSERT INTO client (ip, comment) VALUES ('192.168.1.100', 'Marketing workstation');" pihole restartdns
AdGuard Home is the go-to alternative to Pi-hole for administrators who want a modern UI with built-in encrypted DNS support. Adding our AI Tools Blocklist is straightforward — add the URL as a custom filter list and AdGuard Home handles the rest.
Built-in DNS-over-HTTPS and DNS-over-TLS support out of the box.
Fine-grained control with wildcard patterns and rule syntax for individual AI domains.
Redirect AI-tool domains to a custom internal block page instead of returning NXDOMAIN.
AdGuard Home supports both hosts-file format and plain domain list format. We recommend the plain domain format — it parses faster and produces cleaner dashboard statistics.
Navigate to Filters → DNS Blocklists → Add blocklist → Add a custom list. Set the update interval to 24 hours under Settings → General → Filters update interval.
DNS rewrites let you redirect blocked AI-tool domains to an internal block page. Set up a web server on your network serving the branded notification, then configure DNS rewrites to point AI-tool domains to that server's IP.
AdGuard Home does not natively support configuration replication. Use Ansible or a similar tool to keep YAML files synchronized across primary and secondary instances. The blocklist URL is the same on both — each instance downloads and applies the list independently.
Unbound is a validating, recursive, caching DNS resolver used extensively in enterprise and ISP environments. It achieves blocklist behavior through local-zone and local-data directives that answer queries locally without forwarding them upstream.
Use Unbound's include: directive to load local-zone entries from a separate file. This keeps your main unbound.conf clean and makes automated updates trivial — overwrite the include file and reload.
Returns the sinkhole address from local-data. Useful for redirecting users to an internal block page. Produces a clear log pattern — all sinkholed queries resolve to the same address.
Returns NXDOMAIN, causing browsers to show a generic DNS error. Simpler configuration — no local-data line needed. Less useful for monitoring and user notification.
For memory-constrained environments, use category-filtered lists — block "Text & Language" and "Image & Visual" while allowing "Code & Development" through.
BIND is the most widely deployed authoritative and recursive DNS server in the world. Its Response Policy Zone (RPZ) feature is purpose-built for DNS-level blocking — the enterprise-grade approach used for malware, phishing, and now AI-tool domain enforcement.
*.openai.com catches all subdomains automaticallyIf you already use RPZ feeds for threat intelligence (Spamhaus, SURBL, or commercial feeds), adding our AI-tool RPZ zone is operationally identical — just another RPZ source.
// /etc/bind/named.conf.options — enable RPZ options { // ... existing options ... response-policy { zone "ai-tools.rpz" policy given min-update-interval 60; }; }; // /etc/bind/named.conf.local — define the RPZ zone zone "ai-tools.rpz" { type master; file "/etc/bind/zones/ai-tools.rpz.db"; allow-query { none; }; allow-transfer { 10.0.0.0/8; }; // Allow transfer to secondary DNS };
Each blocked domain gets a CNAME pointing to "." (dot), which tells BIND to return NXDOMAIN. To redirect to an internal block page instead, replace "." with your block-page FQDN (e.g., block.internal.example.com.).
Wildcard entries (*.openai.com) catch subdomains like chat.openai.com, api.openai.com, and platform.openai.com. Our feed includes apex domains and common subdomains, but wildcards defend against subdomains we have not yet cataloged.
After updating the zone file, reload BIND with rndc reload ai-tools.rpz. Remember to increment the serial number in the SOA record — our automation script handles this automatically.
dnsmasq is the DNS forwarder and DHCP server found in most consumer routers, OpenWrt installations, and lightweight Linux gateways. Its address= directive maps a domain and all subdomains to a sinkhole IP, blocking them for every client.
Loading 16,024+ address directives increases dnsmasq's startup time and memory usage. Use the conf-dir directive to load entries from a separate file, keeping the main configuration clean.
# /etc/dnsmasq.conf — include AI blocklist directory # Add this line to your main dnsmasq configuration conf-dir=/etc/dnsmasq.d/,*.conf # /etc/dnsmasq.d/ai-blocklist.conf — generated from AI Tools Blocklist # Each address= directive blocks the domain and all subdomains address=/openai.com/0.0.0.0 address=/claude.ai/0.0.0.0 address=/anthropic.com/0.0.0.0 address=/midjourney.com/0.0.0.0 address=/gemini.google.com/0.0.0.0 address=/jasper.ai/0.0.0.0 address=/copy.ai/0.0.0.0 address=/writesonic.com/0.0.0.0 address=/replika.com/0.0.0.0 address=/character.ai/0.0.0.0 # ... 16,024+ domains total # Optional: log blocked queries for monitoring log-queries log-facility=/var/log/dnsmasq-blocked.log
address=/openai.com/0.0.0.0 blocks openai.com and all subdomains/tmp/dnsmasq.d/ and add conf-dir=/tmp/dnsmasq.d//etc/init.d/dnsmasq restart or service dnsmasq restartEvery platform blocks AI domains effectively. The differences are in management interface, scalability, and advanced features.
Best for: Home labs, small offices, teams that want a visual dashboard. Web-based adlist management. Gravity-based blocklist compilation. Group management for per-client policies. Most community documentation and examples available.
Best for: Modern deployments needing DoH/DoT, built-in HTTPS filtering, and a polished UI. Supports filtering rule syntax for fine-grained control. DNS rewrites for custom block-page redirects. Single-binary deployment.
Best for: Organizations already running Unbound as their recursive resolver. No additional software required. Include-file approach keeps configuration modular. DNSSEC validation out of the box. Low memory overhead.
Best for: Enterprise environments with existing BIND infrastructure. RPZ is the industry standard for DNS policy. Supports zone transfers for multi-server replication. Wildcard entries, CNAME redirects, and granular logging built in.
Best for: Routers, embedded devices, OpenWrt, and lightweight gateway deployments. Simplest configuration syntax. Automatic subdomain blocking with address= directives. Ideal when you cannot install additional software on the network gateway.
Our plain-text domain list (one domain per line) works with any DNS resolver or filtering proxy that supports blocklist imports. PowerDNS Recursor, Knot Resolver, CoreDNS, Technitium DNS Server — all can consume a flat domain list.
A static blocklist decays fast. Our pipeline classifies approximately 300,000 newly registered domains every day, adding identified AI tools to the feed within the same 24-hour cycle.
If your resolver is still using last month's list, hundreds of new AI-tool domains are resolving normally and your users can reach them without restriction.
Pi-hole and AdGuard Home handle updates natively via their built-in filter refresh interval. For Unbound, BIND, and dnsmasq, use a cron job that downloads the latest list, writes it to the resolver's config directory, and reloads.
# Add to crontab: run daily at 3:00 AM 0 3 * * * /usr/local/bin/update-ai-blocklist.sh # Make the script executable chmod +x /usr/local/bin/update-ai-blocklist.sh # Test the script manually before enabling the cron job sudo /usr/local/bin/update-ai-blocklist.sh tail -5 /var/log/ai-blocklist-update.log
Blocking AI tools is only half the job. You also need to prove to your CISO and compliance team that the blocks are working — and identify which users generate the most blocked queries.
Built-in dashboard with query log, long-term statistics, and per-client breakdowns. Filter by sinkholed address (0.0.0.0) to isolate AI blocks.
Similar dashboard with query log and statistics. Clean visualization of blocked vs. allowed queries over time.
Forward DNS logs to a SIEM (Splunk, Elastic, Graylog) for centralized analysis, dashboards, and alerting.
Turn on query logging on your resolver. Pi-hole and AdGuard Home log by default. For Unbound, set log-queries: yes. For BIND, configure a query log channel. For dnsmasq, add log-queries to the configuration file.
Identify blocked queries by their response: 0.0.0.0, NXDOMAIN, or the sinkhole IP. In BIND RPZ, look for "QNAME policy" entries in the log. In dnsmasq, filter for lines containing your blocked addresses. Aggregate by client IP and domain for reporting.
Ship DNS logs to your SIEM for centralized analysis. Build dashboards showing top blocked AI domains, top users attempting AI access, and trend lines over time. Most SIEMs have pre-built parsers for BIND, Unbound, and dnsmasq log formats.
Create weekly or monthly reports showing total AI-tool queries blocked, unique domains encountered, unique clients attempting access, and any new AI domains discovered. These reports satisfy audit requirements and demonstrate control effectiveness to management.
Our REST API lets you enrich DNS log entries with category, subcategory, and confidence score — turning a raw "blocked openai.com" log line into a structured event with risk tier and classification data.
DNS-level blocking only works if clients use your DNS resolver. A technically sophisticated user can configure a public resolver (8.8.8.8, 1.1.1.1) or enable DNS-over-HTTPS in their browser.
Firefox and Chrome both support DoH, and some configurations enable it by default. Without mitigation, users can bypass your sinkhole entirely.
DnsOverHttpsMode: off. Firefox: return NXDOMAIN for use-application-dns.netEnforce the corporate DNS server via GPO and disable DoH in Chrome using the DnsOverHttpsMode enterprise policy.
Deploy a configuration profile via MDM to lock DNS settings. Firefox respects the use-application-dns.net canary domain to auto-disable DoH.
Our Firewall Admin Guide covers these bypass-prevention firewall rules in detail.
Tell us which DNS platform you run. We will send the blocklist in the exact format your resolver expects — ready to deploy in under five minutes.
Specify your DNS platform (Pi-hole, AdGuard Home, Unbound, BIND, dnsmasq) and network size. We will provide the feed URL and format guide within 24 hours.