Si tratta di un proxy dns come AdGuard Home che inoltra su server upstream le nostre richieste di risoluzione.

Può essere messo sul singolo host o può diventare il resolver dell'intera rete, come abbiamo visto qui.

Pronti? Via!

Obiettivo: Installare dnscrypt-proxy sul nostro pc.

• Scaricare il binario dnscrypt-proxy per il proprio sistema (nel mio caso gnu/linux),
• oppure installare da repository
• c'è anche come container (https://github.com/DNSCrypt/dnscrypt-server-docker)

La versione attuale è la 2.1.20 (rif. https://github.com/DNSCrypt/dnscrypt-proxy/releases/latest)

# scarica
wget https://github.com/DNSCrypt/dnscrypt-proxy/releases/download/2.1.20/dnscrypt-proxy-linux_x86_64-2.1.20.tar.gz

# scompatta
tar -xzf dnscrypt-proxy-linux_x86_64-2.1.20.tar.gz -C /opt/

# rifinisce
mv /opt/linux-x86_64 /opt/dnscrypt-proxy
chown -R root:root  /opt/dnscrypt-proxy

# abilita file di configurazione
cp /opt/dnscrypt-proxy/example-dnscrypt-proxy.toml  /opt/dnscrypt-proxy/dnscrypt-proxy.toml

# Creazione servizio
'/opt/dnscrypt-proxy/dnscrypt-proxy -service install

#  avvio servizio
systemctl start dnscrypt-proxy.service

Finito. Ora siamo pronti per risolvere nomi con dnscrypt, basta dichiarare come dns primario della nostra connessione il listener dichiarato nel file dnscrypt-proxy.toml (default:127.0.0.1:53).

Test:

dnscrypt-proxy -resolve www.google.com
Resolving [www.google.com] using 127.0.0.1 port 53

Resolver      : 176.123.4.231 (public.deepdns.net.)

Canonical name: www.google.com.

IPv4 addresses: 142.251.154.119, 142.251.150.119, 142.251.155.119, 142.251.151.119, 142.251.153.119, 142.251.157.119, 142.251.156.119, 142.251.152.119
IPv6 addresses: 2001:4860:482d:7700::, 2001:4860:4829:7700::, 2001:4860:482b:7700::, 2001:4860:4826:7700::, 2001:4860:482a:7700::, 2001:4860:4828:7700::, 2001:4860:4827:7700::, 2001:4860:482c:7700::

Name servers  : no name servers found
DNSSEC signed : no
Mail servers  : no mail servers found

HTTPS alias   : -
HTTPS info    : [alpn]=[h2,h3]

Host info     : -
TXT records   : -

Possibili problemi

1. SELinux impedisce l'avvio del servizio

Su Fedora, se non si installa da package manager, ci potrebbero essere problemi con l'avvio del servizio se SELinux è attivato.

Potrebbe essere notificato un errore di questo tipo:

Unable to locate executable '/opt/dnscrypt-proxy/dnscrypt-proxy': Permission denied
Failed at step EXEC spawning /opt/dnscrypt-proxy/dnscrypt-proxy: Permission denied
status=203/EXEC

Se si riavvia il servizio e si analizza l'audit esaminando l'Access Vector Cache (AVC), abbiamo informazioni molto interessanti:

ausearch -m AVC,USER_AVC -ts recent
----
...
avc:  denied  { execute }
comm="(pt-proxy)" 
name="dnscrypt-proxy" 
dev="dm-0" ino=1186741 
scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:user_tmp_t:s0 
tclass=file

In sostanza, SELinux nega l'esecuzione con systemctl perché il contesto atteso non è quello posseduto dal file, come confermato anche da questo comando che mostra i contesti di tutti i file.

ls -Z /opt/dnscrypt-proxy/
unconfined_u:object_r:user_tmp_t:s0 dnscrypt-proxy             unconfined_u:object_r:user_tmp_t:s0 example-captive-portals.txt   unconfined_u:object_r:user_tmp_t:s0 public-resolvers.md
unconfined_u:object_r:user_tmp_t:s0 dnscrypt-proxy.toml
...

mentre questo comando mostra il contesto atteso:

matchpathcon /opt/dnscrypt-proxy/dnscrypt-proxy
/opt/dnscrypt-proxy/dnscrypt-proxy	system_u:object_r:bin_t:s0

Il binario è etichettato come file di tipo temporaneo (user_tmp_t) appartenente a un contesto utente (unconfined_u), mentre invece SELinux si aspetta che l'eseguibile sia di tipo bin_t appartenente a system_u.

Quello che bisogna fare, è cambiare l'etichetta dell'eseguibile in modo che possa essere eseguito come servizio.

Configurazione SELinux

# cambia l'utente in system_t e il tipo in bin_t
semanage fcontext -a -s system_t -t bin_t '/opt/dnscrypt-proxy/dnscrypt-proxy'
# forza il restore e rendo permanenti tutti i campi in accordo a matchpathcon
restorecon -Fv /opt/dnscrypt-proxy/dnscrypt-proxy
# facoltativo: se l'utente non dovesse essere cambiato, forzarne il cambio con chcon
chcon -u system_u /opt/dnscrypt-proxy/dnscrypt-proxy

# check. Devono dare tutti lo stesso risultato
semanage fcontext -C -l
matchpathcon /opt/dnscrypt-proxy/dnscrypt-proxy
ls -Z /opt/dnscrypt-proxy/

2. Il servizio non parte perché la porta 53 risulta occupata

dnscrypt-proxy non si avvia perché rileva un errore di porta occupata tipo questo:

[FATAL] listen udp4 127.0.0.1:53: bind: address already in use
<date time host> systemd[1]: dnscrypt-proxy.service: Main process exited, code=exited, status=255/EXCEPTION
<date time host> systemd[1]: dnscrypt-proxy.service: Failed with result 'exit-code'.

Molto probabile che stia andando in conflitto con lo stub resolver di systemd.

Se così fosse (basta dare un'occhiata a /etc/resolv.conf), una soluzione rapida potrebbe consistere nel disabilitare systemd-resolved.

Oppure fare in modo che i loro listener siano differenti.

Agiamo su quello di dnscrypt-proxy per es.:

vi /opt/dnscrypt-proxy/dnscrypt-proxy.toml
...
listen_addresses = ['127.0.53.53:53']
...

Ricordiamoci sempre di configurare la nostra connessione con questo listener e buon divertimento.

Il traffico delle nostre risoluzioni è definitivamente NOSTRO.

#dns #dnscrypt #dnscryptproxy #selinux