DNS. Egyidős protokoll a ma létező internettel, ami annak idején azért jött létre, hogy ne hosszú számsorokból álló IP címeket kelljen megjegyezni a kedvenc fórumunk meglátogatásához, hanem elég legyen csak megjegyezni a prohardver.hu címet és már ott is vagyunk a kívánt oldalon. Azóta természetesen rengeteg új feladata lett, rengeteg új rekordtípus született, de maga a protokoll nem igen változott az évtizedek során. Azóta is teljes rálátással van mindenki a DNS forgalomra, mivel az nincsen megfelelően titkosítva. Így a netszolgáltató, sőt esetlegesen a hálózat többi szereplője (pl. wifin) beleláthat a feloldási előzményeinkbe. Bár ez önmagában csak annyit jelent, hogy a szolgáltatónak például lesz egy képe arról, hogy mely fő domaineket látogatjuk napi szinten, (pl google.com), a teljes címet nem fogja egy DNS lekérés tartalmazni (tehát pl google.com/search). Illetve a titkosítás és annak validálásának hiánya miatt sokkal könnyebb eltéríteni a DNS válaszokat. Ez egy probléma, amelyet a Cloudflare ismert fel először és alkották meg a DNS over TLS specifikációját és alkalmazták azt elsőként az 1.1.1.1-es DNS szerverükön. Tovább is olvastam részletek után kutatva és meg is találtam a specifikációt: [link] Kiderült, hogy ugyan friss még a dolog, az Android 9+ már támogatja a funkciót, illetve néhány böngésző bétája is. Elhatároztam tehát, hogy teszek vele egy próbát mindenképp.
Ugyanakkor itt fontos leszögezni, hogy bár a szolgáltató még a titkosított DNS mellett is képes lesz követni, hogy mely IP címekkel van forgalmunk (ami teljesen rendben van, nem is várható el, hogy ne így legyen), azt viszont, hogy pontosan mely címeket látogatjuk, nem tudják majd. Illetve így a Cloudflare, mivel én az ő DNS-ük használata mellett döntöttem tudni fogja természetesen minden netezési szokásom, tehát ez sem 100%-os megoldás az elbújásra, viszont a Cloudflare ajánlja jelenleg a leggyorsabb DNS szervert, így korábbról is az ő megoldásukat használtam (csak titkosítatlanul, tehát még a szolgáltatóm is beleláthatott), illetve ha hihetünk a szavuknak, egy nap után mindenfajta logot törölnek. Természetesen teljesen transzparens megoldás nem igen létezik, hiszen az internet használatával már fel kell áldoznunk egy bizonyos mennyiséget a személyes privacy ellen, viszont így, hogy magam válogatom meg kinek adom ki az adataim, már nyugodtabban alszom.
Érdekesség még, hogy Cloudflare DNS használata előtt, a szolgáltatóm DNS-ét használva ez a teszt oldal is rengeteg hibát írt: [link] A DNSSEC teszten sem sikerült átmenni: [link] És minden oldalbetöltés érezhetően időbe telt, ha a cím éppen nem volt gyorsítótárazva. A Cloudflarrel minden problémám megszűnt és szupergyors a betöltés!
Tehát adva volt a lehetőség, már csak az alkalmazásnak kellett utánajárni! Szerencsére otthoni kis hálózatom magját egy nagyon kedvező árfekvésű RT-N18U jelenti, a FreshTomato nevű svájci bicska rendszerrel. Ami most is meglepett, hiszen a még alig elterjedt technológiát GUI-n keresztül is sikerült benne megtalálnom (Basic -> Network fül):
Bár a Cloudflare DNS-e sajnos nincs támogatva még a beépített dnscrypt-proxy által, nekem sajnos nem sikerült működésre bírni, így a Stubby megoldás felé kezdtem el kacsintgatni és igen, határozottan ez lett az, amire végül szükségem volt. GUI-n mindössze ennyit kellett kattintgatnom:
Itt nagyon fontos volt, hogy a DNSSEC ne legyen engedélyezve, különben az egész Stubby konfig ignorálva lesz és minden forgalmunk továbbra is a hagyományos módon fog elmenni a DNS szerverhez. Erre némi fejfájással jöttem csupán rá a saját bőrömön, de szerencsére erre is van megoldás. Mégpedig az Advanced -> DHCP/DNS oldalt kiválasztva a dnsmasq Custom configuration dobozába illesszük be ezt a sort:
proxy-dnssec
Majd ne felejtsünk el a lap alján menteni.
Most pedig következhet a Stubby konfig módosítása, ugyanis erre is szükség van, ha szeretnénk DNSSEC támogatást, illetve kizárólag a Cloudflare DNS-ére hagyatkozni. Ehhez nyitni kell a routeren SSH-t (Administration -> Admin Access -> SSH Daemon), majd be is kell lépni egy tetszőlegesen választott SSH klienssel és a root felhasználónév, illetve az adminhoz tartozó jelszó párossal. A sikeres bejelentkezést követően szükségünk lesz a szintén Administration fül alatt található JFFS menü engedélyezésére, ez fogja ugyanis tárolni a módosított konfigunkat, amelyet minden indításkor bemásol majd a router az eredeti helyére. Nézzen ki így a végeredmény:
Eddig remekül állunk! JFFS partíciónk csatolásának állapotát gyorsan le is ellenőrizhetjük:
root@unknown:/tmp/home/root# mount | grep jffs
/dev/mtdblock5 on /jffs type jffs2 (rw,noatime)
Amint látható, fel lett csatolva, tehát sikerrel jártunk! Most hozzunk létre egy mappát a módosított konfigoknak:
mkdir /jffs/config/
Másoljuk át az eredeti Tomato Stubby konfigot ide:
cp /etc/stubby.yml /jffs/config/
És nyissuk meg szerkesztésre:
nano /jffs/config/stubby.yml
Belenézve az eredeti konfigba, ez tárult elém:
tls_ca_file: "/rom/cacert.pem"
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
- GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 256
edns_client_subnet_private : 1
idle_timeout: 10000
listen_addresses:
- 127.0.0.1@5453
- 0::1@5453
round_robin_upstreams: 1
upstream_recursive_servers:
# IPv4 addresses
# Cloudflare
- address_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"
- address_data: 1.0.0.1
tls_auth_name: "cloudflare-dns.com"
# Google
- address_data: 8.8.8.8
tls_auth_name: "dns.google"
- address_data: 8.8.4.4
tls_auth_name: "dns.google"
# Quad 9 'secure' service - Filters, does DNSSEC, doesn't send ECS
- address_data: 9.9.9.9
tls_auth_name: "dns.quad9.net"
# The Surfnet/Sinodun servers
- address_data: 145.100.185.15
tls_auth_name: "dnsovertls.sinodun.com"
tls_pubkey_pinset:
- digest: "sha256"
value: 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4=
- address_data: 145.100.185.16
tls_auth_name: "dnsovertls1.sinodun.com"
tls_pubkey_pinset:
- digest: "sha256"
value: cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA=
# The getdnsapi.net server
- address_data: 185.49.141.37
tls_auth_name: "getdnsapi.net"
tls_pubkey_pinset:
- digest: "sha256"
value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=
# IPv6 addresses
# Cloudflare
- address_data: 2606:4700:4700::1111
tls_auth_name: "cloudflare-dns.com"
- address_data: 2606:4700:4700::1001
tls_auth_name: "cloudflare-dns.com"
# Google
- address_data: 2001:4860:4860::8888
tls_auth_name: "dns.google"
- address_data: 2001:4860:4860::8844
tls_auth_name: "dns.google"
# Quad 9 'secure' service - Filters, does DNSSEC, doesn't send ECS
- address_data: 2620:fe::fe
tls_auth_name: "dns.quad9.net"
# The Surfnet/Sinodun servers
- address_data: 2001:610:1:40ba:145:100:185:15
tls_auth_name: "dnsovertls.sinodun.com"
tls_pubkey_pinset:
- digest: "sha256"
value: 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4=
- address_data: 2001:610:1:40ba:145:100:185:16
tls_auth_name: "dnsovertls1.sinodun.com"
tls_pubkey_pinset:
- digest: "sha256"
value: cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA=
# The getdnsapi.net server
- address_data: 2a04:b900:0:100::38
tls_auth_name: "getdnsapi.net"
tls_pubkey_pinset:
- digest: "sha256"
value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=
Én ezt a következőkre módosítottam:
tls_ca_file: "/rom/cacert.pem"
appdata_dir: "/tmp/stubby"
dnssec: GETDNS_EXTENSION_TRUE
dnssec_return_status: GETDNS_EXTENSION_TRUE
return_both_v4_and_v6: GETDNS_EXTENSION_TRUE
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
- GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 256
edns_client_subnet_private : 1
idle_timeout: 10000
listen_addresses:
- 127.0.0.1@5453
- 0::1@5453
round_robin_upstreams: 0
upstream_recursive_servers:
# IPv4 addresses
# Cloudflare
- address_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"
- address_data: 1.0.0.1
tls_auth_name: "cloudflare-dns.com"
# IPv6 addresses
# Cloudflare
- address_data: 2606:4700:4700::1111
tls_auth_name: "cloudflare-dns.com"
- address_data: 2606:4700:4700::1001
tls_auth_name: "cloudflare-dns.com"
A változás az, hogy megadtam egy stubby átmeneti fájlokhoz tartozó mappát a ramdiszken:
appdata_dir: "/tmp/stubby"
Ezek a sorok felelnek a DNSSEC-ért:
dnssec: GETDNS_EXTENSION_TRUE
dnssec_return_status: GETDNS_EXTENSION_TRUE
return_both_v4_and_v6: GETDNS_EXTENSION_TRUE
Illetve a legfontosabb, hogy ezt letiltottam:
round_robin_upstreams: 0
Bár nagy jelentősége nincs, hiszen kizárólag a CloudFlare DNS címeit hagytam meg a konfigban.
Ezt követően lehet menteni a fájlt, majd az Administration -> Scripts -> WAN Up fül alá illesszük be a következő sorokat:
cp /jffs/config/stubby.yml /etc/stubby.yml
sleep 1
service dnsmasq restart
Adjunk egy rebootot a routernek, vagy szakítsuk meg manuálisan a WAN kapcsolatot és hagyjuk, hogy a router újra csatlakozzon. S amennyiben sikerrel jártunk, az új konfig lesz érvényben. Az eredeti pedig a /rom/etc/stubby.yml útvonalon megtalálható marad, és bármikor visszaállítható a WAN Up rész kitörlésével, majd egy reboottal. Azonnali visszaállításhoz pedig egy:
ln -sf /rom/etc/stubby.yml /etc/stubby.yml; service dnsmasq restart
parancsra lesz szükségünk.
Ellenőrizni munkánk sikerességét pedig tcpdumppal érdemes, amelyet sajnos a Tomato alapból nem tartalmaz, viszont az Entware igen. Telepítés és a következő parancsok kiadása után:
opkg update; opkg install tcpdump
ki kell derítenünk, hogy mely interfacen bonyolítja le routerünk a WAN forgalmat. Erre két módot tudok javasolni, az egyik az Advanced -> Routing fülön az interface oszlop. A sok-sok elem közt kell keresni egy interfacenév (WAN) párost, ami nekem ppp0 (WAN), hiszen PPPoE a kapcsolatom típusa. A másik megoldáshoz pedig SSH-n add ki az ifconfig parancsot, és amelyik interface inet addr címe megegyezik a külső WAN-os IP címeddel, nagy valószínűséggel az lesz a WAN interface.
Tehát esetemben ppp0-n kell hallgatózni, először a titkosítatlan, régi feloldás után kutatva:
tcpdump -i ppp0 udp port 53
Amennyiben itt nem, vagy csak nagyon jelentéktelen forgalom zajlik (néhány eszköz ignorálja a router DNS-ét és a sajátját preferálja, ami természetesen nem lesz titkosítva, de érdemes minden otthoni eszközön belőni a router DNS-t) és a forgalom nagyja a titkosított 853-as TCP porton zajlik:
tcpdump -i ppp0 tcp port 853
Ha van rajta forgalom, már biztosak lehetünk benne, hogy sikerrel jártunk! 
És a tonnányi felesleges beszéd után végre büszkélkedhetünk egy szupergyors, teljes mértékben titkosított A Cloudflare és a router közti DNS feloldóval, amelyet minden hálózatra kötött eszköz képes lesz használni! Még azok is, amelyek nem támogatják a DNS over TLS-t, hiszen a belső hálózaton a router egy normál DNS kiszolgálóként fog továbbra is működni.
Jó hekkelést kívánok!
