Cloudflare and AdGuard Lead Phishing DNS Blocks in 100-Host Test

MakeUseOf tested DNS responses without opening the associated websites or downloading their contents. Its comparison therefore captures a specific security function: whether a selected resolver prevents an application from obtaining the normal IPv4 address for a hostname associated with malware or phishing. It does not measure what a browser, endpoint protection product, or email security service would do afterward.

The experiment is useful because it combines a common sample with an unfiltered control and provider-specific interpretations of blocking responses. Its strongest result is the division between malware and phishing—not AdGuard’s one-domain lead over Cloudflare. Understanding that division also reveals what Windows users can reasonably expect from filtered DNS, and what administrators should verify before adopting it.

Cloudflare and AdGuard led the totals, but phishing determined the ranking​

MakeUseOf’s results placed AdGuard first overall, followed closely by Cloudflare, with NextDNS and Quad9 farther behind. Separating the two threat categories changes the interpretation immediately.

These are MakeUseOf’s measurements from one test run, not results reproduced by WindowsForum. Each service received the same 50 malware-associated and 50 phishing-associated hostnames, queried for A records—the DNS records that supply IPv4 addresses.

On malware, the spread was three hostnames from best to worst. AdGuard and Quad9 blocked all 50, Cloudflare blocked 48, and NextDNS blocked 47. Across that half of the dataset, the services agreed much more often than they disagreed.

Phishing produced a different pattern. Cloudflare blocked 37 hostnames, AdGuard 36, NextDNS 23, and Quad9 18. The difference between Cloudflare and Quad9 was therefore 19 phishing hostnames, even though Quad9 blocked two malware hostnames that Cloudflare allowed.

That distinction is important when choosing a service for a particular job. Describing Quad9’s result only as “68 percent” conceals its complete coverage of the malware sample. Describing AdGuard’s result only as “86 percent” similarly conceals the fact that 14 phishing hostnames still received an allowed result.

The overlap reveals more than the finishing order​

MakeUseOf also reported how often the services agreed on individual hostnames. That provides a second view of the results, beyond adding up each provider’s blocks.

For malware, 45 of 50 hostnames were blocked by everyone; the other five were blocked by three services. For phishing, only eight were blocked by everyone, while two were allowed by everyone. The remaining 40 phishing hostnames produced a mixture of block and allow decisions.

Across the complete sample, that means 53 hostnames were blocked by all four services, two were allowed by all four, and 45 generated disagreement. Almost all of the disagreement came from phishing. This is the most useful evidence behind the warning that successful DNS resolution is not a safety verdict.

There is another consequence hidden in the category totals. AdGuard’s one-domain overall advantage over Cloudflare consists of two additional malware blocks offset by one fewer phishing block. Even before examining individual hostnames, the category breakdown shows that the apparent winner depends partly on what the reader values.

The experiment gave malware and phishing equal weight. Under that weighting, one additional blocked malware hostname contributes exactly as much to the total as one additional blocked phishing hostname. A reader chiefly concerned with phishing should therefore look directly at the phishing column, rather than treating the combined score as a universal measure of protection.

Nor can the overlap table be used to recommend a particular pair of services. It shows how many providers blocked each hostname, but it does not identify every pairing. It supports the conclusion that providers differ; it does not supply enough detail to calculate the coverage of a specific two-provider combination or describe how such a combination should be deployed.

URLhaus and PhishTank supplied different kinds of evidence​

MakeUseOf began with two sources that serve different purposes. URLhaus supplied malware-associated hostnames, while PhishTank supplied verified phishing URLs that the tester converted into hostnames. That conversion was necessary for a DNS comparison, but it also created a meaningful difference between the two halves of the test.

URLhaus’s official documentation describes its domain-only host file as containing hostnames associated with malware URLs that are active or were added during the preceding 48 hours. It also describes excluding hostnames belonging to domains in the Tranco Top 1M to reduce false positives. The feed is therefore curated for hostname-based use, with deliberate restrictions on what enters it.

PhishTank’s developer documentation describes its downloadable dataset as containing entries marked both verified and online. The verified field indicates that the phishing report has been verified by its community; the online field indicates that the phishing destination is operational. Its database files are updated hourly.

Those descriptions establish useful prerequisites, but they establish different things. URLhaus offers a hostname feed constructed for blocking applications. PhishTank verifies phishing URLs, which may include a particular page or path beneath a hostname. Removing that path changes the unit being judged.

This helps explain why the two categories should remain separate throughout an evaluation. The malware and phishing scores do not merely represent different threats encountered through an otherwise identical selection process. They also reflect different feed rules and different amounts of information preserved when the original reports become DNS questions.

The control removed dead names before assigning credit​

After extracting hostnames, removing duplicates, and discarding raw IP addresses and unusable entries, MakeUseOf reported 392 unique URLhaus hosts and 41,522 unique PhishTank hosts. It randomly selected 75 from each source, producing 150 initial candidates.

The tester then queried those candidates through Cloudflare’s ordinary, unfiltered DNS-over-HTTPS service. That control found 131 resolving hostnames and 19 that did not resolve, with no query errors reported. The surviving set contained 74 malware hostnames and 57 phishing hostnames.

Expressed another way, one of the 75 malware candidates failed that preliminary control, compared with 18 of the 75 phishing candidates. This is an observation about that particular selection, not a general measure of either feed’s quality. It nevertheless shows why checking current DNS availability was especially consequential for the phishing half.

From the surviving candidates, the tester fixed the final sample at 50 malware and 50 phishing hostnames. All 100 returned an IPv4 address during the final control check. Immediately before scoring each hostname against the filtering services, the tester checked it against the unfiltered control again and reported that it still resolved.

That repeated control prevents a basic scoring error. If a hostname has disappeared from DNS, a failed lookup through a security resolver cannot automatically be credited to its threat intelligence. The destination may simply have become unavailable regardless of which provider answered.

The control establishes something narrower and more useful: at the time of comparison, the hostname had an address available through the unfiltered resolver. A filtering service’s recognized blocking response can then be compared with that live baseline. This makes the result more informative than a count of failed lookups against an old list.

A live hostname is still not a freshly inspected malicious page​

The tester deliberately avoided opening the websites. Consequently, the control confirmed DNS availability, while the feeds supplied the malware or phishing classification. Those are separate parts of the evidence chain.

A hostname returning an address does not establish that the originally reported page still exists at its old path or serves the same content. URLhaus itself notes that a URL’s content can change after cleanup. The experiment’s repeated DNS checks improve confidence in its blocking measurements without turning those checks into a fresh inspection of each website.

The final 50/50 balance also makes the comparison easier to read, but it is a constructed balance. It does not represent the relative frequency of malware and phishing in an individual’s browsing, an organization’s email, or its network traffic. The overall score describes performance on this deliberately balanced sample.

Likewise, selecting 50 phishing hostnames from a much larger candidate pool does not make every kind of phishing equally represented. MakeUseOf’s platform analysis shows that the selected sample had a substantial concentration of hosted infrastructure. That concentration deserves attention when interpreting the category results.

The useful administrative lesson is to preserve the selection history alongside a score: where the candidates came from, what was excluded, how many survived the control, and how the final categories were balanced. Without those details, a percentage can look precise while concealing the choices that gave it meaning.

Cloudflare, Quad9, NextDNS, and AdGuard express blocks differently​

The comparison used the Python DNS library dnspython, HTTP/2, and DNS-over-HTTPS to send the same A-record questions to the four filtered services. DNS-over-HTTPS, commonly shortened to DoH, carries DNS questions inside HTTPS requests. Cloudflare’s documentation describes it as encrypting the connection between the client and resolver.

Encryption and filtering perform different jobs. DoH changes how the question reaches the resolver; the selected resolver and its policy determine whether the answer is filtered. The experiment demonstrated this distinction directly by using an unfiltered DoH service for the control and filtered services for the scored queries.

The responses also required interpretation. A block could appear as a special address or as an error-like DNS result, depending on the provider. Counting every returned address as an allowance—or every failed lookup as a security block—would misclassify some outcomes.

Cloudflare’s documentation confirms that its malicious-domain filtering returns 0.0.0.0 instead of the destination’s real address. That is a returned A-record value, but it is not the normal address needed to reach the destination. A scoring system that only asks whether an answer contains an IPv4 value would get this wrong.

MakeUseOf observed the same unspecified address for blocked A-record queries through its NextDNS profile. That observation belongs to the configuration and run being reported. It should not be expanded into an unsupported statement that every possible NextDNS configuration must respond identically.

Quad9’s authority count distinguishes a block from a missing domain​

Quad9’s official documentation provides a particularly useful distinction. Its security blocks return NXDOMAIN, the DNS response also used when a name does not exist. Quad9 differentiates those cases using the authority count: AUTHORITY: 0 identifies a block, while AUTHORITY: 1 identifies an ordinary nonexistent name.

That explains why merely looking for NXDOMAIN is insufficient. Two responses can share that status while representing different causes. The test’s use of the additional authority information is therefore a material part of its methodology, not incidental technical detail.

Quad9 also documents a separate failure branch: a DNSSEC authentication failure produces SERVFAIL, rather than the blocking form of NXDOMAIN. DNSSEC is the DNS authentication mechanism referenced by that error. For this comparison, the important consequence is that a validation failure belongs in a different category from a malicious-hostname block.

A defensible evaluator should therefore preserve the response status and relevant answer details, not only a final yes-or-no score. Otherwise, a later review cannot distinguish an intentional policy block from a nonexistent name or another resolution failure.

AdGuard illustrates the other side of the problem. MakeUseOf frequently received 94.140.14.33 and treated it as AdGuard’s block address. That is the response reported in this run; it is not an instruction to configure a device to use that address as its DNS server.

Resolver addresses and addresses returned in DNS answers have different roles. One tells the client where to send a question. The other is part of the answer it receives. Confusing them would undermine both a reproduction of the experiment and an attempt to deploy the chosen service.

HTTP/2 matters to a current Quad9 reproduction​

Quad9’s documentation says it began globally disabling HTTP/1.1 support for DoH on December 15, 2025. The MakeUseOf test used HTTP/2, which places its transport choice within that documented requirement.

For someone attempting a similar comparison now, this is a practical compatibility issue. An older DoH client that cannot use HTTP/2 may encounter a transport problem before the resolver makes any useful filtering decision. Such a failure must remain a transport error in the results, not a successful security block.

This also explains why a reproducible comparison needs more than four provider names and a domain list. The client library, transport, query type, endpoint, profile, and interpretation of the response all help define what was measured. Changing one of those details can change whether the experiment is even asking the same question.

The present results remain limited to the reported A-record queries. They do not supply a separate set of measurements for IPv6 address lookups or a browser’s complete connection process. That scope is appropriate for a DNS comparison, provided it remains visible when the findings are translated into advice.

PhishTank URLs expose the limits of hostname-level filtering​

The largest interpretive issue is the difference between a URL and a hostname. A URL can identify a particular page beneath a host. A DNS question asks about the hostname and does not retain the page path that originally made the phishing report specific.

MakeUseOf converted PhishTank’s verified URLs into hostnames to make them usable in the comparison. That is a necessary simplification for this test, but it can transform “this page is phishing” into the broader proposition “this hostname should be blocked.”

Those propositions can align closely when a hostname exists primarily to support an attack. They can diverge when a malicious page sits on compromised or shared infrastructure that also supports legitimate content. A hostname-level block then has a broader reach than the URL-level report.

MakeUseOf found that 36 of the 50 phishing hostnames matched recognizable hosting or proxy platforms, including Weebly, Firebase Hosting, Cloudflare Pages, Wix Studio, and Blogger. That concentration supplies a plausible explanation for some provider disagreement. It does not reveal which internal rule or intelligence source caused any individual provider’s decision.

Nor does a recognizable hosting platform settle the correct outcome. A platform-associated hostname can still be malicious and appropriately blocked. Conversely, the platform name alone does not establish how much unrelated content would be affected by a block. The individual hostname and its use remain important.

The feeds create an asymmetry before the resolvers answer​

URLhaus’s documented exclusions are relevant here. Its domain-oriented feed deliberately avoids some popular-domain infrastructure to reduce false positives. PhishTank’s verified-online data instead establishes the status of phishing URLs before the tester extracts their hostnames.

The malware sample and phishing sample therefore arrive at the resolver with different preparation. One source already applies hostname-oriented selection rules. The other begins with a more specific object and loses some of that specificity during conversion.

This does not invalidate the comparison. It identifies the question being answered: how do the selected DNS services treat currently resolving hostnames extracted from these particular feeds? It also explains why malware and phishing results should not be collapsed into an unqualified statement about “malicious sites.”

For administrators, the distinction is operational. A high phishing block count is useful when the blocked hostname is an appropriate unit of enforcement. The value becomes harder to judge when the same hostname also supports required activity, which is why legitimate-site testing belongs beside threat coverage.

The experiment did not include that second dataset. It measured blocks against known-bad reports, not mistaken blocks against legitimate destinations. Consequently, block coverage is not overall accuracy: there is no measured false-positive rate to place alongside the malicious-hostname totals.

This is especially relevant to the narrow margin at the top. AdGuard blocked one more hostname overall than Cloudflare. Without observations about legitimate traffic, that single extra block cannot establish which service would produce the better experience or lower operational cost for a particular organization.

Provider disagreement is a reason to retain layered protection​

The phishing results also place a limit on what users should infer from an ordinary lookup. Forty phishing hostnames received different treatment depending on the selected resolver. A returned address could therefore coexist with a block decision elsewhere.

That does not mean users should manually query four providers before every connection. It means DNS resolution should retain its proper meaning: the resolver supplied an address under its current policy. It has not certified every page or file available through that hostname.

The experiment never reached the browser or downloaded content. It therefore offers no measurements of browser phishing warnings, Microsoft Defender, Microsoft Defender SmartScreen, or endpoint file inspection. Those products’ behavior cannot be inferred from either a DNS block or an allowed response in this dataset.

A legitimate hostname serving a malicious page also illustrates why hostname filtering has a ceiling. The DNS service operates on the name presented to it. The page-specific evidence that a browser or another security layer might examine lies outside this test’s question and outside its reported measurements.

The concrete decision for Windows readers is to retain those other security layers when adding filtered DNS. This study supplies evidence about an additional opportunity to stop a connection. It supplies no basis for disabling protections that act on different information or at a later stage.

Resolver configurations matter more than the provider logo​

The four rows describe selected configurations, not every service each company offers. That boundary is most obvious with Cloudflare, whose ordinary resolver served as the unfiltered control while its malware-filtering service supplied one of the scored results.

Cloudflare’s official documentation identifies 1.1.1.2 and 1.0.0.2 as its malware-blocking resolver addresses. It describes that filtering as covering malware and phishing. Its malware-and-adult-content option uses 1.1.1.3 and 1.0.0.3, adding a different policy choice.

A user who changes DNS to ordinary 1.1.1.1 has therefore not reproduced the tested Cloudflare filtering configuration. The provider name is the same, but the policy is different. For a deployment decision, that distinction is more consequential than the one-domain difference between Cloudflare and AdGuard.

Cloudflare’s documented encrypted configuration likewise distinguishes its security and family services. Selecting DoH by itself does not select malware filtering. The encrypted destination must correspond to the intended filtering policy.

NextDNS has a different boundary. MakeUseOf tested a fresh profile with default security settings, rather than a profile containing every available aggressive control or a custom selection of additional lists. Its 70/100 result applies to that starting configuration.

NextDNS’s flexibility changes what must be recorded​

The relevant NextDNS decision is whether the reader wants a configurable DNS policy. MakeUseOf describes controls for security protections, blocklists, logging, and other DNS behavior. Those choices make the profile part of the tested product.

An administrator evaluating a customized NextDNS deployment should therefore record the enabled settings alongside the provider name. Otherwise, a later result cannot be compared meaningfully with this default-profile run—or even with an earlier test of the same organization’s own profile.

Customization should not be treated as evidence of a higher score before it is measured. The existence of additional controls does not tell us which of these missed hostnames they would have blocked, or what legitimate destinations they might also affect. The supported conclusion is that the tested defaults are one configuration among possible choices.

Quad9, by comparison, is presented in MakeUseOf’s account as a security-focused resolver without general ad or broader content filtering. Its sample result is particularly easy to misread because the lower combined total sits beside complete coverage of the malware half.

That does not make the phishing shortfall irrelevant. Readers choosing primarily for phishing protection have reason to examine it. It means the decision should use the specific result—18 of these 50 phishing hostnames—without converting it into a claim that Quad9 generally failed to recognize malicious infrastructure.

AdGuard’s tested default public resolver combines malicious-domain protection with ad and tracker filtering, according to MakeUseOf. That broader scope may be useful to someone seeking both functions. It also introduces policy effects that a malware-and-phishing-only dataset cannot evaluate.

Older DNS comparisons are context, not confirmation​

Historical tests demonstrate why results need to stay attached to their conditions. In a July 2020 comparison using URLhaus and PhishTank, independent writer Ming Di Leom reported 89.54 percent blocked for NextDNS, 81.03 percent for Quad9, and 49.11 percent for Cloudflare in the July 10 run. That ordering differs substantially from MakeUseOf’s 2026 result.

Those old figures cannot validate or disprove the new ones. They describe a different test years earlier, and they are not an independent repetition of MakeUseOf’s 100-hostname experiment. Their useful contribution is historical perspective: a provider’s position in a published comparison is inseparable from the test that produced it.

The current results should be treated the same way. Threat reports change, live infrastructure changes, and configurable services can be tested under different policies. A permanent ranking would require evidence beyond a single small run.

This leaves a more practical selection framework. Cloudflare offers a distinct malware-filtering choice; Quad9 offers a security-focused choice; NextDNS makes configuration central; and AdGuard’s tested service combines security with additional filtering categories. Readers should first choose the policy they actually want, then evaluate its coverage and compatibility.

The published percentages do not resolve privacy, latency, reliability, or cost decisions. Those were outside the experiment. A security comparison can inform a resolver choice without being stretched into a complete purchasing or deployment verdict.

Windows users should verify the active resolver before switching​

Keep an existing resolver unless this comparison identifies a specific mismatch with your requirements, and verify the intended filtering configuration before changing a device or network. The clearest immediate problem to catch is a mismatch between the service someone believes they selected and the service actually answering their queries.

For Cloudflare users seeking malware filtering, ordinary 1.1.1.1 and the malware-filtering 1.1.1.2 are different choices. For NextDNS users, the active profile and enabled settings belong in that check. For any provider, the presence of encrypted DNS does not by itself demonstrate that malicious-domain filtering is active.

Managed environments require an additional boundary. A public-resolver comparison is not an instruction to replace organization-managed DNS settings on individual PCs. The experiment queried providers directly; it did not test a business’s existing resolution requirements, managed network policy, or application compatibility.

VPN use is another practical complication supported by Quad9’s documentation. Quad9 says the vast majority of VPN clients do not use DNS servers supplied through the router or configured in local system settings. A computer can therefore behave differently with its VPN connected, even though the Windows DNS setting has not changed.

Quad9 says using its service through such a VPN generally requires entering the Quad9 addresses in the VPN client’s custom DNS settings, where that functionality exists. The exact controls vary by VPN client. On an organization-managed VPN, that is a configuration decision for the responsible administrator, not a reason for an end user to bypass policy.

Quad9 documents a Windows check for the received transport​

Quad9 provides a Windows PowerShell or Terminal command that asks which protocol it received for a DNS query:

Resolve-DnsName -Type txt proto.on.quad9.net.

This is a diagnostic lookup, not a command that changes the DNS configuration. Quad9 documents the following possible text responses:

To use that check meaningfully, run it in the network state you intend to evaluate. If the normal working environment includes a VPN, test with that VPN connected. If you also need to understand the non-VPN state, treat that as a separate observation rather than assuming one result covers both.

Quad9’s documentation says an NXDOMAIN response to this diagnostic means Quad9 was not used for that query. This is distinct from interpreting NXDOMAIN during a malicious-hostname test: the diagnostic hostname has its own documented purpose and expected behavior.

A doh response establishes that Quad9 received that lookup over DoH. It does not measure Quad9’s malicious-hostname coverage, and it does not reproduce the MakeUseOf experiment. Its value is more immediate: it helps confirm that the intended provider and transport are actually in the path being examined.

The result also belongs to the query that was made. It should not be expanded into a claim that every application on the PC necessarily follows the same route. The supplied experiment used a specific DNS client to contact each service directly, which is another reason its coverage figures cannot automatically describe an entire Windows deployment.

A useful DNS evaluation preserves controls and tests legitimate work​

For an administrator planning an authorized comparison, the transferable procedure begins with documenting the exact configuration. Record the resolver endpoint, whether the connection uses DoH or another transport, the query type, the date, and any profile settings. This creates a baseline that can be repeated and interpreted later.

Next, keep malware and phishing candidates separate, remove duplicate hostnames, and establish that each scored hostname still resolves through an unfiltered control. The MakeUseOf experiment shows why both initial screening and checks close to the filtered queries are valuable: the state of malicious infrastructure can change while a list remains available.

Then classify responses according to the provider’s documented behavior. Preserve ordinary resolution failures separately from recognized policy blocks. For Quad9, that includes the difference between its blocking form of NXDOMAIN, an ordinary nonexistent name, and SERVFAIL; for Cloudflare, it includes recognizing 0.0.0.0 as a block response.

Finally, add a separate legitimate-use evaluation before changing a production policy. This is an editorial recommendation arising from the study’s unmeasured false-positive side, not a result reported by MakeUseOf. The purpose is to determine whether the filtering choice interferes with the actual destinations users need, rather than assuming a high malicious-hostname count settles compatibility.

That evaluation need not involve opening live malicious pages. MakeUseOf obtained its DNS measurements without doing so. The safer and more faithful way to study this particular layer is to keep DNS observation separate from browsing or downloading hostile content.

The most concrete takeaways are these:

• Choose the exact filtering service or profile you intend to deploy; a provider’s ordinary resolver may implement a different policy.
• Compare malware and phishing results separately, because the combined score conceals the largest differences in this test.
• Verify the active DNS path in the network state that matters, particularly when a VPN can override local settings.
• Record recognized block responses separately from missing domains, validation failures, and transport errors.
• Keep browser and endpoint protections enabled, and evaluate legitimate application access before broadening a DNS filtering policy.

Filtered DNS earned its place in this experiment by stopping many known-bad hostnames before a browser needed to contact them. The decision for Windows users and administrators is to deploy the intended policy, verify that it is actually being used, and judge it against both threat coverage and legitimate work. An ordinary DNS answer remains permission to continue resolving a connection—not a certificate that the destination is trustworthy.