What's new

DNScrypt dnscrypt installer for asuswrt

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

The referenced DCs are presence points aka PoPs. The point of my post was on recursive servers - the servers that are used to build cloudflare's cache for 1.1.1.1/1.0.0.1 services ... These appear to be based in the US which is why content delivered over CDNs is mainly delivered via the US.

So unless cloudflare creates local/regional recursive services in those presence points you referenced, most CDN services will continue to serve you content via the US.
I understood from Cloudfare's blog post that indeed their recursor service runs in each data center = points of presence. What made you think otherwise?

You are totally missing the point. I am getting great query times too but most CDN delivered content is being served from the US versus the nearest CDN PoP.

Please read up on CDN and Anycast DNS with single and multi recursive sources. You'll save me a few grey hairs.
Can you give some examples of URLs where this happens? I'm in Belgium and have not been able to replicate what you describe while using 1.1.1.1. I can understand your theory, but if the Cloudfare PoP is close to your ISP (which it is in my case) and the CDN geolocation knows it is, it should work well even without EDNS Client Subnet?

I have tested using the dnsperfbench tool with the -httptest option as mentioned in this blog post:
https://www.sajalkayan.com/post/cloudflare-1dot1dot1dot1.html

The tool can be downloaded here:
https://github.com/turbobytes/dnsperfbench/releases

If I try this, I get a close IP answer from Cloudfare, OpenDNS and Google:
Code:
./dnsperfbench -resolver 195.130.130.1 -httptest https://turbobytes.akamaized.net/static/rum/100kb-image.jpg
+-------------------------------------+--------------------+-------+---------+-------+-------+----------+--------+
|              RESOLVER               |       REMOTE       |  DNS  | CONNECT |  TLS  | TTFB  | TRANSFER | TOTAL  |
+-------------------------------------+--------------------+-------+---------+-------+-------+----------+--------+
| 195.130.130.1 (Unknown)             | 2.22.55.122:443    | 20ms  | 13ms    | 41ms  | 13ms  | 22ms     | 108ms  |
| 1.1.1.1 (Cloudflare)                | 92.122.122.160:443 | 17ms  | 15ms    | 39ms  | 13ms  | 25ms     | 109ms  |
| 208.67.222.222 (OpenDNS)            | 2.22.55.120:443    | 26ms  | 14ms    | 43ms  | 13ms  | 22ms     | 119ms  |
| 8.8.8.8 (Google)                    | 2.22.55.120:443    | 40ms  | 15ms    | 32ms  | 13ms  | 21ms     | 121ms  |
| 185.228.168.168 (Clean Browsing)    | 80.239.137.26:443  | 22ms  | 21ms    | 41ms  | 19ms  | 22ms     | 125ms  |
| 9.9.9.9 (Quad9)                     | 2.16.186.96:443    | 27ms  | 22ms    | 56ms  | 19ms  | 28ms     | 152ms  |
| 8.26.56.26 (Comodo)                 | 104.86.110.185:443 | 32ms  | 22ms    | 50ms  | 20ms  | 29ms     | 153ms  |
| 199.85.126.20 (Norton)              | 72.247.178.27:443  | 27ms  | 28ms    | 54ms  | 23ms  | 30ms     | 162ms  |
| 114.114.114.114 (114dns)            | 23.215.104.203:443 | 133ms | 117ms   | 239ms | 120ms | 162ms    | 772ms  |
| 119.29.29.29 (DNSPod)               | 223.119.50.201:443 | 125ms | 220ms   | 473ms | 219ms | 309ms    | 1.346s |
| 180.76.76.76 (Baidu)                | 23.2.16.27:443     | 294ms | 229ms   | 471ms | 231ms | 324ms    | 1.549s |
| [2001:4860:4860::8888] (Google)     | FAIL               | FAIL  | FAIL    | FAIL  | FAIL  | FAIL     | FAIL   |
| [2606:4700:4700::1111] (Cloudflare) | FAIL               | FAIL  | FAIL    | FAIL  | FAIL  | FAIL     | FAIL   |
| [2a0d:2a00:1::] (Clean Browsing)    | FAIL               | FAIL  | FAIL    | FAIL  | FAIL  | FAIL     | FAIL   |
| [2620:fe::fe] (Quad9)               | FAIL               | FAIL  | FAIL    | FAIL  | FAIL  | FAIL     | FAIL   |
| [2620:0:ccc::2] (OpenDNS)           | FAIL               | FAIL  | FAIL    | FAIL  | FAIL  | FAIL     | FAIL   |
+-------------------------------------+--------------------+-------+---------+-------+-------+----------+--------+
The 195.130.130.1 that I added is a DNS resolver from my ISP to compare.

The average ping to the answer above from my local ISP as well as to those from Cloudflare, OpenDNS and Google was 12 ms. The average ping to the answer from Quad9 was 19 ms in this case.

Maybe others can give it a try from their connection to compare? Or could you try it with a URL of something that you got served from the US instead of your nearest CDN PoP? Note that the Windows version that can be downloaded does not seem to give reliable results with the -httptest option. I tested with the Linux binary.
 
Last edited:
I don't use dnscrypt because I consider it an unnecessary overhead with little privacy benefit (at least wrt my ISP and environment).

However, I've started using 1.1.1.1 and quad9 a few weeks ago.

Maybe others can give it a try from their connection to compare?

Thanks for providing turbobytes.akamized.net which is good for litmus test.

Local ISP & google dns servers return an obviously close-by IPv4 address. Can quickly tell from its actual domain name.

Both 1.1.1.1 and quad9 return the same IP which according to online geo databases says this IPv4 belongs in US.

However, checking further (e.g. network latency is as fast as that IP returned by local ISP & google) the IP cannot be in US.

So most likely what happened is that the geo databases are outdated or not updated at all. That latter is very likely for CDN providers. Short of IPv4 addresses and shuffle around faster than geo data update (if updated at all).

At least that's true in my case. So both 1.1.1.1 & quad9 are good.
 
Another way to test this without installing any tool:

Windows:
Code:
nslookup -q=TXT whoami.ds.akahelp.net
Linux:
Code:
dig +short txt whoami.ds.akahelp.net
Using Cloudfare shows me a recursor with an IP that is geolocated (according to MaxMind) in Brussels, Belgium:
Code:
C:\>nslookup -q=TXT whoami.ds.akahelp.net 1.1.1.1
Server:  1dot1dot1dot1.cloudflare-dns.com
Address:  1.1.1.1

Non-authoritative answer:
whoami.ds.akahelp.net   text =

        "ns"
        "162.158.233.17"
OpenDNS uses ECS and shows me a recursor with an IP that is geolocated (according to both MaxMind and the reverse lookup) in Frankfurt, Germany:
Code:
C:\>nslookup -q=TXT whoami.ds.akahelp.net 208.67.222.222
Server:  resolver1.opendns.com
Address:  208.67.222.222

Non-authoritative answer:
whoami.ds.akahelp.net   text =

        "ecs"
        "81.83.14.0/24/0"
whoami.ds.akahelp.net   text =

        "ip"
        "81.83.14.193"
whoami.ds.akahelp.net   text =

        "ns"
        "2620:0:cc7::72"
Google uses ECS and shows me a recursor with an IP that is geolocated (according to MaxMind) in Groningen, Netherlands:
Code:
C:\>nslookup -q=TXT whoami.ds.akahelp.net 8.8.8.8
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
whoami.ds.akahelp.net   text =

        "ip"
        "81.83.14.155"
whoami.ds.akahelp.net   text =

        "ns"
        "173.194.169.108"
whoami.ds.akahelp.net   text =

        "ecs"
        "81.83.14.0/24/0"
Quad9 shows me a recursor with an IP that is geolocated (according to both MaxMind and the reverse lookup) in Frankfurt, Germany:
Code:
C:\>nslookup -q=TXT whoami.ds.akahelp.net 9.9.9.9
Server:  dns.quad9.net
Address:  9.9.9.9

Non-authoritative answer:
whoami.ds.akahelp.net   text =

        "ns"
        "2620:171:f8:f0::6"
So on my connection, Cloudfare appears to do the recursive lookup from a location in Belgium (which is where I live). Both Groningen (Netherlands) and Frankfurt (Germany) are some 300 km away.
 
Last edited:
@LostFreq Do you run dnsperfbench directly on your router? I downloaded the latest linux release, made it executable but it won't run? Some guidance would be appreciated. If I need to start a new thread, just let me know...
No, I tried that but it didn't work (no download for ARM). If you don't have a Linux PC, it is very easy to create a Linux Live-USB stick:
1) Download this Ubuntu Linux desktop image: http://releases.ubuntu.com/16.04/ubuntu-16.04.4-desktop-amd64.iso
2) Download this Universal USB Installer: https://www.pendrivelinux.com/downloads/Universal-USB-Installer/Universal-USB-Installer-1.9.8.0.exe
3) Insert a USB stick (I think it needs to be at least 2 GB) that may be reformatted
4) Run the installer, select Ubuntu, the .iso image and your USB stick and the option to format it to FAT32.

You can then boot from this USB stick (you may need to press some function key during boot or set a BIOS option to enable that). Now running Linux, you can start Firefox, download dnsperfbench-linux, right-click in the downloads directory to open a terminal window, make the dnsperfbench-linux executable with chmod 755 dnsperfbench-linux and then you can run it like this: ./dnsperfbench-linux

The tool runs for maybe a minute before you get to see the results.
 
Last edited:
I understood from Cloudfare's blog post that indeed their recursor service runs in each data center = points of presence. What made you think otherwise?


Can you give some examples of URLs where this happens? I'm in Belgium and have not been able to replicate what you describe while using 1.1.1.1. I can understand your theory, but if the Cloudfare PoP is close to your ISP (which it is in my case) and the CDN geolocation knows it is, it should work well even without EDNS Client Subnet?


Maybe others can give it a try from their connection to compare? Or could you try it with a URL of something that you got served from the US instead of your nearest CDN PoP?

Nowhere in that blog post do they state that they have or use local recursive services for priming their 'distributed cache' from authoritative servers.

I also ran a grc DNS test while using 1.1.1.1, and the source DNS server was in the US.

Quoting the blog post:

"When a resolver needs to get an answer from an authority, things get a bit more complicated. A resolver needs to follow the DNS hierarchy to resolve a name, which means it has to talk to multiple authoritative servers starting at the root.

For example, our resolver in Buenos Aires, Argentina will take longer to follow a DNS hierarchy than our resolver in Frankfurt, Germany because of its proximity to the authoritative servers. In order to get around this issue we prefill our cache, out-of-band, for popular names, which means when an actual query comes in, responses can be fetched from cache which is much faster."

From that, one can deduce that they use recursive DNS servers nearest to or in the world's busiest hubs for DNS services (US) together with their authoritative servers to prime their 'distributed cache'. If what you say is indeed what they are doing then they could have hosted a recursive server in Argentina but they didn't. Until they release more info on how they accomplish this, make modifications to their recursive servers' topology so CDNs can function correctly and with the current results I am seeing, I am staying clear of their new service.

As for examples of sites/services:

- Office 365; with 1.1.1.1, all of O365 services are being served from the US when my tenant is in the EU. Without 1.1.1.1, less than a third of the services are served from the US and the rest are all served from the EU (no exceptions).

- LinkedIn was previously being served from Ireland now it is being served from the US.

- Banking sites (US and EU) are being served from the US when they were previously being served from the EU (NL and FR mostly)

The list goes on.
 
If you don't have a Linux PC, it is very easy to create a Linux Live-USB stick:

Thanks for your extensive explanation, very kind. Lucky for me, I'm a Linux user already, so I'll give it a shot my laptop.
 
I also ran a grc DNS test while using 1.1.1.1, and the source DNS server was in the US.
I'm not sure what you mean by source DNS server, but the US reference that I see in the GRC DNS Benchmark tool is to the network owner? Cloudflare is a US company.
Quoting the blog post: "For example, our resolver in Buenos Aires, Argentina will take longer to follow a DNS hierarchy than our resolver in Frankfurt, Germany because of its proximity to the authoritative servers. In order to get around this issue we prefill our cache, out-of-band, for popular names, which means when an actual query comes in, responses can be fetched from cache which is much faster."

From that, one can deduce that they use recursive DNS servers nearest to or in the world's busiest hubs for DNS services (US) together with their authoritative servers to prime their 'distributed cache'. If what you say is indeed what they are doing then they could have hosted a recursive server in Argentina but they didn't. Until they release more info on how they accomplish this, make modifications to their recursive servers' topology so CDNs can function correctly and with the current results I am seeing, I am staying clear of their new service.
That indeed sounds dubious. It would not be smart to use the Frankfurt responses to fill a cache for Buenos Aires. Maybe what they meant is that the resolver in Argentina needs a cache more than the German server does, as it takes a bigger hit on uncached queries. This is something that Cloudflare should be more clear about.
As for examples of sites/services:
- LinkedIn was previously being served from Ireland now it is being served from the US.
I tested this 138KB image from their homepage:
Code:
./dnsperfbench -resolver 195.130.130.1 -httptest https://static.licdn.com/sc/h/64xk850n3a8uzse6fi11l3vmz
+-------------------------------------+---------------------+-------+---------+-------+-------+----------+--------+
|              RESOLVER               |       REMOTE        |  DNS  | CONNECT |  TLS  | TTFB  | TRANSFER | TOTAL  |
+-------------------------------------+---------------------+-------+---------+-------+-------+----------+--------+
| 195.130.130.1 (Unknown)             | 2.18.171.114:443    | 18ms  | 13ms    | 34ms  | 13ms  | 26ms     | 103ms  |
| 208.67.222.222 (OpenDNS)            | 2.18.171.114:443    | 26ms  | 13ms    | 38ms  | 12ms  | 26ms     | 114ms  |
| 8.8.8.8 (Google)                    | 2.18.171.114:443    | 42ms  | 13ms    | 27ms  | 12ms  | 27ms     | 121ms  |
| 1.1.1.1 (Cloudflare)                | 192.229.233.180:443 | 15ms  | 18ms    | 48ms  | 17ms  | 35ms     | 134ms  |
| 9.9.9.9 (Quad9)                     | 192.229.233.180:443 | 27ms  | 19ms    | 44ms  | 17ms  | 41ms     | 147ms  |
| 199.85.126.20 (Norton)              | 192.229.233.180:443 | 26ms  | 20ms    | 50ms  | 18ms  | 36ms     | 150ms  |
| 8.26.56.26 (Comodo)                 | 192.229.233.180:443 | 30ms  | 17ms    | 51ms  | 18ms  | 35ms     | 151ms  |
| 114.114.114.114 (114dns)            | 192.229.163.180:443 | 142ms | 95ms    | 203ms | 96ms  | 190ms    | 725ms  |
| 185.228.168.168 (Clean Browsing)    | 108.174.11.72:443   | 21ms  | 136ms   | 273ms | 133ms | 662ms    | 1.224s |
| 119.29.29.29 (DNSPod)               | 23.45.186.10:443    | 125ms | 176ms   | 352ms | 174ms | 417ms    | 1.243s |
| 180.76.76.76 (Baidu)                | 218.60.45.6:443     | 626ms | 186ms   | 386ms | 185ms | 374ms    | 1.758s |
| [2620:0:ccc::2] (OpenDNS)           | FAIL                | FAIL  | FAIL    | FAIL  | FAIL  | FAIL     | FAIL   |
| [2a0d:2a00:1::] (Clean Browsing)    | FAIL                | FAIL  | FAIL    | FAIL  | FAIL  | FAIL     | FAIL   |
| [2001:4860:4860::8888] (Google)     | FAIL                | FAIL  | FAIL    | FAIL  | FAIL  | FAIL     | FAIL   |
| [2620:fe::fe] (Quad9)               | FAIL                | FAIL  | FAIL    | FAIL  | FAIL  | FAIL     | FAIL   |
| [2606:4700:4700::1111] (Cloudflare) | FAIL                | FAIL  | FAIL    | FAIL  | FAIL  | FAIL     | FAIL   |
+-------------------------------------+---------------------+-------+---------+-------+-------+----------+--------+
The answer that I get from Cloudflare (192.229.233.180) is geolocated (according to MaxMind) in the US, but with a minimum ping time of 16 ms cannot be (for example London-New York is 5,500 km so a roundtrip at the speed of light in a straight line still takes 37 ms). I assume this is Verizon's Edgecast CDN using anycast routing.
 
I think @AtAM1 mis-interpreted his quoted paragraphs from CF's blog post.

The paragraphs basically said that their DNS servers at their point-of-presence's pre-fill the cache with common domains at start-up.

I believe the dude who wrote the blog made the article in a way like a story and more interesting to read.

The facts are that Frankfurt being closers to root servers will take less time to resolve from scratch. Buenos Aires being farther away from root servers will take longer to resolve.

Hence, CF pre-fills their DNS servers at Buenos Aires. It doesn't imply they pre-fill by copying from Frankfurt or other PoP's cache. Nor it implies DNS servers at Frankfurt won't pre-fill on start-up. Since all PoPs running the same software stack (I assume), it's reasonable to expect all DNS servers at their PoPs do pre-filling with locally resolved data.

Frankly I can't tell if all CF PoPs have CDNs properly resolved to best possible proximity. At their "major" PoPs in each continent, I have little doubt about that. Most likely it's a geo db "issue" as I mentioned before.

I tried facebook, twitter, linkedin. All get back with IPs a few ms away. But their geo data say some IPs are in Ireland and others are in US. That's simply not possible in physics.

quad9, however, does get me an IP of linkedin which is 180ms away. But I have less faith in quad9..That also means we can't rule out CF might have glitches in their less "major" PoPs.
 
I've setup dnscrypt with 1.1.1.1 and its IPv6 address. The asus setting page has no DNS addresses listed and everything seems to be working.

How do I check to make sure that DoH is working?
 
I've setup dnscrypt with 1.1.1.1 and its IPv6 address. The asus setting page has no DNS addresses listed and everything seems to be working.

How do I check to make sure that DoH is working?

See the first post in this thread.
SSH in to your router & do the ‘pidof’ thing.
 
See the first post in this thread.
SSH in to your router & do the ‘pidof’ thing.

The "pidof" thing will only show you if the dnscrypt-proxy is running, but not if the DoH is working :)

This are the steps from cloudflare to test if its working:

dnscrypt-proxy
The dnscrypt-proxy 2.0+ supports DoH out of the box. It supports both 1.1.1.1, and other services. It includes more advanced features, such as load balancing and local filtering.

Step 1: Install the dnscrypt-proxy. You can find the instructions here.

Step 2: Verify that the dnscrypt-proxy is installed, and at least version 2.0

dnscrypt-proxy -version
2.0.8

Step 3: Set up the configuration file using the official instructions, and add ‘cloudflare’ and ‘cloudflare-ipv6’ to the server list in dnscrypt-proxy.toml

server_names = ['cloudflare', 'cloudflare-ipv6']

Step 4: Make sure that nothing else is running on localhost:53, and check that everything works as expected

dnscrypt-proxy -resolve cloudflare-dns.com
Resolving [cloudflare-dns.com]

Domain exists: yes, 3 name servers found
Canonical name: cloudflare-dns.com.
IP addresses: 2400:cb00:2048:1::6810:6f19, 2400:cb00:2048:1::6810:7019, 104.16.111.25, 104.16.112.25
TXT records: -
Resolver IP: 172.68.140.217

https://developers.cloudflare.com/1.1.1.1/dns-over-https/cloudflared-proxy/
Scroll down here!
 
The "pidof" thing will only show you if the dnscrypt-proxy is running, but not if the DoH is working :)

This are the steps from cloudflare to test if its working:



https://developers.cloudflare.com/1.1.1.1/dns-over-https/cloudflared-proxy/
Scroll down here!

Okay it looks like its working thanks!

One thing I noticed since I started using dnscrypt on my devices it seems to be defaulting the dns server to 1.1.1.1 instead of my modem. Do I need to manually set the DNS server to the router on all the devices? I was under the impression that on auto setting DHCP should set the DNS server to the gateway address by default.
 
Okay it looks like its working thanks!

One thing I noticed since I started using dnscrypt on my devices it seems to be defaulting the dns server to 1.1.1.1 instead of my modem. Do I need to manually set the DNS server to the router on all the devices? I was under the impression that on auto setting DHCP should set the DNS server to the gateway address by default.


Check under system log > port forwarding.
Port 53 should be pointed @ your router?
 
Check under system log > port forwarding.
Port 53 should be pointed @ your router?

Yup the Port forwarding seems to be correct. If I manually set my devices dns to my routers address everything works. But on auto they get set to 1.1.1.1 for some reason.

IPv6 seems to configure correctly
 
I would like to install this - but I want to get all my ducks in align first in case I break it. I already have opendns in use. I use skynet and ab-solution - which play nicely with this from reading the posts.

I think my main question is that I believe this makes mods to the dnsmasq.conf.add in /jffs/configs. I already have a number of lines in there to allow my roku players to use a smart DNS for UK TV streaming (FYA, the firewall way did not work for this). I would like to know that these are still going to work after the script it run, and also when dnsmask is in use :

dhcp-host=set:RKP-LNG,C8:3A:6B:26:F8:D3,192.168.1.24
dhcp-option=tag:RKP-LNG,option:dns-server,108.61.169.104
dhcp-host=set:RK3-BW,AC:3A:7A:39:0B:43,192.168.1.25
dhcp-option=tag:RK3-BW,option:dns-server,108.61.169.104
dhcp-host=set:RK2-MED,AC:3A:7A:D2:0D:0C:,192.168.1.26
dhcp-option=tag:RK2-MED,option:dns-server,108.61.169.104
dhcp-host=set:RK2-GRG,AC:3A:7A:D2:69:51,192.168.1.27
dhcp-option=tag:RK2-GRG,option:dns-server,108.61.169.104
dhcp-host=set:RK2-COBY,AC:3A:7A:D2:88:C8,192.168.1.28
dhcp-option=tag:RK2-COBY,option:dns-server,108.61.169.104
dhcp-host=set:RK3-CAM,DC:3A:5E:FD:FC:66,192.168.1.30
dhcp-option=tag:RK3-CAM,option:dns-server,108.61.169.104
dhcp-host=set:RKP-B1,C8:3A:6B:58:6C:9F,192.168.1.31
dhcp-option=tag:RKP-B1,option:dns-server,108.61.169.104

Thanks,
 
Interesting.
‘Pidof’ works for me, returns a number.
The test you suggest returns a “dnscrypt not found” result.
I’m confused.....

Pidof just tells you that the process is running and returns the process id. It doesn't actually test the connection.

You have to run ./dnscrypt-proxy -resolve cloudflare-dns.com inside the /jffs/dnscrypt/ folder
 

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top