A DNS áttekintése

A Domain Name System (DNS) az internet „telefonkönyve”: a domainneveket IP-címekre fordítja le, hogy a böngészők és más szolgáltatások egy decentralizált szerverhálózaton keresztül megtalálják az internetes erőforrásokat.

Mi az a DNS?

Amikor meglátogatsz egy webhelyet, a rendszer egy számszerű címet ad vissza. A privacyguides.org esetében például a 192.98.54.105 cím térhet vissza.

A DNS az internet korai időszaka óta létezik. A DNS-szerverek felé és felől érkező DNS-kérések alapértelmezetten általában nincsenek titkosítva. Otthoni internetkapcsolatnál az ügyfél jellemzően a szolgáltatótól kap DNS-szervereket DHCP-n keresztül.

A titkosítatlan DNS-kérések továbbítás közben könnyen megfigyelhetők és módosíthatók. A világ egyes részein az internetszolgáltatókat egyszerű DNS-szűrés alkalmazására kötelezik. Blokkolt domain IP-címének lekérdezésekor a szerver nem feltétlenül válaszol, vagy más IP-címet ad vissza. Mivel a DNS-protokoll nincs titkosítva, az internetszolgáltató — vagy bármely hálózatüzemeltető — DPI segítségével figyelheti a kéréseket. A szolgáltatók közös jellemzők alapján akkor is blokkolhatják őket, ha más DNS-szervert használsz.

Az alábbi példák azt mutatják be, mit láthat egy külső megfigyelő hagyományos, titkosítatlan DNS és titkosított DNS használatakor.

Titkosítatlan DNS

A Wireshark projekt részét képező tshark segítségével rögzíthetjük az internetes csomagforgalmat. Az alábbi parancs a megadott feltételeknek megfelelő csomagokat menti:
```
tshark -w /tmp/dns.pcap udp port 53 and host 1.1.1.1 or host 8.8.8.8
```
Ezután Linuxon/macOS-en a dig, Windowson pedig az nslookup segítségével mindkét szerverhez DNS-lekérdezést küldhetünk. A böngészők ezt automatikusan megteszik, hacsak nincsenek titkosított DNS használatára konfigurálva.
Linux, macOSWindows
dig +noall +answer privacyguides.org @1.1.1.1 dig +noall +answer privacyguides.org @8.8.8.8
nslookup privacyguides.org 1.1.1.1 nslookup privacyguides.org 8.8.8.8

Ezután elemezhetjük az eredményt:

Wiresharktshark

wireshark -r /tmp/dns.pcap

tshark -r /tmp/dns.pcap

A Wireshark felső paneljén a „frame-ek”, alul pedig a kiválasztott frame összes adata látható. A vállalati vagy állami szintű szűrő- és megfigyelőrendszerek ezt emberi beavatkozás nélkül, automatikusan elvégezhetik, és a frame-ekből a hálózati megfigyelő számára hasznos statisztikai adatokat állíthatnak elő.

No.	Time	Source	Destination	Protocol	Length	Info
1	0.000000	192.0.2.1	1.1.1.1	DNS	104	Standard query 0x58ba A privacyguides.org OPT
2	0.293395	1.1.1.1	192.0.2.1	DNS	108	Standard query response 0x58ba A privacyguides.org A 198.98.54.105 OPT
3	1.682109	192.0.2.1	8.8.8.8	DNS	104	Standard query 0xf1a9 A privacyguides.org OPT
4	2.154698	8.8.8.8	192.0.2.1	DNS	108	Standard query response 0xf1a9 A privacyguides.org A 198.98.54.105 OPT

Egy megfigyelő ezek közül bármelyik csomagot módosíthatná.

Mi az a „titkosított DNS”?

A titkosított DNS több protokollt jelenthet; a leggyakoribbak a DNSCrypt, a DNS over TLS és a DNS over HTTPS.

DNSCrypt

A DNSCrypt a DNS-lekérdezések titkosításának egyik első megoldása volt. A 443-as porton működik, TCP- és UDP-átvitellel is. Soha nem nyújtották be az IETF-nek, és nem ment át az RFC szabványosítási folyamatán, ezért néhány megvalósításon kívül nem terjedt el széles körben. Nagyrészt a népszerűbb DNS over HTTPS váltotta fel.

DNS over TLS (DoT)

A DNS over TLS az RFC 7858 által meghatározott titkosított DNS-kommunikáció. Támogatása először Android 9-ben, iOS 14-ben, illetve Linuxon a systemd-resolved 237-es verziójában jelent meg. Az iparág az utóbbi években inkább a DoH felé mozdult, mert a DoT összetettebb protokoll, és az egyes megvalósítások RFC-megfelelése eltérhet. Emellett a 853-as dedikált portot korlátozó tűzfalak könnyen blokkolhatják.

DNS over HTTPS (DoH)

Az RFC 8484 által definiált DNS over HTTPS a lekérdezéseket HTTP/2 protokollba csomagolja, és HTTPS-sel védi. Böngészőkben először többek között Firefox 60-ban és Chrome 83-ban jelent meg.

Natív DoH-támogatás később iOS 14-ben, macOS 11-ben, Microsoft Windowsban és Android 13-ban is megjelent — Androidon azonban nem alapértelmezett. Általános linuxos asztali támogatás továbbra is a systemd megvalósítására vár, ezért külső szoftver telepítésére van szükség.

Natív operációsrendszer-támogatás

Android

Az Android 9 és újabb rendszerek támogatják a DNS over TLS-t. A beállítás helye: Settings → Network & Internet → Private DNS.

Apple-eszközök

Az iOS, iPadOS, tvOS és macOS újabb verziói egyaránt támogatják a DoT-ot és DoH-t. Mindkét protokoll használható natívan konfigurációs profillal, illetve a DNS Settings API segítségével.

Konfigurációs profil vagy a DNS Settings API-t használó alkalmazás telepítése után kiválasztható a DNS-konfiguráció. Aktív VPN mellett a VPN-alagúton belüli feloldás a VPN DNS-beállításait használja a rendszer globális beállításai helyett.

Az Apple nem biztosít natív felületet titkosított DNS-profilok készítéséhez. A Secure DNS profile creator nem hivatalos eszköz ilyen profilok létrehozására, de az elkészült profilok nincsenek aláírva. Az aláírt profil előnyösebb, mert az aláírás igazolja az eredetét és segít ellenőrizni az integritást. Az aláírt profilok zöld „Verified” jelölést kapnak. További információ: About Code Signing.

Linux

A sok Linux-disztribúcióban DNS-feloldáshoz használt systemd-resolved még nem támogatja a DoH-t. DoH használatához például dnscrypt-proxy telepíthető, majd úgy konfigurálható, hogy a rendszerfeloldó összes DNS-kérését HTTPS-en továbbítsa.

Mit láthat egy külső fél?

A következő példában azt rögzítjük, mi történik DoH-kéréskor:

Indítsd el a tshark programot:

tshark -w /tmp/dns_doh.pcap -f "tcp port https and host 1.1.1.1"

Küldj kérést curl segítségével:

curl -vI --doh-url https://1.1.1.1/dns-query https://privacyguides.org

A kérés után állítsd le a csomagrögzítést a CTRL + C billentyűkkel.
Elemezd az eredményt Wiresharkban:
```
wireshark -r /tmp/dns_doh.pcap
```

Látható a minden titkosított kapcsolatnál bekövetkező kapcsolatfelépítés és TLS-kézfogás. Az ezt követő „application data” csomagok egyikében sem jelenik meg a lekért domain vagy a visszakapott IP-cím.

Miért ne használjak titkosított DNS-t?

Olyan helyen, ahol internetes szűrés vagy cenzúra működik, tiltott erőforrások felkeresésének önálló következménye lehet, amelyet a fenyegetési modelledben mérlegelned kell. Erre a célra nem javasoljuk a titkosított DNS-t; inkább Tort vagy VPN-t használj. VPN esetén a VPN saját DNS-szervereit érdemes használni, hiszen a VPN-szolgáltatóban már amúgy is megbízol a teljes hálózati forgalmad tekintetében.

DNS-lekérdezést általában azért végzünk, mert valamilyen erőforrást szeretnénk elérni. A következő módszerek akkor is felfedhetik böngészési tevékenységedet, ha maga a DNS titkosított.

IP-cím

A böngészési tevékenység megállapításának legegyszerűbb módja az eszköz által elért IP-címek vizsgálata. Ha egy megfigyelő tudja, hogy a privacyguides.org a 198.98.54.105 címen található, és az eszközöd ettől a címtől kér adatot, jó eséllyel arra következtethet, hogy a Privacy Guides oldalt látogatod.

Ez csak akkor hasznos, ha az IP-cím kevés webhelyet kiszolgáló szerverhez tartozik. Megosztott platformoknál — GitHub Pages, Cloudflare Pages, Netlify, WordPress, Blogger stb. — vagy reverse proxy mögött jóval kevésbé informatív, márpedig ez a modern interneten nagyon gyakori.

Server Name Indication (SNI)

Az SNI-t tipikusan akkor használják, amikor egy IP-cím sok webhelyet szolgál ki, például Cloudflare-hez vagy más DDoS-védelmi szolgáltatáshoz hasonló környezetben.

Indítsd újra a rögzítést tshark-kal. Az IP-címre szűrünk, hogy ne keletkezzen túl sok csomag:
```
tshark -w /tmp/pg.pcap port 443 and host 198.98.54.105
```
Nyisd meg a https://privacyguides.org oldalt.
Állítsd le a rögzítést CTRL + C billentyűkkel.
Elemezd:
```
wireshark -r /tmp/pg.pcap
```
A kapcsolatfelépítés után megjelenik a TLS-kézfogás. Körülbelül az 5. frame-nél egy „Client Hello” látható.

Nyisd le a ▸ jelölésű mezőket:

▸ Transport Layer Security
  ▸ TLSv1.3 Record Layer: Handshake Protocol: Client Hello
    ▸ Handshake Protocol: Client Hello
      ▸ Extension: server_name (len=22)
        ▸ Server Name Indication extension

Itt látható az SNI, amely felfedi a meglátogatott webhelyet. A tshark közvetlenül is kilistázhatja az SNI-t tartalmazó csomagok értékeit:
```
tshark -r /tmp/pg.pcap -Tfields -Y tls.handshake.extensions_server_name -e tls.handshake.extensions_server_name
```

Vagyis a domain még „titkosított DNS” használata mellett is kiszivároghat SNI-n keresztül. A TLS 1.3 ökoszisztémában megjelent Encrypted Client Hello ezt a típusú szivárgást hivatott megakadályozni.

Kormányok — különösen Kína és Oroszország — már blokkolni kezdték az ilyen technikákat, vagy jelezték erre irányuló szándékukat. Oroszország olyan külföldi webhelyeket is blokkolni kezdett, amelyek HTTP/3-at használnak; ennek része a QUIC, amelyben a ClientHello is titkosított.

Online Certificate Status Protocol (OCSP)

A böngésző az OCSP használatával is felfedheti böngészési tevékenységedet. HTTPS-webhely meglátogatásakor ellenőrizheti, hogy a webhely tanúsítványát visszavonták-e. Ez gyakran HTTP-n történik, tehát nincs titkosítva.

Az OCSP-kérés tartalmazza a tanúsítvány egyedi „sorozatszámát”, amelyet az „OCSP responder” kap meg az állapot ellenőrzéséhez. A böngésző viselkedése openssl használatával szimulálható:

Kérd le a szervertanúsítványt, és sed segítségével mentsd ki a lényegi részt:

openssl s_client -connect privacyguides.org:443 < /dev/null 2>&1 |
    sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_server.cert

Kérd le a köztes tanúsítványt. A hitelesítésszolgáltatók (CA-k) általában nem közvetlenül írják alá a végfelhasználói tanúsítványt, hanem „köztes” tanúsítványt használnak:
```
openssl s_client -showcerts -connect privacyguides.org:443 < /dev/null 2>&1 |
    sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_and_intermediate.cert
```
A pg_and_intermediate.cert első tanúsítványa az 1. lépésből ismert szervertanúsítvány; sed segítségével hagyd meg a következő részt:
```
sed -n '/^-*END CERTIFICATE-*$/!d;:a n;p;ba' \
    /tmp/pg_and_intermediate.cert > /tmp/intermediate_chain.cert
```
Kérd le a szervertanúsítvány OCSP-responderét:
```
openssl x509 -noout -ocsp_uri -in /tmp/pg_server.cert
```
A példában a Let's Encrypt válaszadója jelenik meg. A tanúsítvány részletes adatai:
```
openssl x509 -text -noout -in /tmp/pg_server.cert
```

Indítsd el a csomagrögzítést:

tshark -w /tmp/pg_ocsp.pcap -f "tcp port http"

Küldd el az OCSP-kérést:

openssl ocsp -issuer /tmp/intermediate_chain.cert \
             -cert /tmp/pg_server.cert \
             -text \
             -url http://r3.o.lencr.org

Nyisd meg a rögzítést:

wireshark -r /tmp/pg_ocsp.pcap

Két OCSP-csomag jelenik meg: egy „Request” és egy „Response”. A kérésnél a sorozatszám:

▸ Online Certificate Status Protocol
  ▸ tbsRequest
    ▸ requestList: 1 item
      ▸ Request
        ▸ reqCert
          serialNumber

A válaszban szintén megtalálható:

▸ Online Certificate Status Protocol
  ▸ responseBytes
    ▸ BasicOCSPResponse
      ▸ tbsResponseData
        ▸ responses: 1 item
          ▸ SingleResponse
            ▸ certID
              serialNumber

A tshark segítségével közvetlenül is kiszűrheted a sorozatszámot:

tshark -r /tmp/pg_ocsp.pcap -Tfields -Y ocsp.serialNumber -e ocsp.serialNumber

Ha a hálózati megfigyelő rendelkezik a nyilvánosan elérhető tanúsítvánnyal, a sorozatszámot hozzá tudja rendelni, így következtethet a meglátogatott webhelyre. Ez automatizálható, és IP-címek is összekapcsolhatók sorozatszámokkal. A sorozatszám Certificate Transparency naplókban is ellenőrizhető.

Használjak titkosított DNS-t?

Az alábbi folyamatábra összefoglalja, mikor érdemes titkosított DNS-t használni:

graph TB
    Start[Kezdés] --> anonymous{Anonim szeretnél<br>maradni?}
    anonymous--> | Igen | tor(Használj Tort)
    anonymous --> | Nem | censorship{Cenzúrát szeretnél<br>megkerülni?}
    censorship --> | Igen | vpnOrTor(Használj<br>VPN-t vagy Tort)
    censorship --> | Nem | privacy{Magánszférát szeretnél<br>az internetszolgáltatóddal szemben?}
    privacy --> | Igen | vpnOrTor
    privacy --> | Nem | obnoxious{Az ISP zavaró<br>átirányításokat<br>végez?}
    obnoxious --> | Igen | encryptedDNS(Használj<br>külső szolgáltatós<br>titkosított DNS-t)
    obnoxious --> | Nem | ispDNS{Az ISP támogat<br>titkosított DNS-t?}
    ispDNS --> | Igen | useISP(Használd az ISP<br>titkosított DNS-ét)
    ispDNS --> | Nem | nothing(Ne változtass semmit)

Külső fél titkosított DNS-szolgáltatását elsősorban átirányítások és egyszerű DNS-blokkolás megkerülésére érdemes használni, ha biztos vagy benne, hogy ennek nincs következménye, illetve ha olyan szolgáltatót keresel, amely alapvető szűrést biztosít.

Ajánlott DNS-szerverek listája

Mi az a DNSSEC?

A Domain Name System Security Extensions (DNSSEC) a DNS olyan kiegészítése, amely hitelesíti a domainnév-lekérdezésekre adott válaszokat. Nem biztosít adatvédelmet maguknak a lekérdezéseknek; célja annak megakadályozása, hogy egy támadó manipulálja vagy „megmérgezze” a DNS-válaszokat.

A DNSSEC digitálisan aláírja az adatokat, hogy ellenőrizhető legyen azok hitelessége. A biztonságos feloldás érdekében a DNS-hierarchia minden szintjén aláírás történik, így az egyes válaszok eredete ellenőrizhető.

A folyamat hasonló egy jogi dokumentum kézi aláírásához: az aláíró egyedi aláírást használ, amelyet szakértő ellenőrizhet. A digitális aláírások azt igazolják, hogy az adatot nem módosították.

A DNSSEC hierarchikus digitális aláírási láncot valósít meg a DNS minden rétegén. privacyguides.org lekérdezésnél például a gyökér DNS-szerver aláírja a .org névszerver kulcsát, a .org névszerver pedig a privacyguides.org hiteles névszerverének kulcsát.

A Google DNS Security Extensions (DNSSEC) overview és a Cloudflare DNSSEC: An Introduction anyagai alapján; mindkettő CC BY 4.0 licencű.

Mi az a QNAME-minimalizálás?

A QNAME „qualified name”, például discuss.privacyguides.net. Régebben egy domain feloldásakor a DNS-feloldó a lánc minden szerverétől a teljes lekérdezésről kért információt:

Szerver	Feltett kérdés	Válasz
Gyökérszerver	Mi a discuss.privacyguides.net IP-címe?	Nem tudom, kérdezd a .net szervert…
.net szerver	Mi a discuss.privacyguides.net IP-címe?	Nem tudom, kérdezd a Privacy Guides szerverét…
Privacy Guides szervere	Mi a discuss.privacyguides.net IP-címe?	5.161.195.190!

A „QNAME-minimalizálással” a DNS-feloldó minden lépésnél csak annyi információt kér, amennyi a következő szerver megtalálásához szükséges. Így a gyökérszerver például csak a .net TLD megfelelő névszerveréről kap kérdést, anélkül hogy ismerné a teljes meglátogatni kívánt domaint:

Szerver	Feltett kérdés	Válasz
Gyökérszerver	Mi a .net névszervere?	Megadja a .net szerverét
.net szerver	Mi a privacyguides.net névszervere?	Megadja a Privacy Guides szerverét
Privacy Guides szervere	Mi a discuss.privacyguides.net névszervere?	Ez a szerver!
Privacy Guides szervere	Mi a discuss.privacyguides.net IP-címe?	5.161.195.190

Ez kissé kevésbé hatékony lehet, de a központi gyökér- és TLD-névszerverek nem kapják meg a teljes lekérdezésedet, így kevesebb információ továbbítódik a böngészési szokásaidról. A technikát az RFC 7816 részletezi.

Mi az az EDNS Client Subnet (ECS)?

Az EDNS Client Subnet lehetővé teszi a rekurzív DNS-feloldónak, hogy a DNS-kérést indító klienshez tartozó alhálózatot továbbítsa.

Célja az adatküldés „gyorsítása” azzal, hogy a klienshez földrajzilag közeli szerver válaszát segít kiválasztani, például tartalomelosztó hálózatoknál, amelyeket gyakran használnak videóstreameléshez és JavaScript webalkalmazásokhoz.

Ennek adatvédelmi ára van, mert a DNS-szerver információt kap a kliens hozzávetőleges helyéről — általában az IP-hálózatáról. Ha az IP-címed például 198.51.100.32, a DNS-szolgáltató 198.51.100.0/24 hálózatot továbbíthat a hiteles szervernek. Egyes szolgáltatók úgy anonimizálják ezt, hogy egy másik, hozzávetőleg a tartózkodási helyed közelében lévő IP-t adnak meg.

Ha telepítve van a dig, az alábbi paranccsal ellenőrizheted, továbbít-e a DNS-szolgáltatód EDNS-információt:

dig +nocmd -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats

A parancs a teszthez kapcsolatba lép a Google-lal, és visszaadja az IP-címedet, valamint az EDNS client subnet információt. Más DNS-feloldó teszteléséhez megadhatod az IP-jét, például 9.9.9.11 esetén:

dig +nocmd @9.9.9.11 -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats

Ha az eredményben egy második edns0-client-subnet TXT rekord is megjelenik, a DNS-szerver továbbít EDNS-információt. Az utána látható IP vagy hálózat pontosan az az információ, amelyet a szolgáltató megosztott a Google-lal.

o-o.myaddr.l.google.com. 60 IN TXT "198.51.100.32"
o-o.myaddr.l.google.com. 60 IN TXT "edns0-client-subnet 198.51.100.0/24"
;; Query time: 64 msec
;; SERVER: 9.9.9.11#53(9.9.9.11)
;; WHEN: Wed Mar 13 10:23:08 CDT 2024
;; MSG SIZE  rcvd: 130

A Magánszféra Kalauz a Privacy Guides nem hivatalos magyar változata. Tartalmi eltérés esetén az angol eredeti az irányadó. Eredeti Privacy Guides