It seems to be in beta (experimental protocol), but it would be nice if MikroTik looks at this.
Here is an video demonstrating an implementation of this: https://www.youtube.com/watch?v=-jspv9FwgjA
It uses a Linux server as a DNS->HTTPS server.
So in this case I could redirect all UDP port 53 to a server and make this to work.
But getting this inn to the RouterOS would be nice, no extra boxes and a big lift in privacy
“experimental protocol”… there is not even consensus about implementation… Google and mozilla are using some form, IEFT with cloudflare different…
Implementing such feature in routerOS would be just waste of time for developers. Wait till it is finished and supported by all major players, then we may ask mikrotik to add it
So you are worried that your ISP or government spies on your DNS requests, but at the same time you installed
a websense proxy server that decrypts, scans and re-encrypts all https traffic as a man-in-the-middle??
What I do at work is their business and what I do at home is my business.
You do not need to install and use anything just because it there.
That is what I love about RouterOS, its modular.
Why would Mikrotik enable a feature that has almost ZERO client support in its current incarnation?
Also lets cover some things here. If I want to go to secretsite.com and I’m using DNS over HTTPS, my PC or router will send the request to the DNS over HTTPS servers. They will make the DNS queries. Now keep in mind that the actual name servers holding the DNS zone record for secretsite.com is just a regular ole DNS server. Now while your DNS request is all HTTPS to CloudFlare, CloudFlare is all unsecure to the nameservers for secretsite.com so they know where to get the IP(s). Sure they could cache results so they don’t need to make root server queries all the time but if secretsite.com’s zone record is updated with new IPs then these HTTPS DNS servers could have wrong information now cached until they clear it.
Now that I’ve done my DNS over HTTPS query I know have the IP for secretsite.com (let’s say 4.5.5.5) so now I need to get to 4.5.5.5 which means I have to send it over my Internet route to my ISP. Now my ISP knows its routing traffic for me to 4.5.5.5 which means my ISP now knows where I went. You might say “Yes but they don’t know what SITE name” but that’s not entirely true. 1) Most of these sites aren’t siting on shared hosting anymore, they are sitting on VMs with their own IPs. 2) SNI presents the actual FQDN requested because one site might have multiple domains or TLDs for it and if they are all meant to be hit via HTTPS the TLS cert needs to know which FQDN is being used to compare against.
All that things like DNSCrypt or DNS over HTTPS do is make sure that the DNS query itself is secured and no MiTM can happen and spoof the DNS results. So it means when I query secretsite.com I can be assured that I’ll always get back the proper IP. In no way do these methods stop your ISP from knowing where to route the traffic. Sure they may or may not have the FQDN but they do have the IP.
I do agree with you. It does not hide the IP you are visiting.
Look at England, all ISP are required to log all DNS records form all customer.
Going trough a DNS log is fast with little data. But looking trough a full list of “sourceIP/port destIP/port” pr customer would take a lot more resources.
Not sure if ISP do log that data, or for how long.
I do see that there are lots of changing coming so it would be interesting to see in a few year what it would look like.
Because it is requested by Microtik users/buyers.
Here is an example with my case. My ISP does MITM attack at my DNS requests to any available DNS server. In theory it should block any request to illegal resources, however in our reality something gone wrong. In some cases it just gives me wrong answer on legal resources. It is solved within couple of days with support team. I should mention that resources i request by that IP are not blocked, and if i resolve DNS issue with any method (hosts file, DNSCrypt and so on) it works fine.
So any working solution that helps resolve DNS MITM attack would be helpful.
I’ve been using DNS over HTTPS on a rooted RB951 and it’s been flawless. No timeouts, no perceptible latency increase and the additional security it brings is very nice. Hopefully this makes it into RouterOS v7.
Like all (encrypted) tunneling it just moves the security problem to a different place.
That may be beneficial when you trust CloudFlare more than you trust your ISP, and in some places that might be justified, but
in other places (like here) you just expose yourself to more monitoring and profiling.
It is the same issue as when using a VPN in the modern meaning of the word (i.e. not to transport private traffic between two sites, but
to connect your own system to the world wide internet via another location)
Privacy in my eyes a very high good and we are tracked everywhere on the Internet and also in real life.
Having protected datastreams against peeking eyes is good but the time is not right because we are to early. Big Data is working well with data from who the request comes and where it wants to go.
Goigle and Facebook would kill for be able to see this and you give it to other big fiirms of which you don’t know of what they are going to with that data.
I would love to that the ISP would replace the source address with an other. With IPv6 that would be not a problem. With IPv4 there are not enough addresses but asolution could be by switching the source address between two outgoing connections randomly. Returning traffic is switched again to return to the original requester. The ISP will still be logging the switched IP’s so they can obey the law on this. As long both connections are not timing out the being kept paired.
For users who need correct source address, a table could create with the ISP of destination adresses (in domain form) not to be switched. For advanced users a second gateway could be provided for non-private traffic.
This would also turn and Big Data collecting through DNS, external of the ISP useless.
Inside the network there otften content servers from Google, Facebook, etc. and then Iwould propose a bounce version of above and then the IP adresses are switched inside the network of the ISP.
An ISP can setup redirect for port 53 to their preferred DNS.
They can then control what DNS you should see, and at the same time log everything using Umbrella or other equal solution.
So we need a solution that we can make sure we have control of what DNS we use.
