DOH HTTP/1.1 Retirement December 15, 2025
Summary
Quad9 will be discontinuing support within DNS-over-HTTPS (DOH) using HTTP/1.1 on December 15, 2025. This should have no impact on most users, but there are some older or non-compliant devices or software which may be unsupported after that time with DOH and which will have to revert to unencrypted DNS or shift to DNS-over-TLS.
Background
Quad9 was the first large-scale recursive resolver to offer standards-based encryption (DNS-over-TLS in 2017). We also provide DNS-over-HTTPS (DOH) as an encryption method, which has been slowly increasing as a percentage of our traffic since standardization and our inclusion of that protocol in 2018. Browsers have been the primary devices operating with DOH, which has some benefits: browsers are updated frequently and are typically kept up to date with newer 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. We have supported both HTTP/1.1 and HTTP/2 since our inclusion of DOH in our protocol stack seven years ago. However, we are reaching the end of life for the libraries and code that support HTTP/1.1 in our production environment and, therefore, will be sunsetting support for DOH over HTTP/1.1 on December 15, 2025.
Are you affected?
This sunsetting of HTTP/1.1 should not be noticed 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 to our knowledge all other Apple products/apps), or Android and iOS operating systems. They are all fully compliant with our existing and future DOH implementations and, to our knowledge, have always been compliant.
If your platform does not work without the older HTTP/1.1 protocol, then we would suggest you upgrade your system or shift to DNS-over-TLS which does not have an HTTP layer. There is always the possibility of moving to unencrypted DNS, but that decision should be closely considered as a downgrade of security and needs to be made carefully if you are in a network environment of higher risk.
The only platform that we are aware of directly that has ever used HTTP/1.1 and which will stop working after the sunset date are MikroTik devices that have been configured to use DNS-over-HTTPS, as those devices do not support the modern and recommended HTTP/2 transport protocol. We have communicated this to MikroTik on their support forum (https://forum.mikrotik.com/t/quad9-to-drop-support-for-http-1-1/264174/4), but there has not yet been an announcement by MikroTik as to when they will update their software to this more recent standard. Other than MikroTik, we have no specific knowledge of any other HTTP/1.1 devices or libraries with sizable user communities, though that does not mean there are no IOT devices or software libraries which are using that method.
From a geographic perspective, there is a community of users in Brazil who are on HTTP/1.1 which we believe to be MikroTik-based. Due to the fact that we cannot associate queries with users (or even one query with another) it is not easily possible for us to determine what types of devices these are, if not MikroTik, nor is it possible for us to inform those users about the impending change as by design we do not know who they are. We welcome any comments from our Brazilian community from knowledgeable users who can enlighten us as to the reasons for this geographic concentration (please contact support@quad9.net with details).
Our Reasoning
Despite our large geographic footprint and sizable 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 backwards compatibility for clients that are not meeting the recommended minimum version of protocols. 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 to take when compared with the costs and complexity of backwards compatibility development. In addition, HTTP/1.1 has significant speed and scale challenges, and as time progresses it may be the case that leaving it in our stack would introduce edge-case security or DOS attack vectors which would be difficult to discover and expensive to keep in our testing models.
The update allows us to move forward with additional, newer 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 will have more flexibility and additional protocol support (keep watching this blog area for details), and the refresh also allows us to take better advantage of newer server hardware that we have been deploying worldwide to continue keeping pace with adoption rates.
We recognize this will cause inconvenience for some subset of users, and many users will not be aware of the change before it is applied as there is no assured direct method for us to communicate with our end users. This is the double-edged sword of not storing user data: we cannot directly notify everyone of changes.
If you know someone who will be impacted, please share and encourage them to take the necessary steps now to avoid interruption of service.