Usare dnscrypt-proxy come resolver
dnscrypt-proxy è l'applicazione ufficiale per la risoluzione dei nomi via dnscrypt (rif. https://dnscrypt.info/implementations).
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-proxyper 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.