mirrors/dnscrypt-proxy
1
0
Fork 0
mirror of https://github.com/DNSCrypt/dnscrypt-proxy.git synced 2025-03-04 02:14:40 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Remove confusing information

Frank Denis 2021-07-15 19:04:26 +02:00
parent 67fb00c977
commit c8c22bc452
4 changed files with 61 additions and 51 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

44
Checking.md

@ -1,6 +1,6 @@
# Checking that your DNS traffic is encrypted and authenticated
Once everything has been setup, if you want to verify that your DNS traffic is actually encrypted and authenticated, here are a couple things you can try:
Once everything has been setup, in order to to verify that your DNS traffic is actually encrypted and authenticated, here are a couple options
## Stop or pause the proxy
@ -10,7 +10,7 @@ On Unix systems the following commands will pause the proxy:
pkill -STOP dnscrypt-proxy
```
If applications cannot resolve anything now (e.g. no website is available and/or reachable), it probably means that all your DNS traffic was going through the proxy, and was therefore encrypted and authenticated.
If applications, including web browsers, cannot resolve DNS names any longer, it probably means that all your DNS traffic was going through the proxy, and was therefore encrypted and authenticated.
To resume execution, use the following command:
@ -18,29 +18,19 @@ To resume execution, use the following command:
pkill -CONT dnscrypt-proxy
```
Alternatively, on Linux, you can completely stop - now DNSCrypt-Proxy shouldn't resolve anything - and start service again using e.g. systemd `systemctl(1)` utility (which is the service manager found in distributions, that have made the switch to systemd) or `service(8)` command (which works even for distributions, that have migrated to systemd). Here are examples:
```sh
sudo systemctl stop dnscrypt-proxy
sudo systemctl start dnscrypt-proxy
sudo service dnscrypt-proxy stop
​sudo service dnscrypt-proxy start
```
On Windows systems, User can achieve similar results, simply by closing and start application again. There is popular "Task Manager" (to open, press `Ctrl+Alt+Delete` and click "Task Manager" on the screen or just press `Ctrl+Shift+Esc`) where User can close application and then start it again etc.
On Windows systems, the service can be stopped and restarted with the `service-uninstall.bat` and `service-start.bat` script, or by using the Task Manager.
## Block a domain
Add a [filter](Filters) to block a name that is very likely to resolve under normal circumstances.
If you can't access it any more, it means that your DNS traffic is using the proxy, and is therefore encrypted. If you still do, then make sure to flush your DNS cache and restart dnscrypt-proxy service.
If you can't access it any more, it means that your DNS traffic is using the proxy, and is therefore encrypted. If you still do, then make sure to flush your DNS caches and restart dnscrypt-proxy service.
## Enable query logging
Enable [query logging](Logging), use your device normally, and check that the log file gets filled by queries you just made.
## Use third-party tools
## Using traffic capture
The command-line tool `tcpdump` can be used to see if there is outgoing non-encrypted traffic:
@ -49,11 +39,14 @@ sudo tcpdump -n dst port 53 and \
'not dst net (::1 or 10 or 127 or 172.16/12 or 192.168/16)'
```
## Verify DNS provider via DNS Leak test
## Using 3rd party tools
Another way to check and verify if DNSCrypt-Proxy works correctly, is to perform simple DNS Leak test, which can be done - for example - on [dnsleaktest.com](https://www.dnsleaktest.com/) website. Differences between **Standard** and **Extended** tests are - in short - related with the number of rounds and queries etc. Additional informations, that should help User to decide, which test is better, can be found here: [Standard vs Extended](https://www.dnsleaktest.com/what-is-the-difference.html).
The [dnsleaktest.com](https://www.dnsleaktest.com/) is a popular website to check what DNS resolvers you may be using.
Below, there is an example of the Extended test, with two resolvers configured via `server_names` option (cf. `dnscrypt-proxy.toml` configuration file). Used resolvers: **scaleway-fr** (DNSCrypt server donated by Scaleway.com; hosted in Paris, France) and **switch** (Public DoH service provided by SWITCH, Switzerland).
Note that it will only check the configuration of your web browser. Other software may be using a different DNS configuration.
A HTTP proxy can also cause this test to return incorrect results.
Below, there is an example of the Extended test, with two configured resolvers:
```sh
,----------------------------------------------------------------------------------------------------------------.
@ -62,17 +55,4 @@ Below, there is an example of the Extended test, with two resolvers configured v
| 212.47.228.136 scaleway-fr.dnscrypt.info. Scaleway France |
| 130.59.118.147 kirby.switch.ch. Swiss Education and Research Network Zurich, Switzerland |
`----------------------------------------------------------------------------------------------------------------'
```
The result should contain informations about server or servers configured by the User (as in above example) or chosen by DNSCrypt-Proxy itself (based on configuration using various filters and/or options available in `dnscrypt-proxy.toml` configuration file). As we can see above, everything is okay - the result is compliant with User configuration.
If DNS Leak test and other methods - described above (vide "_Block a domain_", "_Enable query logging_" sections etc.) works and shows a proper results, then DNSCrypt-Proxy probably works correctly.
However, if DNS Leak tests shows a different IP address (e.g. your **ISP**) there is a high probability of leaking the DNS data to your **I**nternet **S**ervice **P**rovider. In short: DNS Leak is a privacy/security vulnerability, because your IP address, location, and browsing data, are an easy target and DNS requests are - let say - wide open for network observation/observers.
Here are some additional websites on which DNS Leak tests can be carried out.
- [DNS Leak Test, browserleaks.com](https://browserleaks.com/dns)
- [DNS Leak Test, Tenta VPN Browser](https://tenta.com/test/)
- [DNS Leak Test: Find and Fix DNS Leaks | ExpressVPN](https://www.expressvpn.com/dns-leak-test)
**NOTE:** It seems to be a good idea to redo DNS Leak test, especially after software (e.g. related with networking), system or web browser updates. We cannot be one hundred percent sure, that if today there isn't a DNS Leak, there won't be one tomorrow.
```

34
Installation-linux.md

@ -1,5 +1,3 @@
***
# Installing dnscrypt-proxy on Linux
Unfortunately, providing universal installation instructions for Linux is impossible, since there are many distributions, working their own way, especially when it comes to configuring system settings (DNS).
@ -241,34 +239,44 @@ chattr -i /etc/resolv.conf
### If `immutable` flag doesn't work
It is still possible, that setting `immutable` flag will be not possible, due to e.g. _"Operation not supported"_ issue and/or `/etc/resolv.conf` file will be changed anyway (network managers tend to overwrite this file). There is one more thing Users can do, to prevent this from happening. If, for example, `resolv.conf` file contain _"Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)"_ message, open `/etc/resolvconf/resolv.conf.d/base` file and add:
```
It is still possible, that setting `immutable` flag will be not possible, due to e.g. _"Operation not supported"_ issue and/or `/etc/resolv.conf` file will be changed anyway (network managers tend to overwrite this file). As a last resort, if the `resolv.conf` file contain _"Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)"_ message, edit the `/etc/resolvconf/resolv.conf.d/base` file and fill it with:
```text
nameserver 127.0.0.1
options edns0
```
Save and close file. (Please note, that - for example - Debian distribution use slighty different IP address: `127.0.2.1`. Additionally, **EDNS0** allows DNS clients to expand UDP packets size up to 4096 bytes for certain DNS parameters, while the original restricted size is 512 bytes. It's important, especially due to the implementation of the DNSSEC mechanism).
Finally, reboot computer - it seems to be the best method to check if everything works (or just restart networking/resolvconf, using e.g. `service(8)` or `systemctl(1)` commands) and then check `/etc/resolv.conf` file again. Now, there always should be: IP address and EDNS0 option.
Save and close the file.
Anyway, if DHCP is in use and `dhclient` still overwrites `/etc/resolv.conf` file, User should try to remove `domain-name-servers` from the `request` statement in the `/etc/dhcp/dhclient.conf` file (for more - important - informations, please read: _"Modifying /etc/dhcp/dhclient.conf"_ section [in:] [Debian wiki - resolv.conf](https://wiki.debian.org/resolv.conf)).
Notes:
* Debian distributions use `127.0.2.1` instead.
* `options edn0` is an optional micro-optimization.
Because problems with overwriting/replacing the `/etc/resolv.conf` file may have various sources and causes, it is worth reading, among other things, another man pages for `dhclient.conf(5)` (see especially `prepend domain-name-servers` option) and `resolvconf(8)` with _"libc"_ section [in:] **"CONSUMERS OF NAMESERVER INFORMATION"**.
Then, a surefire way to get the new configuration taken into account by all applications is to restart the system.
### If you can only reach DNS-over-HTTPS server
Finally, if DHCP is in use and `dhclient` still overwrites `/etc/resolv.conf` file, try removing `domain-name-servers` from the `request` statement in `/etc/dhcp/dhclient.conf` (the Debian wiki has some documentation about this: [_"Modifying /etc/dhcp/dhclient.conf"_](https://wiki.debian.org/resolv.conf)).
When running `dnscrypt-proxy`, it can be the case that it only successfully reaches DNS-over-HTTPS (DoH) servers, but not DNSCrypt servers.
A symptom is that, when running `./dnscrypt-proxy` the only servers that do not time out are DoH servers, *e.g.*:
```
Additional recommended reading: the `resolvconf` man page.
### If you can only reach servers over TCP
Some systems may be able to reach out to DNS-over-HTTPS (DoH) servers over HTTP/2 and DNSCrypt over TCP, but not DNSCrypt servers over UDP nor DoH servers over HTTP/3.
An illustration is timeouts for DNSCrypt servers in the default configuration:
```text
...
[NOTICE] [securedns] TIMEOUT
[NOTICE] [securedns-doh] OK (DoH) - rtt: 40ms
...
```
In that case, make sure that `dnscrypt-proxy` can connect peers not only on TCP 443 (HTTPS, and hence DoH), but also on UDP 443. If you are using `iptables` on Linux, you can add the following rule
In that case, make sure that `dnscrypt-proxy` can connect to remote servers on TCP port 443 (HTTPS, and hence DoH over HTTP/2), but also on UDP 443 (DNSCrypt and QUIC). Linux systems still using the `iptables` mechanism can do it as follows:
```sh
iptables -A OUTPUT -p udp --sport 443 -j ACCEPT
```
and then restart `dnscrypt-proxy`.
### Upgrading

29
Installation-on-Alpine-Linux.md

@ -1,15 +1,19 @@
# Installation on Alpine Linux
## Enabling the Community Repository
dnscrypt-proxy is in the 'community' repository which needs to be enabled in `/etc/apk/respositories` by removing the comment `#` on the appropriate line e.g.
```
```text
# main and community enabled, testing disabled on the 'edge' branch
http://alpine.mirror.wearetriple.com/edge/main
http://alpine.mirror.wearetriple.com/edge/community
#http://alpine.mirror.wearetriple.com/edge/testing
```
If you're not running on 'edge' then you might see the version numbers instead
```
```text
# main and community enabled, testing disabled on the 'V3.9' branch
http://alpine.mirror.wearetriple.com/V3.9/main
http://alpine.mirror.wearetriple.com/V3.9/community
@ -17,21 +21,31 @@ http://alpine.mirror.wearetriple.com/V3.9/community
```
## Installation
Alpine maintains discreet packages for dnscrypt-proxy, and the openrc package for managing the service
Alpine Linux maintain their own packages for dnscrypt-proxy, and the openrc package for managing the service.
Installation:
```sh
apk update && apk add dnscrypt-proxy dnscrypt-proxy-openrc
```
## Service Setup
To start at boot, use
```sh
rc-update add dnscrypt-proxy default
```
Then to start the service immediately...
```sh
rc-service dnscrypt-proxy start
```
or
```sh
/etc/init.d/dnscrypt-proxy start
```
@ -42,7 +56,14 @@ There are also some examples on [https://wiki.alpinelinux.org/wiki/DNSCrypt-Prox
Example configuration files are stored in `/usr/share/dnscrypt-proxy`.
## Upgrades
When upgrading the package, a new file `/etc/dnscrypt-proxy/dnscrypt-proxy.toml.apk-new` will be created. The original configuration file remains, and the new default configuration file gets this `apk-new` extension. Be aware new configuration properties (if available) will be in the `apk-new` file, since an edited configuration file can not be automatically updated. To see the differences, use `diff`
When upgrading the package, a new file `/etc/dnscrypt-proxy/dnscrypt-proxy.toml.apk-new` will be created.
The original configuration file remains, and the new default configuration file gets this `apk-new` extension.
Be aware that new configuration properties (if available) will be in the `apk-new` file, since an edited configuration file can not be automatically updated.
To see the differences, use the `diff` command:
```sh
diff /etc/dnscrypt-proxy/dnscrypt-proxy.toml /etc/dnscrypt-proxy/dnscrypt-proxy.toml.apk-new
```

5
Local-DoH.md

@ -94,6 +94,7 @@ Note that the actual resolvers don't have to be Cloudflare's, and don't have to
In order to revert the changes, set `network.trr.mode` to `0`. Other parameters will then be ignored, so they can be left as-is.
### Caution!
User must remember, that enabling `ECH`/`ESNI` is not enough. Generally speaking, the domains which User wants to visit, also must have support for Encrypted SNI, as well as for DNSSEC and TLS 1.3 - the fact, that web browsers support these essential features and advanced protocols - in this situation - is not sufficient and doesn't change anything.
If the above conditions are not met, privacy is not fully assured and/or protected, because - for example - unencrypted Server Name Indication (`SNI`) leaks an information about the origin server (hostname from the TLS handshake etc.) with which the client wants to connect and - potentially - allows attacker/network observers obtaining a lot of informations about the client communication. Of course, that's only one example.
Enabling `ECH` doesn't actually do anything unless the website you are connecting to was explicitly configured to support it. This requires TLS 1.3.
As of today, this is not supported anywhere, except on websites cached by Cloudflare and participating to the experiment.