+1 ;)+1 for DNSCrypt
:)Nov 24 00:03:12 | daemon.notice dnscrypt-proxy[1099]: Starting dnscrypt-proxy 1.4.1
Nov 24 00:03:12 | daemon.info dnscrypt-proxy[1099]: Initializing libsodium for optimal performance
Nov 24 00:03:12 | daemon.info dnscrypt-proxy[1099]: Generating a new key pair
Nov 24 00:03:12 | daemon.info dnscrypt-proxy[1097]: Server certificate #143xxx4751 received
Nov 24 00:03:12 | daemon.info dnscrypt-proxy[1097]: This certificate looks valid
Nov 24 00:03:12 | daemon.info dnscrypt-proxy[1097]: Chosen certificate #143xxx4751 is valid from [2015-07-03] to [2016-07-02]
Nov 24 00:03:12 | daemon.info dnscrypt-proxy[1097]: Server key fingerprint is xxx9:BFBA:FAFC:9257:DFDC:68C7:69BF:AC24:94CD:743F:3C1D:4966:134D:FE2C:4BDC:Fxxx
Nov 24 00:03:12 | daemon.notice dnscrypt-proxy[1097]: Proxying from 127.0.0.1:40 to 208.67.220.220:443
i think you missed whole point of suggested by OP,changes/features, ie ability to do it Without tunnels of Any kind.)+1 for DNSCrypt
No one said anything about tunnels or VPN. He said that he was using DNSCrypt-Proxy on tomato for his DNS. Just as many of us are. The whole point of DNSCrypt is to send the DNS through an encrypted tunnel.i think you missed whole point of suggested by OP,changes/features, ie ability to do it Without tunnels of Any kind.
otherwise you can "anything over VPN" around Globe, anyway, but its eventually consume Lot more resources and attract Lot more /unwanted/redundant/ attention.
yes, but low-overhead "embedded" implementation. similarly - nobody would call SSH "tunnel" instead of serious VPN's or atleast IPIP, EOIP, despite similarity.No one said anything about tunnels or VPN. He said that he was using DNSCrypt-Proxy on tomato for his DNS. Just as many of us are. The whole point of DNSCrypt is to send the DNS through an encrypted tunnel.i think you missed whole point of suggested by OP,changes/features, ie ability to do it Without tunnels of Any kind.
otherwise you can "anything over VPN" around Globe, anyway, but its eventually consume Lot more resources and attract Lot more /unwanted/redundant/ attention.
i think too.I think that this feature will be very usefull and rest of routers solutions support DNSCrypt
likewise.I would also like to add my vote for DNScrypt support! I currently run a separate server for this.
If you could add support for this, it would be great for everyone or even DNSCrypt which a lot of people use and is more common/known to them. Either would be acceptable. I kinda expect that RFC7858 would be easier to add as the support for unbound has been out quite a long time now if I recall even tho the RFC is quite young as you pointed out.Doesn't this supersede DNScrypt, plus, is now an accepted standard? https://tools.ietf.org/html/rfc7858
But it is still a very fresh RFC
We are talking about DNSCrypt not DNS over TLSSince it is not mentioned yet...
There is no mention of privacy and you wouldn't expect it due to the SNI issue that you mentioned earlier.DNSCrypt is a protocol that authenticates communications between a DNS client and a DNS resolver. It prevents DNS spoofing. It uses cryptographic signatures to verify that responses originate from the chosen DNS resolver and haven't been tampered with.
Don't look so sad there Mr Coyote......... In any case one has to follow standards, the RFC bouncing ball.Well that problem got resolved... funny how things turn out in completely unexcpected ways... wait, no... https://www.reddit.com/r/linux/comments ... abandoned/
Would love to get this info, please.I'm using dnscrypt via a raspberry in combination with pi-hole and OpenDNS. Works perfectly for alle my internal clients and I dont have to use a dnscrypt proxy on every mashine. If anyone is interested in configuring it (especially as their are some compatibility tricks you have to be aware of) I can provide you a the required steps to make it work
I'm also interested how to add DNSCrypt support on the RPi as currently I'm using two MikroTiks and RaspberryPi with pi-hole and OpenDNS.Would love to get this info, please.I'm using dnscrypt via a raspberry in combination with pi-hole and OpenDNS. Works perfectly for alle my internal clients and I dont have to use a dnscrypt proxy on every mashine. If anyone is interested in configuring it (especially as their are some compatibility tricks you have to be aware of) I can provide you a the required steps to make it work
Yes! This!Doesn't this supersede DNScrypt, plus, is now an accepted standard? https://tools.ietf.org/html/rfc7858
But it is still a very fresh RFC
https://www.theregister.co.uk/2018/10/2 ... _standard/DoH is incompatible with the basic architecture of the DNS because it moves control plane (signalling) messages to the data plane (message forwarding), and that's a no-no.
+1DNS over TLS is now supported both by CloudFlare (1.1.1.1) and Google (8.8.8.8), so looks like it's time =)
Topic started at 30 Jan 2012 09:55 ... we wait for a miracle+1
interesting, how many people still have to write "+1" that this gave the result?
No. It just proves how futile is the idea of implementing nonstandard or nonstable technologies - they are gone withing few years. Where is DNScrypt today? Is it massively accepted? No. If mikrotik implemented it back then, it would be enormous waste of time.Topic started at 30 Jan 2012 09:55 ... we wait for a miracle
ovpn UDP support may be too "enormous waste of time"?No. It just proves how futile is the idea of implementing nonstandard or nonstable technologies - they are gone withing few years. Where is DNScrypt today? Is it massively accepted? No. If mikrotik implemented it back then, it would be enormous waste of time.Topic started at 30 Jan 2012 09:55 ... we wait for a miracle
Wait for standardized solution which is widely accepted. Then ask for support and you got at least a chance...
+10 to "enormous waste of time"?+10
Huh?..HTTPS gives you more security
Well, as it was earlier - by IP addressinability to catch this traffic as an administrator
When will the DoH appear ? Когда же?Huh? Since DNS over HTTPS uses port 443 and there is no visual difference in traffic type, admin can't intercept or block this traffic (except by destination address).
What does it mean?add DNSSEC features
Sent from my C6833 using Tapatalk
https://en.m.wikipedia.org/wiki/Domain_ ... ExtensionsWhat does it mean?add DNSSEC features
Sent from my C6833 using Tapatalk
Both would be the ideal scenario Naturally that I understand that there's budget/resources constrains and prioritization of features, and therefore that is not viable.Instead of wordless pluses, how about a discussion on TLS vs HTTPS.
TLS gives you a specific port and capability to filter and NAT etc. HTTPS gives you more security, but also the inability to catch this traffic as an administrator. More aspects?
Isn't that at the Browser level only?What about SNI? ESNI is not on stage currently
Why not both? Although DNS over HTTPS seems to be the way forward, very few providers are actually deploying DNS over TLS. As long as you maintain a persistent connection to the resolver, latency should be minimal.Instead of wordless pluses, how about a discussion on TLS vs HTTPS.
TLS gives you a specific port and capability to filter and NAT etc. HTTPS gives you more security, but also the inability to catch this traffic as an administrator. More aspects?
add action=dst-nat chain=dstnat dst-address=208.67.220.220 dst-port=53 protocol=udp to-addresses=208.67.220.220 to-ports=5353
add action=dst-nat chain=dstnat dst-address=208.67.222.222 dst-port=53 protocol=udp to-addresses=208.67.222.222 to-ports=5353
Why limit the destination address to one pubic DNS server. Why not just dstport 53 protocol udp/tcp redirect to port 5353 (sounds like dnssec for pihole).Can we just holding back these advanced fancy DNS standards, but support setting up non-standard tcp/udp port in /ip dns?
Just a little update in 6.45, or maybe 6.46...
DNS pollution(intercept plain text like google from udp 53 port then return 127.0.0.1) is very easy way for a ISP to do if mikrotik device (and most common soho devices) only support udp 53.
BTW, I'm using below rules to redirect dns port.Code: Select alladd action=dst-nat chain=dstnat dst-address=208.67.220.220 dst-port=53 protocol=udp to-addresses=208.67.220.220 to-ports=5353 add action=dst-nat chain=dstnat dst-address=208.67.222.222 dst-port=53 protocol=udp to-addresses=208.67.222.222 to-ports=5353
Tested this works with opendns, but failed with cloudflare or some other public dns. (assume ISP rules to intercept opendns is not created for now)Why limit the destination address to one pubic DNS server. Why not just dstport 53 protocol udp/tcp redirect to port 5353 (sounds like dnssec for pihole).Can we just holding back these advanced fancy DNS standards, but support setting up non-standard tcp/udp port in /ip dns?
Just a little update in 6.45, or maybe 6.46...
DNS pollution(intercept plain text like google from udp 53 port then return 127.0.0.1) is very easy way for a ISP to do if mikrotik device (and most common soho devices) only support udp 53.
BTW, I'm using below rules to redirect dns port.Code: Select alladd action=dst-nat chain=dstnat dst-address=208.67.220.220 dst-port=53 protocol=udp to-addresses=208.67.220.220 to-ports=5353 add action=dst-nat chain=dstnat dst-address=208.67.222.222 dst-port=53 protocol=udp to-addresses=208.67.222.222 to-ports=5353
In your rule, somebody hardcoding 8.8.8.8 or 1.1.1.1 would not get trapped.
All good points that have been indefinitely mentioned throughout the forum in numerous threads.Mikrotik is a business, so we have to treat this feature request as such. Not on ideological (privacy of user) or technical (DoT vs DoH) grounds.
That said, the question Mikrotik is asking themselves is obvious. Is this feature "worth it"?
Our approach should be to not only say "yes" with a sea of +1s (by the way, can there not be some annual feature request poll, annual feedback survey or something like that), but provide arguments that support this conclusion.
For example;
Which major DNS providers now offer DoT/DoH?
Which competing network hardware manufacturers provide DoT/DoH or are planning to?
Which consumer devices support DoT/DoH? The point here is that if consumers start using DoT/DoH, then they will expect to see it in the network gear in their homes, workplace, ISPs.
Now, did you expect me to provide answers to the above? Too bad. I'm Friday-lazy, but consider this me trying to get the ball rolling.
Ok, fine. Here's a list of DNS providers https://en.wikipedia.org/wiki/Public_re ... ame_server so it's evident Cloudflare, Google and Quad9 are leading the way.
Also, about consumer devices, we have "Private DNS" in Android 9.0, which accepts DoT.
Regarding competing firms, someone in the know could chime in.
Thank you.Nothing I can see. But it's early beta and the main goal is to have new kernel, not so much new features, even though there are some (not for DNS).
Probably because they are ISPYou want DNS entryption that is easy to be blocked by the ISP? Why?
DoT is not trivial to implement. DoH is much easier to implement.Seriously, thank you to MT for implementing DoH at least.
+1 for DoT though, as they are both different and have their own strengths and weaknesses. As DoH is already implemented, it should be trivial to implement DoT, especially with how well-documented and well-supported it is by most of the world.