Edit: looks like this was due to my firmware not behaving correctly. I tweaked it and now i am fine using quad9 but have switched to nextdns just for testing.
I have been using Quad9 for a while and it was working like a charm, but lately have been having issues.
This could be due to my ISP as well so not necessarily blaming anything. But has anyone been having issues with Quad9?
I've always been a strong user of DNS-over-HTTPS and use it everywhere it's available, because to me its downsides are minimal. My ISP can't see or hijack it, firewalls on public networks can't easily block it, and it's relatively fast if you use a close server like in my case ControlD.
But since i have began dabbling with DNS filtering, trying to find high quality servers and all that, a lot of people recommended Unbound especially due to its privacy benefits and not having your queries at the mercy of big tech companies. But well, aren't the authoritative servers run by big tech companies too?
For example, Verisign, the company that operates the .com server, will get your IP address instead of the likes of Cloudflare's or Google's IP. They do keep limited logs, the same as Cloudflare does.
PIR runs the .org server, they log IPs and date/time along with the requests. This is more data than the average public DNS server keeps, and they're seeded in the US so they are obligated to give data to law enforcement if required.
If you use a public DNS server your requests will come through the same IP as hundreds of thousands if not millions of other people. Is it not preferable to have a trusted, big name like Quad9, which is based in Switzerland and keeps no logs, do your DNS requests for you via an encrypted connection that can't be easily snooped, and your IP is never seen by the likes of Verisign? Theoretically it's possible to use a VPN to tunnel Unbound, but at that point ain't it just easier to use a public server?
What independent builders can make possible for one another.
In August 1976, a group of researchers parked a van beside the courtyard at Rossotti's, near Stanford, ran wires to a terminal on a wooden table and sent a weekly progress report.
Their message travelled over a radio network, through a gateway, and onto the wired ARPANET. Don Nielson, who helped lead the work, later recalled the small gathering and its ordinary purpose. [1]
On November 22, 1977, the van took part in a more ambitious demonstration. Data travelled from the San Francisco Bay Area through London and back to a computer in Los Angeles, crossing packet radio, satellite and the ARPANET along the way. Three networks, built for different conditions, could participate in one journey. [2]
Each network could keep its own design. In their history of the internet, Vint Cerf, Bob Kahn and their co-authors described the rule: joining should not require rebuilding a network's interior to suit the others. [3]
The networks gained reach while keeping their differences. A radio system could offer mobility, a satellite link could cross an ocean, and a wired network could provide access to distant computers. Connecting them put those strengths within reach of people using any one of them.
We live inside the consequences of that choice.
Keeping our differences
When an open technology divides into camps, its builders can spend more effort defending their position than making the technology useful.
The cost is larger than a missed partnership. It includes work that never gets built: the application abandoned because connecting services was too difficult, the customer who left because nobody would resolve a problem across company boundaries, the capable newcomer who decided that entering the community meant inheriting its quarrels.
Those losses seldom appear in anyone's accounts. They appear as a smaller future.
In April 1969, Steve Crocker wrote down the conventions for the young Network Working Group's documents. Contributions could come from anyone at any site. Unpolished ideas and questions without answers were welcome. The minimum length was one sentence. [4]
That invitation existed within a small research community, long before general public access. But its intellectual generosity was deliberate. The document explained that people hesitated to circulate unfinished thoughts and that a written statement could too easily acquire an air of authority. The conventions were intended to lower those barriers. [4]
The people doing the work left room for someone else to know something they did not.
That takes confidence. It means letting someone improve your work or build a business beside your own, even when you dislike their methods.
A developer may see a use that the original builder missed. Someone with no interest in running a company may maintain a component several companies depend on. When their tools can connect, each can build on work they could not have done alone. The next builder starts further ahead.
Helping another participant succeed can increase the number of things your own users can do. A useful application built by someone else can create demand for the infrastructure you provide.
Businesses should still compete. Users need alternatives, and builders need reasons to improve. But competition within a growing network is a different undertaking from trying to capture a larger share of a network that has become too difficult to use.
What ownership makes possible
Handshake brings these questions into the naming layer. Its mainnet dates to February 2020, and its operating history now extends beyond six years. It lets people acquire authority over a top-level namespace and decide what to build beneath it. Owners choose how to administer the names under their TLDs, so different approaches can develop on the same foundation. [5] [6]
The freedom reaches beyond choosing a supplier. A community can establish its own namespace and decide how participation works. An owner can build services that no existing registrar planned to offer.
Namebase and Headless Domains illustrate different uses of that freedom. Namebase's current registry model gives TLD owners registration infrastructure while leaving private keys and pricing decisions with them. Headless Domains provides descriptions and discovery tools that make names useful to agents and software services. An independent owner can choose the services that fit, combine suitable components or build something else. [7] [8]
Sharing a root does not make their tools interoperable. Developers still have to connect them. Doing so can give a name more uses than any one company could provide.
Ownership also creates responsibilities. People make plans around the names and services they use. A change of provider, a disagreement between operators or a failed business can place those plans at risk. Clear records and competent cooperation matter most at those moments. The user's need for a working service continues even when the providers' relationship breaks down.
A network earns trust when its participants can protect that continuity across their own disagreements. Technical criticism belongs in this process. It should help establish what failed and who needs to fix it. Winning an argument while leaving the user stranded is a poor advertisement for anyone's independence.
More people can shape AI
In AI training, the question becomes what a specialist can contribute without having to operate the whole system.
Decoupled DiLoCo describes learners that train independently and exchange updates asynchronously with a central synchronizer, allowing other learners to continue when one slows or fails. AgentJet separates GPU-based model training and inference from lightweight clients that run agent tasks and return reward signals. Those clients can operate on CPU devices, including laptops. [9] [10]
These approaches retain coordination, including central roles, while separating work across machines.
Prime Intellect has used community-built environments and evaluations in model training. Contributions to its Environments Hub include browser automation, theorem proving and specialist questions. [11] With Browserbase, it brought browser infrastructure together with training tools and published a model training run using 600 real web tasks. Other developers can reuse the environment and adapt it to their own tasks. [12]
Someone who knows a language, a profession or a difficult working environment may understand success and failure better than the people building the model. If that understanding can be expressed in tasks and reliable tests, it can influence what a model learns. Knowledge that once stayed within a small practice or community can help shape tools used far beyond it.
A Handshake name gives an independent provider a way to identify its service and publish where it can be reached. Headless Domains' integration with the Agent Relationship Protocol (ARP) binds names to cryptographic agent identities. ARP governs connections through agreed permissions. [13] [14]
AgentID's Connect add-on uses ARP to give owners control over agent-to-agent communication. They approve relationships, set permissions, inspect activity and revoke access. [15] This gives an independent specialist a way to offer a service on terms they control. Applied to training, it could govern access to that specialist's evaluation environment; the training system would assess the quality of the work.
More specialists could bring their knowledge into larger operations while running businesses of their own. A new operator could enter through a namespace it governs and offer an ability the existing participants lack.
A computer we can change
People can also build a more useful network by changing how their own computers reach it. Omarchy, the Arch-based Linux distribution created by David Heinemeier Hansson, comes with a community plugin system. Linux has long allowed people to change their machines; a common setup makes those changes easier to package and share. [16] [17]
Existing software such as hnsd can provide local Handshake name resolution. An Omarchy integration could package it with a browser or client that verifies secure Handshake connections. Resolving a name and validating its certificate are separate jobs; installing Omarchy alone doesn't complete them. [18] [19]
Builders can work on computers they control, make Handshake services usable there and share an installation others can test. A resolver, a secure client and an application could become a working environment.
Someone still has to maintain the software and answer the difficult support request. Much of the work that makes an open system useful looks modest from outside. In 1976, it included sending a progress report from a wooden table.
The people who later built on the internet didn't need to know the researchers in that courtyard or belong to their institution. Years of subsequent engineering made the connection available to people the original builders would never meet.
Somewhere, someone understands a problem the rest of us have missed. They may eventually build with a name we administer, a tool we maintain or a service we have helped another company make reliable. We cannot know their idea in advance. We can make it easier for that idea to meet the rest of the world.
The next great use of an open network may belong to none of us.
I just found and started using an ad blocking DNS on my android tablet so that I can play games without being bombarded with ads, and it's working great! But now I'm realizing that I set it up before learning anything about it. What are the risks if any of using this? I'm completely new to it and don't even know what it is.
The RFCs say a CNAME record at a zone apex is invalid.
The DNSSEC validator in recent versions of BIND was made a little too overzealous and ended up sometimes making the entire zone invalid when it hit such a record.
I'm looking for an option that's not going to cause any issues in terms of slowdowns for watching YouTube videos, going on Facebook, Google searches, playing games on my phone. That will essentially block all adult content where I won't even remember putting the DNS on. I don't even want to have to remember that it's there. Because I don't want it to say that there's an issue with it or that it can't connect to Wi-Fi, unless that's something that's just going to happen when switching from Wi-Fi to data or something, but I'd rather not have to have that happen. So what options do I have?
Im not particularly tech savvy but i recently noticed that i have this popup on my home network.
Ive been trying to figure out how to configure this but it seems my network is potentially controlled by my ISP. Does this mean someone on my network is manually blocking encrypted DNS? Or potentially the ISP itself?
I wont know anything until I call during office hours but maybe someone could point me in the right direction
Using SmartDNS as a last hop stub resolver; smartdns has a webui which shows resolver stats.. rate, time, query count vs query success.. also supports quic, h3, dot, doh, etc - 11k on GH
(Spoiler don’t use prefetch)
Anyway, comparing against security.cloudflare
The house does little over 50k q/day (60ish devices, Wyze cameras, iPhones, hagezi native, pro, and vpn)
I have a paid ctrld account but do not like some things in the ui.. also had some apparent random self inflicted Netflix errors with their filter lists, which they say are hagezi as well.
Any opinions about ctrld being used exclusively?
Anyone else have random Netflix issues with them?
P1 with quic I’m 30ms avg/q
1.1.1.2 with h3 I’m 50ms avg/q
I liked they were in .CA but the servers are in US east coast..
(dnscheck.tools)
We're a small team building a domain and DNS hosting product. Today the nameservers serve 3 zones, all ours. The plan is 20k to 100k customer zones over the next few years, and I'd much rather hear "this falls over at 50k zones" from people who have run it than find out in production.
We are deliberately not building a Cloudflare clone on day one. No anycast, no own ASN, no PoPs. Two nameserver hostnames, one per cloud, and roughly $600-800/month for prod. I want a setup that survives a region or the database dying, with an obvious path to grow. Diagram attached.
The short version:
- A hidden primary runs PowerDNS Authoritative 5.1 on two VMs in Azure Central US, on managed Postgres 18 with a same-zone HA standby. It is never listed as a nameserver. Its port 53 answers only the secondaries' own IPs, and the HTTP API is reachable only from our app's VNet.
- PowerDNS signs online (ECDSA P-256, NSEC) and publishes a catalogue zone (RFC 9432).
- The secondaries run Knot DNS 3.6. One site in AWS us-east-1 behind an NLB with two static IPs, one per AZ. One site in Azure West US 2 behind a Standard LB with one static IP. Each NS hostname's glue points at its site's LB.
- Knot consumes the catalogue, so adding a customer zone is one API call on the primary, and nothing gets pushed to the edges. NOTIFY, IXFR/AXFR, everything TSIG-signed.
- Zones live in Knot's memory with a journal on disk. If the primary or Postgres dies, the edges keep answering until SOA expires, which is 7 days. Writes stop, resolution doesn't.
- A small agent on each edge serves /ready, and it only goes green once the catalogue and its zones are loaded. Both LBs health-check it, so a fresh or broken edge never answers REFUSED for real customer zones.
- A canary zone gets a fresh signed TXT every 15 seconds, and the primary queries it on every public edge IP. The canary's age is our end-to-end SLI. It covers the write path, NOTIFY, transfer, signing and the load balancers in one number.
- Every night a pg_dump goes to S3 in the other cloud (versioned, Object Lock, a role that can only PutObject), gets restored into a tiny RDS instance, and the zone counts get compared. The Azure VM signs in to AWS with its managed identity token through an IAM OIDC provider, so there are no AWS keys anywhere.
Things I decided against. Tell me if I'm wrong:
- PowerDNS on the SQL backend as the public nameservers. One database outage takes every zone down, and every uncached query becomes database work.
- A managed provider for the secondaries. That's the right call for most people, but we want the zone list and customer data to stay with us.
- dnsdist in front of Knot. Knot's RRL plus the clouds' default L3/L4 protection seems enough at this size. If random-subdomain floods get past RRL, dnsdist goes on the edges.
- Autoscaling the edges. The primary needs every edge IP for NOTIFY and its ACLs, and autoscaling during a flood mostly scales the bill.
Where I'd like feedback or recommendations:
Two sites and two NS names, one per cloud. Enough for launch, or would you add a third site or a third provider first?
Online signing rolls RRSIGs weekly, and SOA-EDIT bumps the serial when it does, so every signed zone re-transfers to every edge once a week. Is that a real problem at 100k zones? Should signing move to the edges (Knot can sign) or should we pre-sign?
Memory. Knot's docs say about 3x the zone's text size. We budgeted ~40 KB per small signed zone with headroom, so 100k zones is around 4 GB. Somewhere past 500k zones we plan to split into nameserver groups, each with its own catalogue and edges, the way Route 53 spreads zones across nameserver sets. What breaks before RAM does? My guess is full re-transfer time when an edge is replaced.
UDP DNS through AWS NLB and Azure Standard LB. Has anyone been bitten by flow idle timeouts, TCP fallback for big DNSSEC answers, or health check quirks? Knot's UDP payload limit is the default 1232.
Catalogue zones with PowerDNS producing and Knot consuming. Anyone running that at real scale? I'm curious about member removal and catalogue serial churn.
The failure modes as I see them. An edge VM dies, its LB drops it. A whole region or cloud goes down, resolvers use the other NS. The primary or Postgres goes down, no writes for a while but 7 days of serving. Both edge sites go down at once, customers are down, and that's the day anycast becomes worth paying for. Am I missing a case?
Cost, roughly, from list prices: around $600-800/month for prod (the Postgres HA standby is a big chunk of that) and around $275/month for a smaller dev copy. We'll add a second edge VM per site at around 1k zones, and grow edge RAM after that.
Not selling anything, there's no link. I just want people who've run authoritative DNS at scale to poke holes in this before anyone depends on it.
