I have had that happen many times. But in fairness, sometimes that means they have a development issue open for the request...so the support case gets closed since the request is tracked outside of the "SUP" case. i.e. in JIRA, there is likely some "DEV-" (or whatever name) issue types that get linked to the support case, so the "support case" is closed, since there is open "dev request" and nothing for support to do.
What I get often get is "if we get more requests", so to the point opening a feature request is "vote" has some merit.
On this topic, I think MikroTik knows that HTTP/1.1 days are numbered, with Quad9 being one datapoint. So it may be more a waiting game for it to be prioritized, if all DNS providers dropped HTTP/1.1, it might be a higher priority. But I suspect HTTP/2 is "on the list", and/or there working on more complete implementation include DoQ/DoT too.
I like features as much as everyone, but just a small counter-point:
Http/2 is non-trivial to implement
For most use cases that arise on a router, it shows no benefit. It only speeds things up when complex webpages with many resources are loaded.
Mikrotik’s webui won’t be able to use it, because it requires tls (at least when initiated by browsers, but in practice everyone treats it as if it did)
Basically DoH is the only use case I know of where it has significant benefits. And there the benefits are indeed huge.
If everyone is shifting away http/1.1, I would rather ask: why is Quad9 so keen on abandoning it? (This is not some rethoric, I genuinely would like to know.) Surely maintaining backward compatibility would outweigh any technical difficulty in supporting a comparatively simple protocol. Of course, Quad9 is under no obligation to provide free service to anyone.
A strange excuse. They are choosing to discontinue it from their codebase. In their official communique they also refer to better security with smaller code base, easier testing and allude to server infrastructure.
If the library consideration was the serious issue, I have tested it and with caddy (a well-regarded http(s) server, usually used as a reverse proxy) it takes 3 lines of config to achieve perfect proxying of their server from http/1.1 to http/2, if they wanted to provide 1.1 endpoints, they very easily could.
I think infrastructure is the real reason. In terms of server resources and bandwidth, http/1.1 for DoH is wildly inefficient, I would venture by an order of magnitude per request, maybe because of header compression, even more. But if not being able to, willing to, or prioritizing to have broader reach than support some backward clients: that I understand perfectly.
Non-profits maintain some of the most used resources on the Internet, and have a harder and harder time to put forth the money required to support cloudy scale server infrastructures. They must choose and prioritize carefully where their money does the most good. But if that’s the case, just say it.
I got a response from support on 04/11/25 saying: Thank you for contacting MikroTik Support and for your suggestions. Unfortunately, it is not possible to give any ETA when the HTTP2 support will be implemented.
The ticket is still open in ‘waiting for customer’ status. My original request asked when MikroTik would add support for either DNS over HTTP/2 or DNS over TLS, but they didn’t answer the second part of the question.
It is a good question why they would not just bundle a secure, proven DNS capability like Unbound. It could introduce vulnerabilities using third party code, but I would think the usual more eyeballs on public code is better than writing your own code in house.
I've been waiting 10 years for support for PTR records in current DNS implementation, so get where you're coming from... But part of the issue is they'd have to backport/adapt the current "special" logic like FWD/regex/etc. Another factor is OS package size, as the current DNS server is certainly smaller on disk than Unbound.
My hope is that they at least add BIND9 and Unbound as options in the new 7.21+ /app container support, ideally with hooks in /ip/dns with an option for "Use DNS container". That would get you pretty close to using a standard DNS resolver without all migration issue with replacing the existing DNS server.
I've switched to using unbound in container too and am very happy with it. But it's not suitable for router with low resources, so there no chance that it will be included in the main package to replace MikroTik's DNS implementation. The executable size (uncompressed) will increase by about 6MB for ARM64 (ARM might be slightly smaller) and the RAM usage will increase by about 35MB (also for ARM64, probably smaller for ARM), so even as an add-on package it will not be usable on the hAP ac² (even without any WiFi package) or all the 16MB flash devices. Not to mention devices with only 128MB RAM.
But /app packages are not stored in the flash (at least not by default) and you could have a USB stick in the hAP ac2 to store the unbound container…
It is also my guess that a reason why unbound cannot be used by default is the size of the program. The darned 16MB mistake again. Before I have suggested to make a separate “RouterOS lite” for legacy devices and a full version for the (new) devices that have enough flash for such things. The lite version could also omit things that home users rarely use, to free some space for the always ongoing expansion again.
I think the /app thing is currently only available to ARM64 and x86. The RAM requirement is also too much for the hAP ac² (mine doesn't have any WiFi package, only has a tiny UDPXY container that uses 800KB RAM, and currently only has 40MB free).
Now that Quad9 DoH no longer works, of course it is again obvious that the implementation of DoH in the DNS resolver is strange and unreliable.
It should at least be possible to have multiple DoH servers in the configuration, and also a combination of DoH and normal servers. So you could have configured 9.9.9.9 both as DoH and normal DNS, and not lose all DNS resolution as a result of this (hastened) change by Quad9.
I'm guess they copied the /app catalog from Synology and/or LSCR. But in 7.21 there are a lot of fixes/improvements to /container, beyond /app. Like being retry startup of containers marks as "start at boot", detection of exit signals, and allow directly specify envs/mounts in /container item (among others).
So if you have AX device, you should be able to use unbound directly as /container since it's configuration is pretty trivial so lack of /app is not too big a deal (i.e. verse something like librenms /app where multiple containers and bunch of mounts are needed that is a lot of manual configuration/alignment of VETHs/firewall). For DNS server container, you really just need a mount for config and a standalone VETH, along with /container.
But, true, nothing helps on the 16MB devices. Now on hAPac2, you might still be able to run unbound if you used "original" Wi-Fi drivers, and ac2 does have USB for disk (unlike it the hAPax2 which does not have USB).
This is a textbook case of when laziness from one party and adversarial doggedness from the other click together in a perfect case of entirely avoidable disruption.
I would like to have it "fixed" too but on the other hand: do you EXPECT the car manufacturer to upgrade your 12 years old car to newest regulations and provide eg. navigation map updates for free? Be honest. MT declares that devices are supported for 5 years. Everything beyond that is a HUGE bonus.
But on the hAP be³ you can setup a container with one of the multitude solutions that support DoH or DoT or both. It's only on those old devices with incompatible CPU architecture or limited RAM where secure DNS with Quad9 is fully impossible.
In fact MikroTik is not to blame at all, when you bought a router in 2013 without DoH, then suddenly in some firmware upgrade it starts to support DoH, followed by one of the DoH providers changing their system and you being locked out.
The router still conforms to its 2013 specification. DoH can be turned off.
When you now buy a new router, it will probably still not be in the specifications that it “supports DoH with Quad9”. And it would still work with Cloudflare, Google, etc.
