Add DNS over HTTPS (DoH) support

NetworkMeister · Mon Apr 02, 2018 4:57 pm

Add DNS over HTTPS (DoH) client to RouterOS. This will significantly improve the privacy of network users and devices (especially when RouterOS device serves as DNS cache/recursive resolver).

https://developers.google.com/speed/pub ... over-https
https://developers.cloudflare.com/1.1.1 ... ver-https/

While experimental protocol, the infrastructure is already provided by 2 of the biggest 4 recursive DNS providers and provides significant benefits in practice.

R1CH · Mon Apr 02, 2018 6:18 pm

DNSCrypt support would also be welcome, to avoid the overhead of wrapping all DNS requests in HTTP / TCP.

Sob · Mon Apr 02, 2018 6:47 pm

There's also DNS over TLS (RFC7858).

But when you look how much attention MikroTik gave to DNS in the past (there's nothing over basic functionality and one could argue that even some basics are missing), I don't see any of this happening anytime soon.

msatter · Mon Apr 02, 2018 9:24 pm

Add DNS over HTTPS (DoH) client to RouterOS. This will significantly improve the privacy of network users and devices (especially when RouterOS device serves as DNS cache/recursive resolver).

https://developers.google.com/speed/pub ... over-https
https://developers.cloudflare.com/1.1.1 ... ver-https/

While experimental protocol, the infrastructure is already provided by 2 of the biggest 4 recursive DNS providers and provides significant benefits in practice.

viewtopic.php?f=2&t=132678

hardtik · Wed Feb 13, 2019 11:09 am

+1

Can anybody from MikroTik reply on this thread?

dave864 · Sun Apr 07, 2019 12:32 am

+1
About time DNSCrypt or DNS over TLS was implemented.

anav · Sun Apr 07, 2019 4:45 pm

RPI apparently has the ability to do this and is very inexpensive, now that I have ad block working I might give this a try.

jplr · Tue Jul 16, 2019 11:11 am

also interested in encrypted DNS. +1

pe1chl · Mon Sep 09, 2019 4:26 pm

This is something that (when you want to have it at all) should be implemented in the client, not in the router.
And of course MikroTIk already supports DNS over HTTPS done by the client.
(and you will lose the possibility of controlling access to sites, shaping bandwidth to certain sites, etc. but that is what it is all about)

pe1chl · Mon Sep 09, 2019 5:06 pm

But then it also does not bring the advantages that the client side implementers think it will bring!
So they will work around it even when you implement it in the router.
It appears that some implementations allow a switchoff (lookup a DNS name which should return NXDOMAIN) but MikroTik DNS does not support static names which return NXDOMAIN, and experience shows that this kind of switches is removed or made possible to override in no-time.

Sob · Mon Sep 09, 2019 9:16 pm

"Funny" thing is that implementation in browser (as Mozilla is pushing now; or generally per-application) makes the least sense of all. Either I want to protect whole network, so I need it on router. Or I want to protect computer (better for mobile devices, because with them I don't always have control over network) and then I need system-wide solution there. Not only browsers use DNS.

And the idea with canary domain and ability to tell browser this way to not use DoH, it's not hard to predict how it will go, is it? If I'm the bad guy who wants to mess with users' DNS, of course I will use that.

davidg · Thu Sep 12, 2019 1:10 pm

And the idea with canary domain and ability to tell browser this way to not use DoH, it's not hard to predict how it will go, is it? If I'm the bad guy who wants to mess with users' DNS, of course I will use that.

I'm actually reading this post because I was wondering if routerOS had any way to NXDOMAIN a given address, in order to implement the canary domain as per https://support.mozilla.org/en-US/kb/co ... over-https. I don't want traffic on our (SOHO) network that skips DNS-based filtering or tells google/cloudflare everything.

pe1chl · Thu Sep 12, 2019 4:26 pm

Yes that is why there is some discussion about this.
However, be warned that this "canary domain", as Sob already writes too, is likely to go away in the future once hackers who want to play man-in-the-middle on DNS see this, implement the canary domain, Mozilla finds out about that, and decides to disable that feature (at least by default).

You should prepare for the situation that you get less and less control over what happens on your network!
All wellknown ways of peeking in traffic to implement policies (like website blocking, or QoS implementations that e.g. try to set a lower priority for some traffic) are going to be taken away from you by those browser developers.

It is not only DNS over HTTPS. Firefox will also start to do all web browsing traffic over a "VPN" between the browser and some Cloudflare service, running over HTTPS.
So no way to block sites by IP address anymore! (or to put lower priority on some websites)
You will only see a lot of sessions to a single HTTPS service and no more way to get insight in what is happening over those sessions.

Anastasia · Tue Nov 19, 2019 4:03 pm

Does the company mikrotik have plans to do DNS over HTTPS?
Where is the official answer about this?

sebastia · Tue Nov 19, 2019 4:15 pm

For the time being, we have to look to other platforms, ex dnsmasq

Wed Nov 20, 2019 3:58 pm

For the sake of argument, can you give some examples why do you need DoH on the router, if you can use it in your browser already?

eworm · Wed Nov 20, 2019 5:08 pm

Probably because there is so much more than just browsers...

pe1chl · Wed Nov 20, 2019 5:37 pm

For me the main need for DoH support is the capability in the local DNS server to add static names that return NXDOMAIN. And while you are at it, also other
record types like NS, TXT etc. Some browsers try to resolve use-application-dns.net which on internet DNS would return an IP address. When it returns NXDOMAIN
instead, it is assumed the local admin does not want the users to use DoH and this feature is switched off. But in RouterOS it is not possible to arrange that.
(IMHO the browser makers should also accept responses like 127.0.0.1 as indicator, but they don't)

Rez · Wed Nov 27, 2019 3:47 pm

I'd like to append my request for RoS DoH support as well.
We should not have to trade security for usability when the need arises.

To elaborate:
I am currently intercepting all DNS server requests, redirecting them to the router itself (RB4011), using static DNS at router level to block many social sites as well as redirect some domains to internal servers, while all allowed requests are forwarded to 1.1.1.1 or 8.8.8.8.
If I use DoH at browser level - I get security but I can no longer redirect the domains.
When Windows 10 starts recognizing DoH enabled DNS servers, the manual rules won't apply either.
The only way I see is for RoS to intoduce DoH support and transparently resolve using DoH enabled DNS servers.

Default case: DoH is enabled in neither browser or OS.

DNS requests are not secure.
Router DNS cache is used.
Router static DNS entries are honored.

Case 1: No DoH support at router level. Browser uses DoH:

Browser DNS requests are secure.
OS DNS requests are not secure.
Router DNS cache is not used for browser requests.
Router static DNS entries are ignored for browser requests.

Case 2: No DoH support at router level. OS supports DoH.
(Windows 10 DNS client is said to support DoH natively for DoH enabled DNS servers in the next major update)

Windows uses DoH.
All DNS requests are secure.
Router DNS cache is not used.
Router static DNS entries are ignored.

Ideal case: If Mikrotik adds native DoH support to RoS:

Home network (Browser, OS, IOT devices) > DNS req. > RouterOS > DoH req. > Cloudflare / Google
All DNS requests are secure.
Router DNS cache is used.
Router static DNS entries are honored.
Devices do not need to support DoH directly to benefit from it.

Wed Nov 27, 2019 5:48 pm

The only way I see is for RoS to intoduce DoH support and transparently resolve using DoH enabled DNS servers.

DoH uses HTTPS as a transport, so transparent redirects are not gonna be possible.

[*]DNS requests are not secure.

DoH has nothing to do with security. Really nothing. Some believe it has something to do with confidentiality (which is not the same as security), though this statement is also arguable.

And... Yes, I would also like to ask for a builtin way (like the ability to return NXDOMAIN for a given domain) to tell clients to NOT use DoH.

msatter · Wed Nov 27, 2019 7:34 pm

Using a pi-hole here and have just, put a small doh-proxy in front. Wotk great and I have TLS 1.3 secure connection.

The router blocks on IP basis DoH addresses that I know of, so that is cut off. Normal DNS requests are delivered at Pi-hole by the router. DoT is next as proxy ior Pi-hole.

The DNS server of RouterOS limited and if you want more, get other solution.

Pi-hole is also a development version that tackles the CNAME cloaking of third party tracking and cookies behaving as first party to avoid detection.

Rez · Wed Nov 27, 2019 8:21 pm

The only way I see is for RoS to intoduce DoH support and transparently resolve using DoH enabled DNS servers.
DoH uses HTTPS as a transport, so transparent redirects are not gonna be possible.

It would be transparent to the client devices which are still using vanilla DNS requests - not the router.
Upon client request - the router does the resolve via DOH, caches it and serves it back as a "vanilla" dns response to the client.

[*]DNS requests are not secure.
DoH has nothing to do with security. Really nothing. Some believe it has something to do with confidentiality (which is not the same as security), though this statement is also arguable.

How would you call preventing your ISP and all servers in between to sniff and log your DNS queries then?
Indeed the term "security" might be a bit much, considering that third party DNS providers are involved but still I'd rather risk with one instead of all of them along the way.

pe1chl · Wed Nov 27, 2019 9:30 pm

[*]DNS requests are not secure.
DoH has nothing to do with security. Really nothing. Some believe it has something to do with confidentiality (which is not the same as security), though this statement is also arguable.
How would you call preventing your ISP and all servers in between to sniff and log your DNS queries then?

You transfer the possibility for your ISP (a party you selected yourself and probably know well, and who you pay for your internet service) to sniff the DNS traffic to another party who you do not know, you do not know where they are located, and you do not pay them money for the service directly (so they have to earn money from your requests in a different way).

You choose what you prefer.

it is similar to using a VPN (in the newfangled sense of the word). It may prevent your ISP from sniffing, but you transfer that possibility to the VPN company.

Sob · Wed Nov 27, 2019 11:27 pm

It would be up to you what DOH resolver you'd use, it could be something public, some trusted commercial service, your own server somewhere else, anything. So this part is fine, but what you'll achieve is different matter.

If you want to keep DNS queries secret, there's currently no point, because you'll most likely use them to connect to some website and SNI will tell anyone on the way to which one.

It will prevent tampering, so ISP will no longer be able to block something simply by blocking relevant DNS queries. That seems good at first sight. Problem is, they probably don't do that just for fun, but often because they have to. So the result will be that they will have to find some other, much worse method.

msatter · Wed Nov 27, 2019 11:43 pm

Server Name Indication (SNI) can be used by the client to select one of several sites on the same host, and so a different X.509 certificate can be sent depending on the hostname that was sent in the SNI extension. If the SNI extension is not sent the server's options are to either disconnect or select a default hostname and matching certificate. The default would typically be the main site.

SNI has been made mandatory to implement in TLS 1.3 but not mandatory to use. Some sites want to encourage the use of SNI and configure a default certificate that fails WebPKI authentication when the client supports TLS 1.3. This is under the assumption that if a hostname is not sent, then it means that the client does not verify the server certificate (unauthenticated opportunistic TLS). For implementation that actually don't send the SNI extension, but do verify the server certificate this can cause connection failures.

https://wiki.openssl.org/index.php/TLS1.3

Sob · Thu Nov 28, 2019 1:29 am

I'd say you're looking at too low level. SNI is what makes multiple https websites on single IP address possible. It's very common and it's not going away. So even though client may not use SNI, if we're talking about common stuff like web browsers, they all use (and have to use) SNI, because "web wouldn't work" without it. I know there's some work on encrypted SNI, but AFAIK it's not finished yet. When it becomes common, it will solve the information leak problem and then it will also make sense to hide DNS queries. But we're not there yet.

msatter · Thu Nov 28, 2019 3:24 pm

That the web would not work without is partially true if you look at only IPv4. With IPv6 you don't need SNI anymore because you have huge numbers of unique IPv6 address available. I read about ESNI and it badly supported or even not supported.

If you then put your DoH sever on a IPv6 address then you could omit the SNI in your "Client Hello" to the DoH server (proxy) when using TLS 1.3.

eworm · Thu Nov 28, 2019 3:38 pm

If you want to keep DNS queries secret, there's currently no point, because you'll most likely use them to connect to some website and SNI will tell anyone on the way to which one.

So developing ESNI (encrypted SNI) does not make sense because usual DNS leaks the information anyway?

Your argument is nonsense and would stop any technical improvement. Let's start to use/implement DoH now, so ESNI is the last piece of the puzzle still missing.

pe1chl · Thu Nov 28, 2019 4:20 pm

With IPv6 you don't need SNI anymore because you have huge numbers of unique IPv6 address available.

Even with IPv6, SNI is normally used because it often is an extra burden to assign multiple IPv6 addresses to the same webserver for the purpose of serving different domains.

Sob · Thu Nov 28, 2019 4:47 pm

@eworm: No, it's a misunderstanding. Currently we have two leaks, DNS and SNI. If you want privacy (not complete, but much better than what you have now), they both have to be fixed, and we do want that to happen. But since it didn't happen yet, if you as user enable DOH, it will help a little bit, but not much. It's like complaining about cold in house, when you have open both door and window. Closing only one won't save you. And sure, someone has to start, everyone can't wait on everyone else like with IPv6.

pe1chl · Thu Nov 28, 2019 5:13 pm

Of course when these techniques become universally implemented, we need to make a sticky topic for the many users that come here with requests like:

- I need to block some specific website (Youtube/Facebook/whatever)
- I need to allow access to only one specific website (externally hosted company site)
- I need to limit the use of bandwidth by this or that service, e.g. operating system updates

etc. There can be a simple cooked reply stating that these things are no longer possible, and that all recipes those people find that claim to solve it do no longer work.
And also that despite information they have read elsewhere, other manufacturer's equipment cannot do it either.

At first sight it may seem that this privacy is a good thing, but of course it will cause some things to collapse, like free Wifi for visitors and limited-bandwidth wireless internet connectivity with purposely limited usage.

msatter · Thu Nov 28, 2019 7:28 pm

With IPv6 you don't need SNI anymore because you have huge numbers of unique IPv6 address available.
Even with IPv6, SNI is normally used because it often is an extra burden to assign multiple IPv6 addresses to the same webserver for the purpose of serving different domains.

Why use a webserver. I don't want DoH go through a webserver then a proxy and finally arrive at the DNS server and the has to the way back.

I don't know a DNS server that offers DoH or DoT any thr proxies or loadbalancers are used.

Do away, with we have to use SNI and just have a single certificate and one addres (IPv6)...leak three IPv6 address.

I suggested it earlier with Xs4all (ISP) that don't need a fixed address to browse on the internet.
So spread traffic from costumers over many adresses and only Xs4all knows wo have that traffic back. For every visited domain the client gets a diiferent source IP on the border of inner and outer. Needs two gateways and/or VPN so that services and have a fixed adress available.

pe1chl · Thu Nov 28, 2019 7:33 pm

With IPv6 you don't need SNI anymore because you have huge numbers of unique IPv6 address available.
Even with IPv6, SNI is normally used because it often is an extra burden to assign multiple IPv6 addresses to the same webserver for the purpose of serving different domains.
Why use a webserver. I don't want DoH go through a webserver then a proxy and finally arrive at the DNS server and the has to the way back.

This is not about DoH, this is about SNI. SNI is required when serving websites for multiple domains on a single server (or at least a single address).
You claimed "with IPv6 you don't need SNI anymore" which is technically correct, but in practice it isn't true because those who serve multiple domains on a single webserver are not willing to add IPv6 addresses to that server for each of the domains served.
(especially as that solution is not practical on IPv4 and so there would be two different mechanisms, name-based and address-based virtual hosting, on the same server)

msatter · Thu Nov 28, 2019 7:39 pm

Webservers that also hosts sites, are not needed to provide DoH.

That is born from not having good proxies.

Sob · Thu Nov 28, 2019 9:23 pm

You seem to be mixing two unrelated things together. SNI is what's used when browser (as most common example) talks to a website that user wants to open. It doesn't matter what you used to resolve hostname to IP address, maybe it was completely secure way, using DoH or any other method. But when making https request to target website, browser sends (at this time unencrypted) hostname as part of request and anyone on the way can see it. Whether target webserver actually supports SNI or not is irrelevant, because browser doesn't know that when sending request. And browser has to use SNI, because if server requires it, it won't work correctly without it. If it doesn't need it, it will simply ignore it. The latter is not a problem, but the former is.

msatter · Fri Nov 29, 2019 11:24 am

A DoH proxy or loadbalancers for DNS do not serve websites so have don't a requirement to be using a SNI.

That the webservers crops up each time, is due that many used a webserver in between the client and the DNS server. This is not needed anymore now proxies can handle DoH natively.

If later we get esni makes not much difference if one block on IP addresses of yhe DoH servers.

pe1chl · Fri Nov 29, 2019 11:39 am

A DoH proxy or loadbalancers for DNS do not serve websites so have don't a requirement to be using a SNI.

YOU ARE JUST NOT GETTING IT!!!! The SNI is NOT RELATED to the use of DoH.
The SNI is another "leak of information" that is leaking the same information as a DNS lookup would, thus rendering the use of DoH for "privacy protection" ineffective.
When you just don't understand that, please end the discussion about that.

msatter · Fri Nov 29, 2019 12:20 pm

DoH is using SNI after "Hello Client". Secondly, your ISP can't see which domain you are requesting for an IP address in you DoH traffic. Thirdly using a VPN, the VPN provider and every device between them and destination, knows where you are going on IP address and then SNI.

SNI is used to run many services after one IP address. Running only one service behind an IP makes SNI obsolete but makes it easier to block by IP address.

We are in the Adding HTTPS DoH topic after all.

Fri Nov 29, 2019 12:45 pm

For other people trying to follow this discussion, here is some nice information about ESNI https://blog.cloudflare.com/esni/

Sob · Fri Nov 29, 2019 8:33 pm

@msatter: Let's try once more. You want to visit https://forum.mikrotik.com. There are two steps:

1) resolve forum.mikrotik.com to numeric IP address
2) establish tcp connection to IP address from 1), negotiate encryption with server and send http request

To do 1), you have several choices. You can send traditional DNS query to port 53 and ask ISP's server or some public one (ISP can see both). You can tunnel these queries through VPN (ISP can no longer see them, but now VPN provider can). You can be sneaky, write down the correct IP address and put it in local hosts file, this way there won't be any DNS query leaving your computer and nobody will see it. Or you can use DoH and neither ISP nor VPN provider will see the query, because it will be encrypted. Whoever runs the DoH server will see it, obviously, but you probably trust them.

Now let's focus on DoH. It's DNS over HTTPS, so there's the HTTPS part and HTTPS can use SNI to indicate target hostname. Honestly, I have no idea if DoH client uses SNI or not. But it doesn't matter, because even if it does, it will contain the name of DoH server, parhaps something like dns01.someprovider.tld. So now ISP or VPN provider would know that you're using DoH resolver. But hey, good news, they can't know that you're asking about forum.mikrotik.com.

And now the problematic part. Browser already knows the correct IP address (which forum.mikrotik.com uses). Browser opens tcp connection to this address and port 443. You're still good, nobody knows anything about forum.mikrotik.com (not counting that they may already know that this IP address belongs to it, but the name is not mentioned anywhere). Now browser needs to get certificate from server, in order to verify that it's really the correct one and there's no man-in-the-middle attack going on. And bam, here comes the "bad SNI".

Browser doesn't know what websites are hosted on target address. It can be just forum.mikrotik.com, it can be other MikroTik's websites, or perhaps some employee can also host a personal blog about kittens there, blog.routersandkittens.com. And each of these sites can have different certificate. If you want to visit forum.mikrotik.com, it would be useless if server sends certificate for blog.routersandkittens.com. Technically, there could be one certificate valid for both, but it probably won't be this case. Perhaps server could send both and client could choose. It would work for two hosted websites. But it could also be more than two, thousands, no problem. Server can keep sending thousands of certificates to each client.

And that's what SNI does, as part of negotiation, client (in this case web browser) tells server "hello, I want to visit forum.mikrotik.com, would you please send me correct certificate?" And the problem is, currently used unencrypted SNI sends this greeting in readable plaintext form. So all the effort to get forum.mikrotik.com resolved secretly was for nothing, because now anyone on the way (either ISP or VPN provider) can see that you're visiting forum.mikrotik.com.

You see the problem now, right?

Sob · Fri Nov 29, 2019 8:55 pm

I got a little carried away and it's too long, but two more points, just to be sure that there's no misundertanding:

- Yes, MikroTik should add DoH client to their TODO list, because router is the right place for it.

- Users should not see DoH as magic solution for privacy, because by itself it's not. Widespread use of encrypted SNI will help, but it's something that will happen in future (maybe). But too many servers have unique and static IP addresses and much can still be gathered from that, so if "they" (evil hackers, government, ... take your pick) are trying to get you, they probably will, even with DoH and ESNI.

msatter · Fri Nov 29, 2019 9:39 pm

To me DoH is something that belong browers or any client software that could use it. It is there, to hide traffic between other encrypted traffic. SNI still gives away, where that encrypted traffic is heading....besides the destination IP address. You can't change te destination address but you can change the source address to avoid trace back to the user source address.

DoT should be at home on routers as a replacement for current DNS.

If you make the source IP address variable as with CGNAT but then every different destination IP address has a different source IP addres and different return port. Kind of VPN with double NAT.
Governments won't like it because they can only track it in the CGNAT self and ofcourse in the devices of the users.

Sob · Sat Nov 30, 2019 1:24 am

It's slightly OT, but you're underestimating governments. They have special powers, they can cheat, they are the ones who make rules for ISPs. Your plan to use random source addresses? It would require cooperation from ISP. Or from VPN provider, but that's just different kind of ISP. If government doesn't like it, they will simply say "no, that's not allowed". There are foreign VPN providers who they can't reach, but what stops government from making a law that would make using them illegal? It would look bad if the country claims to value freedom and such, and it's not really needed (yet). That's it.

The last part is very important. For example, where I live, our enlightened government decided to protect citizens from gambling, or at least that was one story. The actual implementation of that idea is a law that forces ISPs to block access to few websites. The list currently contains a little over hundered of them and most is taken by 1xbet1.com to 1xbet110.com, which I'd say tells a lot about the whole thing. And if it wasn't absurd enough already, it's allowed to "block" access only on DNS level and only on own resolvers (or whatever is default config given to clients). Any user is free to set some other resolver like 8.8.8.8 to bypass blocking and ISP is not responsible for that. Anyone with the slightest amount of technical knowledge can immediatelly see how the whole thing is useless. But government is happy. I don't know, maybe it even works on average idiot who needs to be protected from gambling. But what will be next? Maybe the secret art of resolver changing will become too known and updated law will require to really block "bad" DNS queries, no matter what resolver is used? No problem, there's already DoH. So maybe in next version, ISPs will have to block access to few well-known DoH resolvers? Block connections to gambling sites based on SNI? There's no limit how far it can go (well, they can't probably outlaw internet completely... at least we can't imagine something like that now). And of course at some point, they will find other things to block, because once you start with something...

And about encrypted SNI, it has one major problem, at least current version of it. It's optional extension and it requires extra work (to put key in DNS). Who will bother with that? It could be enough if some big players like Cloudflare do it. And if it annoys some governments, they can't really block "half of internet" by blocking their whole network, can they? Hooray, the technology will win the fight! Erm... but for some reason my mind still brings up the famous https://xkcd.com/538/.

pe1chl · Sat Nov 30, 2019 11:56 am

I get 1208925819614629174706177 IP addresses from my ISP (1208925819614629174706176 of them are IPv6 and 1 is IPv4) but of course it is completely useless to vary between them because the 1208925819614629174706176 IPv6 addresses are all in a single block that is easily traceable to me.

And as I have already written: using multiple IPv6 addresses to separate websites running on the same server: not going to happen. It would have to be done by EVERY webserver in the world before SNI can be omitted on IPv6 requests, and even then the webbrowser may not even know if the request is over IPv6.
For example, on our company network the LAN is only IPv4, there is no routing to internet, there is a proxy server for web access, and it has IPv4 and IPv6 externally.
The browsers connect the proxy using IPv4, they send their "CONNECT www.example.com:443" request to the proxy, which resolves the domain name and connects it (IPv6 preferred), then the browser starts its TLS handshake over this tunnel. The browser has no way of knowing whether the connection to the website is IPv4 or IPv6, so it can only assume it has to send the SNI. Which could then be picked out by an external observer on the internet (the proxy log of course already contains de requested domainname, it does not require SNI for that).

And as Sob writes, there sometimes are "legitimate" reasons to block some site, either by law (because the visited site performs illegal activities) or by local policy (e.g. because some workplace does not want the employees to spend their time on certain activities, or because parents want to hide some content from their children).

We should understand that the ever progressing move towards privacy on the internet does not have only advantages. There sometimes are reasons to block certain things and there sometimes is a requirement to research some (past) activities that have happened on a network or user, and taking away that possibility will certainly lead to more abuse and crime. Which in turn may lead to more drastic action by frustrated governments.

msatter · Sat Nov 30, 2019 3:43 pm

1208925819614629174706177 Is not important you need only on at your home or firm if you don't offer services.

Example you connect to example.com and your IPv6 or IPv4 is converted to source address 1.2.3.4 port 1000. At same time sob connects out and he receives source address 1.2.3.4 port 1010 and I connect also out and get source address 1.2.3.4 and port 1020. Traffic is separated and the ISP knows which client address belongs to which source address and port.

If you have spare IP addresses then you can also vary with that.

The ISP still can still block destination addresses. You can't offer services unless your ISP gives you a virtual IP or dedicated IP on IPv4. On IPv6 you are free to offer any IP in your block.

I would prefer also secure connection proxy in front of many services and SAN (alternative name) allows that with only one certificate. A webserver does only have to do what it is designed for, serving pages.

Sob · Sat Nov 30, 2019 6:58 pm

So in a way, you must like current IPv4 shortage and ISPs who use NAT to hide multiple customers behind common public address. Hundered customers, one address, and evil website tracing users doesn't know who is who (it probably does anyway because of cookies or browser fingerprinting, but not just from IP address). But nosy government is still fine, because it can simply require ISPs to keep records about who was connecting where.

And the proxy, it's what e.g. Cloudflare does. You as client are connecting to their servers and they are forwarding traffic to real servers with content. I do believe that they can make a difference, for a while at least. The local government of random country has no power over them and if you successfully hide DNS queries and they have ESNI, you're safe. Blocking their whole network would be too extreme. But it won't be one annoyed government, it will be many of them. They will eventually come together and figure something out. A global regulation, marketed as a noble cause, some variation of "we can't let criminals be anonymous". It won't be easy, but nobody really believes that they would just give up.

hardtik · Sun Jan 12, 2020 5:02 am

Almost 12 months are passed and no information... no plans, no progress.

I need to make DNS queries outside local network via secured channel to improve confidentiality.
In my scenario Mikrotik router is used as DNS cache.
So all local DNS queries are made using that Mikrotik server.
Why is it not possible to make external DNS calls using DoH?
All clients connected to local network will give encrypted DNS communication without need to setup each client (or even software).

Hey Mikrotik guys, please tell us why not?

inteq · Sun Jan 12, 2020 9:52 am

I might be a minority here, but all this DNS over https/TLS,etc, in my opinion, has nothing to do with user's privacy at all, but it has everything to do with making ad blocking and corporate filtering obsolete.

guipoletto · Mon Feb 03, 2020 12:24 pm

I might be a minority here, but all this DNS over https/TLS,etc, in my opinion, has nothing to do with user's privacy at all, but it has everything to do with making ad blocking and corporate filtering obsolete.

Agreed, DOH is BULL.

The only things it archieves are:

1- completely breaks local caching, therefore causing problems in networks with high latency. (basically everyone on radio.)

2- ensures no one besides google will have visibility on DNS-query statistics (google collects its data chrome, that's why they pledge no data collection server-side. they already have all the data they want from chrome.).

this is mostly a powerplay by google, at the cost of performance in the whole internet infrastructure.
disguised off course, as the latest and greatest privacy thing.

msatter · Mon Feb 03, 2020 1:36 pm

DOT is blockable by blocking UDP/TCP port 853 and so controlable in a network. DOT in the router, using and offering, is not a bad thing and even wished for.

In ROS I can enforce which DNS server is used except when I use IKEv2 to a provider.

DOH is there to avoid control and that should only be used where is no free internet. It is like working with a host file with all the IP-addresses you need in there.

You could send dummy requests to local DNS server to keep up appearances but if is looked at the traffic it will still show you are looking a different site.

VPN is a possible solution which also provides DNS. But you have be allowed reach the IP addres of the VPN server.

Mon Feb 03, 2020 1:39 pm

2- ensures no one besides google will have visibility on DNS-query statistics (google collects its data chrome, that's why they pledge no data collection server-side. they already have all the data they want from chrome.).

What does it have to do with Google? In Firefox you can enter any DOH server you want.

pe1chl · Mon Feb 03, 2020 3:47 pm

I might be a minority here, but all this DNS over https/TLS,etc, in my opinion, has nothing to do with user's privacy at all, but it has everything to do with making ad blocking and corporate filtering obsolete.
Agreed, DOH is BULL.

The only things it archieves are:

1- completely breaks local caching, therefore causing problems in networks with high latency. (basically everyone on radio.)

More interesting is that it breaks local DNS server functions e.g. setting static names in your MikroTik router for e.g. the local printer or another local service.
You can now only have DNS entries in a public internet DNS server, and even then it does not work by default when the address is e.g. 192.168.88.2
(such addresses are blocked by default when DoH is configured)

StubArea51 · Mon Feb 03, 2020 4:10 pm

I might be a minority here, but all this DNS over https/TLS,etc, in my opinion, has nothing to do with user's privacy at all, but it has everything to do with making ad blocking and corporate filtering obsolete.

I would tend to disagree. The case you mention is only one possible application of DNS over HTTPS.

There are many places in the world where the Internet is restricted and tools like this help users in those regions to browse privately. There are other use cases as well but increased privacy and encryption for the end user is a trend that will continue IMO.

pe1chl · Mon Feb 03, 2020 4:17 pm

There are many places in the world where the Internet is restricted and tools like this help users in those regions to browse privately. There are other use cases as well but increased privacy and encryption for the end user is a trend that will continue IMO.

But the privacy/restriction problem will only move from the ISP resolver to the DoH resolver chosen. Whether that is an improvement, depends on the local situation.

StubArea51 · Mon Feb 03, 2020 4:28 pm

But the privacy/restriction problem will only move from the ISP resolver to the DoH resolver chosen. Whether that is an improvement, depends on the local situation.

That's a great point, but at least the user has the choice of which DNS resolver to trust and it's obscured to the transit providers.

anav · Mon Feb 03, 2020 4:37 pm

This entire thread is way over my head, but smatter........ I tried DNS over pihole and all it got me was grief from the family as the internet would work intermittently or not at all.
There is no clean implementation path I could discern using pihole (how to set it up without effing up my router configuration or creating a monster mess). Obviously beyond my capabilities so I ditched the effort.

Just trying to keep it real, in terms of supporting extra capabilities when deemed, by the angry red bird, to be of sufficient practicality and purpose by adding said functionality to the router!!!!

inteq · Mon Feb 03, 2020 5:44 pm

But the privacy/restriction problem will only move from the ISP resolver to the DoH resolver chosen. Whether that is an improvement, depends on the local situation.
but at least the user has the choice of which DNS resolver to trust and it's obscured to the transit providers.

The question is: will the user have a choice or Google will use its own DNS no matter what the users chooses?
Or better yet, what will stop X or Y to use their DNS over whatever and just bypass the user's choice?

StubArea51 · Mon Feb 03, 2020 6:01 pm

I prefer 9.9.9.9 / 2620:fe::fe

It has malware protection and is very transparent about not storing or tracking user data.

https://www.quad9.net/policy/

msatter · Mon Feb 03, 2020 7:03 pm

This entire thread is way over my head, but smatter........ I tried DNS over pihole and all it got me was grief from the family as the internet would work intermittently or not at all.
There is no clean implementation path I could discern using pihole (how to set it up without effing up my router configuration or creating a monster mess). Obviously beyond my capabilities so I ditched the effort.

Just trying to keep it real, in terms of supporting extra capabilities when deemed, by the angry red bird, to be of sufficient practicality and purpose by adding said functionality to the router!!!!

Sorry to read that and I think you had problems with DHCP. First I setup it without being it also a DHCP server and just get it resolving DNS locally. Then look if a client can resolve by using dig miktotik.com @192.168.88.X and the IP is from the pi-hole.
Then can tell the DHCP in the router that there is new DNS server and it takes time till the clients are informed about it. It could take more than a day in which all keep working.
After the clients are using the pi-hole now you could also force the router to use pi-hole.

Pi-hole DHCP is something you could use but don't have to.

The soon to be released Pi-hole 5.0 has become database driven and CNAME aware. I think that it is ready to come out the Beta period in a few weeks. In the works a control webclient wich does not need a separate webserver anymore.

guipoletto · Mon Feb 03, 2020 9:42 pm

2- ensures no one besides google will have visibility on DNS-query statistics (google collects its data chrome, that's why they pledge no data collection server-side. they already have all the data they want from chrome.).
What does it have to do with Google? In Firefox you can enter any DOH server you want.

Google is going to enable DOH by default in future versions of chrome, firefox is going to use Cloudflare by default.

https://arstechnica.com/information-tec ... ventually/
https://arstechnica.com/tech-policy/201 ... ng-on-you/

anav · Tue Feb 04, 2020 5:00 pm

Thanks msatter, please contact me (via my profile) if you have spare time so we can converse on pihole separately from this thread.
Much thanks!

TheSirStumfy · Mon Feb 10, 2020 10:19 am

Privacy up down, data collected here there...

Can we expect support for this?

Than users themselves can decide who or what thew want to use, DNS DoH DoT...

idlemind · Mon Feb 10, 2020 4:23 pm

Of course when these techniques become universally implemented, we need to make a sticky topic for the many users that come here with requests like:

- I need to block some specific website (Youtube/Facebook/whatever)
- I need to allow access to only one specific website (externally hosted company site)
- I need to limit the use of bandwidth by this or that service, e.g. operating system updates

etc. There can be a simple cooked reply stating that these things are no longer possible, and that all recipes those people find that claim to solve it do no longer work.
And also that despite information they have read elsewhere, other manufacturer's equipment cannot do it either.

At first sight it may seem that this privacy is a good thing, but of course it will cause some things to collapse, like free Wifi for visitors and limited-bandwidth wireless internet connectivity with purposely limited usage.

Or just limit the whole connection and stop trying to get fancy. If you can't serve 20mbps then dont try to for some things and not others. I really don't care if my Gmail runs at full speed but u can't watch a YouTube video on your WiFi, the end result is the feeling that it's broken.

Here in the US you're not responsible for what people do on a free WiFi connection. Funny enough captive portals aren't required either.

The one exception I'll give you is schools. They have some rules that say Internet access has to be restricted. How they will cope with these regulations will be interesting. The only feasible solution I see is malware (read: security software) on all network connected devices and no connectivity otherwise.

whitbread · Wed Feb 12, 2020 10:32 am

Just block dammit client-side DoH and DoT DNS. DNS is router's job - no matter if UDP-53, DoH or DoT. I do not see any argument for secure DNS, but I would never use my ISP's DNS either.

Wed Feb 12, 2020 10:40 am

How do you plan to block DoH from your clients?

msatter · Wed Feb 12, 2020 11:56 am

A begin:

Current DNS/DOT:
1.1.1.1
8.8.4.4
8.8.8.8
4.2.2.2
4.2.2.1
14.215.150.17
14.215.155.156
14.215.155.170
14.215.155.203
42.120.214.1
58.247.212.48
58.247.212.36
58.247.212.119
61.129.8.159
61.151.180.44
61.215.150.17
101.226.220.16
111.161.57.77
111.161.57.81
121.161.220.16
121.51.128.164
149.112.112.112
151.51.1.151
180.76.76.76
180.163.19.5
182.140.167.188
182.140.167.166
216.239.35.0/24
223.5.5.5

Added block-doh:
9.9.9.9
9.9.9.10
45.32.105.4
45.32.253.116
45.77.124.64
47.96.179.163
104.16.248.249
104.16.249.249
104.236.178.232
104.28.0.106
104.28.1.106
108.61.201.119
116.203.35.255
116.203.70.156
118.89.110.78
136.144.215.158
139.59.48.222
146.185.167.43
149.112.112.10
149.112.112.9
185.228.168.10
185.228.168.168

Current DNS/DOT:
2001:4860:4860::8844
2001:4860:4860::8888
2620:fe::fe

Added from block-doh:
2001:19f0:4400:7bcc:5400:1ff:fed1:8599
2001:19f0:6001:146f:45:77:124:64
2001:19f0:7001:1ded:5400:1ff:fe90:945b
2001:19f0:7001:27a2:45:32:253:116
2001:470:f324::45:77:124:64
2001:470:ff0a::45:32:253:116
2604:a880:1:20::51:f001
2606:4700:30::681c:16a
2606:4700:30::681c:6a
2606:4700::6810:f8f9
2606:4700::6810:f9f9
2620:fe::10
2620:fe::9
2620:fe::fe:10
2620:fe::fe:9
2a01:4f8:1c1c:5e77::1
2a01:4f8:1c1c:75b4::1
2a01:7c8:d002:1ef:5054:ff:fe40:3703
2a03:b0c0:0:1010::e9a:3001

$i a=dns.aa.net.uk
$i a=dns.aaflalo.me
$i a=dns-nyc.aaflalo.me
$i a=dns.adguard.com
$i a=dns-family.adguard.com
$i a=doh.dnswarden.com
$i a=ecs-doh.dnswarden.com
$i a=ads-doh.securedns.eu
$i a=dns.alekberg.net
$i a=dns.brahma.world
$i a=dns.cloudflare.com
$i a=commons.host
$i a=dns.containerpi.com
$i a=dns.digitale-gesellschaft.ch
$i a=doh.dns.sb
$i a=dns1.dnscrypt.ca
$i a=dns2.dnscrypt.ca
$i a=doh.cleanbrowsing.org
$i a=doh.crypto.sx
$i a=doh-ipv6.crypto.sx
$i a=doh-de.blahdns.com
$i a=doh.eastus.pi-dns.com
$i a=doh-fi.blahdns.com
$i a=fi.doh.dns.snopyta.org
$i a=ibksturm.synology.me
$i a=doh-jp.blahdns.com
$i a=doh.northeu.pi-dns.com
$i a=doh.westeu.pi-dns.com
$i a=doh.westus.pi-dns.com
$i a=doh.appliedprivacy.net
$i a=doh.ffmuc.net
$i a=doh.li
$i a=doh.tiarap.org
$i a=edns.233py.com
$i a=ndns.233py.com
$i a=sdns.233py.com
$i a=wdns.233py.com
$i a=dns.google
$i a=jp.gridns.xyz
$i a=doh.tiar.app
$i a=public.dns.iij.jp
$i a=jp.tiar.app
$i a=jp.tiarap.org
$i a=doh.libredns.gr
$i a=dns.nextdns.io
$i a=doh.powerdns.org
$i a=doh.seby.io
$i a=doh-2.seby.io
$i a=dns.twnic.tw
$i a=dns9.quad9.net
$i a=ea-dns.rubyfish.cn
$i a=uw-dns.rubyfish.cn
$i a=dns2.alekberg.net
$i a=doh.securedns.eu
$i a=dns.t53.de
$i a=doh.xfinity.com

Wed Feb 12, 2020 12:31 pm

Good luck blocking all the cloud providers, since anyone can host any service anywhere.

msatter · Wed Feb 12, 2020 1:28 pm

I already use a DoH/DoT server in front of Pihole so the browsers/devices I use. The settings have to changed if an other server is going to be used.

Malware software can build their own connection over DoH but that has first have pass Netguard or the HIPS to have access to the network.

DoH is a way to hide and not to be used in normal situations. If your ISP is selling your DNS data then DoT is also possible. If that is blocked then then are rightfully going to use the way of hacking yourself out with DoH.

Wed Feb 12, 2020 1:33 pm

Don't forget about countries that spy on people, block information, etc. This is a whole debate with many sides.

msatter · Wed Feb 12, 2020 2:42 pm

I slowly realise that a problem is that RouterOS have not certificates in store. Thus implementing DoT is not easy. However, ROS can do https so why not have that automatic certificate checking available for other services like IKEv2 to VPN providers?

pe1chl · Wed Feb 12, 2020 4:58 pm

Don't forget about countries that spy on people, block information, etc. This is a whole debate with many sides.

DoH moves the problem of spying from the country of the user to the country of the DoH hoster. Not always an improvement!

Wed Feb 12, 2020 5:03 pm

You can host your own DoH server somewhere. Also, if the problem is blocking of news websites, maybe you don't care if Cloudflare is spuying on you.

pe1chl · Wed Feb 12, 2020 6:11 pm

In our country, news websites are not blocked. Some Movie/Music sharing websites are. But they are blocked both on ISP DNS and on IP address.
However, DNS queries are not captured and redirected so there is no difference between using ISP DNS or one's own DNS resolver or even big player DNS resolvers operating on port 53.

But, when you send your traffic (either only DNS or all traffic) via encrypted tunnel (DoH/DoT) to some hoster in another country, you essentially expose yourself to the monitoring and blocking mandated in that other country. When Trump does not like what our local paper writes about him, he may require Google/Cloudflare/etc to block that website or he may require them to log my visits to that site to use it against me should I want to visit the USA.

Not really an improvement over using local DNS.

whitbread · Wed Feb 12, 2020 7:58 pm

Good luck blocking all the cloud providers, since anyone can host any service anywhere.

So true - this is holy sh*t! Actually I am in fact using a doh-blocklist, but if I am not trusting this anymore the only way to go is HTTPS inspection - nothing I'd like to do either. If I cannot trust my clients anymore being shielded by PiHole I will have to. This is why I don't like DoH personally, but I don't have to deal with blocking by ISP or gov of course.

pe1chl · Wed Feb 12, 2020 9:21 pm

Good luck blocking all the cloud providers, since anyone can host any service anywhere.
So true - this is holy sh*t! Actually I am in fact using a doh-blocklist, but if I am not trusting this anymore the only way to go is HTTPS inspection - nothing I'd like to do either. If I cannot trust my clients anymore being shielded by PiHole I will have to. This is why I don't like DoH personally, but I don't have to deal with blocking by ISP or gov of course.

No, you are doing the blocking yourself and it is your clients who have to deal with a blocking ISP

Thu Feb 13, 2020 9:40 am

I still don't understand how you can trust your country government (which is known for blocking and filtering information), but don't trust Mozilla, Cloudflare and Google

pe1chl · Thu Feb 13, 2020 12:38 pm

I still don't understand how you can trust your country government (which is known for blocking and filtering information), but don't trust Mozilla, Cloudflare and Google

Well, in some countries people trust their local government more than they trust the USA where there can be a president like Trump.
But of course this decision depends on the trust you can have in the local government as well.

Here, these blocks are not made by the government but by the court of justice, who receive requests from institutions protecting e.g. artists who want to sell music and find it freely downloadable on internet. They request that certain sites be blocked, and sometimes this request is granted (of course it makes no difference at all for the downloading of music).
They have mostly focussed on the Bittorrent system.

As I have no interest in using Bittorrent to download music or videos, I am not affected by that silly battle, and I have no problem using plain DNS.
In other countries it may be different, e.g. because news sites or other sites with opinions against the government are blocked. That does not happen here.
But I see no reason to hand over even more data to Mozilla, Google and Cloudflare than already happens by default. We do not know what happens with the data.

msatter · Thu Feb 13, 2020 9:27 pm

Normis reacted many times in this thread. Can you more specific what you are looking for or want to contribute.

Just asking to write something is mostly a shot in the dark.

Have you read the pages I linked to in the other thread? That was about dns leaking and this is about the way traffic that goes between you and the dnsserver.

Sob · Thu Feb 13, 2020 10:47 pm

It looks like creative spammer to me. Seven posts in hour and half and every single one of them completely useless. I expect that there will be spam signature added in few days. The only unusual thing is that account was registered few months ago.

whitbread · Thu Feb 13, 2020 11:07 pm

I still don't understand how you can trust your country government (which is known for blocking and filtering information), but don't trust Mozilla, Cloudflare and Google

And I don‘t understand how anyone can trust G**gle at all. In fact all US-based services are to be untrusted. I don‘t use government‘s or ISP‘s DNS services either, nonetheless my gov does not do blocking or filtering.

msatter · Thu Feb 13, 2020 11:30 pm

If you use a validating, recursive, caching DNS resolver you don't need any ISP or any other resolver that is providing a DNS service.

You are then asking the authorative servers themselves and so cutting out all the collectors/providers in between. Those big firms will only know of that resolve when they are the authorative server for that domain. You request goes plain over the internet but then you csn alway put that traffic in a VPN tunnel.

https://en.m.wikipedia.org/wiki/Name_server

I am using it now for several years and it as fast or faster then using the DNS of my ISP. Unbound is very flexible and full of features you can only dream of and give you full control of what you need. It has DoT serving to clients and if you want to use a DoT server to resolve, it works great.

No DoH supported, I don't expect that ever happening. Knot resolver is also such a kind of server that has similar or more features.

If you want be indepented then run you own DNS recursive server. Running great on just a RaspberryPI board.

vortex · Thu Feb 27, 2020 3:28 pm

Is this really better than going through your ISP for EU users?

Thu Feb 27, 2020 3:30 pm

Like said many times before, it depends on your country and your ISP.
Some people have strong censorship, some are afraid of their governments.

So in the end, information will flow somewhere, this feature allows you to control who you trust more.

vortex · Thu Feb 27, 2020 4:00 pm

I think Firefox just defaulted everybody to Cloudflare.

Thu Feb 27, 2020 4:14 pm

I personally trust cloudflare more than my ISP, but you are free to turn it off.

Screenshot 2020-02-27 at 16.14.10.png

vortex · Thu Feb 27, 2020 4:29 pm

So there's no EU equivalent?

Thu Feb 27, 2020 4:37 pm

https://dnsprivacy.org/wiki/display/DP/ ... +Resolvers

pe1chl · Thu Feb 27, 2020 4:40 pm

It would be nice when MikroTik finally implemented support for static records that return NXDOMAIN in RouterOS so Firefox can do their canary lookup and the admin can select the desired behavior....

vortex · Thu Feb 27, 2020 4:54 pm

https://dnsprivacy.org/wiki/display/DP/ ... +Resolvers

I see nothing from the EU jurisdiction that is similarly well-known.

vortex · Thu Feb 27, 2020 11:25 pm

What I read was not accurate, Mozilla is only rolling out the Cloudflare default in the US for now.

Wed Mar 04, 2020 4:45 pm

I see a Finland server here https://blahdns.com/

vortex · Fri Mar 06, 2020 6:14 pm

But the ISP can just perform a reverse lookup.

Mon Mar 09, 2020 9:15 am

Lots more EU servers here https://github.com/curl/curl/wiki/DNS-over-HTTPS

lucius · Fri Mar 13, 2020 7:23 pm

I didn't go through every post, but I noticed that at some point normis asked for a use case.

Example 1:
There are companies that have on-prem systems, that are used both from the Internet and from the corp LAN.
Let's say company has an email server, located on domain "email.company.net". The server lives inside the company network. People have laptops, mobile phones, etc. All of that connects to hostname "email.company.net". When accessing that hostname from inside corp LAN, you have to resolve "email.company.net" hostname to some internal IP address. So it can point local users to a local IP. You don't access a local server via a public IP, from inside a NAT routed network (maybe with some magic you could, but it's far less dirty to just give out the local IP to the client). So, in your local DNS you add a record (static entry in Mikrotik) for the hostname. The client receives a local IP address of the server, available inside the LAN and problem is solved. Clients only need to use that DNS server (and DHCP gives then the proper one) and that's it. Everything works from the Internet and also when you're inside the corp network where the servers actually live.
This approach solves availability of resources from both corp LAN and Internet, where this is needed.

Example two:
Another example are systems that are not at all available from the Internet directly, but only from through a VPN. Many companies employ this. So, the client (or the entire client network) first has to connect to VPN, then access resources. If this VPN is resolved with Mikrotik (many RB devices, even the cheap ones, have nice hardware offloading for IPSEC, so it's a very good solution for site-to-site VPN) it's all good. We just use static entries in DNS in ROS and point clients to use DNS from ROS. And everything works. No need for additional DNS server.

And this all works well for IMAP, SMTP etc, because normally everything on the machine uses DNS server as set up on the system. So email clients and custom applications all work. But what about browsers. All is well until a browser decides not to honor system DNS settings. Then, anything in the corp LAN that you try to access through a browser, doesn't work anymore. Same is you're accessing through a VPN. Stuff like CRM, webmail - well, most apps today are web apps anyway, used through a browser.

And now it starting to happen, browsers are trying to reinvent how Internet works. Because... DNS, in it's standard and widely used implementation, is no longer deemed safe enough. Ok, fine. Someone has to lift the standards. Browsers are trying to do it, other apps will probably follow after that. But if Mikrotik doesn't follow this change, and MT is used to provide DNS queries, then setups like the ones described in above examples will stop working.

Yeah, we can use a separate DNS server that would solve this, of course, and maybe we should. But why not have it in ROS, as an option at least. Network-wise we have (almost) everything you can imagine in ROS - even stuff you wouldn't expect to have. But none of the more recent DNS stuff. Why ? Why would Mikrotik not provide a solution that solves this issue, like any other network related issue it already solves, in the same box ?

I understand that many proposals exists to solve DNS problem and it's not yet clear which one is going to be used in future. It's hard to know what to implement. One way is to implement just the ones that browsers are going for -> because those are the ones we're going to need to have in our network for above setups to continue working. And that's probably the ones that everyone is going to switch to in the end.

I believe these setups (like the ones mentioned above) are not at all uncommon. Well, maybe people don't use ROS for DNS in such cases, but you get the point. So, again, yes, we can solve this by installing a compatible DNS inside our network, but... ROS was always able to handle this stuff for us, without the need for additional equipment. Why would we need to change that. Is it too heavy load for a Mikrotik device (TLS handshakes and all that) ? But recent RB-s are not at all slow, I guess this won't be a problem. Or would it be ? Normis, could you provide any insight regarding this ?

Regards,
David

kerafyrm · Thu Apr 09, 2020 6:46 am

For the sake of argument, can you give some examples why do you need DoH on the router, if you can use it in your browser already?

How about my homepod, robotcleaner, Intelligent curtain and other smart device, and home server like unraid or freenas?
My refrigerator can connect the internet itself to tell me the balance foods.
We are obviously at a time of Internet of Everything, doh or dot is the most useful to everyone.

EvGn · Wed May 06, 2020 11:09 am

There is information when the DoH function will go from beta to release?

eworm · Wed May 06, 2020 11:31 am

There is information when the DoH function will go from beta to release?

When version 6.47 is released to stable channel. There's no date for that, though.

EvGn · Wed Jun 03, 2020 2:39 pm

Tell me how to configure DoH cloudflare, when specifying the address 1.1.1.1 an error occurs: "DoH server connection error, resolving error"
and:

1.PNG

mitry · Wed Jun 03, 2020 8:05 pm

In 6.47 announced DoH support, but it does not working.
I tried servers 1.1.1.1, 8.8.8.8, 9.9.9.9 - no success. How to use it?

tweaker33 · Wed Jun 03, 2020 8:23 pm

In 6.47 announced DoH support, but it does not working.
I tried servers 1.1.1.1, 8.8.8.8, 9.9.9.9 - no success. How to use it?

to use it check the manual form cloudflare at https://developers.cloudflare.com/1.1.1 ... ver-https/

TLDR from the cloudflare page ; in the DoH server field you have to put

https://cloudflare-dns.com/dns-query

anav · Wed Jun 03, 2020 9:48 pm

From other threads........

Fm Normis
Follow these steps exactly:

./ip dns set servers=1.1.1.1,1.0.0.1
./system ntp client set enabled=yes server-dns-names=time.cloudflare.com
./tool fetch url=https://curl.haxx.se/ca/cacert.pem
./certificate import file-name=cacert.pem passphrase=""
./ip dns set use-doh-server=https://1.1.1.1/dns-query verify-doh-cert=yes
./ip dns set servers=""

ALso.......
https://jcutrer.com/howto/networking/mi ... over-https

EvGn · Wed Jun 03, 2020 10:03 pm

From other threads........

Fm Normis
Follow these steps exactly:

./ip dns set servers=1.1.1.1,1.0.0.1
./system ntp client set enabled=yes server-dns-names=time.cloudflare.com
./tool fetch url=https://curl.haxx.se/ca/cacert.pem
./certificate import file-name=cacert.pem passphrase=""
./ip dns set use-doh-server=https://1.1.1.1/dns-query verify-doh-cert=yes
./ip dns set servers=""

ALso.......
https://jcutrer.com/howto/networking/mi ... over-https

why do i need a root certificate?

pe1chl · Wed Jun 03, 2020 10:17 pm

why do i need a root certificate?

Because it is not included in RouterOS.

Jotne · Wed Jun 03, 2020 10:52 pm

I did not use any certificate, just added:

/ip dns
set allow-remote-requests=yes use-doh-server=https://1.1.1.1/dns-query

One line only for DNS and it works fine.

pe1chl · Wed Jun 03, 2020 10:55 pm

With that setup you might as well just omit the DoH and use 1.1.1.1 DNS directly...

Jotne · Wed Jun 03, 2020 11:00 pm

Why?

Do you thing my ISP opens up the https packets and look for DNS packets?
I will add certificate later. This was just for testing purpose, since DoH was just released.

pe1chl · Wed Jun 03, 2020 11:04 pm

Why?

Because a trusted channel is completely useless when you don't validate who is at the other end...

Do you thing my ISP opens up the https packets and look for DNS packets?

No, but neither do I think that my ISP will fiddle with DNS traffic towards 1.1.1.1 (inspecting or modifying it).
So I have not configured DoH.
(even more so because now finally the DNS resolver improvements I have been asking for have been implemented, and they are mutually incompatible with DoH due to a design error at MikroTik)

I will add certificate later. This was just for testing purpose, since DoH was just released.

Setting a working DoH (that will also work after reboot) is still a bit tricky with this version.

anav · Wed Jun 03, 2020 11:22 pm

Hi Pe1chl, (so hard just change ur nick to Pikachu

Please let me know when the MT router is actually ready for doh dns. (without errors in logs for example).
I wish to use it and point all my devices to it.

Assuming that I will still need action redirect chain=dstnat rules to ensure people dont go around lease settings??

w0lt · Thu Jun 04, 2020 4:03 am

Hi Pe1chl, (so hard just change ur nick to Pikachu

He simply doesn't understand us HAMS.

DE W0LT 73's

-tp

Shalom · Thu Jun 04, 2020 4:15 am

I did not use any certificate, just added:
Code: Select all
/ip dns
set allow-remote-requests=yes use-doh-server=https://1.1.1.1/dns-query
One line only for DNS and it works fine.

Just want to share to all people, if you want to verify the DoH server, you can go to https://1.1.1.1/dns-query using the web browser and download the the 3 certificates from the server site. Then import the 3 certificates to your router and it should be fine.
The guide link is using the Mozilla CA which i not necessary to use them all, i just need the DoH server site certificates.
Hope it help you >.<

Jotne · Thu Jun 04, 2020 8:12 am

you can go to https://1.1.1.1/dns-query using the web browser

There are no webpage opening at this url.

Shalom · Thu Jun 04, 2020 10:30 am

you can go to https://1.1.1.1/dns-query using the web browser
There are no webpage opening at this url.

yes correct there is no page, but you can view the site certificate from the browser pad lock and download the 3 certificates from there.

eworm · Thu Jun 04, 2020 11:37 am

Just want to share to all people, if you want to verify the DoH server, you can go to https://1.1.1.1/dns-query using the web browser and download the the 3 certificates from the server site.

Only two certificates are required, use the two with "DigiCert" in name. The "cloudflare-dns.com" certificate is shipped by the server.

emils · Thu Jun 04, 2020 11:56 am

Are you sure it needs the intermediate certificate as well? It works for me with just the root certificate as well. I have published the example on wiki as well if you have any comments:

https://wiki.mikrotik.com/wiki/Manual:I ... over_HTTPS

pe1chl · Thu Jun 04, 2020 12:26 pm

Are you sure it needs the intermediate certificate as well? It works for me with just the root certificate as well.

That depends how the server is configured. It should return the intermediate certificate in the reply, but some servers do not do that.

EvGn · Thu Jun 04, 2020 2:13 pm

Are you sure it needs the intermediate certificate as well? It works for me with just the root certificate as well. I have published the example on wiki as well if you have any comments:

https://wiki.mikrotik.com/wiki/Manual:I ... over_HTTPS

I completed everything that is written in the instructions, I get an error:
DoH server connection error: Connection refused

anav · Thu Jun 04, 2020 2:27 pm

W0lt are you a true ham or one of these quasi fake HAMS that uses internet repeaters LOL.
Whats the point of that!!! When the internet goes down, the we see the true HAMS..... ;-P

PS. Oh yes back to the topic.
Sounds like between Doh error messages and excessive writes to the router, might be best to wait to next patch.

kiler129 · Sun Jun 07, 2020 4:00 am

Are you sure it needs the intermediate certificate as well? It works for me with just the root certificate as well. I have published the example on wiki as well if you have any comments:

https://wiki.mikrotik.com/wiki/Manual:I ... over_HTTPS

I think one thing is unclear here. While my DoH setup is working flawlessly I wonder what's the decision tree for DoH vs UDP. If I have DoH + normal DNS configured which one is used? Is there a fallback if DoH is inaccessible?
Personally, since it's uncertain, I removed the normal DNS and set CF DoH only.

Jotne · Sun Jun 07, 2020 9:12 am

If I have DoH + normal DNS configured which one is used? Is there a fallback if DoH is inaccessible?
Personally, since it's uncertain, I removed the normal DNS and set CF DoH only.

I did comment this as well in the 6.47 thread. There are no way to see if the router uses DoH server or the DNS, so the solution for me was to not use DNS name like this: https://1.1.1.1/dns-query instead of this https://cloudflare-dns.com/dns-query. And no static DNS added. So only DoH that respond to DNS request.

Edit
Did a test and added a DNS server 8.8.8.8, then change DoH to https://1.1.1.250/dns-query (non working IP)
Logg filled quickly up with message like this:

DoH server connection error: SSL: handshake failed: error 14077410 (6)

The Router did not fall back to old DNS, so if DoH is configured and does not work, it stops resolve DNS requests, even if a DNS is configured.

Maybe I can make a script that test if DoH resolve DNS and if not disable it. But not sure how to make it go back to DoH. On solution is to set DoH at start of script, do a test if it works, if yes let it stay with DoH, if not remove DoH and use the DNS server until next time script runs.

sindy · Sun Jun 07, 2020 1:01 pm

Maybe I can make a script that test if DoH resolve DNS and if not disable it. But not sure how to make it go back to DoH.

Take the code below as an inspiration - you can run the check every now and then whenever the DoH server is disabled, and instead of put "success", re-enable the DoH in DNS configuration. Please don't ask me why the value returned by /tool fetch output=file in case of success is a semicolon and whether it will still be the case in next ROS versions.

[me@MyTik] > :if ([:do {tool fetch url="https://1.1.1.1/dns-query\?name=mikrotik.com%26type=A" output=file dst-path=result http-header-field=accept:application/dns-json} on-error={put "failure"}] = ";") do={put "success"}

Jotne · Sun Jun 07, 2020 2:03 pm

Thanks sindy, your script works.

But when I try to add commands to it, it does not work.

:if ([:do {tool fetch url="https://1.1.1.1/dns-query\?name=mikrotik.com%26type=A" output=file dst-path=result http-header-field=accept:application/dns-json} on-error={/ip dns set allow-remote-requests=yes servers=8.8.8.8 verify-doh-cert=yes use-doh-server=""}] = ";") do={/ip dns set allow-remote-requests=yes servers=8.8.8.8 use-doh-server=https://1.1.1.1/dns-query verify-doh-cert=yes}

Also tried to understand it and split to multiline.

:if ([:do {
	tool fetch url="https://1.1.1.1/dns-query\?name=mikrotik.com%26type=A" output=file dst-path=result http-header-field=accept:application/dns-json
} on-error={
	/ip dns set allow-remote-requests=yes servers=8.8.8.8 verify-doh-cert=yes use-doh-server=""}] = ";") do={
	/ip dns set allow-remote-requests=yes servers=8.8.8.8 use-doh-server=https://1.1.1.1/dns-query verify-doh-cert=yes
	}

PS from what I get of information, you should use column in front of commands, like :put not put

sindy · Sun Jun 07, 2020 2:23 pm

Well, if you want it indented, it would be as follows:

:if ([
  :do {
    tool fetch url="https://1.1.1.1/dns-query\?name=mikrotik.com%26type=A" output=file dst-path=result http-header-field=accept:application/dns-json
  } on-error={
    /ip dns set servers=8.8.8.8 use-doh-server=""}
] = ";") do={
  /ip dns set servers="" use-doh-server=https://1.1.1.1/dns-query
}

Or maybe even more properly structured:

:if ([
  :do {
    tool fetch url="https://1.1.1.1/dns-query\?name=mikrotik.com%26type=A" output=file dst-path=result http-header-field=accept:application/dns-json
  } on-error={:nothing}
] = ";") do={
  /ip dns set servers="" use-doh-server=https://1.1.1.1/dns-query
} else={
  /ip dns set servers=8.8.8.8 use-doh-server=""
}

PS from what I get of information, you should use column in front of commands, like :put not put

Correct, but RouterOS is quite tolerant in cases where the context is unambiguous.

You don't need to set all parameters of /ip dns, only those which you really want to change.

Jotne · Sun Jun 07, 2020 3:35 pm

Thanks.

It seems to not work in the fail situation.

If I cut an past this to terminal

{
:if ([
  :do {
    tool fetch url="https://1.1.1.21/dns-query\?name=mikrotik.com%26type=A" output=file dst-path=result http-header-field=accept:application/dns-json
  } on-error={:nothing}
] = ";") do={
  /ip dns set servers="" use-doh-server=https://1.1.1.1/dns-query
} else={
  /ip dns set servers=8.8.8.8 use-doh-server=""
}
}

1.1.1.21 does not exist so should turn of DoH and set DNS. I see terminal replies with: status: failed

PS RouterOS mix of do { and do={ makes me some confused as well.

sindy · Sun Jun 07, 2020 3:58 pm

It seems to not work in the fail situation.
...
I see terminal replies with: status: failed

Yes, you are right, I haven't tested it thoroughly enough, the output value is ";" regardless whether the command succeeds or fails. So you really have to use the on-error to learn the actual result. So it would look as follows:

:local result yes
:do {tool fetch url="https://1.1.1.1/dns-query\?name=mikrotik.ca%26type=A" output=file dst-path=result \
    http-header-field=accept:application/dns-json} on-error={:set result no}
:if $result do={
  /ip dns set servers="" use-doh-server=https://1.1.1.1/dns-query
} else={
  /ip dns set servers=8.8.8.8 use-doh-server=""
}

(use of the result string as a variable name has nothing to do with its use as a name of the destination file for the :tool fetch)

PS RouterOS mix of do { and do={ makes me some confused as well.

This is an example of where the context makes a difference. :do is a command itself, and on-error is one of its parameters; do= is a parameter of an :if command. One of other symptoms of ROS' tolerance is that you may omit the parameter name for some mandatory parameters. So instead of the proper :do command={:put "this"}, you can abbreviate to :do {:put "this"}. With :if, it is the same case: the proper syntax is actually :if condition=($a=$b) do={:put "equals"}, but most people write just :if ($a=$b) do={:put "equals"}

Jotne · Sun Jun 07, 2020 4:18 pm

Works perfectly, and thanks for the explanation of commands. Learning some new every day, even if I am not 20 any more

sindy · Sun Jun 07, 2020 4:35 pm

Works perfectly

Good. And now please explain me the idea behind hiding where you browse from your ISP or government when you can, but cowardly reverting to plaintext DNS whenever it fails.

There are not so many DoH servers out there (yet?), so it is not a big deal for an ISP with a gun (government's or other) aimed at their head to prohibit access to all of them, nor to identify eventual newly appearing ones from your traffic alone.

Jotne · Sun Jun 07, 2020 4:50 pm

And now please explain me the idea behind hiding where you browse from your ISP or government when you can, but cowardly reverting to plaintext DNS whenever it fails.

It not so much what I need, but more that I can do

DNS is one of the things that ISP still has control over (until DoH and other solution)
Reverting to normal DNS is needed, since there are not fail over or priority on the RouterOS DNS. If DoH server stops, everything stops.

When there are more DoH servers out there, it may be a better solution to use an another DoH server as fail over.

roe1974 · Mon Jul 27, 2020 4:34 pm

@Jotne

How often do you run the script with sheduler ?

Richard

Jotne · Tue Jul 28, 2020 8:13 am

00:01:00
Every minute.

IYARINDRA · Thu Oct 08, 2020 12:01 pm

00:01:00
Every minute.

my log filled with this...

Capture.PNG

How to skip this log from script?

ewindes · Fri Oct 16, 2020 5:48 am

FYI, October 2020, and I found that the missing certificate for Cloudflare was "DigiCert ECC Secure Server CA".
(Available from https://cacerts.digicert.com/DigiCertEC ... CA.crt.pem)

After downloading the PEM file, you can upload through the Mikrotik web interface (Files), and import (Certificates).

Who is online