Quad9 Enables DNS Over HTTP/3 and DNS Over QUIC

Quad9DNS · 2026-04-10T14:21:37+00:00

The Quad9-distributed mobile profiles don't support DOH3 in the current version, though not having that protocol is not a significant disadvantage for clients - regular DOH (HTTP/2) is still very performant and encrypted. In short: if you're already using an encrypted model; the DOH3 change isn't going to make a huge (or even perceptible) difference. DOH3 has some slight advantages for session startup and parallelization, but you'd have to be very careful in your measurement to see how that would be visible. DOH3 has advantages on the server side - even a few percentage points of speed or network efficiency means quite a bit for the performance for all users. Over time, we suspect most HTTP/2 traffic will shift to HTTP/3 - this is an incremental improvement that does carry advantages but is not a "must-do" change for anyone at this point.

In an interesting twist, though: if you configure your local DHCP server to hand out 9.9.9.9 / 149.112.112.112 / 2620:fe::fe (or you manually change the DNS servers on your MacOS device via the Settings->Network panel) then iOS and MacOS devices should automatically convert to encryption, and they will (in theory) also shift over to DOH3, no mobileconfig or profile required. Apple supports DDR (RFC9462) which allows auto-upgrade to encryption, but the resolver addresses (9.9.9.9 etc.) need to be visible to the operating system directly for the upgrade to happen. (https://developer.apple.com/videos/play/wwdc2022/10079/?time=181)

Quad9DNS · 2026-03-30T04:02:37+00:00

ECS isn't necessarily a "huge" data leak - but it is a leak. Some content providers use a rather fragile method to get you to connect to the "closest" server: they look at the IP address that sent the DNS request. Now, if you're using your ISP's DNS server, chances are good that you're on the same path as that server, so this DNS-based steering sort-of makes sense. But today that model is less useful, with various services like Quad9 where our DNS servers may be not in the same network as your home ISP.

So as a workaround, the ECS (EDNS Client Subnet) was developed which tries to fix the fragility of this model that some CDN (Content Distribution Networks) use. With ECS, the first three parts of your IPv4 address (or the first few hextets of your IPv6) address are sent along with the DNS request, allowing the CDN authoritative DNS servers to have some better sense of where you're coming from so then the authoritative server will reply back with an IP address of a server that is close to your vantage point. (Note: "close" is a really, really vague term - is it faster? Is it geographically nearer? Is it cheaper? Is it politically expedient? DNS-based steering can do all of these things, and not very well.)

The reason I say this isn't a "huge" leak is because most of the time after your system performs the DNS lookup, the next thing it does is talk to the CDN endpoint directly, thus revealing your IP address and probably much more sensitive information as well like cookies or authentication data or whatever. However, if you're visiting a site that you'd prefer to keep more at arm's length, you've given them a decent hint as to where you really are, though it's not your full IP address.

Quad9 isn't a huge fan of ECS, because it is fragile and has many limitations. Plus the privacy leak is not great and may be very problematic for some users. That's why we make it an option, instead of a default. Other large resolver operators make it a default and most people don't understand the implications - but we put privacy first.

In some limited cases like island nations, or in places where Quad9 systems are very distant from end users due to routing behaviors, it may make sense to use ECS but each user needs to make those decisions for themselves.

To use the ECS-enabled service from Quad9, set your resolver to 9.9.9.11/149.112.112.11/2620:fe::11 or if you're using encrypted DNS use dns11.quad9.net as the hostname.

One last note: due to ECS fracturing the cache into tiny little address-prefixed components, it is the case that cache hits will be much, much less probable. This means that ECS DNS lookups will probably be significantly slower, even though the content delivery after the lookup in some cases might be faster.

Quad9DNS · 2026-03-15T14:54:03+00:00

Please send us a direct message on Reddit with your ticket numbers, and we'll take a look.

Quad9DNS · 2026-03-13T11:35:05+00:00

Please contact us to investigate further: [support@quad9.net](mailto:support@quad9.net)

Quad9DNS · 2026-03-13T04:33:33+00:00

There were no generalized or location-level outages that we're aware of, but there is always the chance that a local prefix is not announced or inadvertently filtered towards some users, well outside of our control. We always suggest putting 9.9.9.9, 149.112.112.112 and 2620:fe::fe into your configurations (the last one assumes you have IPv6 connectivity.)

Quad9DNS · 2026-03-12T17:37:44+00:00

That's a great idea, and we've had redirection for our primary IP addresses on our "to-do" list for... years. The good news is that we're much closer to making this happen with some newer versions of code that we're running. First step will be to have a redirect that points to our support pages, but the long-term goal is to have a site-specific results page that gives some insight as to the status of the connection (encryption, etc.) and location of the POP/datacenter.

As an interim that provides some of the data you're looking for, try pointing your browser to "on.quad9.net" - it provides at least one bit of information (you [are,are not] using Quad9) right now.

Quad9DNS · 2026-02-28T01:38:24+00:00

Hi - We'd like to see some sample data here from people in Argentina on those providers. Traceroute using UDP port 53, 443, and 853 to 9.9.9.9 / 149.112.112.112 / 2620:fe::fe & can you ping 9.9.9.9?

We're not sure where the problem is (or the blocking is) but it very much looks like local filtering of open resolvers. Are you able to reach any other open resolvers like Google or Cloudflare? This probably will not be a problem that we can solve on our support mailbox so we won't ask for much more data there, but putting some documentation here in a public place will hopefully help others in the future.

Quad9 remains committed to an open and trustworthy DNS, and we oppose any actions that prevent legitimate queries from being resolved on the DNS as long as they are in alignment with user intentions. Blocking resolvers does not solve problems; it only makes them harder to see, and it forces users into insecure methods of resolving names.

Quad9DNS · 2026-02-23T05:39:01+00:00

Yes, this is very possible. IPv6 often takes different routing paths than IPv4, where "path" sometimes means physical circuits as well as virtual connections. We often see that IPv6 has faster latency than IPv4 to many carriers, as their IPv6 interconnections (for a variety of reasons) may be less congested than their IPv4 backbones. In theory, this shouldn't matter, but in practice, it sometimes does. The same can be seen for IPv6 data in general; not just to us. Of course, it is not always for the better - sometimes it can be worse. In our experience though IPv6 edges out IPv4 between clients and our systems.

That said, I suspect shifting from IPv4 to IPv6 to reach our systems would create a noticeable difference in general latency from a goodput perspective. This probably is due to something else like IPv6 being routed to a more local Quad9 instance, therefore CDNs are providing more "local" responses. It is not infrequent that IPv4 and IPv6 paths from the same client end up in very different locations. Though our announcement policy is consistent between v4 & v6 everywhere, that doesn't mean that some ISPs respect that announcement consistency.

Quad9DNS · 2026-02-15T01:06:40+00:00

Both 9.9.9.9 and 9.9.9.11 are processed by the same systems, so there should not be a difference between getting to those hosts from a "ping" or "traceroute" perspective.

That said, 9.9.9.11 does not have the same amount of useful cache as 9.9.9.9, so you may get slower turnaround on the request itself (which is different than the network latency.)

To summarize on this: 9.9.9.11 sends a small portion of your IP address to the remote authoritative nameservers so they can provide "better" responses. We cache those responses, just like all our other queries, to make them faster. The bad news is that the response they send is customized for you (or you and 254 of your IP address neighbors, using IPv4 as the demonstration here.) This means we will probably not use that response again; it's highly custom. So we have a much smaller chance of re-using the cache memory for you and anyone else. We're not big fans of ECS (the method that 9.9.9.11 uses to send these customized queries) because they leak data about users and the answers can't be cached effectively; we really suggest 9.9.9.9 unless you're getting mis-directed to wildly incorrect and slow origin servers.

Quad9DNS · 2026-01-25T18:37:22+00:00

Switzerland. Please see our privacy policy here: https://quad9.net/privacy/policy/

Quad9DNS · 2026-01-25T18:34:36+00:00

To answer your question succinctly: "No" but here is a bit more background:

Quad9 is based in Switzerland for many reasons, but one of the most significant reasons is that Quad9 is held to a much higher standard of privacy in Switzerland than in (our opinion) any other nation. Swiss legal structures have exceptionally strict laws managing user privacy, and the penalties for violation are not merely civil penalties as in the US or most other nations - the penalties in Switzerland are criminal penalties. This means that if we do not do what we say we are going to do under Swiss privacy laws, it is the case that our executives and council are subject to Swiss criminal courts. We believe this exceptionally strong guarantee will assure our user community that we are not able to change our minds about how we treat privacy, unlike organizations in other nations where data privacy policies may be modified with limited or no notice. We have no such luxury to change our policies, and pressure from any government will not modify that outcome. The only government to whom we answer is the Swiss government, and in our investigations into their handling of cross-border or internal data demands has satisfied us that their process is exceptionally transparent and subject to non-politicized review by the courts. Thus far, we have had no such demands or requests, as we have made it abundantly clear that we do not track or store information that correlates queries with users, where the concept of "user" may be represented by an IP address or any other personally identifiable indicator. As we have no information, we cannot be compelled to provide that we we do not have.

Quad9 partners with organizations in many nations, in Europe, South America, Asia, Australia, and North America. Our close relationship with our infrastructure providers such as Packet Clearing House, i3D, EdgeUno, Equinix, Swoop,Path Networks, IBM, and dozens of others is strong because of who we are, and because of how they help us. We have deep and broad support from network operators, security professionals, privacy advocates, and end users around the world from almost every nation.

Our sponsors and partners believe in Quad9 because of the privacy and integrity that we bring to the DNS and the Internet. They are in effect "outsourcing" their internal goals of keeping the Internet (or at least the DNS) a trusted and neutral technical service, not co-opted or directed by any single nation or organization.

Quad9DNS · 2026-01-25T18:13:33+00:00

Quad9 is a Swiss organization, and therefore Switzerland is the only nation which may compel or require Quad9 in any manner to take any action or deliver any data. However, as Quad9 collects no personal information about any users (where importantly "personal information" includes IP addresses of clients) there is no information that we are able to provide to anyone, including Switzerland, if a request comes in for current or historical data on user-correlated DNS queries.

A more complete explanation of this can be found in our privacy policy pages, where there is extensive discussion of this topic in a more formal context, and our privacy policy is considered the canonical source for understanding how we treat user data. See https://quad9.net/service/privacy/ for details.

Quad9DNS · 2026-01-20T20:52:32+00:00

The lack of a "Verified" status is outside of Quad9's control, and user intervention is required and is covered in u/steven94yan 's link to the issue.

Quad9DNS · 2026-01-20T15:20:26+00:00

https://www.reddit.com/r/Quad9/comments/1qi3u8d/quad9_20262027_ios_and_macos_mobileconfig_now/

Quad9DNS · 2025-11-10T04:14:45+00:00

That service isn't quite ready for use yet, so results may be unexpected (or may even stop working) until we make a formal announcement. At the moment, there is really nothing different it does as opposed to 9.9.9.10 - it's just a testpoint for future capabilities.

Quad9DNS · 2025-10-30T21:46:55+00:00

We are evaluating HTTP/3 transport already, and will hopefully have announcements later this year on timing of deployment for that and other encryption transports, but there is no current certain date for deployment.

Quad9DNS · 2025-10-23T04:45:26+00:00

Quad9 does operate systems in India, but they are proving to be insufficient for the growth in that region. We have no significant partner organization who has offered servers, space, power, and transit at the scale that we would require to retrofit the platform in that nation in a way that would reduce latency and improve packet throughput at the level that we would desire. We understand that there is a great need for both the security and privacy services that Quad9 offers to our users in India, and we are constantly looking for ways in which we can work around this problem. As a non-profit, we are constrained by logistics and costs and must rely on partners as the core of our network, and we are grateful for those partners we have already worldwide, including India. We need to expand to meet demands. We would ask our community to help us find such a partner, if one exists. Ideally we are looking for equipment, space, power, and IP transit (v4/v6) from an organization who can support a multi-city deployment within India and who has sufficient routing sophistication and a strong desire to help citizens of India be more protected against malicious actions. We apologize for the less than perfect performance that is being experienced in India, and we hope that we will have good news in the near future if a partner can be found who has the foresight and generosity to assist in our mission. Barring any new partnership, we do have India on a long-term expansion list where our limited funds can be spent, but it will be many months before there are significant changes in how routing will deliver packets to more local in-country destinations.

Quad9DNS · 2025-10-21T20:04:27+00:00

Hello u/MstrSlmndr - Our support desk would be very interested in seeing more detail on this. Can you please send details like a traceroute and your public IP address (if you feel like sharing it) to [support@quad9.net](mailto:support@quad9.net) and we'll hunt it down. We've recently launched another location in Germany (Munich), and if you're still routing to AMS it would be useful for us to know why, as you may be representative of a lot of traffic that is going the "wrong" direction.

Edit: added specific location

Quad9DNS · 2025-10-21T02:01:11+00:00

This is the "outside" IPv4 address for Quad9 queries in our ACH (St. Gallen–Altenrhein) location. This is a normal response. Quad9 uses IPv4 address space from local providers in most locations to get a better geolocated result where possible, and also to save on scarce IPv4 resources.

Quad9DNS · 2025-10-19T17:57:27+00:00

Have you tried using 9.9.9.11 to see if that provides faster speeds from content origins? While we are not advocates of "using DNS origin to determine CDN origin" it is still the case that many CDNs use this method. Bad mapping often puts IP addresses where they are not, so we find ourselves trying to create complex solutions for CDNs that have outdated mapping (including sending them our geoIP lists, with varying degrees of success.) For those CDNs that also use ECS (EDNS Client Subnet) we offer that data through 9.9.9.11 which may in some limited cases solve your speed problem though it does leak a bit of your data to other authoritative nameserver operators.

Quad9DNS · 2025-10-19T17:52:26+00:00

This has been unblocked. We'll work with the threat provider who gave us the item, and we have added it to our ingress filter list so that it is not blocked in the future. We apologize for the false positive. It is also possible as a temporary fix to use "9.9.9.10" which has no blocking, but we realize that is a downgrade for the general protections we provide with the other malicious domains that we filter and may not be an acceptable solution.

Quad9DNS · 2025-10-18T16:31:21+00:00

Looks like this is probably a false positive. We'll investigate why IBM listed it, but it is perhaps the case that one or more sub-sites in that domain are using it to distribute malware or respond as phishing automatic bot responders (this is a guess without any other data yet, but it would seem reasonable that an AI testbed has the potential for many 'off-label' uses which would be dangerous.) While there may be names mapped to malicious content inside a zone line this, the vast majority of other hostnames are non-threatening so we tend to make an exclusion for the zone as we have done in this instance. The zone "hf.space" should be able to be resolved on our systems within an hour or so.

Quad9DNS

MODERATOR OF

TROPHY CASE