Back to Blog
blog
Quad9 will discontinue support within DNS-over-HTTPS (DOH) using HTTP/1.1 on December 15, 2025. This will have no impact on most users, but there are some older or non-compliant devices or software that may become unsupported after that point with DOH and will need to revert to unencrypted DNS or shift to DNS-over-TLS.
Quad9 was the first large-scale recursive resolver to offer standards-based encryption (DNS-over-TLS in 2017). We also offer DNS-over-HTTPS (DoH) as an encryption method, which has been slowly increasing as a percentage of our traffic since standardization and inclusion of that protocol in 2018. Browsers have been the primary tools for working with DoH, which has some advantages: Browsers are updated frequently and are usually kept up to date with new standards.
The DOH standard recommends HTTP/2 as the lowest version of the protocol for use for DOH (https://datatracker.ietf.org/doc/html/rfc8484#section-5.2), but does not rule out using the older HTTP/1.1 standard. Since adding DoH to our protocol stack seven years ago, we have supported both HTTP/1.1 and HTTP/2. However, we are reaching the end of life of the libraries and code supporting HTTP/1.1 in our production environment and therefore, support for DOH on HTTP/1.1 will be ended on December 15, 2025.
This sunset of HTTP/1.1 should not go unnoticed by the vast majority of our user community who are using Chrome (or any Chromium-based browser or stack), Firefox or Firefox forked projects, Safari (and all other Apple products/apps to our knowledge), or the Android and iOS operating systems. They are all fully compliant with our existing and future DOH implementation and, to the best of our knowledge, have always been in compliance.
If your platform does not work without the older HTTP/1.1 protocol, we would suggest that you upgrade your system or shift to DNS-over-TLS which does not have an HTTP layer. There’s always the possibility of moving to unencrypted DNS, but that decision should be considered closely as a downgrade of security and needs to be taken with caution if you’re in a high-risk network environment.
The only platforms that we know of directly that have ever used HTTP/1.1 and which will stop working after the sunset date are MikroTik devices that are configured to use DNS-over-HTTPS, as those devices do not support the modern and recommended HTTP/2 transport protocol. We have informed Mikrotik on their support forum (https://forum.mikrotik.com/t/quad9-to-drop-support-for-http-1-1/264174/4), but there has been no announcement yet by Mikrotik as to when they will update their software to this latest standard. Apart from MikroTik, we have no specific knowledge of any other HTTP/1.1 devices or libraries with large user communities, although that does not mean there are no IoT devices or software libraries that are using that method.
From a geographic perspective, there is a community of users in Brazil that are on HTTP/1.1, which we consider MikroTik-based. Due to the fact that we cannot associate questions with users (or even one question with another) it is not easily possible for us to determine what type of devices these are, if not MikroTik, nor is it possible for us to notify those users of the impending change because by design we do not know who they are. We welcome any comments from knowledgeable users in our Brazilian community that can tell us about the reasons for this geographic concentration (please contact support@quad9.net with details).
Despite our large geographic footprint and large user community, Quad9 remains a relatively small team. Our limited development efforts are better spent on bringing new features and core stability support to the Quad9 community, and we cannot justify the expense of integrating backward compatibility for customers who are not meeting the recommended minimum version of the protocol. HTTP/2 has been the recommended standard since the publication of the request for comments, and we believe this minimization of code is a reasonable step compared to the cost and complexity of backward compatibility development. Additionally, HTTP/1.1 has significant speed and scale challenges, and as time goes on it may be that leaving it in our stack will introduce edge-case protections or DOS attack vectors that will be difficult to discover and expensive to keep in our test models.
The update allows us to move forward with additional, new protocol support that we have been testing, which is ready for deployment and is part of a general refresh of our entire platform and system stack. We’ll have more flexibility and additional protocol support (keep watching this blog area for details), and the refresh also allows us to better take advantage of the new server hardware we’re deploying around the world to keep pace with adoption rates.
We recognize that this will cause inconvenience to some subset of users, and that many users may not be aware of the change before it is implemented because we have no assured direct way to communicate with our end users. This is a double-edged sword of not storing user data: we cannot notify everyone about changes directly.
If you know someone who will be affected, please share and encourage them to take the necessary steps now to avoid service disruption.
<a href