Hi,

Last days CloudFlare has annouced new DNS service.
This includes also secured DNS
- DNS over HTTPS
- DNS over TLS
https://developers.cloudflare.com/1.1.1 ... structure/

Please advice me if secured DNS can be implemented in Mikrotik.
I know that other DNS technology DNSCrypt is still not implemented.

CloudFlare is one of the best dns
http://www.dnsperf.com/


Thanks in advance.

I want that too, but it's not compatible with RouterOS, just like the advanced OpenVPN setup. Needless to say, I'm using an ad-blocking DNS (Adguard DNS) blocks malware sites as well. 1.1.1.1 DNS seems real good (need to see the malware results compare to other alternatives), hope they also implement ad-blocking feature.

Why would you trust your metadata to a third party else than where you sent you internet traffic through!?

1.1.1.1 DNS seems real good (need to see the malware results compare to other alternatives), hope they also implement ad-blocking feature.

I see no claims at all about filtering malware or ads. It is just a DNS resolver.

Why would you trust your metadata to a third party else than where you sent you internet traffic through!?

In some cases the ISP DNS resolver has "additional features" that some people may not like, including returning false IP addresses for
certain domains or returning a false IP address for every lookup of a nonexisting domain.
Using an independent resolver may fix that.

It will help with filtering, at least for now. It won't do that much for privacy, because everything moves to https and SNI is happy to tell anyone on the way what domain you access.

The part about filtering I'm worried about, is that current DNS filtering is great. When someone wants to censor something (governments just love that), DNS filtering is the first thing they try. In most simple case, when it's done on ISP's resolvers, it sort of works, at least for regular user who uses network config provided by ISP. And surprisingly, censors are often satisfied with that. For ISP, it's not hard to set up either. And every user who doesn't like that, simply uses different resolvers. In the end, everyone is happy. But the more these "uncensorable" ways are going to be used, the sooner will the censors want to do something about it. It's not really an argument against these new secure ways, because the idea that "if we want to censor something, it should actually work" will come to them sooner or later anyway...

+1
I want it too

Me too
+1

Same for me. +1

+1, I'm not paranoid but I'm sure SOB is tracking my DNS!

Will be implemented in ROS v7

Will be implemented in ROS v7

This is hope or you know something more ?

I just wondering which solution became more popular :
- DNS over HTTPS
- DNS over TLS
?

It's not hope or knowing more, it's cruel joke. Have you heard about ROS v7 before, right?

On topic, DNS over TLS has head start, it's already RFC. On the other hand, it uses "unusual" port 853 by default, and it's going to be problem in some places. If I'd want to guess, DNS over HTTPS has better chance. Not that I'd be too excited by this "make everything on internet HTTPS" movement.

I was looking for that as well.

Why is everyone suddenly looking for this?
The performance will be dreadful compared to normal DNS, isn't it?
You would probably only want this when there is really no other way of having unfiltered DNS.
In most cases the use of a VPN to some unfiltered site is way more practical.

Then piggy-back a VPN on top of TLS (e.g. SSTP or OpenVPN) and work from there...

I'm also interested in this feature.

And maybe not everyone want to or have the resources to redirect ALL their traffic outside of a country to accommodate, what .4% of their requests? Or they don't want the performance penalty?

The explanation is simple. People are suddenly looking into this, because they've seen news about Cloudflare's new public resolvers. It might have opened their eyes about how DNS works and motivated them to want more privacy. Or they just wanted to check if RouterOS supported it, in case they would need it one day. VPN is good too, but VPN's don't grow on trees. Technically, neither do DNS resolvers, but in terms of accessibility it's like if they were, they are free for everyone, unlike VPNs.

You should understand that encrypting your DNS for the sole purpose of "websurfing" does not yield any privacy because the ISP can still look into the https session startups and see the SNI (which was added to allow https on shared hosting). So when you really want privacy, you need to tunnel all your traffic to an external VPN.
(this of course only gives you privacy against the ISP and your local government, now the VPN provider can see everything you do)

Securing only DNS and not the actual traffic brings very little. It could be a workaround against polluted DNS (some answers modified, maybe a default answer instead of "not found"), but is only required when the ISP does some dst-nat to capture all standard DNS traffic (so you can't simply use 1.1.1.1 or 8.8.8.8 instead of your ISP's DNS forwarders), even on nonstandard ports like 5353 which are provided to work around such things.

When you still want DNS over TLS, a better solution would be to setup an SSTP or OpenVPN connection to some service that allows you to send DNS queries (in UDP) over such a VPN to their resolvers. The DNS queries go over that VPN, the other traffic is sent directly. This will be way more efficient than DNS over TLS, as setting up a TLS connection has a lot of overhead. (the connection could be kept alive for multiple queries but apparently nobody does that)

You should understand that encrypting your DNS for the sole purpose of "websurfing" does not yield any privacy because the ISP can still look into the https session startups and see the SNI (which was added to allow https on shared hosting). So when you really want privacy, you need to tunnel all your traffic to an external VPN.

I think one of us misunderstands how this is supposed to work with encrypted DNS and why it's important that RouterOS's DNS server is revamped:
https://tools.ietf.org/id/draft-schwart ... ni-02.html

but is only required when the ISP does some dst-nat to capture all standard DNS traffic (so you can't simply use 1.1.1.1 or 8.8.8.8 instead of your ISP's DNS forwarders), even on nonstandard ports like 5353 which are provided to work around such things.

This is also incorrect. DPI can/does use DNS priming for priming protocol identification
https://patents.justia.com/patent/9887881

@jaymemaurice: We're talking about slightly different SNI (well, it's the same SNI, but how it's used now vs. what the linked draft suggests). And that draft is strange, it looks like recipe for really overcomplicated hide & seek game to me.

According to it, if I want to connect to https://badforbiddenstuff.tld, browser will get the new DNS SNI record, which will tell it to send worldofkittens.tld as server name instead of badforbiddenstuff.tld. Server will still send back certificate valid for badforbiddenstuff.tld and client will verify that. It will do any good only with TLS 1.3 which can send certificates encrypted (I didn't know that, that's interesting news) and so attacker won't be able to get anything from it. Good so far, and I do believe that it could help against passive attacker. But I'm more worried about attackers who are less passive, who want to block stuff. And they will of course know that badforbiddenstuff.tld exists and that it has DNS SNI record with worldofkittens.tld. So unless worldofkittens.tld is real existing site sharing the same IP address with badforbiddenstuff.tld, it can be easily blocked. And worst case, when they really can't tell one from another, worldofkittens.tld will simply go as collateral damage. And I also have hard time to believe that browsers will actually implement this, because it means sending extra DNS query for every single hostname. So it's likely to end up like SRV records for HTTP(S), i.e. not supported because the extra queries could slow things down, it would be bad for user experience and it's just not worth it, because it would be used only by tiny fraction of sites anyway.

Hi,

Is there any chance that somebody from Mikrotik Team will comment this post/request ?

...

I also want this feature.

Me too need this

Hello, new MikroTik owner here.

I'd also like to see DNS over HTTPS support.

I am not sure if the forum will let me post a link but I will try anyway. This is the source code of cloudflared (daemon) which can act as DNS over HTTPS proxy. It is written in Go language, it should be straightforward to port.

Cloudflared (daemon for cloudflare services including DNS over HTTPS) is open-source and written in Go language, you can find it on GitHub and port to MikroTik.

Cloudflared (daemon for cloudflare services including DNS over HTTPS) is open-source and written in Go language, you can find it on GitHub and port to MikroTik.

But there are 1000 things you can find on GitHub and port to MikroTIk, and after having completed that there will be still more requests for new things to add....

Why would you trust your metadata to a third party else than where you sent you internet traffic through!?

Irrelevant. We're requesting TLS and HTTPS (for DNS) support.

---

Please Mikrotik team, do this. DNS hijacking/redirection is a real issue.

Hope this feature can be implemented soon, this is the last piece before we can go full encrypted

Hope this feature can be implemented soon, this is the last piece before we can go full encrypted

You can already go full encrypted by setting up a VPN link to a router "in the cloud" (your own CHR running on a VPS host or one of the many VPN services) and route your DNS traffic over that.
(RouterOS is powerful enough to route only your DNS traffic and maybe your http traffic over the VPN, while still routing https traffic directly)

But if your only problem is ISP messing with DNS, then VPN/VPS route is relatively complicated, with extra costs, while you don't really need any of that.

Pity that "DNS over TLS" was implemented as a new standard. They could just have used existing VPN technology and tunneled standard DNS over that.
So services like CloudFlare could simply offer VPN access to their resolvers. Would be more efficient too.
And best of all, router manufacturers would not have to implement new things (and customers would not have to beg and wait for it).

I hope, DOH(DNS Over Https) supported on Mikrotiks soon.
And hope also following URL can help you.
https://dnsprivacy.org

I've got DNS over TLS working on my hEX! If you've rooted your device (don't contact MT for support if you do this!) it's quite straightforward to install. Since cloudflared is written in Go, it's easy to cross-compile and the only thing it needs to operate is a ca-certificates.crt bundle which I copied over from Debian. I then use a dst-nat REDIRECT rule to point all port 53 traffic to cloudflared running on port 5353:



Unfortunately Go binaries are statically compiled, making them very large. The mipsle cloudflared is 15 MB so it doesn't fit on the flash on the device, it needs downloading to RAM on startup. The 16 MB flash is definitely limiting what you can do when it comes to installing your own software. Cross-compiling one of the DoH implementations written in C will probably result in a more manageable binary size, but this is of course much more complicated.

Me too
+1

I've got DNS over TLS working on my hEX! If you've rooted your device (don't contact MT for support if you do this!) it's quite straightforward to install. Since cloudflared is written in Go, it's easy to cross-compile and the only thing it needs to operate is a ca-certificates.crt bundle which I copied over from Debian. I then use a dst-nat REDIRECT rule to point all port 53 traffic to cloudflared running on port 5353:



Unfortunately Go binaries are statically compiled, making them very large. The mipsle cloudflared is 15 MB so it doesn't fit on the flash on the device, it needs downloading to RAM on startup. The 16 MB flash is definitely limiting what you can do when it comes to installing your own software. Cross-compiling one of the DoH implementations written in C will probably result in a more manageable binary size, but this is of course much more complicated.

Do we have rooted after update ros to new version ?

Not sure, supposedly the update process wipes out any non-standard files so I'm not going to update until I have a very good reason to. I imagine Mikrotik will silently patch the jailbreak so I don't know how long this will be possible.

relevant thing for the conference! Waiting for a new feature

Needed very much +1 .,, ISP is sniffing and redirecting DNS traffic.. Even when using SOCKS5 over SSH and forget to direct DNS traffic through the tunnel too (that's how I found out)

+1

Can anybody from MikroTik reply on this thread?

Duplicate discussion

viewtopic.php?f=1&t=58866&p=709526&hilit=DNSSEC#p709359