How to Audit a DNS Provider's Privacy Claims: A Checklist
Every DNS provider says they respect your privacy. Here are the eleven questions that distinguish the ones who have thought about it, and what a bad answer to each one looks like.
By Guardino Team · Guardino Technologies
Every DNS provider's homepage says roughly the same thing. Privacy is respected, data is not sold, logs are minimal or absent. The statements are so uniform that they carry almost no information, which is a problem, because the underlying practices differ enormously.
This is a checklist for telling them apart. It is deliberately vendor-neutral: the questions apply to any resolver, including the free public ones, including the one your internet provider gave you, and including ours.
1. What exactly is written, field by field?
Ask: which fields are persisted for a query? The domain? The client address? A device or account identifier? A timestamp? The response?
A good answer enumerates them. "We store the queried domain, whether it was allowed or blocked, a category, and a timestamp. We do not store the source IP address in long-term storage."
A bad answer is a category rather than a list: "we store minimal data," "only what is necessary to provide the service." Necessary according to whom, and for how long?
The reason to start here is that this single question separates providers who have thought about it from providers who have written a paragraph.
2. Is anything written by default, or only if I opt in?
There is a real difference between "we keep logs and you can ask us to stop" and "we keep nothing unless you ask us to start." Both can be defensible, and they are not the same product.
Ask: if I sign up and change nothing, what exists about me a week later?
A bad sign is a provider who cannot answer this cleanly, or whose answer differs between the marketing page and the privacy policy. Which brings us to the next item.
3. Do the documents agree with each other?
This is the highest-yield check on the list and it takes fifteen minutes.
Open, in separate tabs: the homepage, the privacy policy, the terms of service, the sub-processor list if there is one, and any developer or API documentation. Search all of them for the retention claim.
What you are looking for is disagreement. It is remarkably common for a homepage to say one thing and a privacy policy to say another, usually because the marketing page was written by one team and the policy by a lawyer working from an older description of the system. When they disagree, the policy is the one that binds and the homepage is the one that is aspirational.
A provider whose documents all say the same specific thing has done work that most have not.
4. How long, in numbers?
Ask: how many days, for each thing that is retained?
A good answer gives numbers, differentiated by data type, and explains why they differ. Operational logs for debugging and abuse prevention are a legitimately different category from per-query records, and a provider who conflates them is either confused or hoping you will be.
A bad answer is "as long as necessary," which is the standard formulation for having no policy.
5. Who else touches it?
Ask: who are the sub-processors, and what does each one do?
A published list naming the hosting provider, the database provider, the payment processor and the analytics tool, with a sentence each on purpose, is a sign of a company that has actually mapped its own data flows. The absence of such a list is not proof of anything, but its presence is meaningful, because compiling one is tedious and nobody does it for show.
Look for the gaps. A service that lists a payment processor and a CDN but no database provider has either an unusual architecture or an incomplete list.
6. What happens when someone asks for the data?
Ask: what is the process when a legal request arrives? Is there a transparency report? What was produced last time?
The structural point: a provider that genuinely retains nothing per-query is in a much stronger position than one who promises to resist requests, because resistance is a policy and absence is a fact. Policies change with ownership; absent data stays absent.
A useful follow-up: what would you be able to produce about a specific user, if compelled today? A provider who has thought about this has an answer ready, and it is usually shorter than you expect.
7. Where is it stored, and under what law?
Jurisdiction matters, but less than the previous question and more than nothing.
Ask: in which countries is data stored, and which law governs the entity holding it?
Weigh it correctly. A provider holding no per-query records is in a similar position in most jurisdictions. A provider holding detailed records is exposed everywhere, with different procedure. Look at what is retained first; where it is retained is a modifier, not the main term.
Watch for a specific pattern: claims about a privacy-friendly jurisdiction that turn out to describe where a marketing entity is incorporated rather than where the servers and the operating company are. These are not the same thing and the difference is exactly the thing that matters.
8. Can you export or delete it, and does that actually work?
Ask: is there a self-service export and a self-service deletion, or is it an email to support?
Then, if you can, test it. Sign up, generate some traffic, request the export, and read what comes back. This is the only item on the list that produces direct evidence rather than a claim, and it is worth the hour.
What you learn from an export is what is actually held, which sometimes differs from the privacy policy in both directions. A file that contains more than the policy described is a red flag. A file that contains less can be a good sign or can mean the export is incomplete, which is worth asking about.
9. Is anything encrypted in a way the provider cannot read?
For services that retain records for longer periods, ask whether any of it is encrypted such that the provider itself cannot decrypt it.
Understand what the answer implies. If a provider says archives are encrypted with a key only the customer holds, that is a strong property and it comes with a hard consequence: they cannot restore your data either. A provider claiming customer-held encryption and also offering to recover your data if you lose your passphrase is describing two things that cannot both be true, and that contradiction is one of the fastest tells available.
So the follow-up question is: what happens if I lose the key? If the answer is anything other than "the data is unrecoverable," the key is not really only yours.
10. Has anyone independent looked?
Ask: has any third party examined the systems, and can I read the report rather than the summary?
Read the scope. Published audits are routinely narrower than the marketing description of them. An audit that reviewed the retention configuration on a particular date is meaningful and is not a continuous guarantee. An audit whose scope was chosen by the vendor to confirm the vendor's claims is weak evidence.
Do not weight certification badges heavily. A compliance framework attests to having a process, not to a specific retention practice, and the two are regularly confused in marketing copy.
11. What is the business model?
Ask: how does this service make money?
If a service is free, at scale, with no visible revenue, the honest question is what the asset is. Sometimes the answer is fine: a loss leader, a research project, a company monetising something adjacent. Sometimes the asset is the query data.
A paid service has a simpler alignment, which is not a guarantee of anything but does remove the most common structural incentive to retain more than necessary.
Two claims to treat with suspicion in either direction
"Zero-log." The phrase has no fixed meaning. Different providers use it for no records at all, for no records tied to identity, and for records deleted after a day. It is a marketing term. Any provider using it without further specification has told you nothing, and the right response is to ask questions one and four.
"We keep your logs for thirty days." This sounds like a disclosure and can also be an overstatement, if the service in fact stores nothing until a customer switches logging on. A provider whose default is to keep nothing but whose policy describes a retention window is contradicting itself in the more flattering direction, which is still a contradiction. Both errors indicate the same underlying thing: the documents and the system have drifted apart.
Applying this to us
It would be strange to publish a checklist and dodge it, so:
Guardino writes no per-query records unless the customer turns logging on. If they do, the searchable window is thirty days on the free tier, ninety days on Pro and a year on Team. Source IP addresses are not kept in long-term storage. Customers on paid plans can additionally keep older months as archives encrypted in their own browser, held in Switzerland, under a passphrase we never receive, with the consequence that we cannot read them and cannot recover them if the passphrase and recovery code are both lost. Sub-processors are listed publicly. Export and deletion are self-service.
We have not been independently audited. That belongs on this page as much as the rest of it does.
Run the same eleven questions against whoever you are considering, including us, and prefer the answers that are specific over the ones that are confident.
Related reading
Frequently asked questions
Is a no-logging claim ever verifiable from the outside?+
Not directly, and any provider who implies otherwise is overselling. You cannot observe the absence of a write. What you can evaluate is whether the claim is specific enough to be falsifiable, whether the surrounding documents contradict it, whether an independent party has examined the systems, and what jurisdiction and corporate structure would do to the claim under pressure. A specific claim that is consistent everywhere and has been externally examined is a materially different thing from a homepage banner, even though neither is proof.
How much should a third-party audit weigh in the decision?+
It should raise confidence, with two caveats worth checking before it does. First, scope: an audit that examined the retention configuration at one point in time says nothing about the configuration six months later, and many published audits are narrower than the marketing summary suggests. Second, who chose the scope: an audit designed by the vendor and confirming exactly what the vendor claimed is weaker evidence than one with a scope you can read and evaluate. Read the report, not the badge.
Does the jurisdiction of the provider actually matter in practice?+
It matters for what can be compelled and with how much process, and it matters less than people assume relative to the design of the system. A provider that genuinely holds no per-query records is in a similar position everywhere, because a legal order cannot produce data that does not exist. A provider that holds detailed logs is exposed in every jurisdiction, just with different procedures. Look at what is retained first and where it is retained second.
What if I need filtering, which means the resolver has to see my queries?+
It does have to see them, and any service claiming to filter without seeing what it filters is describing something that cannot work. Seeing is not the same as recording, though, and that distinction is where the actual policy lives. A filtering resolver can evaluate a domain against a list in memory and write nothing, or it can write everything. Ask specifically about the write, not about the read, and prefer a service where keeping records is a choice you make rather than a default you inherit.
Ready
Reclaim your attention.
Set up Guardino in two minutes. Your first 300K queries are on us.
Start your protection→Continue reading
The Layers of DNS Privacy: DoH, DoT, ODoH and What Each One Actually Hides
Each DNS privacy mechanism removes one specific observer. Knowing which one, and what remains visible afterwards, is the difference between a real threat model and a comfortable feeling.
Who Sees Your DNS Queries, and What They Can Work Out From Them
People assume DNS queries are too boring to reveal anything. A week of domain names, with timestamps, is one of the most revealing datasets an ordinary person generates.