DNScrypt dnscrypt installer for asuswrt

[Treadler]

If you use the dnscrypt installer there is a option to ignore the system dns entrys. Does no one read the things there?

Chuckle! I have been known to look at things, but not see them. (Facepalm)!
I definitely did see, & say ‘yes’ to dnscrypt asking if it should handle all the DNS duties.
But yes, you are right to doubt me..........
(Your later admission not withstanding). ;-)

I find this forum a great place to learn, particularly as my network/router knowledge is best described as ‘basic’.

 

[blueshark]

MartinDEE,

Don't forget to re-start 'dnscrypt-proxy', as follows, whenever you make changes to the .toml file:

/jffs/dnscrypt/manager dnscrypt-start

[Starts it if NOT running and re-starts if already running] [emoji1]

What are all option ? This one is for restart and all the other are ? Please list

 

[Twiglets]

What are all option ? This one is for restart and all the other are ? Please list

/jffs/dnscrypt/manager is a script !!!
It can be listed/read etc.

The 'case statement' at the end of the script is as follows (Options Highlighted):
[Sorry indenting disappears when listed but there when edited. !!!???]

case $1 in
dnscrypt-start)
start_dnscrypt
;;
dnsmasq)
sed -i "/^servers-file=.*$/d" /etc/dnsmasq.conf
append_on_demand /etc/dnsmasq.conf "no-resolv" "server=127.0.0.1#65053"
;;
fw-rules)
iptables -t nat -C PREROUTING -i br0 -p udp --dport 53 -j DNAT --to $(nvram get lan_ipaddr) > /dev/null 2>&1
[ $? -ne 0 ] && iptables -t nat -A PREROUTING -i br0 -p udp --dport 53 -j DNAT --to $(nvram get lan_ipaddr)
iptables -t nat -C PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to $(nvram get lan_ipaddr) > /dev/null 2>&1
[ $? -ne 0 ] && iptables -t nat -A PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to $(nvram get lan_ipaddr)
;;
init-start)
if [ -f /jffs/dnscrypt/localtime ]; then
ln -s /jffs/dnscrypt/localtime /etc/localtime
date -u -s "`date -u -r \"$0\" '+%Y-%m-%d %H:%M:%S'`"
fi
case $RAN_PRV in
haveged)
/jffs/dnscrypt/haveged -w1024 -v1
;;
rngd)
init_hwrng &
;;
esac
$0 monitor-start
start_dnscrypt
;;
monitor-start)
start_monitor &
;;
services-stop)
[ -f /jffs/dnscrypt/localtime ] && touch "$0"
;;
wan-start)
update_opendns 0 &
;;
esac

 

[noworries]

So I turned on "Suspcious Query Logging" in the .toml configuration file.

I don't see any documentation of this feature in the wiki. Below is from the example .toml configuration file (with file and format un-commented to enable the feature.).

############################################
#        Suspcious queries logging        #
############################################

## Log queries for nonexistent zones
## These queries can reveal the presence of mlware, broken/obsolete applications,
## and devices signaling their presence to 3rd parties.

[nx_log]

  ## Path to the query log file (absolute, or relative to the same directory as the executable file)

  file = 'nx.log'


  ## Query log format (currently supported: tsv and ltsv)

  format = 'tsv'

Here's a partial result showing representative frequency by the time-stamps. I get that dnscrypt is listening on 127.0.0.1, but am I supposed to be able to discern the source device, somehow?

What do I do with this information? Does dnscrypt block these, or do I need to do so myself with a blacklist?

Is too much information just a bad thing?

...
[2018-04-20 02:25:07]   127.0.0.1       f.0.a.e.9.1.8.6.0.0.0.0.0.0.0.0.1.0.0.0.8.4.0.2.0.0.b.c.0.0.4.2.ip6.arpa        PTR
[2018-04-20 02:25:07]   127.0.0.1       e.b.c.2.2.1.8.6.0.0.0.0.0.0.0.0.1.0.0.0.8.4.0.2.0.0.b.c.0.0.4.2.ip6.arpa        PTR
[2018-04-20 02:25:07]   127.0.0.1       110.190.101.151.in-addr.arpa    PTR
[2018-04-20 02:25:08]   127.0.0.1       133.188.101.151.in-addr.arpa    PTR
[2018-04-20 02:25:08]   127.0.0.1       217.197.79.204.in-addr.arpa     PTR
[2018-04-20 02:38:03]   127.0.0.1       169.254 A
[2018-04-20 02:38:28]   127.0.0.1       169.254 A
[2018-04-20 02:40:28]   127.0.0.1       192.127.0.0.1   A
[2018-04-20 02:43:54]   127.0.0.1       168.2.109       A
[2018-04-20 03:04:50]   127.0.0.1       127.0.0 A
[2018-04-20 03:18:27]   127.0.0.1       169.254 A
[2018-04-20 03:20:23]   127.0.0.1       169.254 A
[2018-04-20 03:20:57]   127.0.0.1       grasshopper-analytics.dishanywhere.com  A
[2018-04-20 03:27:22]   127.0.0.1       192.127.0.0.1   A
[2018-04-20 03:29:56]   127.0.0.1       127.0   A
[2018-04-20 03:34:15]   127.0.0.1       168.2.109       A
[2018-04-20 03:38:22]   127.0.0.1       169     A
[2018-04-20 03:40:28]   127.0.0.1       192.127.0.0.1   A
[2018-04-20 03:45:36]   127.0.0.1       192.127.0.0.1   A
[2018-04-20 04:40:43]   127.0.0.1       169.254 A
[2018-04-20 04:41:16]   127.0.0.1       127.0.0 A
[2018-04-20 05:17:20]   127.0.0.1       169     A
[2018-04-20 05:50:58]   127.0.0.1       127     A
[2018-04-20 06:07:04]   127.0.0.1       168     A
[2018-04-20 06:10:18]   127.0.0.1       168.2.109       A
[2018-04-20 06:17:01]   127.0.0.1       192.127.0.0.1   A
[2018-04-20 06:24:56]   127.0.0.1       169.254.247     A
[2018-04-20 06:43:38]   127.0.0.1       169.254.247     A
[2018-04-20 06:49:16]   127.0.0.1       192.127.0.0.1   A
[2018-04-20 06:52:50]   127.0.0.1       127     A
[2018-04-20 07:04:28]   127.0.0.1       169     A
[2018-04-20 07:05:49]   127.0.0.1       169.254 A
[2018-04-20 07:08:50]   127.0.0.1       168.2.109       A
[2018-04-20 07:14:19]   127.0.0.1       127     A
[2018-04-20 07:32:26]   127.0.0.1       192.127.0.0.1   A
[2018-04-20 07:37:52]   127.0.0.1       192.127.0.0.1   A
[2018-04-20 07:39:05]   127.0.0.1       192.127.0.0.1   A
[2018-04-20 07:46:41]   127.0.0.1       169.254.247     A
[2018-04-20 07:47:00]   127.0.0.1       168.2.109       A
[2018-04-20 07:52:16]   127.0.0.1       168.2.109       A
[2018-04-20 07:54:30]   127.0.0.1       127.0.0 A
[2018-04-20 08:00:13]   127.0.0.1       192.127.0.0.1   A
[2018-04-20 08:04:08]   127.0.0.1       168.2.109       A
[2018-04-20 08:20:03]   127.0.0.1       127.0   A
[2018-04-20 08:23:48]   127.0.0.1       192.127.0.0.1   A
[2018-04-20 08:24:41]   127.0.0.1       y.analytics.yahoo.com   A
[2018-04-20 08:24:41]   127.0.0.1       y.analytics.yahoo.com   A


...

 

[DonnyJohnny]

What are all option ? This one is for restart and all the other are ? Please list

Basically the dnscrypt-start, kill all dnscrypt* process and start it. It is useful when you manually edit the toml configuration and want to restart dnscrypt-proxy to effect the new configuration.

If u looking for more option... go explore the toml file on your own.. if you have doubt with the toml file, you need to check with the developer and post your issue there. Suggest before you post, search the issue first. In any case, the dnscrypt-proxy is pretty stable now.
https://github.com/jedisct1/dnscrypt-proxy

 

[TheUntouchable]

I was using 1.1.1.1 without dnsscrypt and now I am using 1.1.1.1 with dnsscrypt. The DNS response time increased from 20ms to 70ms. Is this due to DoH? dnscrypt itself tells me that the dns response from 1.1.1.1 is about 20-25ms, but my network monitoring tells me something different.. (The large number on the screenshot is the average of the last 30 days)

Just a short update on this issue: After the update/installation/reconfiguration script was re-run from the start page, it installed the latest dnscrypt-proxy version 2.0.10 with the same options during configuration as before and then DNS latency reverted from 70ms back to 20-30ms.

 

[M@rco]

@bigeyes0x0 Not sure whether it's the installer script that outputs this error, but when updating to 2.0.10 I got the following error:

...
Info:  Found previous dnscrypt-proxy config file
 =>  Do you want to use this file without reconfiguring? [y/n]: y
 Info:  Use previous settings file
 Info:  Staring dnscrypt-proxy...
 *** Error:  Couldn't start dnscrypt-proxy
 *** Error:  Please send WebUI System Log to dev
...

However, looking at syslog it seems it actually (re-)started fine:

Apr 20 22:00:45 marco: Start dnscrypt-proxy
Apr 20 22:00:45 dnscrypt-proxy[2421]: Source [public-resolvers.md] loaded
Apr 20 22:00:45 dnscrypt-proxy[2421]: dnscrypt-proxy 2.0.10
Apr 20 22:00:45 dnscrypt-proxy[2421]: listen udp 127.0.0.1:65053: bind: address already in use
Apr 20 22:00:45 dnscrypt-proxy[208]: Stopped.
Apr 20 22:00:50 marco: Warning: dnscrypt-proxy is dead
Apr 20 22:00:50 marco: Start dnscrypt-proxy
Apr 20 22:00:50 dnscrypt-proxy[2465]: Source [public-resolvers.md] loaded
Apr 20 22:00:50 dnscrypt-proxy[2465]: dnscrypt-proxy 2.0.10
Apr 20 22:00:50 dnscrypt-proxy[2465]: Now listening to 127.0.0.1:65053 [UDP]
Apr 20 22:00:50 dnscrypt-proxy[2465]: Now listening to 127.0.0.1:65053 [TCP]
Apr 20 22:00:50 dnscrypt-proxy[2465]: [cs-nl] OK (crypto v1) - rtt: 12ms
Apr 20 22:00:50 dnscrypt-proxy[2465]: [d0wn-nl-ns4] OK (crypto v1) - rtt: 10ms
Apr 20 22:00:50 dnscrypt-proxy[2465]: [dnscrypt.eu-nl] OK (crypto v1) - rtt: 22ms
Apr 20 22:00:50 dnscrypt-proxy[2465]: [securedns] OK (crypto v1) - rtt: 11ms
Apr 20 22:00:50 dnscrypt-proxy[2465]: Server with the lowest initial latency: d0wn-nl-ns4 (rtt: 10ms)
Apr 20 22:00:50 dnscrypt-proxy[2465]: dnscrypt-proxy is ready - live servers: 4

 

[Twiglets]

So I turned on "Suspcious Query Logging" in the .toml configuration file.

I don't see any documentation of this feature in the wiki. Below is from the example .toml configuration file (with file and format un-commented to enable the feature.).

############################################
#        Suspcious queries logging        #
############################################

## Log queries for nonexistent zones
## These queries can reveal the presence of mlware, broken/obsolete applications,
## and devices signaling their presence to 3rd parties.

[nx_log]

  ## Path to the query log file (absolute, or relative to the same directory as the executable file)

  file = 'nx.log'


  ## Query log format (currently supported: tsv and ltsv)

  format = 'tsv'

Here's a partial result showing representative frequency by the time-stamps. I get that dnscrypt is listening on 127.0.0.1, but am I supposed to be able to discern the source device, somehow?

What do I do with this information? Does dnscrypt block these, or do I need to do so myself with a blacklist?

Is too much information just a bad thing?

...
[2018-04-20 02:25:07]   127.0.0.1       f.0.a.e.9.1.8.6.0.0.0.0.0.0.0.0.1.0.0.0.8.4.0.2.0.0.b.c.0.0.4.2.ip6.arpa        PTR
[2018-04-20 02:25:07]   127.0.0.1       e.b.c.2.2.1.8.6.0.0.0.0.0.0.0.0.1.0.0.0.8.4.0.2.0.0.b.c.0.0.4.2.ip6.arpa        PTR
[2018-04-20 02:25:07]   127.0.0.1       110.190.101.151.in-addr.arpa    PTR
[2018-04-20 02:25:08]   127.0.0.1       133.188.101.151.in-addr.arpa    PTR
[2018-04-20 02:25:08]   127.0.0.1       217.197.79.204.in-addr.arpa     PTR
[2018-04-20 02:38:03]   127.0.0.1       169.254 A
[2018-04-20 02:38:28]   127.0.0.1       169.254 A
[2018-04-20 02:40:28]   127.0.0.1       192.127.0.0.1   A
[2018-04-20 02:43:54]   127.0.0.1       168.2.109       A
[2018-04-20 03:04:50]   127.0.0.1       127.0.0 A
[2018-04-20 03:18:27]   127.0.0.1       169.254 A
[2018-04-20 03:20:23]   127.0.0.1       169.254 A
[2018-04-20 03:20:57]   127.0.0.1       grasshopper-analytics.dishanywhere.com  A
[2018-04-20 03:27:22]   127.0.0.1       192.127.0.0.1   A
[2018-04-20 03:29:56]   127.0.0.1       127.0   A
[2018-04-20 03:34:15]   127.0.0.1       168.2.109       A
[2018-04-20 03:38:22]   127.0.0.1       169     A
[2018-04-20 03:40:28]   127.0.0.1       192.127.0.0.1   A
[2018-04-20 03:45:36]   127.0.0.1       192.127.0.0.1   A
[2018-04-20 04:40:43]   127.0.0.1       169.254 A
[2018-04-20 04:41:16]   127.0.0.1       127.0.0 A
[2018-04-20 05:17:20]   127.0.0.1       169     A
[2018-04-20 05:50:58]   127.0.0.1       127     A
[2018-04-20 06:07:04]   127.0.0.1       168     A
[2018-04-20 06:10:18]   127.0.0.1       168.2.109       A
[2018-04-20 06:17:01]   127.0.0.1       192.127.0.0.1   A
[2018-04-20 06:24:56]   127.0.0.1       169.254.247     A
[2018-04-20 06:43:38]   127.0.0.1       169.254.247     A
[2018-04-20 06:49:16]   127.0.0.1       192.127.0.0.1   A
[2018-04-20 06:52:50]   127.0.0.1       127     A
[2018-04-20 07:04:28]   127.0.0.1       169     A
[2018-04-20 07:05:49]   127.0.0.1       169.254 A
[2018-04-20 07:08:50]   127.0.0.1       168.2.109       A
[2018-04-20 07:14:19]   127.0.0.1       127     A
[2018-04-20 07:32:26]   127.0.0.1       192.127.0.0.1   A
[2018-04-20 07:37:52]   127.0.0.1       192.127.0.0.1   A
[2018-04-20 07:39:05]   127.0.0.1       192.127.0.0.1   A
[2018-04-20 07:46:41]   127.0.0.1       169.254.247     A
[2018-04-20 07:47:00]   127.0.0.1       168.2.109       A
[2018-04-20 07:52:16]   127.0.0.1       168.2.109       A
[2018-04-20 07:54:30]   127.0.0.1       127.0.0 A
[2018-04-20 08:00:13]   127.0.0.1       192.127.0.0.1   A
[2018-04-20 08:04:08]   127.0.0.1       168.2.109       A
[2018-04-20 08:20:03]   127.0.0.1       127.0   A
[2018-04-20 08:23:48]   127.0.0.1       192.127.0.0.1   A
[2018-04-20 08:24:41]   127.0.0.1       y.analytics.yahoo.com   A
[2018-04-20 08:24:41]   127.0.0.1       y.analytics.yahoo.com   A


...

You need to crossreference the AB-Solution Logs with the nx.log.
All the nx.log contains is the queries that are for 'nonexistent zones' [as commented in the .toml file]

You need to read up and understand a little bit about DNS then it will make more sense.
(Yes, too much info is confusing )

As a quick set of 'hints' read the following about 'DNS Resource Records'

DNS Resource Records
Zone DNS database is a collection of resource records and each of the records provides information about a specific object. A list of most common records is provided below:

• Address Mapping records (A)
  The record A specifies IP address (IPv4) for given host. A records are used for conversion of domain names to corresponding IP addresses.
  
  
• IP Version 6 Address records (AAAA)
  The record AAAA (also quad-A record) specifies IPv6 address for given host. So it works the same way as the A record and the difference is the type of IP address.
  
  
• Canonical Name records (CNAME)
  The CNAME record specifies a domain name that has to be queried in order to resolve the original DNS query. Therefore CNAME records are used for creating aliases of domain names. CNAME records are truly useful when we want to alias our domain to an external domain. In other cases we can remove CNAME records and replace them with A records and even decrease performance overhead.
  
  
• Host Information records (HINFO)
  HINFO records are used to acquire general information about a host. The record specifies type of CPU and OS. The HINFO record data provides the possibility to use operating system specific protocols when two hosts want to communicate. For security reasons the HINFO records are not typically used on public servers.
  
  Note: Standard values in RFC 1010
  
  
• Integrated Services Digital Network records (ISDN)
  The ISDN resource record specifies ISDN address for a host. An ISDN address is a telephone number that consists of a country code, a national destination code, a ISDN Subscriber number and, optionally, a ISDN subaddress. The function of the record is only variation of the A resource record function.
  
  
• Mail exchanger record (MX)
  The MX resource record specifies a mail exchange server for a DNS domain name. The information is used by Simple Mail Transfer Protocol (SMTP) to route emails to proper hosts. Typically, there are more than one mail exchange server for a DNS domain and each of them have set priority.
  
  Example:
  msn.com MX preference = 5, mail exchanger = mx2.hotmail.com
  msn.com MX preference = 5, mail exchanger = mx3.hotmail.com
  msn.com MX preference = 5, mail exchanger = mx4.hotmail.com
  msn.com MX preference = 5, mail exchanger = mx1.hotmail.com
  
  msn.com nameserver = ns3.msft.net
  msn.com nameserver = ns5.msft.net
  msn.com nameserver = ns4.msft.net
  msn.com nameserver = ns1.msft.net
  msn.com nameserver = ns2.msft.net
  mx1.hotmail.com internet address = 65.55.92.184
  mx1.hotmail.com internet address = 65.54.188.72
  mx1.hotmail.com internet address = 65.54.188.94
  mx1.hotmail.com internet address = 65.54.188.110
  mx1.hotmail.com internet address = 65.54.188.126
  mx1.hotmail.com internet address = 65.55.37.72
  mx1.hotmail.com internet address = 65.55.37.88
  mx1.hotmail.com internet address = 65.55.37.104
  mx1.hotmail.com internet address = 65.55.37.120
  mx1.hotmail.com internet address = 65.55.92.136
  mx1.hotmail.com internet address = 65.55.92.152
  mx1.hotmail.com internet address = 65.55.92.168
  
  
• Name Server records (NS)
  The NS record specifies an authoritative name server for given host.
  
  
• Reverse-lookup Pointer records (PTR)
  As opposed to forward DNS resolution (A and AAAA DNS records), the PTR record is used to look up domain names based on an IP address.
  
  
• Start of Authority records (SOA)
  The record specifies core information about a DNS zone, including the primary name server, the email of the domain administrator, the domain serial number, and several timers relating to refreshing the zone.
  
  
• Text records (TXT)
  The text record can hold arbitrary non-formatted text string. Typically, the record is used by Sender Policy Framework (SPF) to prevent fake emails to appear to be sent by you.

 

[noworries]

You need to crossreference the AB-Solution Logs with the nx.log.
All the nx.log contains is the queries that are for 'nonexistent zones' [as commented in the .toml file]

Interesting, thanks for the redirection to ABS logs. Looks like my Dish Hopper and Sling add-on are very busy. I'll dig into it further, but the Dish Hopper is querying 168.2.109 (missing an IPV4 field) for some reason, for example. Bizarre.

Any thoughts as to why, and if one would care?

 

[noworries]

I've wondered why I occasionally and suddenly lose outbound connections. I just noticed that dnscrypt crashed and, voila, no outbound. Restarting dnscrypt resolved the issue. No forensics about the cause.

 

[Twiglets]

Interesting, thanks for the redirection to ABS logs. Looks like my Dish Hopper and Sling add-on are very busy. I'll dig into it further, but the Dish Hopper is querying 168.2.109 (missing an IPV4 field) for some reason, for example. Bizarre.

Any thoughts as to why, and if one would care?

Check that something is not truncating the line when you are reading the logs.
I am not aware of anything that would accept an ip address 168.1.109 without an error !!!

 

[Twiglets]

I've wondered why I occasionally and suddenly lose outbound connections. I just noticed that dnscrypt crashed and, voila, no outbound. Restarting dnscrypt resolved the issue. No forensics about the cause.

Dnscrypt-proxy should not crash !!!
Investigate what else was happening and check all available logs for clues.

 

[Deleted member 28123]

Just a quick heads up if anyone, especially those that are not in the US, decide to use Cloudflare's DoH 1.1.1.1 or 1.0.0.1 with dnscrypt-proxy.

Most if not all of your CDN traffic will be served via the US.. So while you are shaving off +100ms of your DNS queries you are actually slowing down your browsing experience! There's also the issue of whether you really want your traffic served via the US which is a privacy concern for non-US based privacy conscious users.

Google's DoH fares somewhat better but seeing that its core business is advertising, I'd skip it too.

We need European and Asian Anycast and DoH capable DNS service providers with their source DNS hosted within their regions... if you know of any, please share. Until then, I'll continue on using a private EU-based Dnscrypt/DoH instance.

 

[Treadler]

Just a quick heads up if anyone, especially those that are not in the US, decide to use Cloudflare's DoH 1.1.1.1 or 1.0.0.1 with dnscrypt-proxy.

Most if not all of your CDN traffic will be served via the US.. So while you are shaving off +100ms of your DNS queries you are actually slowing down your browsing experience! There's also the issue of whether you really want your traffic served via the US which is a privacy concern for non-US based privacy conscious users.

Google's DoH fares somewhat better but seeing that its core business is advertising, I'd skip it too.

We need European and Asian Anycast and DoH capable DNS service providers with their source DNS hosted within their regions... if you know of any, please share. Until then, I'll continue on using a private EU-based Dnscrypt/DoH instance.

https://www.cloudflare.com/network/

Hope this helps?

 

[Deleted member 28123]

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.

 

[joegreat]

https://www.cloudflare.com/network/

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.

Well, based on my traceroute and ping outputs below (and geolocation of the IPs), I would says that 1.1.1.1/1.0.0.1 have local copies in Vienna/Austria (Cloudflare has a local presence).

The tranceroute shows that the 1.1.1.1 is only routed via the local Viennese network (aorta.net/Vienna) and also terminates there to 1.1.1.1 (same for 1.0.0.1).
The great ping rates around 15 ms also show that the DNS servers are really nearby!

Now I am really temped to give it a try (over my current setup to DNS servers in Germany, France and Italy)...

C:\WINDOWS\system32>tracert 1.1.1.1
Routenverfolgung zu 1dot1dot1dot1.cloudflare-dns.com [1.1.1.1]
über maximal 30 Hops:

  1    <1 ms    <1 ms    <1 ms  asus [192.168.0.1]
  2     *        *        *     Zeitüberschreitung der Anforderung.
  3    16 ms    12 ms    15 ms  84.116.25.33
  4    11 ms    17 ms    15 ms  at-vie15a-rd1-ae31-2048.aorta.net [84.116.228.149]
  5    28 ms    20 ms    12 ms  at-vie05b-ri3-ae12-0.aorta.net [213.46.173.125]
  6    10 ms    13 ms    10 ms  ix-et-25.hcore1.WI4-Vienna.as6453.net [195.219.25.0]
  7    16 ms    12 ms    20 ms  195.219.25.10
  8     8 ms    12 ms    10 ms  1dot1dot1dot1.cloudflare-dns.com [1.1.1.1]

C:\WINDOWS\system32>ping -t 1.1.1.1
Ping wird ausgeführt für 1.1.1.1 mit 32 Bytes Daten:
Antwort von 1.1.1.1: Bytes=32 Zeit=14ms TTL=57
Antwort von 1.1.1.1: Bytes=32 Zeit=15ms TTL=57
Antwort von 1.1.1.1: Bytes=32 Zeit=36ms TTL=57
Antwort von 1.1.1.1: Bytes=32 Zeit=14ms TTL=57
Antwort von 1.1.1.1: Bytes=32 Zeit=17ms TTL=57
Antwort von 1.1.1.1: Bytes=32 Zeit=17ms TTL=57
Antwort von 1.1.1.1: Bytes=32 Zeit=9ms TTL=57
Antwort von 1.1.1.1: Bytes=32 Zeit=14ms TTL=57

 

[Deleted member 28123]

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.

 

[RMerlin]

And there's also the matter of eDNS-client-subnet support - unless it's supported at both levels (the DDNS and the CDN), you won't get optimal results.

 

[noworries]

Dnscrypt-proxy should not crash !!!
Investigate what else was happening and check all available logs for clues.

I just noticed that sites started reporting that they could not be found, then sometimes working. Then I saw in the system log that dnscrypt stopped, for some reason at 11:49. I restarted it manually at 11:52 and browsing works again.

Apr 21 11:48:29 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=xxx SRC=39.135.17.37 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=49 ID=27795 DF PROTO=TCP SPT=161 DPT=5985 SEQ=0 ACK=2213521926 WINDOW=0 RES=0x00 ACK RST URGP=0
Apr 21 11:48:45 pixelserv-tls[11185]: 440825 uts, 1 log, 0 kcc, 26 kmx, 1.01 kvg, 180 krq, 26433 req, 1056 avg, 19191 rmx, 9 tav, 389 tmx, 357 slh, 27 slm, 0 sle, 21613 slc, 3472 slu, 546 uca, 2630 uce, 50 sct, 24768 sch, 290 scm, 277 scp, 0 sst, 997 ssh, 7043 ssm, 0 ssp, 715 nfe, 5 gif, 2 ico, 118 txt, 0 jpg, 0 png, 0 swf, 19 sta, 0 stt, 6 ufe, 0 opt, 418 pst, 0 hed, 15 rdr, 0 nou, 0 pth, 0 204, 0 bad, 19 tmo, 21617 cls, 0 cly, 0 clt, 0 err
Apr 21 11:48:58 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=xxx SRC=107.170.193.75 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=248 ID=54321 PROTO=TCP SPT=35171 DPT=8890 SEQ=1482571135 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0
Apr 21 11:49:27 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=xxx SRC=109.248.9.10 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=244 ID=36141 PROTO=TCP SPT=46779 DPT=33389 SEQ=2387993918 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0
Apr 21 11:49:31 dnscrypt-proxy[19112]: Stopped.
Apr 21 11:49:59 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=xxx SRC=5.188.11.91 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=242 ID=51185 PROTO=TCP SPT=59188 DPT=11009 SEQ=779880078 ACK=0 WINDOW=1024 RES=0x00 SYN URGP=0
Apr 21 11:50:34 pixelserv-tls[11185]: 440934 uts, 1 log, 0 kcc, 26 kmx, 1.01 kvg, 180 krq, 26456 req, 1056 avg, 19191 rmx, 9 tav, 389 tmx, 357 slh, 27 slm, 0 sle, 21636 slc, 3472 slu, 546 uca, 2630 uce, 50 sct, 24791 sch, 290 scm, 277 scp, 0 sst, 997 ssh, 7047 ssm, 0 ssp, 715 nfe, 5 gif, 2 ico, 118 txt, 0 jpg, 0 png, 0 swf, 19 sta, 0 stt, 6 ufe, 0 opt, 418 pst, 0 hed, 15 rdr, 0 nou, 0 pth, 0 204, 0 bad, 19 tmo, 21640 cls, 0 cly, 0 clt, 0 err
Apr 21 11:52:03 kernel: [BLOCKED - INBOUND] IN=eth0 OUT= MAC=xxx SRC=177.68.36.82 DST=xxx LEN=40 TOS=0x00 PREC=0x00 TTL=241 ID=29264 DF PROTO=TCP SPT=32409 DPT=23 SEQ=829530438 ACK=0 WINDOW=14600 RES=0x00 SYN URGP=0
Apr 21 11:52:18 user: Start dnscrypt-proxy
Apr 21 11:52:19 dnscrypt-proxy[24188]: Source [https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md] loaded
Apr 21 11:52:19 dnscrypt-proxy[24188]: dnscrypt-proxy 2.0.6
Apr 21 11:52:19 dnscrypt-proxy[24188]: Loading the set of blocking rules from [blacklist.txt]
Apr 21 11:52:19 dnscrypt-proxy[24188]: Now listening to 127.0.0.1:65053 [UDP]
Apr 21 11:52:19 dnscrypt-proxy[24188]: Now listening to 127.0.0.1:65053 [TCP]

I don't see much else, other than I do get a fair number of this message:
kernel: br0: received packet on eth1 with own address as source address

RT-88U, Merlin 384.4.2, ABS, Skynet, dnscrypt 2.0.6, and pixelserv 2.1

 

[Treadler]

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.

I hear what you’re saying. My real world experience though, is great.
Cloudflare via DoH is easily as ‘snappy’ as my ISP.

Quad9 & Google are both like wading through wet cement by comparison. (A location specific problem I’d imagine).

Re privacy; locally, ISP’s are required to store the last two years worth (metadata) of everything done online, so that horse has bolted.........