This should have been the first post on the Veilty blog.
The earlier DNS articles still matter. They explain how DNS works, why it sits close to almost every internet request, and why it matters for security. They also help people discover the project through search. But they are not the best doorway into Veilty because they start with DNS as a technology. This note starts with the reason we are building the product.
What Veilty Is
Veilty is a privacy-minded DNS filtering service for people who want a cleaner and safer internet experience without handing over more activity history than necessary.
That is the short version, but it is not enough by itself. Veilty is still at the MVP stage, with some parts already shaped like a real product and some decisions still being tested. We would rather be direct about that than wrap an early product in language that sounds more finished than the work actually is.
The direction is clear. Veilty is being built around a frustration with existing DNS products: useful DNS services often ask users to choose between visibility and privacy. Either activity history is stored somewhere inside the service, or it is not stored at all. The second option is often the cleanest privacy answer, and in many cases it is the right default, but it also removes one of the reasons people understand and enjoy DNS filtering in the first place.
Statistics are not just decoration, and logs are not just a technical leftover. A dashboard that shows what was blocked, what changed, what spiked, and which filters made a difference helps people understand their own internet activity. It turns DNS filtering from something invisible into something people can learn from and control.
At the same time, this data is sensitive. A domain name may be public, but the fact that a specific person, household, device, or team requested that domain at a specific time is not public in the same way. DNS privacy work has long pointed out that DNS can reveal a lot about user activity because almost every online action begins with a lookup.1 A resolver may not see everything a browser or application does, but it often sees enough to create a meaningful pattern.
That tension is the root of Veilty. The most useful product surface is also one of the most private. We started building because we wanted a better middle ground.
The Problem With Owning the Server
Veilty did not begin as a product. It began as a practical setup for personal use. We ran resolvers on a few VPS machines and configured them the way we wanted. That felt like control: the data was no longer inside a large third-party DNS service, the filters were ours, and the machines were ours to configure.
Over time, the obvious problem became harder to ignore. A VPS still has to be trusted. It has an operating system, access paths, logs, updates, credentials, providers, backups, and many ordinary ways for mistakes to happen. It needs care. If the machine is compromised while historical activity is stored in plaintext, the attacker does not need to defeat an elegant privacy model. The history is simply there.
That realization changed the project. We had moved the trust problem, not solved it, so the goal became bigger than resolving DNS and applying filters. We wanted to reduce what remains readable after resolution. We wanted useful historical visibility without turning the past into a plaintext archive.
DNS resolution cannot be made magically private from the resolver at the moment the resolver handles the request. The resolver needs to process the name in order to answer, filter, or route it. Encrypted DNS transports such as DNS over TLS and DNS over HTTPS help protect traffic on the wire,23 but they do not remove every trust question around the resolver itself.
So Veilty does not promise impossible end-to-end privacy for the entire DNS process. The narrower promise is more honest: historical activity should be harder to read by default. Stored logs and statistics should not be casually available to an operator, backend, storage layer, or compromised POP. A service can still keep useful history without treating that history as an internal dataset that everyone in the system can read.
That does not make the whole DNS service fully end-to-end encrypted. POP still has to handle live DNS requests before they can be protected for storage. The honest claim is narrower: Veilty is working toward end-to-end style protection for historical activity, while acknowledging that live DNS processing cannot be hidden from the component doing the processing.
This was the moment the project started to feel different. We could keep useful history only if stored history was not treated as readable internal data. That idea became one of the roots of Veilty.
Private History in Practice
When people hear "encrypted logs," it is easy to imagine a perfect shield, but that would be the wrong mental model. POP still sees the request while it is being handled. Plaintext exists only as transient processing data in memory before it is protected for storage, and Veilty should not store plaintext logs or plaintext metrics on POP. A compromised POP can still observe new activity while it is being processed, but it should not be able to open historical logs or statistics that were already protected.
For stored history, the intended boundary is asymmetric encryption with user-held private keys. The backend, storage, and POP can keep the product working, but logs, metrics, and other stored user-activity history should remain encrypted in a form that support, admins, operators, or attackers cannot decrypt without the user's private keys. Even broad service access should leave a bad actor looking at ciphertext, not readable browsing history. In plain language, protected history is meant to be client-readable, not operator-readable.
Technically, this is a hybrid encryption model rather than public-key encryption for every byte. Activity payloads are encrypted with a symmetric content key, and that smaller key is protected with the user's asymmetric key pair. The implementation direction uses browser-side Web Crypto API primitives: AES-GCM for activity payload encryption and asymmetric key wrapping for the content keys.4 The service can store ciphertext, routing and retention metadata, and wrapped keys, but it should not hold a support-readable private key or hidden recovery key.
That choice has a hard recovery trade-off. If the private key is protected by the user's password and the user loses that password, a reset can restore account access but cannot recreate the old private key. Historical activity encrypted to the lost key should become unreadable and be discarded or restarted from that point. That is inconvenient, but it is also what prevents a support flow, operator account, or backend compromise from becoming a back door into user activity.
The value is in reducing historical blast radius. We think about this boundary through three roles: POP handles the live DNS work, backend coordinates the product, and storage keeps historical activity. The goal is that none of these roles should automatically become a reader of protected history.
POP needs a separate caveat because it is close to the request. A compromised POP can observe new activity while it is still in the memory path, but that is different from opening history that was already protected and moved into storage. Once activity is encrypted for storage, POP access should not reopen it unless the attacker also gets the user's private key material or a plaintext copy that should not exist in Veilty's own log and metrics storage.
There is also a weaker but still important risk around correlation. A compromised POP may see the current configuration it is using and may be able to connect some protected aggregate views to that active configuration. That is not the same as opening historical logs, but it matters for dashboard data, which is why the exact shape of stored statistics is still being tested. We want useful aggregates without letting aggregates become a shortcut back to private history.
The point is not to declare the problem solved too early. The point is to make the boundary concrete enough to test, especially around what dashboard data can safely reveal.
There will still be operational information. A service needs some facts in order to route, count, retain, and return data. Privacy is not the absence of all information. It is the discipline of making each layer know only what it needs to know, and this is where the original self-hosting lesson still guides the product.
Less readable history means less damage when something goes wrong. That is not as catchy as a marketing slogan, but it is the kind of claim we can build around.
Visibility Still Matters
It would be simpler to say that Veilty should store nothing. For some users and some modes, that may be exactly right. Minimal history is easier to reason about, and no retained data is hard to leak. But Veilty is not only a resolver. It is meant to be a product people can use, understand, and shape around their own needs, and visibility is part of that.
People want to know whether tracker blocking actually works. They want to see when a device suddenly becomes noisy, understand why an app stopped connecting, and figure out whether a filter is too strict, too weak, or just right for their household. Without statistics, DNS filtering can feel like a black box. With statistics, it becomes a tool.
Veilty's answer is still evolving, but the direction is clear. We want dashboards and historical insight to exist without making raw activity history easy for the service itself to inspect.
Advanced users should eventually be able to choose the balance more precisely. Some will want the quietest possible mode with almost no retained history, while others will want more aggregated insight because the value is worth the risk to them. The important part is that this trade-off should be visible, honest, and understandable. Privacy settings should not be hidden behind vague promises.
What Veilty Is Not
Veilty is not here to kill existing DNS services. There are well-known resolvers with global infrastructure, strong uptime, polished dashboards, and years of trust. Many users are happy with them, and many teams have good reasons to use them.
Veilty exists because we were not satisfied with the usual trade-off. We wanted DNS filtering that feels useful without making historical activity too easy to read. That also means Veilty is not a magic private internet.
DNS filtering can block unwanted destinations before a connection is made. It can reduce exposure to ads, trackers, suspicious domains, and accidental visits to known bad places. It can make browsing quieter and make some risks easier to notice. But DNS filtering cannot fix a device that is already compromised, cannot see everything an application does after a connection is established, and cannot replace browser security, endpoint security, operating system updates, identity protection, or basic care.
We do not want to sell DNS filtering as an impenetrable shield for a home, a small office, or a company, then explain the real limitations in small print. That would be easy marketing and bad security. Broader security claims should come only when Veilty can stand behind them.
This is one reason our current focus is regular users. Veilty was born from the needs of people like us, not from a desire to wrap a simple resolver in enterprise language. Family and team use can still matter. Shared spaces, permissions, and collaboration can be useful. But the product has to stay honest about what DNS can and cannot protect.
The Product Direction
The product direction begins with simple use. A person should be able to point a device at Veilty and get a cleaner internet experience without studying DNS internals. Filters should be understandable, changes should be predictable, and the product should not feel like a pile of infrastructure exposed through a dashboard.
We are also working through public resolvers and the product layer above them. Without registration, a user should still be able to choose a filter configuration. The trade-off is that changing that configuration may require changing the endpoint on the device. Registration should remove that friction by making private endpoints possible.
The lightest registered mode can still stay simple. It can be filter-only, backed by shared public behavior, and avoid logs and metrics entirely. That mode matters because not every user wants history, and not every useful DNS setup needs a dashboard.
From there, control becomes more personal. People should be able to shape DNS behavior around their own preferences. Some will want a light configuration, some will want stronger blocking, and some will want separate contexts for different devices, family members, or workspaces. The product should let that grow naturally without making the first step heavy.
Richer private endpoints should be more than aliases. They should be able to carry rules, settings, filters, and profiles that belong to the user. They can also support logs, metrics, and visualization when the user chooses that trade-off.
Those capabilities have real infrastructure cost. Storage, transit, reading history, and more complex resolver behavior are not free from an operational point of view. That is why history and advanced rules should be explicit product choices, not silent defaults.
Later, Veilty may also explore transparent proxy or smart DNS behavior for location-specific compatibility cases. That is not the center of the current promise, and it should not distract from the first job of making DNS filtering private, understandable, and useful.
We have also tried to leave room for multi-tenancy and multi-account use. This matters for families, small teams, and people who manage several spaces at once, but it is important not to confuse product boundaries with encryption boundaries. Multi-tenancy and multi-account support do not make DNS end-to-end encrypted by themselves. They give people cleaner ways to separate access, collaborate where needed, and manage shared spaces without losing the privacy model.
Private historical visibility sits behind all of this. Veilty should make it possible to look back at activity in useful ways without assuming that the service should always be able to read everything. This is one of the hardest parts of the product because it affects logs, statistics, storage, dashboards, and recovery flows at the same time.
Transparency is the final part of that direction. Veilty is being built in the open, and privacy claims should eventually be backed by code, tests, and documentation rather than by wording alone. If a boundary is still being tested, we should say so. If DNS cannot protect against a class of risk, we should say so. Trust should not depend only on tone.
The Principle Behind the Product
We do not want this first note to become a technical document, but the principle is worth stating in plain language. Each part of the system should know as little as it reasonably can. A service part that only needs to route protected history should not understand the contents of that history. Storage should not become a private activity reader, and an operator should be able to keep the service healthy without browsing user DNS history.
This is not only about encryption. It is about product restraint. The easiest way to build analytics is to collect readable events and make them convenient. The safer way is to ask what each layer truly needs, what can be aggregated, what can be encrypted, what can be omitted, and what should never be retained in the first place.
Veilty will not get all of those decisions perfect on the first try. But the direction matters. We are building toward a product where privacy is a constraint, not a page in the footer.
The Stakes
Most people do not think about DNS until it breaks, and that is understandable. DNS is supposed to disappear into the background. You open a website, an app connects, a device checks for updates, and the lookup happens quietly.
Quiet infrastructure can still reveal a lot. A household's DNS activity can show routines, devices, apps, interests, work tools, entertainment, school services, and mistakes. A team's DNS activity can show vendors, internal habits, research, and operational patterns. Even when each individual domain looks harmless, the timeline can become personal.
That is why Veilty treats history carefully. We want people to have useful visibility into their own activity, but we do not want that visibility to become an easy window for everyone else who touches the service. This is the balance we are trying to build.
The Promise We Are Comfortable Making
Veilty will not promise perfect privacy, will not promise that DNS filtering solves every security problem, and will not pretend that unfinished work is finished infrastructure.
The promise is narrower and more practical. Veilty should help users make safer choices online. It should make DNS filtering understandable. It should give people useful visibility without making their past activity easier to read than it has to be. It should prefer collecting less over collecting more, and it should make trade-offs explicit instead of hiding them.
That is the product we want to build: not a perfect shield, not a magic private internet, and not another dashboard built on readable history. Veilty is our attempt to build the middle ground we wanted when we started with a few VPS resolvers and realized that owning the server was not the same as protecting the data.
That is why Veilty exists.