DNS Over HTTPS Walks Straight Past Your Controls

There is a way for anything on your network to look up a name without your DNS server ever hearing the question. No setting changed on the machine, no administrator rights, nothing you would find in a log. The lookup leaves as an ordinary HTTPS request on port 443, goes to a resolver somewhere on the internet, and comes back with an answer your own resolver would have refused to give.

The blocklist never fires. The threat feed never gets the query. The log line you would have gone looking for was never written.

It is called DNS over HTTPS, DoH for short, and it was built for a good reason. Plain DNS travels in clear text on port 53, so the coffee shop, the airport and your internet provider can read every name you resolve and change the answers if they fancy it. DoH wraps the lookup in the same encryption as the rest of the web and hides it in the crowd. As a privacy measure for a person on a hostile network, it does exactly what it says.

The trouble is that the thing it defeats and the thing you rely on are the same thing.

Your resolver is not just a lookup service. It is a control point: where a known-bad domain gets answered with nothing, where a query to a command server shows up in a log, where Protective DNS refuses the malware domain before the connection is made. DoH takes the lookup off your resolver and hands it to one you never chose, and every control you hung off that resolver goes with it.

This is not an argument against encrypting DNS. Encrypted DNS is right, and the last section of this post is how to run it. It is an argument about who gets to choose the resolver, because that choice is the whole game, and DoH was designed to take it away from you and give it to the browser, the app and, if you are not careful, the attacker.

What DoH Actually Is

Strip the branding off and DoH is a normal web request that happens to carry a DNS question.

Ordinary DNS is a small binary message sent over UDP or TCP to port 53. DoH puts that same message, or a JSON version of it, inside an HTTPS request to a web server that speaks the protocol; the reply is an HTTPS response¹. That is the entire idea.

RFC 8484 standardised it in October 2018, and the intent was never hidden. The point, its own introduction says, is “allowing web applications to access DNS information via existing browser APIs”¹.

Existing browser APIs. A web page. Nobody found that as an awkward side effect years later. It sits in the first paragraph of the standard, written down as the goal.

Here is a lookup done the DoH way, from a command line, against a public resolver, asking for example.com:

$ curl -s -H 'accept: application/dns-json' \
    'https://cloudflare-dns.com/dns-query?name=example.com&type=A'
{"Status":0,"TC":false,"RD":true,"RA":true,"AD":true,"CD":false,
 "Question":[{"name":"example.com","type":1}],
 "Answer":[{"name":"example.com","type":1,"TTL":146,
            "data":"23.192.228.80"}]}

No special client. No port but 443. A single HTTPS request, the same shape as fetching a web page, and a name resolved by a machine on the other side of the world that has never heard of your network or your rules. Google runs the same endpoint, so does Quad9, so do dozens of others.

Now look at what your firewall sees. A TLS connection to a web server on 443, which it cannot read inside because that is the point of TLS, and cannot tell from the hundreds of others opening every second to content delivery networks and analytics and adverts. The DNS question is gone. It left the building dressed as web traffic and nobody at the door could see its face.

There are three ways a client can move a DNS lookup, and it is worth laying them side by side, because the difference is the whole post.

Plain DNS is readable and blockable, and that is exactly why it was easy to control and easy to spy on. DoT encrypts the lookup but keeps its own port, so you can still refuse it at the border. DoH is the one with no handle on it: encrypted like DoT, but sharing the one port you can never close, so the only lever left is which resolver the client chose, and that is the lever this post is about.

Who Gets To Pick The Resolver

The reason this matters is that a modern machine has five different things on it that can each decide where DNS goes, and you control exactly one of them by default.

The operating system asks the resolver your network handed out over DHCP or router advertisements. That one is yours, and it is the model everything older than about 2019 assumed: one resolver, handed out by the network, which is why network-level DNS controls worked for thirty years.

The browser broke it. Firefox and Chrome both ship the machinery to do their own DoH, to a resolver their vendor picked, over your head, standing down only when they spot a managed network. And an application can carry its own DoH client and a hardcoded resolver in its code, decided at build time; it does not read your DHCP or ask. Plenty of legitimate software already does.

A script on a web page is the one that should stop you, because it needs nothing installed at all. That curl command above is a single HTTPS request, and a browser makes HTTPS requests for a living. A few lines of JavaScript on any page a user opens can send lookups to a public DoH endpoint, because the big providers deliberately allow cross-origin requests so web apps can use them, the stated purpose in RFC 8484. The page you are reading could resolve names through a resolver in another country right now and you would see one more HTTPS connection.

And malware picks its own resolver for the obvious reason: it does not want you to see where it is calling. It carries the resolver in its code, often reaching it by address so there is no bootstrap lookup to catch, and needs your permission for none of it.

Read that column again. The bottom three need no administrator rights, no setting changed, and nothing that shows in the operating system. The control you spent years building, one resolver, one blocklist, one log, assumed the top row was the only row. It has not been for years.

The Same Trick The Browser Vendors Feared

The web-page case is neither theoretical nor recent. It is how protocol helpers get abused: a web page emits bytes, something downstream acts on them, and cannot tell they came from an attacker’s page rather than a real client, because on the wire they are identical. With DoH the downstream piece is a public resolver, which answers with no way to know the JavaScript asking came from a phishing page, and your resolver, the one with the blocklist and the log, was never in the path to have an opinion. Not a hole punched through your controls, but a road built around them, paved in the same encryption you tell everyone to use.

It Is Already The Malware Author’s Channel

You do not have to imagine how this gets used. It has been documented for years, by named researchers, on real samples, and the direction of travel is one way only: from a criminal bot in 2019 to a state intelligence tool the year after, and busier every year since, with fresh backdoors still landing in 2026.

Godlua, the first widely reported case, was a Linux and Windows backdoor whose write-up records it “uses DNS over HTTPS to get the C2 name to ensure secure communication between the bots, the Web Server and the C2”². On a network watching port 53, resolving your command server is a gift to the defender. Over DoH there is nowt to watch.

Proofpoint’s line on PsiXBot is the one worth quoting, a threat-intelligence vendor saying the quiet bit out loud. Using DoH for command and control, they wrote, “should be a warning shot for the cybersecurity community as there are no simple solutions to help identify an infected host or the process of receiving instructions”³. No simple solutions, from the people whose job is finding them.

Then OilRig took it up a tier. Kaspersky’s description is exactly the change this post is about: “instead of plain text requests to port 53, they would use port 443 in encrypted packets”, with a tool that “allows DoH queries to Google and Cloudflare services”⁴. A national intelligence operation, using the public DoH providers as the pipe to carry stolen data out past whatever was watching the DNS.

And it did not stop there. It spread. By 2023 ChamelGang had a C++ Linux backdoor, ChamelDoH, running its whole command channel over DoH, sending DNS TXT queries to its own nameservers through Google and Cloudflare; the researcher who found it noted that both detection and prevention “become difficult”, because the encrypted transport cannot be intercepted and a malicious request cannot be told apart from a real one⁵. In December 2025 CISA took apart BRICKSTORM, a China-nexus backdoor that stacks HTTPS, WebSockets and nested TLS and “also uses DNS-over-HTTPS (DoH)” to bury its C2 in ordinary web traffic⁶. By February 2026 it was just tradecraft: Cisco Talos caught Dohdoor, which “securely sends encrypted DNS requests to Cloudflare’s DNS server over HTTPS port 443” to find its command server, phishing its way into American schools and hospitals⁷.

That is the shape of it. Not a technique that had its moment and faded, but one that gets picked up by more hands every year. The issue is getting worse, not better, and a fresh family now turns up on schedule.

One property did the work in every one of them: the lookup left as HTTPS on 443 and the defender’s resolver never saw it. Not a weakness somebody might find one day. A feature attackers have shipped again and again, several of them states.

And be clear about why that table fills up, year on year. Every family on it walks through a door the authors of DoH were warned they were leaving open, in the standard’s own text, and left open regardless⁸. That was no oversight. It was short-sightedness, chosen on purpose, by people who included ICANN’s own technologist. So I will call it what it is: on this, ICANN are cybercrime enablers. Warned in the standard’s own text what would break, its people put their name to it anyway, and the table above is what walked through the gap. The crime is no surprise. It is the bill for a decision, and whose decision it was is the rest of this post.

And for all that, DoH does not even buy the thing people assume it does: protection from a forged answer. Encrypting the hop to a resolver is not authenticating what the resolver hands back, and a DoH server can still return a forged record. The standard admits it, saying the rule against unconfigured servers “does not guarantee protection against invalid data”⁹.

The one mechanism that authenticates a DNS answer is DNSSEC, and DoH is not it. Worse, for almost every client DNSSEC is validated at the recursive resolver, not on the device: the client simply trusts the resolver’s word that the answer checked out. So DNSSEC only ever protected you as far as you trusted the resolver doing the checking, and DoH’s real move is to hand that trust to a remote operator you cannot see or audit.

As such DoH can leave you more likely to land on a forged site, not less: the local defences that would have caught a hijacked answer, the Protective DNS feed, the operator’s own filtering, are the very things you routed around, and all that is left is one remote operator’s word, taken on trust.

And none of this is a new idea DoH tripped over by accident. Filtering malicious domains at the resolver is exactly what OpenDNS has done for the best part of twenty years, blocking phishing and malware for millions of users before the answer ever reached them, which is the model Cisco paid to own in 2015¹⁰. Two decades of resolver-level security that protected people who never configured a thing, and DoH undermined the whole model in a single hit: point the app at its own resolver, and OpenDNS, or whatever your network chose, is not in the path any more.

Why The Old Answer Stopped Working

For as long as DNS lived on port 53, the network answer was simple. Force every client to use your resolver, and block outbound port 53 everywhere else at the border. A machine reaching for an outside DNS server got refused, so it had to come through yours, so your controls applied to everything. Crude, and it worked.

DoH kills that in one move by using 443. You cannot block outbound 443. It is the web. So the port you would close to force DNS through your resolver is the one you can never close, and the encryption that stops your ISP snooping also stops you telling a DoH lookup from a page load.

The two things you would use to regain control, close the port and read the traffic, are both gone by design. Defeating exactly those two, in the hands of a hostile network, is what DoH was built to do.

And reading the traffic is not the escape it sounds like, because there is only one way to do it: break and inspect all of it. To see the DNS inside a 443 connection you have to man-in-the-middle every HTTPS connection on the network, put your own root certificate on every device, and decrypt and re-encrypt the lot. That is what a growing number of admins now resort to, to claw back the visibility a single firewall rule used to give them for nowt.

And it is a far worse trade: you have weakened TLS for everything, put a decryption box in the path of every login and every bank session, and built one target that compromises all of it, a posture US-CERT warned against outright¹¹. The proportionate control was broken, so the disproportionate one is what is left.

Which is the bind. The mechanism that shields a journalist on airport WiFi from a hostile network is the one that shields malware on your network from you, and the protocol cannot tell the two apart. A resolver being bypassed does not know whether it is a censor or a security team. It only knows it has been cut out.

The Correct Answer Was Always DNS Over TLS

Here is the part that gives the game away. Encrypting DNS never needed any of this. It was done two years before DoH, in a way that left the person running the network able to do their job.

DNS over TLS, RFC 7858, is from May 2016. Its abstract says what it is for in the first line: to “provide privacy for DNS”, encryption that “eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network”¹². That is the whole privacy case, met: the coffee shop and the ISP shut out exactly as they are with DoH, because the lookup is encrypted end to end.

And it was co-authored by Paul Hoffman, who then co-authored the DoH standard too¹. Not two rival camps, then. The same people, who had already solved privacy, solving it again a different way.

Who Hoffman is matters, because it says where this came from. He is no bystander in DNS: his name is on more than eighty RFCs, the DNS terminology standard among them, and he does the work as a technologist at ICANN¹³. So the standard that hid DNS on 443 was co-written from inside ICANN, the American body that decides what goes in the root.

And ICANN is not the disinterested steward the word implies. I have set its record out separately: built in California, answerable to California, and willing to use its position over the namespace for its own ends. This was no privacy campaign from the edge. It was the establishment that holds the root, meeting a privacy case it had already met in 2016 a second time, in a way that removed the network operator.

So ask what the second way added, because privacy was not it.

The only box that changed is the last one. DoT runs on its own port, 853, so the operator can see that it is DNS and decide what happens to it: allow it to the sanctioned resolver, refuse it elsewhere. DoH puts the same encrypted lookup on 443 and mixes it into the web, where the operator cannot pick it out.

Same privacy, same encryption. The single difference between the two standards is whether the person running the network can still see their own DNS. That is not a privacy feature. Privacy shipped in 2016. It is a bypass feature, and it is the only thing DoH adds.

And they knew it. This is documented, not inferred. RFC 8484’s own Operational Considerations say it plainly: “Filtering or inspection systems that rely on unsecured transport of DNS will not function in a DNS over HTTPS environment due to the confidentiality and integrity protection provided by TLS”⁸.

Those systems are the security tools already protecting users: malware and command-server blocking, Protective DNS feeds, child-safety filters, enterprise inspection. The standard names them, in its own text, as the things that stop working. Breaking tooling that was already defending people was a choice, taken with eyes open and shipped on by default. Knowing the effect and choosing it anyway is a decision they can be asked to account for.

Which is why the privacy framing does not survive the timeline. Once DoT exists, privacy cannot be the reason for DoH, because privacy was already done, by the same author, two years earlier. So privacy was the smokescreen.

Pull it away and look at what the second standard actually set running: an arms race. It took a control that was one firewall line and turned it into a permanent chase, resolvers against blocklists against fresh resolvers, the operator losing by default, and a handful of US firms holding the plaintext at the end of it.

Call that a side effect of a privacy feature if you like. On the evidence, with DoT already shipped and the standard itself admitting it would break filtering, it is the point, and privacy was the word painted on the box. And it was pushed hard under that word, by the parties who gained.

The people selling it as privacy were the browser vendors, and the beneficiaries were not only the users.

Can I ask why, if the aim was privacy, the answer was not the encrypted-DNS standard that already existed and kept the operator in the loop, but a second one built so the operator could not see it? I am not asking who signed it off. I am asking what part of “privacy” required cutting out the one person accountable for the network.

Because that is the real target, and it is the network administrator: the professional responsible for the security and the safety of the network, treated as the adversary by default. DoH does not even remove the surveillance the privacy pitch complained about. As Bert Hubert of PowerDNS set out, DNS was “typically provided by the operator of a network”, and moving it to a third party by default is “a net-negative for privacy for everyone”, because that third party “gets a complete log per device of all DNS queries, in a way that can even be tracked across IP addresses”¹⁴.

The lookups are not hidden. They are handed to a US resolver operator instead of the admin, and the admin is the only party removed. The vendors know it, too. The “detect a managed network and stand down” logic in the next section exists precisely because the default overrides the admin, and they shipped the off-switch rather than change the default.

Now ask who gains from routing DNS past the operator. The poster child is the journalist on hostile airport WiFi, and that person is real. So is the advertising and tracking industry, whose domains walk past a network’s blocklist the moment an app or a browser resolves them over DoH.

Network-level blocking, the Pi-hole, the corporate blocklist, the filtering resolver, works by answering a tracker’s name with nothing. DoH is how the name gets answered anyway. And the largest operator of a public DoH resolver is Google¹⁵, an advertising company that also ships DoH in its own browser¹⁶.

A privacy feature, sold by the firm that sells the tracking, whose design defeats the tool people run to block it. Make of that what you will. I have made my mind up.

Even the crude version of this objection got aired. In July 2019 the UK ISP trade body nominated Mozilla an “Internet Villain” for DoH that would “bypass UK filtering obligations and parental controls, undermining internet safety standards in the UK”¹⁷. They picked a clumsy target and a worse frame, got shouted down, and withdrew it.

Strip the politics off, though, and the observation underneath was correct, and it holds whether the control being bypassed is a child-safety filter, a company blocklist or a Pi-hole in a spare room. DoH is built to get DNS past whoever runs the network.

And it is not a small matter, because DoH is now the hardest of the three to block at all. DoT sits on 853, where a network can still refuse it. DoH does not, so of every way DNS can leave a network it is the one with no handle on it, which makes it the biggest single risk of the lot.

That reaches the law, not just security. In the UK the blocking that carries legal weight is run at the ISP by DNS: the Internet Watch Foundation’s list of child sexual abuse material, and the copyright injunctions the High Court hands down under section 97A, are enforced through DNS and IP filtering on the resolver a customer is handed¹⁸.

Route the DNS half around that over DoH and the block does not apply to that client. A court can order a site blocked, a network can be told to enforce it, and a browser resolving over DoH finds the address anyway, over a channel the network cannot see and cannot close. Enforcing a cyber law or a court order at the network level, which is where it has always been done, becomes very close to impossible.

And this is where the bill lands on everyone, not just the network. Break the proportionate control, the surgical one that blocked a named domain at the resolver under a court order, and the state does not give up. It reaches for a blunter instrument. The UK’s Online Safety Act is that instrument: sweeping duties on platforms, mandated age checks, and Ofcom behind them with the fines, a regime that touches every user and every service in the country¹⁹.

I am not defending the Act. I am pointing at where the pressure for it came from. When the narrow tool that enforced the law at the network stops working, you do not get less enforcement, you get cruder, broader, more intrusive enforcement aimed at everyone, because the aimed version no longer holds. That is the price of breaking a basic control, and the people who broke it are not the ones paying it.

And ICANN could not care less, because from California it is not their problem. When a block fails or a platform breaches its duties, it is not ICANN that gets held up in court, it is the operator, the platform, the company, facing Ofcom and the fines. The fallout lands on everyone downstream of a decision the body that took it never has to answer for.

Line the consequences up and they are all the same shape: a thing the network used to enforce at the resolver, and no longer can.

DoT was the honest answer. It encrypts your DNS and leaves the operator able to do their job. DoH kept the encryption and added one thing on top: the operator can no longer see it. Everything else about it is downstream of that one choice.

Made In The US, Fought Over Everywhere Else

None of this stops at the English Channel, and reading it as a British problem shrinks it to a fraction of its size. The same shape runs right across Europe and out to Australia. A legal instrument in at one end, a DNS block on the network at the other.

Australia has its Federal Court order the ISPs to disable access to overseas infringing sites under section 115A of the Copyright Act²⁰. Portugal skips the court entirely: an administrative memorandum under which rights holders notify a body called MAPINET, and the ISPs block by DNS inside fifteen working days²¹. Different statutes, one load-bearing assumption, and it is the assumption DoH kicks out from under all of them. That the client resolves through the resolver it was handed.

So watch what a state does when that assumption fails. It stops leaning on the ISP and starts ordering the public resolvers themselves to return the wrong answer. That is not a forecast. It is a stack of judgments, and it is getting taller.

Read that as one thing, not five. A few US companies rewrote DNS for the whole planet on their own authority, broke the proportionate control every one of these countries had built, and left the courts to work out what to do with the wreckage. The answers those firms give, hauled in front of a different bench every few months, tell you exactly what the rest of the world weighs with them. One appeals and cries censorship. One fails the lookup and tells the user nothing. And OpenDNS, the resolver that quietly filtered malware for twenty years and that this post has already held up as the model to copy, does not argue at all. It switches itself off for France and for Portugal rather than serve them on those terms²⁶.

Sit with that last one. It is the good example in this whole piece walking out of the room. The service that protected people who never configured a thing now finds a whole country easier to abandon than to serve, and the reason traces straight back to a design decision taken in California by people who never had to think about a French court or a Portuguese one.

That is the pattern, and I will name it. This is what US platform engineering does to everywhere that is not the United States. It builds for its own market, ships the result to the world as the default, and treats every other country’s law, every regulator, every community left downstream of the change as somebody else’s mess to clear up.

And the home government backs the firms to the hilt. In February 2025 the White House put its name to a memorandum casting other countries’ digital laws as “overseas extortion” of American companies, naming the UK and the EU and pointing the trade representative at tariffs by way of reply²⁷. Six months on, a US regulator wrote to a dozen American tech firms warning that obeying the UK’s Online Safety Act or the EU’s Digital Services Act might itself break US law²⁸. Read that twice. The country whose companies broke the controls now tells those companies that complying with another democracy’s answer to the breakage is the offence.

That says all of it. A law passed by an elected parliament in Westminster or Brussels is recast, from Washington, as an attack on America, and the firms are told to ignore it. It is not that they weighed the rest of the world and chose against it. The rest of the world was never on the scale.

The Fix Is Not To Ban Encryption

So the lazy conclusion is “block DoH”, and it is wrong, the same way “block ICMP” is wrong on the firewall. You do not want unencrypted DNS back. Clear-text lookups on port 53 are a real exposure and going back to them to regain visibility is trading one hole for another.

The thing you actually lost was not the encryption. It was the choice of resolver. So take that back and leave the encryption exactly where it is.

The shape is the same one that fixes the DNS in an Active Directory domain: the argument is never “turn the feature off”, it is “decide who is allowed to drive it”. Here is what that means in parts.

Run encrypted DNS yourself. Stand up a resolver that serves DoH and DoT, not just port 53, so a client that wants encryption gets it from you. You cannot tell clients “no DoH” and mean it while offering no encrypted resolver of their own. Give them one, and keep the blocklist, the threat feed and the logging on it as before.

Advertise it, so clients find it on purpose. Discovery of Designated Resolvers (RFC 9462) lets a client query a special name, learn its network’s own encrypted resolver, and upgrade to DoH or DoT against that automatically²⁹. A DDR-aware client then encrypts its DNS and uses yours: the privacy the user wanted and the control you needed, in one move.

Answer the browser’s own off-switch. Firefox checks a canary domain, use-application-dns.net, before turning DoH on by default: answer it with NXDOMAIN or SERVFAIL and Firefox stands down to the system resolver³⁰. Two honest limits, both in Mozilla’s words. The canary “only applies to users who have DoH enabled as the default option. It does not apply for users who have made the choice to turn on DoH by themselves”³⁰. So it is a default-off signal, not a lock, and it does nothing on the app and the malware, which never asked the browser anything.

Set the browser policy where you manage the machine. On a device you own, do not rely on the canary. Chrome’s DnsOverHttpsMode takes off, automatic and secure, and Google’s docs state that where it is unset, “for managed devices DNS-over-HTTPS queries will not be sent”³¹; Chrome disables its own auto-DoH the moment it sees an enterprise policy¹⁶. Point it at your resolver, or set it off and let DDR carry the encryption. Firefox has the matching Enabled, ProviderURL and Locked knobs³². Managed machine, managed decision, and the row you can actually close.

Refuse the alternatives at the border. The rules are short, and they all say the same thing: DNS of any kind, to the outside, only from your resolver.

You will not catch every DoH endpoint by address, and you cannot, because a new one is just a web server and there is no end of web servers. So sit with what that block now costs. To do for DoH what block 53 outbound did for free, you pull a list of DoH server addresses that somebody else keeps scanning for you: the maintained blocklists exist because this is the only way left, and one of them re-resolves every known public DoH domain to its current IPs every hour, by scheduled job, and ships the changes³³. That is the trade the bypass forced.

A control that was one static line is now a subscription to a moving target, chasing web servers that anyone can stand up faster than a list can name them. Protective DNS closes the other end: point your resolver’s upstream at a filtering service like the NCSC’s PDNS, which “was built to hamper the use of DNS for malware distribution and operation”³⁴, and the bad domains are refused before the connection is made, for every client that comes through your resolver, which, once these rules are in place, is all of them.

Put those against the five rows from earlier, and every one of them has a control that closes it. That is the test of a fix: not “did we block DoH”, but “for each thing that can choose a resolver, what stops it choosing the wrong one”.

None of that turns a single bit of encryption off. Clients still get DoH, they just get it from you, and the ones that try to get it from somewhere else hit a wall. The privacy is intact and the control is back. As such, the only thing anyone lost is the freedom to pick a resolver you never approved, and that was never theirs to have on a network you are responsible for.

Can I Ask What Chose That Resolver

Here is the question to put to anyone who tells you the network is fine as it is.

When a machine on your network resolves a name, what decided which resolver answered? If the honest answer is “whatever the OS was handed”, good, but only if you have closed the other four rows of that table, because otherwise it is “whatever the OS was handed, unless the browser, an app, a web page or something nastier chose different, in which case I have no idea and no record”. That is not a DNS setup. That is a hope, and hope catches nowt.

I am not asking who runs the resolver. I am asking what, on each machine, gets to choose it, and whether you could name the resolver every lookup went to yesterday. On a network where DoH is unmanaged you cannot, and the gap is every app that bundles its own resolver, every page a user opens, and every piece of malware that read the same research I just linked. Three named threat actors built their channels on this exact gap, and one answers to a government.

A protocol that takes the choice of resolver away from the network was always going to be a gift to whoever the network was trying to watch, and pretending otherwise because the marketing said “privacy” is how a control that mattered gets switched off by default and nobody logs the day it happened.

Encrypt your DNS. Run the resolver yourself. Advertise it, answer the canary, set the policy, close the border. Keep the encryption and keep the choice. You can have both, and if you run networks for a living, having both is the job.

Privacy Was The Word On The Box

So credit where it is due. Thanks to ICANN, the American body that holds the root and co-wrote this from the inside, for running the US tech playbook one more time: take a problem that was already solved, wrap the fix in a virtuous word, and centralise the result onto a handful of US firms who end up holding the plaintext.

And it is always the US. The body that holds the root, the resolver two browsers now default to, the advertising firm running the biggest public one, the country the plaintext lands in: American, every time. It is a pattern, not a run of bad luck.

Privacy was the smokescreen. DNS was encrypted, private and still governable on port 853 in 2016, and everyone who mattered knew it. What the establishment shipped on top was a protocol built to blind the one person accountable for the network, a permanent arms race of blocklists rescanned by the hour, and court orders that stop dead at the browser.

Whether that was ineptitude or greed I will let you decide, though the record I linked points one way. Either way it beat common sense.

And decisions like this one are why the calls to take the root off ICANN keep coming back, and why they land: so the international community gets a say, instead of one country’s institution deciding the DNS for everyone else and calling it stewardship.

We used to do all of this with one line.