DNSCrypt on Asus-Merlin Variants?

[Just Checking]

http://dnscrypt.org/#dnscrypt-windows

I saw in the above web page that DD-WRT and Tomato have DNSCrypt built in. I use the Merlin FW and Fork variants but have not been able to find this.

Is DNSCrypt already included in Merlins FW but I am missing it? If so, can someone tell me where it is?

If it isn't, is there a reason for not doing this? There are several options for the DDNS server that I saw but, this is not one of them.

 

[shooter40sw]

Follow this
https://github.com/RMerl/asuswrt-merlin/wiki/Secure-DNS-queries-using-DNSCrypt

http://dnscrypt.org/#dnscrypt-windows

I saw in the above web page that DD-WRT and Tomato have DNSCrypt built in. I use the Merlin FW and Fork variants but have not been able to find this.

Is DNSCrypt already included in Merlins FW but I am missing it? If so, can someone tell me where it is?

If it isn't, is there a reason for not doing this? There are several options for the DDNS server that I saw but, this is not one of them.

 

[joegreat]

http://dnscrypt.org/#dnscrypt-windows
Is DNSCrypt already included in Merlins FW but I am missing it? If so, can someone tell me where it is?

Hi,

You need Optware/Entware (a small search will show which one for your router) to install it - plus you need to use Merlin's user scripts to start the dnscrypt daemon.
I use it on my main router and it works like a charm (after I understood the tricky timing and started it with Entware after the clock was set to correct time).

With kind regards
Joe

 

[RMerlin]

If it isn't, is there a reason for not doing this? There are several options for the DDNS server that I saw but, this is not one of them.

Because adding new feature is not a priority on this firmware project. And also because very few users uses DNSCrypt, and it's always a pain to deal with it, it screws up CDNs, etc...

 

[Just Checking]

Because adding new feature is not a priority on this firmware project. And also because very few users uses DNSCrypt, and it's always a pain to deal with it, it screws up CDNs, etc...

By CDN are your referring to "Content Delivery Network"? If so, why would DNSCrypt be any worse than any other DNS provider? DNSCrypt seems to be associated with the "Free Web" movement and TOR but not a direct subsidiary.
It seems to me that this would be a logical addition to the security suite of features that have already been added to the router (like OpenVPN and TOR). I would appreciate if you could expand on your explanation to help me understand this better (or provide a link to some references I can study).

I can understand that you don't want to implement something that few people would use. I think that it would be used more if it were easily implementable on the Asus router without the need to use entware and write scripts. Also, I think people would be more concerned about which provider they are using as a DNS if they understood exactly how much information they give away when using a provider like Google.

 

[Just Checking]

Hi,

You need Optware/Entware (a small search will show which one for your router) to install it - plus you need to use Merlin's user scripts to start the dnscrypt daemon.
I use it on my main router and it works like a charm (after I understood the tricky timing and started it with Entware after the clock was set to correct time).

With kind regards
Joe

Joe,
Thanks for the input that you and shooter40sw (love that Nome de Plume) provided. If you could expand on what you did to implement this, I would appreciate it. I have little experience with scripting so I need more handholding to get this implemented.

 

[RMerlin]

By CDN are your referring to "Content Delivery Network"? If so, why would DNSCrypt be any worse than any other DNS provider? DNSCrypt seems to be associated with the "Free Web" movement and TOR but not a direct subsidiary.

Doesn't DNSCrypt require you to use very specific DNS servers that actually support it, which means losing any locale-aware name resolution?

It seems to me that this would be a logical addition to the security suite of features that have already been added to the router (like OpenVPN and TOR). I would appreciate if you could expand on your explanation to help me understand this better (or provide a link to some references I can study).

OpenVPN is there because it's currently the best open source VPN alternative that lives in userspace, and therefore doesn't break module compatibility like IPSec was causing. And OpenVPN is also appearing in a number of OEM solutions these days, it's no longer just a third party exclusive. It's also available in a number of NAS solutions. It's becoming the most popular alternative to PPTP.

Tor is only there because Asus had already developed it (and ultimately decided not to include it apparently), and it only took a few minutes to debug it and enable it - I personally have no interest in it.

 

[Just Checking]

Doesn't DNSCrypt require you to use very specific DNS servers that actually support it, which means losing any locale-aware name resolution?


OpenVPN is there because it's currently the best open source VPN alternative that lives in userspace, and therefore doesn't break module compatibility like IPSec was causing. And OpenVPN is also appearing in a number of OEM solutions these days, it's no longer just a third party exclusive. It's also available in a number of NAS solutions. It's becoming the most popular alternative to PPTP.

Tor is only there because Asus had already developed it (and ultimately decided not to include it apparently), and it only took a few minutes to debug it and enable it - I personally have no interest in it.

In order to achieve my goal of using DNS resolvers that do not log, track, or block name resolutions, I do have to use specific DNS servers which have those features. That doesn't preclude Locale-aware name resolutions if I do not enable proxy server applications on the browser or network. Proxy servers mask my IP anyway so I get to Web Pages that are in the Country where the exit node or proxy server is located. It is the price of trying to be anonymous. Kind of fun actually.

I can see where casual users do not want to bother with being directed to Facebook, Twitter, MSN, or some other site in a different language. I personally don't do any of those for security reasons. The sites I frequent do not need to be Locale-aware.

Thanks again for the TOR implementation on your FW. Network security and encryption are a fascinating subject. I have gotten more headaches from this than any other subject except Quantum Mechanics. The more I research it, the more concerned it has made me since I realize how easily my networks could have been compromised (and probably still are vulnerable). Android and IOS devices seem to have been made specifically to feed information to Google and Apple. They certainly make it difficult enough to try to secure them.

 

[RMerlin]

In order to achieve my goal of using DNS resolvers that do not log, track, or block name resolutions, I do have to use specific DNS servers which have those features.

Why not just run your own recursive resolver? That would be the only sure way to do so.

 

[Just Checking]

Why not just run your own recursive resolver? That would be the only sure way to do so.

Thanks for the suggestion. I will look into that. Since I know very little about it, I will have to research how difficult it will be to implement.

This started out as just trying to get a couple IP addresses to plug into the router and has kind of ballooned.

 

[SnakeByte]

Why not just run your own recursive resolver? That would be the only sure way to do so.

That would solve 1, but not 2 or 3 on his list, no? ISP's (or other three letters) can still track and/or block? Or were you talking about running the recursive resolver elsewhere?

There is a list of DNSCrypt resolvers to choose from (https://github.com/jedisct1/dnscrypt-proxy/blob/master/dnscrypt-resolvers.csv), so choosing one that's nearby should help with the CDN locality issues. However there are only 78 resolvers listed, so slim pickings.

Here are instructions to get DNSCrypt somewhat working with asuswrt-merlin:
https://github.com/RMerl/asuswrt-merlin/wiki/Secure-DNS-queries-using-DNSCrypt

The instructions are missing the race condition fix however. For that, click on the link at the bottom of the instructions about "further discussions." Note too that the fix provided there doesn't work for asuswrt x86... it's using a dnscrypt binary that isn't included with the entware package (dnscrypt-proxy-hostip). You'll have to figure out a work-around that works best for you (such as echoing the ip to ntp server line into /etc/hosts from your post-mount script/

 

[RMerlin]

Basic crash course on DNS...

Each domain has at least two nameservers registered as being authoritative for that domain. Those two are registered on the authoritative nameservers for that TLD (for instance, the .com TLDs).

DNS resolution works recursively, one level at a time.

Let's take www.mydomain.com.

If you run your own recursive resolver (for instance by running Bind9), when you make a query to that server, it starts at the top level (the TLD). It has a list of root servers. It contacts them to ask for a nameserver authoritative for the .com TLD. It gets returned IPs to such servers.

Next step it asks that .com server who is authoritative for mydomain.com. It gets told one of the nameservers registered with that domain (ns1.mydomain.com, for example).

Next, it contacts one of those servers, and asks them "what is the IP for www.mydomain.com", which that nameserver returns.

Your bind9 server then tells your computer "here is the IP you were looking for".

So in the process, all your ISP ever saw was that you made connections to port 53 to the root servers, and then to a specific server tied to mydomain.com. (and if you don't trust that server, then you've got a problem, because you are just about to connect to their web server anyway). At no point did you connect to your ISP's nameservers.

 

[cosmoxl]

Basic crash course on DNS...

Each domain has at least two nameservers registered as being authoritative for that domain. Those two are registered on the authoritative nameservers for that TLD (for instance, the .com TLDs).

DNS resolution works recursively, one level at a time.

Let's take www.mydomain.com.

If you run your own recursive resolver (for instance by running Bind9), when you make a query to that server, it starts at the top level (the TLD). It has a list of root servers. It contacts them to ask for a nameserver authoritative for the .com TLD. It gets returned IPs to such servers.

Next step it asks that .com server who is authoritative for mydomain.com. It gets told one of the nameservers registered with that domain (ns1.mydomain.com, for example).

Next, it contacts one of those servers, and asks them "what is the IP for www.mydomain.com", which that nameserver returns.

Your bind9 server then tells your computer "here is the IP you were looking for".

So in the process, all your ISP ever saw was that you made connections to port 53 to the root servers, and then to a specific server tied to mydomain.com. (and if you don't trust that server, then you've got a problem, because you are just about to connect to their web server anyway). At no point did you connect to your ISP's nameservers.

but if it's unencrypted then they can still see what you were asking for. they can target you with advertising, or perhaps see illegal activity. the owner of the DNS may even share data with "others" so better make sure your DNScrypt server is trustworthy (not cisco!) bottom line, I want privacy and I think others do as well. Using a VPN provider's DNS takes care of this. Outside a VPN much of our traffic is indeed encrypted these days (https) but DNS requests never are. You can be sure ISPs and the like are mining that data like crazy.

 

[RMerlin]

but if it's unencrypted then they can still see what you were asking for. they can target you with advertising, or perhaps see illegal activity.

Who are "they" here?

the owner of the DNS may even share data with "others"

Which DNS? The recursive resolver is on your own machine, it's not someone else's.

The Internet is a PUBLIC network. Face it. If you want privacy, it's like saying you want to be able to go do your groceries, without anyone at the market being able to see what you put in your basket. You go on the Internet, then you become visible, period. Privacy is impossible. The Internet consists of a bunch of routers talking to one another, and these are all under the control of someone else.

Why do people trust some VPN provider in some foreign country, but they don't trust their own local ISP? I will never understand how paying for a VPN tunnel to a company you know next to nothing about is any more "private". If anything, it makes you MORE vulnerable, since ALL your traffic is aggregated in one single location.

Want me to scare you off even more? If you go through 6 or 8 different routers before reaching your tunnel provider, then all of these will transit a packet that contains, in the clear, your IP address. Someone who would really want to go after you only needs to compromise one of those hops between you and the tunnel provider. They will get your IP address. Then, they can just match the traffic coming out of the VPN provider. They might not see your IP in it anymore, but if every time you send get a packet and you get an ack then the tunnel provider also has traffic at the exact same time, then they can correlate the source (you) with the final destination (on the other side of the VPN provider). If they compromise any router upstream from the tunnel provider, then they can deduce which destination server you are reaching, and match it to your source IP through timing.

Or they can go to the destination server, obtain logs to find out the list of connections matching the VPN provider's IP block, and match it to their captured traffic between you and the tunnel provider. They just have to match the times, and be able to determine if you did visit that specific site or not.

And since all the traffic between the tunnel provider and the destination site is totally unencrypted, they can also match that traffic with your encrypted traffic, and determine which of those packets belong to you. The VPN only encrypts half of the way between you and the final site. So then they can deduce which of those encrypted packets of yours are related to the unencrypted ones they got upstream from the tunnel provider.

So, how far do you want to try to go toward privacy? It's flat out impossible to fully reach.

 

[cosmoxl]

Who are "they" here?



Which DNS? The recursive resolver is on your own machine, it's not someone else's.

The Internet is a PUBLIC network. Face it. If you want privacy, it's like saying you want to be able to go do your groceries, without anyone at the market being able to see what you put in your basket. You go on the Internet, then you become visible, period. Privacy is impossible. The Internet consists of a bunch of routers talking to one another, and these are all under the control of someone else.

Why do people trust some VPN provider in some foreign country, but they don't trust their own local ISP? I will never understand how paying for a VPN tunnel to a company you know next to nothing about is any more "private". If anything, it makes you MORE vulnerable, since ALL your traffic is aggregated in one single location.

Want me to scare you off even more? If you go through 6 or 8 different routers before reaching your tunnel provider, then all of these will transit a packet that contains, in the clear, your IP address. Someone who would really want to go after you only needs to compromise one of those hops between you and the tunnel provider. They will get your IP address. Then, they can just match the traffic coming out of the VPN provider. They might not see your IP in it anymore, but if every time you send get a packet and you get an ack then the tunnel provider also has traffic at the exact same time, then they can correlate the source (you) with the final destination (on the other side of the VPN provider). If they compromise any router upstream from the tunnel provider, then they can deduce which destination server you are reaching, and match it to your source IP through timing.

Or they can go to the destination server, obtain logs to find out the list of connections matching the VPN provider's IP block, and match it to their captured traffic between you and the tunnel provider. They just have to match the times, and be able to determine if you did visit that specific site or not.

And since all the traffic between the tunnel provider and the destination site is totally unencrypted, they can also match that traffic with your encrypted traffic, and determine which of those packets belong to you. The VPN only encrypts half of the way between you and the final site. So then they can deduce which of those encrypted packets of yours are related to the unencrypted ones they got upstream from the tunnel provider.

So, how far do you want to try to go toward privacy? It's flat out impossible to fully reach.

As I wrote above I was speaking only to the desire to use dnscrypt. I wasn't writing about running your own recursive resolver.

I agree with you %100 about the futility of true privacy when it comes to a significantly powerful adversary.

 

[Cake]

Are there VPN providers out there that put all their users behind a shared NAT in a private ip class? I thought that was how it works to keep your real IP secret. PIA lets you pay with gift cards too, so I think that helps, as long as you trust your vpn provider.

I have been playing around with DNSCrypt on Mint Cinnamon, and also put unbound running as a dns cache on 127.0.0.3. It works great. The wifi system I am on at work is not mine, and they use opendns to spoof the dns port 53, and that blocks/redirects websites like youtube. Now dns's that are cached load instantly plus I have access to soundcloud, youtube and all the other fun stuff. I really want to put dnscrypt on my router at home, but have no need really since I use a vpn.

 

[RogueSpear]

I am a citizen of and reside within the United States. Verizon is my ISP (FiOS). I trust neither my government nor my ISP and in fact I view both of them having antipathy for their citizenry and customers respectively. While I don't think I have anything hide (who knows what is considered damning these days), I'm certainly not going to assist them in their data gathering efforts either. So far as the VPN providers that I subscribe to - I don't have the resources, and likely wouldn't be granted the permission, to visit their facilities, inspect their servers, and interview their employees. So the best I can do is rely on resources like privacytools.io for some guidance.

So for the sake of the discussion, let's assume my VPN provider does not in fact keep tabs on me. All of my traffic, except for that which I specify, goes in and out of a VPN tunnel to a VPN server where my traffic is among many others coming in and out of the same public facing IP address. My DNS traffic uses the same tunnel and, ideally, uses DNScrypt. My web browsing mostly takes place within SSL/TLS for whatever that's worth anymore. I understand that I may be fighting a losing or already lost battle, but I refuse to simply roll over. If I can merely annoy and make life slightly more difficult for some faceless people, I feel that I am at least contributing in some way, the fight to regain at least a modicum of ability to read what I want and talk to whoever I want without being scrutinized. Futile as it may sound, I find it a worthwhile endeavor. That's the long winded explanation of my desire to be using DNScrypt.

So I was told in the .56 beta 2 script that the problem is not with beta 2, but with my configuration. The very same configuration that worked perfectly under .55. Somehow or another when I attempt to use DNScrypt, NTP gets borked. So much so that supplying an IP address in the GUI doesn't even do it. If there is no bug in .56 beta 2, yet going from .55 to .56 beta 2 breaks it - and it's not a bug in beta 2, do you think that there is something in .56 beta 2 that would require the lancethepants binaries to be updated/recompiled? I'm just trying to find out what the problem is and perhaps assist in fixing it.

 

[joegreat]

So I was told in the .56 beta 2 script that the problem is not with beta 2, but with my configuration. The very same configuration that worked perfectly under .55. Somehow or another when I attempt to use DNScrypt, NTP gets borked.

Hi,

I am pretty sure it's just a timing issue to get things done in the right order (as I already posted in #3)!

I was also fiddling around some time to get the right order for
- mounting both of the 2 USB drives (they are not always mounted in the same order)
- resolving the DNS names for the NTP servers (via hostip command)
- setting the correct time with NTP (needed for the validation of the dns-crypt certificate)
- starting Entware (which finally starts the dnscrypt-proxy)

A new version of the firmware by sure will change some timings and most likely your NTP does not set the time before you start dnscrypt...

With kind regards
Joe

 

[RMerlin]

So I was told in the .56 beta 2 script that the problem is not with beta 2, but with my configuration. The very same configuration that worked perfectly under .55. Somehow or another when I attempt to use DNScrypt, NTP gets borked. So much so that supplying an IP address in the GUI doesn't even do it. If there is no bug in .56 beta 2, yet going from .55 to .56 beta 2 breaks it - and it's not a bug in beta 2, do you think that there is something in .56 beta 2 that would require the lancethepants binaries to be updated/recompiled? I'm just trying to find out what the problem is and perhaps assist in fixing it.

I doubt that a recompile would be required. I suspect that it's caused by a timing issues related to the order in which each service gets started. Asuswrt does not use a well defined service hierarchy (unlike a typical Linux distro that uses SysV init scripts, Upstart, or whatever other scheme where dependencies are clearly ordered). My guess is some services might not be started in the exact same order in 378.56 than they were in 378.55, which breaks DNSCrypt. A good example is the ntp issues that was recently diagnosed - three different users had a config script that caused dnsmasq to fail to start until, by pure luck, it happened to be restsarted after the USB disk got mounted, which made it work in 378.55 despite the broken configuration. 378.56 simply didn't happen to try to restart dnsmasq/ntp at the precise moment required. So it turned out it was not a bug in 378.56, simply that the bug in their config file wasn't triggered in 378.55, through pure luck.

I still want to spend some more time to see if the whole NTP setup could be made more resilient to such errors. But I cannot start basing development specifically on the current DNSCrypt implementation, as this would require debugging BOTH the firmware services and the DNSCrypt implementation.

Someone will have to do the legwork on the DNSCrypt side of things to determine why it's failing, and then see if it's due to a change in the service start order, or something else. Yes, bugs can exist in the firmware, however since all its built-in services are currently starting properly, the chances that a bug in the firmware is responsible for the DNSCrypt issues is rather low.

I cannot start debugging both the firmware (which is already beyond my ability to entirely debug as a single, unique developer) and the whole DNSCrypt implementation.

The starting point would be to take a closer look at the scripts that are used to start it. The binary files should be fine, there was no low-level change in the firmware's environment to break them.

 

[RMerlin]

One additional bit of advice I can give: do not rely on the USB disk being available in ANY script, unless this is a post-mount script. Any other script or custom config file should first make sure that the USB disk is present before trying to use it in a config file. See the postconf script I posted in the 378.56 beta 2 thread for an example on how to do so.

If you need access to a config file at a very early point in the boot process, store it in JFFS. The earliest script run by the firmware, init-start, gets run immediately after the JFFS partition gets mounted (and before almost anything else).