DNS Filtering Service Comparison: Logging, Encryption, and Deployment

DNS filtering choices differ by operator, logging model, and deployment path

A DNS-filtering label alone does not identify the operator, query-logging default, log region, encrypted transport support, or whether filtering runs through a managed resolver or a local deployment.

This matrix keeps those questions separate across a frozen five-path roster: AdGuard DNS, Control D, NextDNS, Pi-hole, and Quad9. The four managed resolver paths and the local Pi-hole deployment remain in one comparison because a reader may consider them for a similar network-control job, but the page does not treat their operating models as equivalent. A field that applies to a hosted service is not copied into the local-deployment row, and a local configuration statement is not rewritten as a service policy.

The comparison uses thirteen attributes because each one answers a narrower question. Signup identifiers and later verification concern identity collection at different moments. General retention and deletion do not replace the dedicated DNS-query logging and log-region fields. Blocklist sources describe filtering inputs; encrypted DNS describes documented transport support; router deployment describes a setup path. Operating entity, request reporting, public source artifacts, and assessment records supply still different evidence.

Every displayed vendor or project value is transcluded from the current persisted cell for the exact product, plan, region, platform, attribute, and observation version. The value travels with its claim type, source class, source URL, capture date, and evidence state. A typed unknown therefore belongs to one field at one captured scope. It is not completed from another column, another row, general product knowledge, or a later source that has not passed the same capture process.

The page supplies no score, rank, best label, preferred-product conclusion, or performance verdict. Alphabetical order expresses no preference. The privacy-tool comparison methodology and corrections hub explains the frozen roster, source labels, capture rules, corrections path, and neutral ordering. The related email-alias comparison covers an address layer that may be used alongside network-level controls without claiming that either layer makes the other anonymous.

What each path collects at signup and what can trigger later verification

Signup identifiers describe what the documented path requests before initial use, while later-verification triggers describe a separate event and any additional identifier requested after that point.

The signup column keeps the identifier, requiredness, collecting actor, plan, region, platform, and scope supplied by the exact current cell. It does not assume that every path has an account. When a path is documented as accountless or locally deployed, the table preserves that operating distinction instead of inventing a signup workflow or borrowing one from a managed service.

The later-verification column is independent. It records a trigger, requested identifier, requesting actor, and scope only when the cell establishes them. Signup, account recovery, support contact, risk review, abuse response, billing, and another later event are not merged simply because more than one may involve identity information. A documented requirement at one stage does not prove that the same requirement exists at every other stage.

These cells describe captured documents rather than completed account exercises. No account was created and no verification event was triggered for this comparison. Vendor-stated requirements remain vendor-stated and scoped to the named product tuple and capture. If the declared sources do not disclose a later-verification field, the typed absence remains visible; it is not translated into a promise that a later check can never occur.

Source: 5 products. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

Who operates the path and what its documents say about retention, deletion, and requests

Operating identity, general retention, deletion, and request reporting are separate fields, so one policy statement cannot stand in for every actor, record category, or disclosure process.

The operating-entity column reports the legal or project identity and jurisdictional detail supported by the current cell. It does not treat brand, hosting location, user location, endpoint location, governing law, and network location as synonyms. The Pi-hole row remains a local project and deployment path where its cells say so; it is not recast as an organization operating a managed recursive resolver for the reader.

Retention stays tied to the data category, controller, trigger, duration, exception, and scope named by the source. A period attached to one category does not become a universal retention schedule for every DNS record, account record, security record, support record, or diagnostic artifact. A relative or non-numeric period remains in the recorded source terms instead of being converted into an estimated calendar date.

Deletion is also narrower than complete erasure of every related record. The column reports the initiation path, controller, completion statement, timeframe, exceptions, and scope established by its cell. A documented account-deletion path does not establish what another actor retains, while a local uninstall or database action is not rewritten as a hosted-service erasure promise. When the cell does not settle a detail, the page does not fill it from the retention column.

Request reporting preserves the period, jurisdiction, unit, scope, counts, and process statements that the exact cell supplies. Requests, orders, accounts, identifiers, disclosures, and challenged matters are not assumed to be interchangeable units. A process statement is not a count, and the absence of a disclosed report is not rendered as zero requests.

Source: 5 products. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

DNS query logging defaults and log regions are separate comparison fields

A DNS logging default states the documented starting behavior and retention choices, while a log-region field states only the storage, processing, or selection scope its source identifies.

The logging column keeps the documented default, relevant query or metadata categories, retention setting, available choice, plan, platform, and limitations together. Enabled, disabled, configurable, temporary, diagnostic, and another scoped condition are not compressed into a single privacy label. A default does not establish every later user setting, and a choice available to one plan or client does not automatically extend to every plan or deployment.

The log-region column answers a different question. It records only the storage or processing location, selection mechanism, eligibility, plan, category, and limits established by the current cell. Legal domicile, resolver endpoint, user location, processing location, storage location, and a selectable region remain distinct when the evidence distinguishes them. A missing region statement is not replaced by the operating-entity jurisdiction.

The local Pi-hole row stays local where its captured records place the query data. The matrix does not present that model as equivalent to sending queries to a managed resolver, and it does not assume a local deployment has no upstream resolver, network exposure, administrator access, diagnostic record, or other data path. Those questions require their own evidence and are outside what these two cells establish.

Read the two columns together without fusing them. A documented region does not reveal whether logging is on by default. A logging default does not reveal where every covered category is handled. Neither field alone establishes anonymity, complete non-retention, current behavior beyond the capture, or a product-wide privacy result.

Source: 5 products. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

Blocklists, encrypted DNS, and router deployment answer different capability questions

Blocklist sources describe filtering inputs, encrypted DNS describes documented transport roles, and router deployment describes the prerequisites for applying a path at the network level.

The blocklist column records the built-in, third-party, custom, or other list inputs established by the current cell, together with their update, selection, plan, platform, and scope qualifiers. A named list or input does not establish filtering accuracy, completeness, speed, maintenance quality, or suitability for a particular threat model. The page did not submit test domains, measure blocking results, or compare false positives.

The encrypted-DNS column records the documented protocol, endpoint, client or server role, setup requirement, plan, platform, and limitation. DNS over HTTPS and DNS over TLS are treated here as transport support only. A protocol statement does not establish that the resolver keeps no logs, that an account reveals no identity, that destination traffic receives end-to-end protection, that all clients use the protocol, or that a network cannot observe or bypass another part of the path.

The router column reports whether the captured documentation describes router-level use and which device, firmware, DNS-setting, local-host, or other prerequisite it names. Network-level setup is not assumed to cover devices that ignore the configured resolver, use a different protocol path, leave the network, or follow another configuration. The table also does not infer that the same setup steps work on every router or firmware release.

The three columns therefore remain independent. A path may document one capability without settling the others, and the meaning of a value stays attached to its product, plan, region, platform, and observation. No combination of the three becomes a security score, privacy score, effectiveness grade, or recommendation.

Source: 5 products. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

Source availability and audit records are different evidence types

A public repository identifies only the documented component and version scope, while an audit cell records only the assessment artifact, assessor, period, and scope named by its source.

Source availability records the component, repository or artifact locator, version or release locator, license, and limitations established by the current cell. A public repository for a client, daemon, list, documentation set, or another named component does not establish that every hosted service, policy system, resolver operation, deployment, or release is public. The component boundary remains part of the value.

The assessment column answers a separate question. It records the assessor, scope, standard, period or date, report locator, publication status, and stated limitations when the captured source supplies them. A vendor-published assessment reference remains at the claim type stored with its cell. The presence of an artifact does not independently verify every product claim, version, infrastructure layer, or present-day behavior.

Four rows carry a verified absence for the audit field under the declared method. That label means the specified primary documents did not disclose an assessment artifact within the capture boundary. It does not mean no audit exists, no private assessment occurred, no security work was performed, or the product failed an assessment. The page preserves the stored label and explanation instead of shortening it to none or unaudited.

Neither column is a trust badge. Source availability is not an assessment, and an assessment is not a complete source inventory. Both remain dated records whose usefulness depends on the named component, scope, version, period, and limitations.

Source: 5 products. Each source link opens the authority for its cell. The page source record lists the capture date and snapshot for every cell.

How to read this matrix without turning it into a ranking

Read every cell as a dated, scoped record of vendor-published or public-repository evidence, not as a score, rank, product test, best label, or prediction of current behavior.

The roster is deliberately bounded to AdGuard DNS, Control D, NextDNS, Pi-hole, and Quad9. Inclusion does not endorse a path, and omission does not criticize an unlisted path. Alphabetical display order carries no preference. The comparison does not add a provider because it is popular, remove one because a field is unknown, or turn the number of documented fields into a completeness score.

Capture dates report when each source was collected. They do not promise that a policy, repository, interface, plan, platform, endpoint, or service has remained unchanged. Vendor-stated evidence describes the source at its captured scope; public-repository evidence describes the named artifact and version. The page does not independently test resolver behavior, speed, availability, blocking accuracy, security, protocol negotiation, router compatibility, or the completeness of any document set.

Typed unknowns remain field-specific. A verified absence means the declared primary documents did not disclose the field under the recorded method, not that the feature, report, process, or capability cannot exist. A not-applicable value preserves an operating-model boundary. Another unknown preserves a gap rather than converting it into no, none, unsupported, zero, or a favorable privacy inference.

Managed resolvers and the local Pi-hole deployment are comparable here only at the named attribute grain. The table does not claim that they place the same actor in the query path or create the same account, logging, custody, maintenance, or network relationships. Encrypted transport is likewise one field, not proof of anonymity, non-collection, filtering quality, or protection for destination traffic.

The methodology and correction route remains the privacy-tools hub. The private phone-number comparison applies the same separation between a provider's collection and the identifier exposed to another party. These links provide adjacent evidence models; they do not fill or override any DNS cell.

Frequently asked questions

Related research

• Private Phone-Number Apps: Identity, Retention, Porting, and LimitsAn adjacent comparison that separates provider collection from the identifier exposed to a counterparty
• Email-Alias Services: Identity, Retention, Replying, and LimitsAn adjacent comparison for the address layer used alongside network-level controls