Table of contents

1. Introduction
2. Instructions
3. Age verification laws and other bad ideas
4. Other news

Introduction

We've added public DNS-over-HTTPS endpoints to the network.

DNS-over-HTTPS, usually shortened to DoH, is exactly what it sounds like: DNS queries sent through HTTPS instead of the usual plaintext DNS protocol. In plain terms, that means the part of your browser that asks "what IP does this domain point to?" can be sent inside the same kind of encrypted HTTPS connection your browser already uses for websites.

This does not make a browser private by itself. It does not fix canvas fingerprinting, WebGL fingerprinting, timezone leaks, language/header uniqueness, geolocation APIs, bad extensions, hostile JavaScript, or all the other browser-shaped garbage that gets used for tracking. It only changes how DNS lookups are done.

But DNS still matters. Plain DNS is easy for ISPs, captive portals, schools, workplaces, public WiFi networks, and national firewalls to log, redirect, poison, block, or otherwise tamper with. DoH wraps those lookups in HTTPS, so on the wire it looks like ordinary HTTPS traffic to the DoH hostname. That's useful on networks where DNS is being manipulated, and it's also useful in browsers because it can prevent browser-side DNS leaks where the browser or one of its APIs would otherwise resolve names outside the VPN/DNS path you expected.

The endpoints are:

Ad/tracker-blocking:
https://public.deepdns.net/dns-query-ts
https://cryptostorm.is/dns-query-ts
https://cryptostorm.nu/dns-query-ts
https://SERVER.cstorm.is/dns-query-ts

Unfiltered:
https://public.deepdns.net/dns-query
https://cryptostorm.is/dns-query
https://cryptostorm.nu/dns-query
https://SERVER.cstorm.is/dns-query

Replace SERVER with any of the hostnames listed at the bottom of https://cryptostorm.is/wireguard or in https://cryptostorm.nu/nodes.txt, such as paris.cstorm.is, austria.cstorm.is, belgium.cstorm.is, etc.

There are also additional DoH-capable hostnames in the OpenVPN configs generated at https://cryptostorm.is/configs/ and in the configs on GitHub at https://github.com/cryptostorm/conf/. We're not listing them directly here because in some places DNS censorship (probably) is done by crawling public pages like this one, then feeding the discovered domains into blocklists. If the obvious endpoints get blocked somewhere, the less-obvious hostnames in the configs may still work.

The /dns-query endpoint is the normal unfiltered resolver. The /dns-query-ts endpoint goes to a different resolver that blocks ad/tracker hosts using the Pro++ list from HaGeZi's DNS blocklists.

If something breaks, use the unfiltered endpoints. DNS-based blocking is useful, but DNS blocklists are blunt instruments. Some sites load login pages, payment processors, videos, comments, or images from domains that also appear on tracking lists. That's the tradeoff. Using both DNS-based blocking and browser-based blocking is usually better than relying on only one layer, but the unfiltered endpoint is there for the cases where the blocklist gets in the way.

These endpoints have actually existed for a while. We didn't announce them before because DNSCrypt already existed on our side, and DNSCrypt solves some problems better than DoH. DoH still depends on the WebPKI/CA system. If a domain expires or a CA makes a bad decision, someone else can theoretically get a valid certificate for a name and run a service there. DNSCrypt doesn't work that way; the resolver identity is tied to the DNSCrypt server public key, so taking over the domain name alone isn't enough.

So DNSCrypt is still preferable if you're already using DNSCrypt, especially with Anonymized DNSCrypt relays. Our implementation is described at https://cryptostorm.is/blog/anondns

But DoH has one large advantage: it is easy. No extra DNSCrypt client is needed. Most people can paste a URL into their browser's secure DNS settings and be done with it. That's enough of a benefit to make these public.

Opening them publicly also adds more ordinary resolver traffic to the same PowerDNS recursor backends used by VPN clients and our public DNSCrypt servers. More mixed DNS traffic means more background noise around the resolver side of the network, which helps VPN users and public resolver users blend into a larger crowd. DNSCrypt users using anonymized relays already get stronger separation, but more noise on the recursors still doesn't hurt.

Instructions

Pick one endpoint first. For most people, start with:

https://public.deepdns.net/dns-query-ts

If a site breaks, switch to:

https://public.deepdns.net/dns-query

If you're using the VPN service and you often connect to the same server, you would get faster DNS lookups if you use that server's DoH endpoint.

Chrome / Chromium

1. Open Chrome's menu, then go to Settings.
2. Go to Privacy and security.
3. Open Security.
4. Scroll to Use secure DNS.
5. Enable it.
6. Choose the custom/provider option.
7. Paste the DoH URL, for example:
   https://public.deepdns.net/dns-query-ts

If you're using Chrome because you need a Chromium-based browser, consider using Cromite instead. It's a Chromium fork with built-in ad blocking and privacy-focused patches. DoH only changes DNS. It does not fix the rest of the browser fingerprinting/tracking surface.

Firefox

1. Open Firefox's menu, then go to Settings.
2. Go to Privacy & Security.
3. Scroll down to DNS over HTTPS.
4. Choose increased/max protection if you want Firefox to use DoH instead of silently falling back to local DNS.
5. Choose Custom.
6. Paste the DoH URL, for example:
   https://public.deepdns.net/dns-query-ts

If you're using Firefox mainly because you want a more privacy-friendly browser, also look at LibreWolf. It's an independent Firefox fork focused on reducing telemetry, tracking, and fingerprinting. DoH only changes DNS; LibreWolf covers a different part of the browser privacy problem, and some protections can be adjusted per-site when needed.

Microsoft Edge

1. Open Edge's menu, then go to Settings.
2. Go to Privacy, search, and services.
3. Scroll down to Security.
4. Enable Use secure DNS.
5. Choose a service provider / custom provider.
6. Paste the DoH URL, for example:
   https://public.deepdns.net/dns-query-ts

Also: don't use Edge. There isn't really a privacy-friendly Edge fork in the same way there are privacy-focused Chromium or Firefox forks, because Edge is closed source and Microsoft's browser, so nobody can audit, rebuild, or modify the parts that matter into a sane privacy-friendly browser.

Safari / Apple platforms

Safari does not expose a simple "paste custom DoH URL here" setting like Firefox/Chrome/Edge. On Apple platforms, encrypted DNS is usually configured at the OS level using a configuration profile. That means the browser instructions are not as clean, and the exact UI differs between macOS/iOS versions.

If you're on macOS/iOS and want to use these DoH endpoints system-wide, create or install a DNS settings profile that points to one of the DoH URLs above. Be careful with random profile generators; configuration profiles can do much more than change DNS, so inspect what you're installing.

And no, there isn't a privacy-friendly open-source Safari fork either. It's Apple.

Testing

After enabling DoH, restart the browser and test it at https://cryptostorm.is/leaktest. That page checks IP, DNS, and WebRTC leaks using JavaScript. If you have JavaScript disabled, use https://cryptostorm.is/dnsleaktest/ instead.

If the test shows your ISP resolver, your browser is probably not using the DoH endpoint you configured, or the browser's DoH mode is set to a fallback/default protection level that still allows local DNS in some cases. Use the stricter/max protection mode if your browser provides one and you want it to use DoH only.

Age verification laws and other bad ideas

Since this post is already about DNS privacy, censorship resistance, and who gets to see what you're doing online, we should probably mention the current wave of age/ID verification laws.

California's AB 1043, Illinois' SB 3977, Brazil's Lei 15.211/2025, and similar laws being pushed elsewhere are all variations on the same theme: make operating systems, app stores, apps, platforms, or developers collect, infer, transmit, or act on age signals so that access can be allowed, denied, filtered, logged, or delegated to some other layer of the stack.

We're not implementing that, and we're not going to knowingly build on software that does. cryptostorm is a VPN/privacy provider. We encrypt and relay traffic, run resolvers, publish configs, write ugly shell scripts, and try to keep the network from becoming more stupid than necessary. We are not an ID-verification company, a parental-control vendor, or a checkpoint for whether someone is allowed to use their own computer.

Our servers currently run Arch Linux. There's been discussion in the Arch community about these laws, but as of this writing there doesn't appear to be a final project-wide stance. That's understandable; volunteer Linux distributions are not built like Apple, Google, Microsoft, or Meta. They usually don't have centralized user accounts, compliance departments, ID pipelines, state-specific activation flows, or a pile of lawyers waiting around to interpret every new legislative attempt to shove identity into the operating system.

Artix is on our short list if this becomes a real problem for Arch. Artix is Arch-based, rolling-release, and systemd-free. That last part is a bonus. systemd has had a long history of security problems and overreach, and plenty of people have had unkind things to say about it, including Linus Torvalds. PID 1 should be boring. A lot of modern Linux decided it should be an everything daemon instead.

There are also several long Reddit threads collecting bill text, model-bill language, lobbying disclosures, and state-by-state comparisons. The short version is that a lot of these proposals look less like "protect the children" and more like "move liability away from the platforms with the largest child-safety exposure, push the burden onto app stores, developers, and OS vendors, then let whoever controls the age-verification infrastructure become unavoidable."

See:

• Arch discussion about California/etc. age verification (archive.org mirror)
• linux thread comparing bill text from multiple states (archive.org mirror)
• thread on lobbying/model-bill language around Linux/OS age checks (archive.org mirror)

The implementation problem is obvious to anyone who has actually used Linux for more than ten minutes. Who is the "OS provider" for an Arch ISO mirrored by volunteers? What about derivatives? What about a tarball? What about a VPS image? What about containers? What about source builds? What about an offline installer? What about a router image? What about a single-user rescue ISO? What about a server that has no human-facing app store and no concept of a child account?

The answer is that the people writing these laws either don't know, don't care, or know exactly what they're doing and are fine with breaking smaller/free/open systems because the compliance model was designed around large centralized platforms.

So our policy is simple: no age verification, no ID verification, no age-signal APIs, no "upload your documents to prove you're allowed to use the internet", and no software stack changes that would turn our servers into part of that system. If a distribution we depend on goes in that direction, we'll move.

Other news

Lifetime tokens

As of this blog post, there are 21 unsold lifetime tokens left. The live counter on https://cryptostorm.is/#section5 has the current number. Once those are sold, the option to buy new lifetime tokens will be removed from the site.

This does not affect existing lifetime tokens. Existing lifetime tokens are still lifetime tokens. On the backend they have to be represented as a number because computers don't understand "lifetime", so they're set to 73 years, which was the global average life expectancy when that value was chosen.

The only change is that once the remaining lifetime tokens are gone, new ones won't be available for purchase. The reason is simple: server invoices continue forever, and lifetime tokens are a one-time payment. Over long enough timelines, the shorter-duration tokens are what keep the network paid for.

We've done this before years ago, and they may come back again someday, but they will not be part of the annual Black Friday through Cyber Monday half-off sale, or any other possible sale before that. $250 is too cheap for lifetime access. Every other token duration will still be in the sale like usual.

Windows client

We're still working on the next Windows client release at https://cryptostorm.is/windows#widget

The client is essentially our custom OpenVPN GUI, and the next build switches away from the now-unsupported Wintun adapter toward DCO/TAP, adds Xray support, and includes better/more translations. It also has a lot of UI cleanup already done, including a new server dropdown list with country flags and mouseover effects, and instant language switching without restarting the program.

It's closer to a rewrite than a normal update, so it's taking longer than usual. Most of the UI work and a lot of the new code is already done, but we still need to finish the DCO/TAP update, Xray support, and the remaining rewrite work. WireGuard support is being considered too, but that will probably wait until the next major release since it needs a lot more testing, and the official WireGuard client already works fine.