Protegint peticions DNS

DISCLAIMER Pot contenir paraulotes!

Assumim que ja tenim systemd-resolved instal·lat i en execució i sabem fer servir la terminal de linux i programes com nano o vim. Assumim que la lectora té uns coneixements minims de Linux i de xarxes.

Què és el DNS i per què és important protegir les peticions?

El DNS (Domain Name System) és un sistema fonamental a Internet que tradueix noms de domini comprensibles per als humans (com ara example.com) en adreces IP utilitzables pels ordinadors. Les peticions DNS, si es fan en text pla, poden ser interceptades i analitzades per tercers malintencionats, exposant els hàbits de navegació dels usuaris i possibilitant atacs com el man-in-the-middle.

Per aquest motiu, és essencial protegir aquestes consultes amb tecnologies com DNS sobre HTTPS (DoH) o DNS sobre TLS (DoT).

Capturant peticions DNS en clar amb `tcpdump`

Si les peticions DNS no estan xifrades, és possible visualitzar-les fàcilment amb tcpdump. Veiem com capturar peticions DNS que viatgen per UDP al port 53. Obrim una terminal i executem la següent comanda:

sudo tcpdump -i any -n port 53

En una altra terminal, fem una consulta DNS a un servidor públic:

dig debian.org

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> debian.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42705
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;debian.org.			IN	A

;; ANSWER SECTION:
debian.org.		300	IN	A	151.101.130.132
debian.org.		300	IN	A	151.101.194.132
debian.org.		300	IN	A	151.101.2.132
debian.org.		300	IN	A	151.101.66.132

;; Query time: 72 msec
;; SERVER: 193.110.81.0#53(193.110.81.0) (UDP)
;; WHEN: Sun Mar 16 11:40:33 CET 2025
;; MSG SIZE  rcvd: 103

Aquesta comanda serveix per fer una consulta DNS a debian.org utilitzant el servidor DNS configurat a la màquina, en aquest cas, 193.110.81.0 i ens retorna totes les adreces IP associades al domini.

En fer la consulta podrem veure les peticions DNS en clar a la terminal on s’ha executat tcpdump:

➜ sudo tcpdump -i any -n port 53
[sudo] password for user: 
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
11:40:33.781615 eth0 Out IP 192.168.125.95.36518 > 193.110.81.0.53: 42705+ [1au] A? debian.org. (51)
11:40:33.843465 eth0 Out IP 192.168.125.95.37405 > 193.110.81.0.53: 2671+ PTR? 0.81.110.193.in-addr.arpa. (43)
11:40:33.854519 eth0 In  IP 193.110.81.0.53 > 192.168.125.95.36518: 42705$ 4/0/1 A 151.101.130.132, A 151.101.194.132, A 151.101.2.132, A 151.101.66.132 (103)
11:40:33.887521 eth0 In  IP 193.110.81.0.53 > 192.168.125.95.37405: 2671 1/0/0 PTR dns0.eu. (64)
11:40:33.887741 eth0 Out IP 192.168.125.95.50809 > 193.110.81.0.53: 56619+ PTR? 95.125.168.192.in-addr.arpa. (45)
11:40:33.930090 eth0 In  IP 193.110.81.0.53 > 192.168.125.95.50809: 56619 NXDomain 0/1/0 (122)

Aquí podem veure com es fa una petició al servidor DNS configurat 193.110.81.0.53 per resoldre el nom de domini A? debian.org i les seves IP associades.

Qualsevol persona o màquina que estigui a mig camí d’aquesta comunicació podria veure aquesta informació i inclús modificar-la amb finalitats malicioses, el q es coneix com un atac man-in-the-middle. Per exemple, podria interceptar la comunicació i redirigir-nos a una pàgina web falsa…

Configurant `systemd-resolved` per utilitzar DNS sobre HTTPS (DoH)

Systemd és una suite de sistemes i serveis per a Linux que proporciona una sèrie de funcionalitats comúns per a la gestió de sistemes i serveis. systemd-resolved és un dels components de systemd que proporciona resolució de noms de domini i serveis de DNS.

A partir de les versions recents de systemd, systemd-resolved admet DoH de manera nativa. Per configurar-lo:

Obrim el fitxer de configuració de systemd-resolved:
```
sudo nano /etc/systemd/resolved.conf
```

Afegim les següents línies al fitxer:

FallbackDNS=1.1.1.1#cloudflare-dns.com
FallbackDNS=1.0.0.1#cloudflare-dns.com
FallbackDNS=2606:4700:4700::1111#cloudflare-dns.com
FallbackDNS=2606:4700:4700::1001#cloudflare-dns.com
DNS=193.110.81.0#dns0.eu
DNS=2a0f:fc80::#dns0.eu
DNS=185.253.5.0#dns0.eu
DNS=2a0f:fc81::#dns0.eu
DNSOverTLS=yes
DNSSEC=yes

Modifiquem el NetworkManager perquè utilitzi systemd-resolved com a resolutor de DNS:
```
nano /etc/NetworkManager/NetworkManager.conf 
```
Afegim a la secció [main]:
```
[main]
dns=systemd-resolved
```
A tenir en compte que potser haurem de modificar les connexions ja existents per a q facin servir el servidor DNS que estem configurant. En Linux Mint, accedir a les opcions de la xarxa i desactivar, sota l’apartat IPv4 que el DNS vingui donat automàticament per DHCP. Veure l’apartat Resolució de problemes
Creem un enllaç simbòlic de /run/systemd/resolve/stub-resolv.conf a /etc/resolv.conf:
```
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
```
El fitxer /etc/resolv.conf és el fitxer de configuració de DNS que utilitza el sistema per resoldre noms de domini. El servei de resolved te un servidor stub integrat que fa a la vegada de servidor DNS local i cache de dominis. Podem no fer servir el servidor i fer les peticions directament enllaçant: ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
Reiniciem els serveis:

sudo systemctl restart systemd-resolved
sudo systemctl restart NetworkManager

Comprovar que estem fent servir DoH

Obrim dues terminals i executem tcpdump per veure les peticions en clar i les peticions DoH:

# terminal 1, peticions en clar
sudo tcpdump -i any -n port 53
# terminal 2, peticions xifrades
sudo tcpdump -i any -n port 853

En executar dig veurem el següent, a la terminal 1 (peticions en clar):

12:00:30.680160 lo    In  IP localhost.57279 > _localdnsstub.domain: 6073+ [1au] A? debian.org. (51)
12:00:31.018921 lo    In  IP _localdnsstub.domain > localhost.57279: 6073$ 4/0/1 A 151.101.130.132, A 151.101.194.132, A 151.101.2.132, A 151.101.66.132 (103)

Podem veure la petició en clar es realitza en local, ens preguntem a “nosaltres mateixos” per la IP de debian.org al servidor stub del resolved.

I a la terminal 2 (peticions xifrades) podem veure com es fa la petició DoH:

12:05:28.585916 eth0 Out IP 192.168.125.95.40062 > 193.110.81.0.853: Flags [P.], seq 11771:11795, ack 71528, win 882, options [nop,nop,TS val 3598223960 ecr 2288197821], length 24
12:05:28.634319 eth0 In  IP 193.110.81.0.853 > 192.168.125.95.40062: Flags [P.], seq 71528:71552, ack 11795, win 1810, options [nop,nop,TS val 2288207975 ecr 3598223960], length 24

S’aprecia com la petició es fa a la IP local cap al servidor DNS configurat amb DoT: 193.110.81.0 però no es veu la petició en si, ja que està xifrada.

Comprovar que estem fent servir DNSSEC

Podem correr la següent comanda

dig org. SOA +dnssec
#...
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
#...

I comprovar q les flags contenen la flag ad.

Resolució de problemes

El servidor DNS és el de la xarxa local.

Per veure la configuració actual podem fer:

➜ resolvectl status 
Global
           Protocols: -LLMNR -mDNS +DNSOverTLS DNSSEC=yes/supported
    resolv.conf mode: stub
  Current DNS Server: 185.253.5.0#dns0.eu
         DNS Servers: 193.110.81.0#dns0.eu 2a0f:fc80::#dns0.eu 185.253.5.0#dns0.eu
                      2a0f:fc81::#dns0.eu
Fallback DNS Servers: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com
                      2606:4700:4700::1111#cloudflare-dns.com
                      2606:4700:4700::1001#cloudflare-dns.com

# ......

Link 6 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS +DNSOverTLS DNSSEC=yes/supported
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1

Si veiem que l’enllaç que ens dona internet té un DNS propi 192.168.1.1, probablement haurem de desactivar l’obtenció de servidor DNS via DHCP, fent servir la interfície d’usuari per a cada xarxa.

També podem sobreescriure la configuració global:

sudo nano /etc/NetworkManager/NetworkManager.conf
[global-dns-domain-*]
servers=127.0.0.53

Hem de tenir en compte que això sobreescriurà la configuració de DNS per a totes les xarxes, i que potser no és el que volem. Per exemple, si fem servir una VPN, potser volem que la VPN ens doni el servidor DNS.

En aquest cas podem mirar de fer servir resolvectl per a configurar la xarxa en concret:

sudo resolvectl dns tun0 10.1.0.1

O intentar configurar-ho d’alguna altra forma fent servir NetworkManager:

nmcli con mod "$connectionName" ipv4.dns "8.8.8.8 8.8.4.4"

No em funciona a la biblioteca o si hi ha un portal captiu

A vegades, a les biblioteques o a les xarxes públiques, hi ha un portal captiu que ens redirigeix a una pàgina web per autenticar-nos. Això pot fer que la resolució de noms no funcioni correctament fins q no ens autentiquem.

La solució és desactivar la resolució de noms automàtica a la xarxa en q estem i configurar-la manualment.

nmcli con mod "$connectionName" ipv4.ignore-auto-dns yes

Si no funciona, podem provar de configurar el servidor DNS manualment fent servir la porta d’enllaç com a servidor DNS:

Busquem quina es la porta d’enllaç, en l’exemple següent és 192.168.1.1:

ip r
default via 192.168.1.1 dev enxbe2b3e9a0954 proto dhcp src 192.168.1.30 metric 100 
192.168.1.0/24 dev enxbe2b3e9a0954 proto kernel scope link src 192.168.1.30 metric 100

I configurem el servidor DNS tal com hem vist en passos anteriors:

nmcli con mod "$connectionName" ipv4.dns "192.168.1.1"
# O
sudo resolvectl dns wlan0 192.168.1.1

Tot i q tambè hauriem de poder entrar directament al portal captiu copiant l’adreça IP de la porta d’enllaç al navegador.

Això hauria de ser suficient per poder navegar sense problemes :).

Si no funciona la resolució de noms

Podria ser que el servidor stub no s’executi de forma correcta, ja que un altre servei pot estar ocupant el port. Per diagnosticar:

sudo ss -ulpn | grep 53
UNCONN 0      0         127.0.0.54:53         0.0.0.0:*    users:(("systemd-resolve",pid=14890,fd=16))
UNCONN 0      0      127.0.0.53%lo:53         0.0.0.0:*    users:(("systemd-resolve",pid=14890,fd=14))
UNCONN 0      0            0.0.0.0:5353       0.0.0.0:*    users:(("avahi-daemon",pid=1346,fd=12))    
UNCONN 0      0               [::]:5353          [::]:*    users:(("avahi-daemon",pid=1346,fd=13))

Si no veieu res semblant a això i veieu un altre servei corrent al port 53, tenim algun problema!

Bonus: podem veure els logs de debug de resolved fent:

sudo systemctl service-log-level systemd-resolved debug
journalctl -e -f -u systemd-resolved

No vull fer servir systemd!

Si no es vol fer servir SystemD (pels motius q siguin), podem muntar el nostre propi servidor stub fàcilment amb Stubby.

Els passos a seguir serien

Desactivar resolved
Instal·lar i configurar Stubby
Fer servir DNSMasq com a cachè de DNS

Els passos i la configuració són relativament fàcils i hi ha bons tutorials per internet!

Conclusió

La protecció de les peticions DNS és un pas essencial per millorar la privacitat i la seguretat a Internet. Hem vist com les peticions DNS en text pla poden ser interceptades fàcilment i com podem mitigar aquest risc configurant systemd-resolved per utilitzar DNS sobre HTTPS (DoH) o DNS sobre TLS (DoT).

Amb aquesta configuració, ens assegurem que les consultes DNS es transmetin de manera xifrada, impedint que tercers puguin espiar o manipular les nostres connexions. A més, hem explorat com diagnosticar possibles problemes i com comprovar que el sistema està funcionant correctament.

Finalment, és important recordar que la seguretat en línia és un procés continu i que cal estar al dia amb les millors pràctiques i noves amenaces. Configurar DoH o DoT és un pas important, però no l’únic: una estratègia de seguretat completa també inclou altres mesures com l’ús de VPNs, eines d’anàlisi de trànsit i la revisió periòdica de la configuració del sistema.

Protegir les peticions DNS és un petit esforç que pot tenir un gran impacte en la nostra privacitat digital. Així que… a configurar i navegar amb més seguretat!

Protegint peticions DNS

Table of Contents

Protegint peticions DNS

Què és el DNS i per què és important protegir les peticions?

Capturant peticions DNS en clar amb tcpdump

Configurant systemd-resolved per utilitzar DNS sobre HTTPS (DoH)

Comprovar que estem fent servir DoH

Comprovar que estem fent servir DNSSEC

Resolució de problemes

El servidor DNS és el de la xarxa local.

No em funciona a la biblioteca o si hi ha un portal captiu

Si no funciona la resolució de noms

No vull fer servir systemd!

Conclusió

Capturant peticions DNS en clar amb `tcpdump`

Configurant `systemd-resolved` per utilitzar DNS sobre HTTPS (DoH)