A DNS resolver receives names such as example.com, login.example.com, or cdn.example.net. The DNS protocol doesn’t tell the resolver that one name belongs to a news service, another is a gambling site, or a third is being used for phishing.
Those judgments come from classification systems built around DNS. They gather evidence about domains, websites, infrastructure, and observed behavior, then turn that evidence into categories, threat assertions, reputation, or other labels that a policy system can use.
A domain can carry several different kinds of intelligence
“Classification” can describe several related but distinct things.
A content or application category describes the normal purpose of a domain or service. A system might classify a destination as news, education, social media, streaming media, online gaming, file sharing, business software, or another category defined by that classification system. These are the categories that acceptable use policies lean on when they restrict whole classes of destinations.
A threat assertion describes evidence of harmful activity. A domain or hostname might be associated with phishing, malware delivery, command-and-control, generation by a domain generation algorithm (DGA), or another threat.
A reputation or risk assessment expresses how much confidence a system has in the domain based on the evidence available. A newly observed domain with little history may be treated differently from an established domain with years of consistent use, even when neither has been confirmed as malicious.
These labels don’t have to replace one another. A business application can still become compromised. A file-sharing service can remain a file-sharing service while one hostname or tenant is being abused for malware delivery.
The classification problem is therefore broader than assigning one permanent label to every domain.
Classification starts with evidence
Different classification systems use different evidence, and there’s no standard set of inputs required to classify a domain.
Evidence can come from the name itself. The system may examine domain length, character distribution, tokens, n-grams, entropy, use of digits or hyphens, similarity to known brands, or other lexical properties.
Evidence can also come from what the domain serves. A crawler or browser can observe page text, titles, metadata, links, forms, scripts, application names, logos, screenshots, redirects, and other aspects of the site or service.
DNS and infrastructure add another layer. Useful observations can include A and AAAA records, nameservers, hosting networks, Autonomous System Numbers (ASNs), record changes over time, passive DNS history, and relationships to other domains using the same infrastructure.
Registration and certificate data can contribute context as well. RDAP or registration records may show when a domain was registered or which registrar manages it. TLS certificates can reveal additional names that co-occur on the same certificate, though CDNs and managed certificate services also create such co-occurrence incidentally, so it’s evidence of association rather than proof of common control.
Finally, classification systems can consume outside intelligence such as malware analysis, phishing reports, abuse feeds, incident investigations, sandbox observations, analyst decisions, and previously classified related domains.
Not every classifier has access to all of this. A model running only on a domain string faces a very different problem from a system that can fetch the website, inspect DNS history, compare infrastructure, and consult current threat intelligence.
How the models behind classification evolved
For much of the history of automated domain analysis, engineers first decided which measurable properties were likely to distinguish one class of domains from another: length, entropy, token patterns, registration age, resolution behavior. Those properties became features for the classical machine-learning toolkit, models such as logistic regression, decision trees and random forests, support vector machines, and gradient boosting. The models varied, but the workflow didn’t. A person translated domain knowledge into features before any model saw a domain. An early landmark of this era, Notos, showed in 2010 that reputation could be assigned to previously unseen domains from passive DNS features, and detecting algorithmically generated domains produced a large body of work in the same mold.
Deep learning changed the input rather than just the model. Recurrent networks, first applied to DGA detection in 2016, read a domain name as a character sequence and learn the discriminating patterns themselves, with no hand-selected lexical features. Pretrained transformer representations later applied the same idea to URLs. Graph models widened the input a different way, treating clients, domains, and IP addresses as a connected network and classifying a domain from the structure around it rather than from its local features alone.
None of these waves eliminated the previous one. Each widened what a model could take in: engineered measurements first, then the raw name itself, then the web of relationships around it.
Reasoning models widen the evidence a classifier can weigh
The current shift follows the same trajectory. Reasoning and multimodal models are being applied to work that previously depended on separate classifiers, hand-built feature pipelines, or manual review, and the significant change is again the range of evidence a single model can consider together. Such a model can be given a domain name along with page text, metadata, a screenshot, brand information, redirects, infrastructure observations, threat intelligence, and explicit classification rules, then evaluate how those pieces of evidence support or contradict one another. Research prototypes are beginning to explore that shape on narrow slices of the problem, for instance by combining multimodal models with page content, logos, and external brand knowledge for phishing-page detection.
Traditional models keep useful roles in that picture. Fast lexical classifiers, heuristics, character-pattern models, graph analysis, reputation systems, and other specialized techniques can efficiently produce signals that would be expensive or unnecessary to derive with a larger reasoning model.
One practical architecture is therefore a hybrid.
A system might use specialized models to produce observations such as:
lexical:
brand_similarity: high
suspicious_tokens: ["secure", "login"]
character_substitution: present
infrastructure:
registration_age: recent
related_malicious_hosts: 2
page:
claimed_brand: Example Bank
credential_form: present
domain_matches_brand: falseA reasoning model tuned for the classification task can then evaluate those observations together with the underlying evidence and explicit classification rules.
Another system might ask a multimodal model to perform much more of the evidence interpretation directly. A third might rely primarily on classical classifiers and reserve reasoning models for specific categories or ambiguous cases.
There’s not yet a generally accepted architecture for how these components should be combined.
Threat intelligence adds evidence from outside the classifier
Machine learning is only one source of domain intelligence.
A threat feed may identify a domain after malware analysis shows that a sample contacts it for command-and-control. A phishing investigation may confirm that a hostname is collecting credentials. A sandbox may observe a redirect chain ending at a malware download. Passive DNS data may reveal relationships to infrastructure already associated with an attack campaign.
That intelligence can change how a domain is treated without changing its normal content category.
Consider a legitimate business site that becomes compromised. Its content classification may remain “business,” while a security system adds a temporary malicious or compromised assertion based on current threat evidence. Once the site is remediated and supporting evidence changes, the threat assertion may eventually be removed while the content category remains.
This is why content categorization and threat intelligence work better as separate dimensions than as one label competing for the same field.
Relationships can reveal information the domain name doesn’t
Domains rarely exist in isolation.
Two unrelated-looking names may resolve to the same infrastructure. Several domains may use the same nameservers, redirect to the same destination, appear in the same certificate history, or be queried by the same infected hosts.
Classification systems have long used those relationships. Reputation systems score domains partly on the infrastructure and zones around them, and graph-based classifiers make the relationships themselves the primary signal.
Relationships require caution. Shared hosting, content delivery networks, public cloud platforms, and multi-tenant services intentionally place unrelated customers on common infrastructure. Association is evidence, not proof.
The value comes from combining relationships with other observations. A new domain sharing infrastructure with known malicious domains is more interesting when its name, content, registration history, and behavior point in the same direction, and infrastructure that changes addresses rapidly, in the style of fast flux, is itself a relationship signal worth weighing.
Classification has to deal with change and uncertainty
Domains change.
They’re registered, parked, sold, repurposed, compromised, remediated, moved between providers, or assigned to new applications. A classification made months ago may no longer describe what the domain serves today.
Subdomains add another problem. An apex domain such as:
example.commay represent an organization generally, while:
login.example.com
video.example.com
customer123.example.comcan serve very different functions.
Classification systems therefore have to decide what they classify and how inheritance works. Some intelligence belongs naturally at the registrable-domain level. Other assertions are specific to a fully qualified domain name. Shared platforms may require even more care because many unrelated users can exist beneath the same parent domain, and a DNS enforcement point can act on tenant-specific intelligence only when the tenant is distinguishable in the queried name itself. Tenants separated only by URL path look identical to a resolver.
example.co.uk is a registration while co.uk is a suffix. Classification systems, browsers, and certificate authorities typically answer that question with the Public Suffix List, a community-maintained text file originally started by Mozilla, so a load-bearing piece of internet policy infrastructure is, in the end, a curated list rather than a protocol rule.
Confidence matters for the same reason. A domain supported by direct page evidence and confirmed threat intelligence is different from one whose only suspicious property is an unusual character pattern.
There’s no DNS standard for classification confidence, category inheritance, or how long a verdict should remain valid. Those are properties of the intelligence system.
Human judgment still matters
Automated classification works at a scale that manual review can’t match, but some cases remain ambiguous.
A website may legitimately use terminology associated with several categories. A cloud service may host both ordinary business applications and abusive content. A newly registered domain can look suspicious while being entirely benign. Two intelligence sources can disagree.
Human analysts can resolve difficult cases, correct labels, define classification rules, and provide high-quality examples for model training or evaluation. Reasoning models can reduce the amount of routine analysis that requires a person, but they don’t remove the need for review, governance, and measurement of classification quality.
The more consequential the classification, the more important it is to preserve the evidence and reason behind it rather than storing only a final label.
DNS filtering consumes the classification
DNS filtering is one consumer of this intelligence.
When a resolver receives a query, the classification work may already have happened elsewhere. The resolver can look up the relevant content category, threat assertions, reputation, and local policy, then make the DNS enforcement decision.
That separation allows classification to evolve independently from the DNS protocol. New intelligence sources, models, and reasoning techniques can improve the understanding of a domain without changing the format of a DNS query or response.
Summary
Domain classification is an evidence problem before it is a filtering problem. The evidence may come from the domain string, website content, DNS history, infrastructure, registration data, certificates, observed behavior, relationships, or outside threat intelligence.
Traditional systems relied heavily on engineered features and specialized machine-learning models. Deep models later learned representations from the name itself, and graph systems put explicit relationships between DNS entities to work. Today, reasoning and multimodal models are beginning to take on classification work by evaluating richer evidence together, while classical models, heuristics, and specialized detectors remain useful sources of fast and focused signals.
The domain name is only the identifier. Its classification comes from the evidence assembled around it.