I have just tried (just in case something has changed (running v.7.13.4):
/tool fetch url="https://letsencrypt.org/certs/isrgrootx1.pem"
/certificate import file-name=isrgrootx1.pem
/ip dns set use-doh-server=https://all.dns.mullvad.net/dns-query verify-doh-cert=yes
/ip dns static add address=194.242.2.9 name=adblock.doh.mullvad.net
/ip dns static add address=2a07:e340::9 name=adblock.doh.mullvad.net
And in the log I can see:
DoH server connection error: remote disconnected while in HTTP exchange
DoH server connection error: remote disconnected while in HTTP exchange [ignoring repeated messages]
Is it that Mullvad/Yandex are not sticking the RFC or Mikrotik did not implemented DoH properly?
Thank you for a reply, I think it’s not my way and it’s really need in HTTP/2 in mikrotik.
2Mikrotik team:
I would be extremely grateful to the Mikrotik device developers if they could implement HTTP/2 support as soon as possible. This feature would greatly enhance performance and compatibility with modern web standards
This can be allocated as a separate option or package or made disabled by default with a warning that by enabling this you confirm that you are sure that if something happens, it is your own fault
Mind that whichever HTTP version is supported in ROS, it’s only used for management (and proxy). It doesn’t affect ability to route “unknown” protocols.
So I have a question: what benefits does HTTP/2 have over HTTP/1.1 (with TLS1.3) in context of management? IIRC the main benefit is speed … but I don’t see this as a problem with management of ROS devices.
[edit] Ah, I see this discussion is about DoH. Personally I fail to see the importance of DoH compared to “normal” DNS, my ISP is not evil (not any more than Yandex or Google or any other global Corp … actually I’d say it’s way more customer friendly). But I get it that some MT users live in countries where “higher ups” try to affect people’s minds.
Installed but disabled feature still occupies flash storage … which is the only point of post by @infabo
Good point. Agreed with that.
is about DoH
After a little research it was found that for Yandex DoH server and Mullvad DoH only HTTP/2 requests are available and HTTP/1.1 is forcibly excluded to enable the transition to HTTP/2 and it turns out that MT does not support this in DoH.
[UPD] Also I found that Yandex and Mullvad supports only DNS-message request type, not dns-json.
I have realised from your comments that Mullvad DNS DOH is still not supported. Is there any wishlist or any way how this feature could be prioritised.
Does not make sense to pay Mullvad VPN and do not use the Mullvad DNS as well (specifically for the users outside the Mullvad tunnel).
If your router has enough free RAM and storage space (about 60MB each), you can abuse cloudflared running in a container to be able to use any DoH provider, including Mullvad:
In this example with Mullvad, the command line parameter is:
While 8.8.8.8 is used to bootstrap the look up of the DoH domain. In addition, you’ll need two DSTNAT rules to translate the UDP/TCP port 53 to 5053 when dst-address is the address of the VETH interface because cloudflared cannot bind itself directly to port 53.
Afterwards you can use the IP address of the VETH interface as upstream DNS server address.
I am browsing with this test configuration right now and everything seems ok. Tests with https://www.dnscheck.tools/ and https://browserleaks.com/dns confirm that I am using the right DNS resolvers (servers hosted by M247 Europe SRL).
Please note that currently, the suggestion in the older post above to run Unbound in container will not work, because Unbound does not natively support upstream DNS over HTTPS yet!
Thx for the instruction and detailed description. I will try it definitelly as my router can handle it. However in case there is any way how to prioritise the Mullvad DNS nativ support I would like to vote for that or would be at least useful to know the opinion of MT developers if they have it on the list or not at all.
