Your DNS filter sees every query your network generates. But seeing a query and understanding it are two different things.
Most URL classification systems were built around a specific assumption: the host being queried is a website, and the website has content worth categorizing. That assumption held reasonably well for a long time. Block social media during work hours. Permit SaaS tools. Flag newly registered domains.
But modern networks have evolved. A significant share of DNS queries today aren’t headed toward websites at all — they’re destined for infrastructure: DoH resolvers, captive portals, internal hostnames that have no business being sent to an external classification API. When your classification engine encounters these, it typically does one of two things. It returns nothing useful, or it returns something wrong.
Neither outcome is acceptable when you’re making real-time policy decisions.
That’s why we’re expanding URL classification coverage to 92 content categories with three new additions that address some of the most consistently mishandled host types in modern network environments.
captive portal website classification
The Three Hosts Your Filter Didn’t Know What to Do With
Category 89: DNS over HTTPS
DNS over HTTPS (DoH) was designed with privacy in mind. It encrypts DNS queries inside HTTPS traffic so ISPs and passive observers can’t see what you’re resolving. For end users, that’s a reasonable goal. For enterprise security teams, it’s a significant control surface problem.
When a device on your network uses a DoH resolver instead of your configured DNS server, those queries bypass your DNS filter entirely. The resolver answers before your stack ever sees the request. URL classification policies, threat detection, content filtering — all of it evaporates for that traffic.
The hosts that provide DoH resolution — cloudflare-dns.com, dns.google, and dozens of others — have a specific fingerprint. They’re not malicious. They’re utilities. But they deserve their own classification precisely because the policy decision around them is distinct: security architects who want DNS-layer visibility need to identify and block DoH endpoints to force queries back through monitored channels.
We now return Category 89 for these hosts. You can build policy around it without relying on manual domain lists that age out the moment a new DoH provider goes live.
Category 90: Local/Non-Routable
This one is a log pollution and investigation friction problem.
Not every hostname that shows up in DNS query logs is supposed to route to the public internet. localhost, server.lan, printer.local, in-addr.arpa — these are internal identifiers, and when they appear in logs, the correct interpretation is “this belongs to your private network, not the open web.” The incorrect interpretation — which is what you get when a classification engine returns nothing or flags them as unknown — is a false signal that wastes analyst time and degrades the signal-to-noise ratio of your logs.
Previously, we returned an unrated result for these hosts. Starting now, queries for local and non-routable hostnames return Category 90, explicitly indicating that the hostname is private infrastructure and is not expected to produce a classification.
There’s a secondary operational benefit here: Category 90 is also a signal to integration partners that these queries shouldn’t be sent to our API at all. If you already know a hostname is non-routable, filtering it at the client layer before it hits the API is both more efficient and more accurate. The new category makes that logic easier to implement.
Category 91: Network Access / Captive Portal
Captive portals sit at an awkward intersection: they look like web content (they’re served over HTTP/HTTPS, they have domains, they present in a browser), but their function is access control. Airlines, hotels, coffee shops, and enterprise guest networks all use them to gate internet access behind authentication or a terms-of-service agreement.
The problem is that when a content filter blocks a captive portal before the user can authenticate, the user simply can’t connect. The fix — allowlisting specific captive portal domains — requires either manual maintenance or the ability to distinguish “this is a captive portal” from “this is a risky external site.”
Category 91 makes that distinction explicit. aainflight.com, deltawifi.com, and similar hosts now return a classification that lets you build a permit rule with confidence, separate from your broader web access policy. Users get through. Your filter still applies to everything that isn’t a captive portal.
Why This Matters Beyond the Three Categories
These additions reflect something broader about how we approach classification: the goal isn’t to categorize websites. It’s to classify all hosts — including the ones that aren’t websites.
Security analysts and network architects increasingly work in environments where a significant fraction of DNS traffic is infrastructure traffic:
- DoH resolvers
- Internal services
- Captive portals
- IoT device call-home endpoints
- Certificate validation hosts
When these generate “uncategorized” responses, they create two problems simultaneously: noise in the logs and gaps in policy enforcement.
92 categories means finer-grained policy control and more accurate enrichment across the stack — whether you’re using alphaMountain’s API inside a secure web gateway, a DNS filter, a SIEM, or a SOAR playbook.
The full category taxonomy is available at alphamountain.ai/categories.
Try It
Our URL classification runs on a continuously-trained AI engine that updates hourly — not a static list. The new categories are live now.
Want to see how the category expansion affects your current classification coverage? Request a free API trial at [email protected], or investigate any domain or IP immediately at threatYeti.com — no account required.