- Az egészségügyi minisztérium (DoH) HTTPS titkosítást ad a DNS-lekérdezésekhez, javítva az adatvédelmet és a biztonságot a lehallgatás és a manipuláció ellen.
- Nem egyenértékű egy VPN-nel: védi a domainkereséseket, de nem az összes forgalmat vagy az IP-címedet.
- Telepítésének vannak teljesítménybeli előnyei, de feszültségeket is okoz a szülői felügyelet, a megfigyelés és a cenzúra.
Amikor beír egy webcímet, van egy összetevő, amely a színfalak mögött dolgozik annak érdekében, hogy a megfelelő webhelyre jusson: a Domain Name System (DNS). A DNS a könnyen megjegyezhető neveket IP-címekké alakítja, amelyeket a számítógépek megértenek. Kényelmes, igen, de évekig jelentős sebezhetőséggel működött: ezek a lekérdezések titkosítatlanul utaztak. Ezért vált annyira népszerűvé a HTTPS-en keresztüli DNS, más néven DoH – egy extra védelmi réteg, amely megnehezíti az internetszolgáltató számára, hogy nyomon kövesse, mely domaineket látogatja meg.
Fontos egy dolgot már a legelején tisztázni: a DoH javítja a DNS-lekérdezések adatvédelmét, de nem VPN, és nem is változtatja az egész kapcsolatot titkos alagúttá . Ebben a cikkben megvizsgáljuk, hogy pontosan mi is ez, miért vált népszerűvé, hogyan aktiválható Chrome-ban, Edge-ben és Firefoxban, milyen előnyei és hátrányai vannak, miben különbözik a TLS-en és egy VPN-en keresztüli DNS-től, valamint milyen technikai és gyakorlati korlátai vannak.
Mi a DNS, és miért nem felel meg a hagyományos rendszer elvárásainak?
A DNS-kiszolgálók egyike azoknak az összetevőknek, amelyeket szinte senki sem néz meg, mégis az online böngészés nagy részét képezik. Feladatuk, hogy egy domainnevet összekapcsoljanak a megfelelő kiszolgáló IP-címével . Amikor meglátogat egy webhelyet, a számítógépe nem érti a betűket: IP-címre van szüksége ahhoz, hogy tudja, melyik géphez csatlakozzon. Sok routerhez az internetszolgáltató által már konfigurált DNS-kiszolgálók tartoznak, ami kényelmessé teszi a folyamatot, bár látható nyomot hagy annak, aki az infrastruktúrát ellenőrzi.
Az alapvető probléma az, hogy a hagyományos DNS-lekérdezések egyszerű szövegként és védelem nélkül történnek . Ez utat nyit a lehallgatásnak, a közbeékelődéses támadásoknak és a válasz manipulálásának. Egy internetszolgáltató megtudhatja, hogy mely domaineket kérdezi le és mikor; egy megosztott hálózaton lévő támadó megpróbálhatja elfogni a kérést, és csalárd választ adhat vissza. Ez a technika DNS-eltérítésnek nevezik, és végső soron hamis oldalakra, kéretlen hirdetésekre vagy adatlopásra tervezett webhelyekre vezethet. A kormányok és az internetszolgáltatók történelmileg is kihasználták ezeket a gyengeségeket cenzúra bevezetésére, domainek blokkolására vagy további hirdetések megjelenítésére.
- Passzív hallgatás: Valaki megfigyeli a lekérdezéseket, és kikövetkezteti, hogy mely szolgáltatásokat vagy weboldalakat látogatod gyakran.
- Középpontban lévő ember: A kommunikációt lehallgatják, és a választ úgy módosítják, hogy egy szervert személyesítsen meg.
- Blokkolás és szűrés: Megakadályozza bizonyos domainek feloldását a tartalomhoz való hozzáférés szabályozása érdekében.
DNS HTTPS-en keresztül: Titkosítsa a lekérdezést, hogy ne legyen látható mindenki számára.
A HTTPS-en keresztüli DNS, vagy DoH, egy olyan megoldás, amely a HTTPS protokollt használja a DNS-lekérdezések és -válaszok titkosított formában történő továbbítására . Ahelyett, hogy egyértelmű DNS-kérést küldene, az eszköz egy biztonságos kapcsolatba csomagolja azt, jellemzően a 443-as porton keresztül, amelyet a biztonságos webhelyek is használnak. Ez védi mind a lekérdezést, mind a választ, megakadályozva, hogy egy külső megfigyelő könnyen elolvassa azokat.
Ahhoz, hogy ez működjön, a lekérdezett DNS-kiszolgálónak támogatnia kell a domain-alapú DNS-t (DoH ). Nem elég egyszerűen engedélyezni egy opciót a böngészőben: a kiválasztott DNS-feloldónak is meg kell felelnie ennek a szabványnak. A specifikáció folyamatosan fejlődik, és még mindig fejlődő technológiának számít, bár 2018 óta olyan cégek, mint a Google és a Mozilla Foundation tesztelik és integrálják. A jobb adatvédelem mellett a tesztek azt mutatják, hogy a DoH csökkentheti a késleltetést és gyorsabbá teheti a lekérdezéseket, mivel nem mindig szükséges a teljes domain feloldása, hanem csak a minimálisan szükséges rész.
A DoH előnyei: nagyobb adatvédelem, kevesebb manipuláció és jobb teljesítmény
A legnyilvánvalóbb előny a biztonság. Mivel titkosítva utaznak, a DNS-lekérdezéseket sokkal nehezebb kémkedni vagy módosítani . Ez bonyolítja a közbeékelődéses támadásokat, csökkenti a nyilvános Wi-Fi hálózatokon való kitettséget, és megakadályozza, hogy a helyi operátor egyértelműen lássa, mely domaineket kéri le. Mivel a DoH forgalom a 443-as portot használja, beleolvad más HTTPS-kapcsolatokba, és nehéz megkülönböztetni egy normál webes látogatástól.
Teljesítménybeli okok is vannak. A DoH csökkentheti a késleltetést és felgyorsíthatja a DNS-kommunikációt a névfeloldás módjának változásai és a gyorsítótár jobb kihasználása révén. Például egyes API-k GET metódusa hatékonyabb gyorsítótárazásra lett tervezve. A gyakorlatban ez valamivel gyorsabb böngészést eredményezhet, bár nem csodaszer, és a javulás nem mindig észrevehető. Továbbá, mivel a böngészőben van megvalósítva, a felhasználónak nem kell megvárnia, amíg az internetszolgáltatója aktiválja.
Hátrányok és viták: amikor a titkosítás bonyolítja az életet
Nem mindenki nézi jó szemmel a domain alapú titkosítást (DoH). Ugyanaz a titkosítás, amely védi a felhasználót, megnehezíti a hálózat figyelését is . Sok szülői felügyeleti program a DNS-lekérdezések vizsgálatára támaszkodik annak megállapítására, hogy a gyerekek mely webhelyeket próbálják elérni; a DoH esetében ez a feladat sokkal bonyolultabbá, sőt lehetetlenné is válhat. Hasonló helyzet áll fenn a vállalati hálózati rendszergazdák esetében, akik elveszítik a betekintést a lekérdezett domainekbe, és nem tudnak bizonyos szabályokat olyan könnyen érvényesíteni.
Az internetszolgáltatók elveszítik a hozzáférés monitorozásának és bizonyos domainek blokkolásának lehetőségét egy intézmény kérésére. Ez jogos vitát generál: egyesek a magánélet védelmének győzelmeként tekintenek rá, míg mások ellenőrzési és kezelési problémának tartják . A DoT esetében azt is kritizálják, hogy saját felismerhető portot használ, amely lehetővé teszi a DNS-lekérdezések azonosítását anélkül, hogy pontosan tudnák, mit kérdeznek. A DoH ezt az egyértelmű jelzést azzal kerüli el, hogy a HTTPS forgalomban álcázza magát, de cserébe a hálózati rendszergazdáknak kevesebb eszközük marad a kommunikációjuk kezelésére.
Hogyan engedélyezhető a DoH a Chrome-ban, az Edge-ben és a Firefoxban
A Domain Name System (DNS) engedélyezése egy modern böngészőben általában egyszerű, különösen, ha Chromium vagy Firefox alapú. A lehetőség létezik, bár bizonyos esetekben el van rejtve a speciális beállítások menüiben . Mielőtt bármit is megváltoztatna, fontos megérteni, hogy a böngésző csak a saját lekérdezéseit védi: az eszközön lévő más alkalmazások továbbra is használhatnak egy másik DNS-rendszert, ha az nincs rendszerszinten konfigurálva.
Google Chrome
A Chrome-ban a leggyorsabb módszer a gépelés chrome://flags/#dns-over-https a címsorban. Ez közvetlenül a Chrome Jelzőihez vagy kísérleti funkcióihoz vezet.Látni fogod, hogy a Biztonságos DNS-keresések opció ki van választva; kattints az Alapértelmezett legördülő menüre, és válaszd az Engedélyezve lehetőséget. Ezután újra kell indítanod a böngészőt, hogy a módosítás érvénybe lépjen.
Microsoft él
A Chromium alapú Edge-ben a folyamat gyakorlatilag azonos. Nyisd meg a böngésződet és írd be edge://flags/#dns-over-https a keresősávbanBeírod az Edge Flags-t, és ugyanaz a Biztonságos DNS-keresések opció jelenik meg. Váltsd az Alapértelmezett értéket Engedélyezettre, és indítsd újra a böngészőt, amikor a rendszer kéri.
Mozilla Firefox
A Firefoxban nem kell a Jelzők menüpontra lépned. Kattints a jobb felső sarokban található menügombra, és válaszd a Beállítások lehetőséget . Az Általános részben görgess le az aljára, és kattints a Hálózati beállítások elemre. A megnyíló ablakban jelöld be a DNS engedélyezése HTTPS-en keresztül melletti jelölőnégyzetet. Ezután választhatsz olyan szolgáltatók közül, mint a Cloudflare és a NextDNS, amelyek HTTPS-en keresztüli titkosítást végeznek.
DNS TLS-en keresztül (DoT): a másik titkosított útvonal
A TLS-en keresztüli DNS, vagyis a DoT, egy másik módja a DNS-lekérdezések védelmének. A HTTPS helyett TLS-t használ TCP-kapcsolaton és egy szabványosított 853-as porton keresztül. A TLS ugyanaz a biztonsági alap, mint a HTTPS, így az ötlet hasonló: egy titkosított alagút létrehozása, amelyben csak a két résztvevő tudja visszafejteni és feldolgozni az információkat. Ez megnehezíti a közbeeső támadásokat, és megakadályozza, hogy egy harmadik fél elolvassa vagy manipulálja a lekérdezést.
A DotT-nek megvannak az előnyei, különösen a hagyományos DNS-hez képest, amely nem kínál biztonsági intézkedéseket. A titkosítás megakadályozza, hogy a kiberbűnözők elfogják a kéréseket, és bizonyos cenzúrázási intézkedéseket is akadályoz . Ehhez azonban mind a kliens, mind a szerver kompatibilitása szükséges. Számos szolgáltató kínál kompatibilis szervereket, de asztali számítógépen vagy laptopon történő használatához általában további szoftver telepítése szükséges; a modern Androidon, legalábbis az Android 9 óta, már integrálva van. Léteznek megoldások Windowsra és Linuxra, bár ezek nem mindig olyan átláthatóak, mint amennyire azt szeretnénk.
A hátrányok között számos adatvédelmi szakértő kritizálja a DoT-t, amiért egyetlen, felismerhető portot használ. Bár lehetetlen tudni, hogy melyik webhelyhez férnek hozzá, a DNS-forgalom észlelése lehetséges . Egyes hálózati rendszergazdák számára ez azért hasznos, mert lehetővé teszi számukra, hogy áttekintést kapjanak a történésekről; mások számára ez egy olyan jel, amelyet inkább elrejtenének. Továbbá a DoT még nem olyan elterjedt, mint a hagyományos DNS, és szerveroldali elterjedése korlátozott. Aggodalomra ad okot, hogy néhány vállalat egyre inkább a DNS-lekérdezéseket fogja koncentrálni, ami potenciálisan egyfajta nemzetközi monopóliumot hozhat létre.
DoH vs. DoT: Kétféleképpen védhetjük ugyanazt a dolgot
A DoH és a DoT közötti fő különbség a portban és a forgalom álcázásának módjában rejlik. A DoT a saját 853-as portját használja, míg a DoH a 443-ast, és beleolvad a normál HTTPS-kapcsolatokba . Ez a látszólag apró különbség jelentős vitát váltott ki. Adatvédelmi szempontból a DNS-lekérdezések más forgalomtól való megkülönböztethetetlensége előnyt jelent: ha nem ismerik fel őket, nem lehet olyan könnyen manipulálni őket. Hálózatkezelési szempontból azonban elvész az irányítás, és nehezebbé válik a biztonsági vagy szűrési szabályzatok megvalósítása.
Lényegében két vízió létezik. Az IETF, a számos internetes szabványt kidolgozó konzorcium, a DoT mögött áll , míg a Google és a Mozilla Alapítvány határozottan támogatja a DoH-t. Ezek nem ellentétes technológiák, de az adatvédelem, a hálózat láthatósága és a közvetítők szerepének eltérő értelmezését képviselik. A kettő közötti választás attól függ, hogy mit kell védeni, és kinek kell kezelnie a hálózatot.
DoH vs. VPN: A kérdést védi, nem az egész folyamatot
A DoH és a VPN gyakran felmerül az adatvédelemmel kapcsolatos beszélgetésekben, de nem ugyanazt teszik. A DoH a névlekérdezést védi; a VPN pedig az adatok útját . Ennek legegyszerűbb megértése, ha elképzeljük, hogy a DoH egy érzékeny kérdést lezárt borítékba tesz, míg a VPN az egész utat egy privát alagúton keresztül vezeti végig, mielőtt visszatérne a közútra. Mindkettő javíthatja az adatvédelmet, de csak az egyik képes átfogóan lefedni a telefonok, táblagépek és számítógépek forgalmát.
Mit csinál a DNS, mielőtt egy oldal betöltődik?
Mielőtt a böngésző betölthetne egy weboldalt, az eszközének ismernie kell annak helyét. A DNS úgy működik, mint egy telefonkönyv: a weboldal nevét IP-címmé alakítja . Ez folyamatosan történik: amikor megnyit egy oldalt, elindít egy alkalmazást, frissíti az e-mailjeit vagy lejátszik egy videót. Az esetek többségében csendben történik, és Ön nem veszi észre, ami nagyszerű a kényelem szempontjából, de könnyen figyelmen kívül hagyható adatvédelmi problémaként is. A hagyományos DNS-lekérdezések nem titkosítottak, így az internetszolgáltatója, a munkáltatója, az iskolája, egy kávézó Wi-Fi-je vagy egy szálloda hálózata láthatja, hogy az eszköze mely domaineket próbálja elérni. Nem látják egy HTTPS-oldal teljes tartalmát, de elég sokatmondó képet kapnak az Ön tevékenységéről.
Egy DNS-lekérdezés nem fed fel minden megtekintett oldalt vagy mindent, amit egy űrlapba beír, de egy domainlista felfedheti a szokásokat, érdeklődési köröket, munkaeszközöket, egészségügyi kutatásokat vagy pénzügyi szolgáltatásokat . Ezért vált a titkosított DNS hasznos adatvédelmi funkcióvá. Nem fed fel mindent, de többet, mint azt sokan gondolnák.
Mit rejt el és mit tár fel az Oktatási Minisztérium?
A DoH HTTPS-en keresztül küldi a DNS-lekérdezéseket, ugyanazon a titkosított protokollon keresztül, amelyet a biztonságos webhelyek használnak. A kérés titkosítva hagyja az eszközét, és egy olyan névfeloldóhoz érkezik, amely támogatja a szabványt . Nyilvános Wi-Fi-n ez megnehezítheti a hálózat üzemeltetője számára, hogy véletlenül elolvassa a lekérdezéseit. Ha az internetszolgáltatója kezeli a DNS-t, a DoH névfeloldóra való váltás megakadályozhatja, hogy a szokásos módon lássa ezeket a lekérdezéseket. Továbbá, ha egy hálózat manipulálja a névfeloldási eredményeket, a titkosított DNS csökkentheti a manipuláció bizonyos formáit.
A DoH mostantól a lekérdezést rejti el, nem a teljes beszélgetést. Ez megakadályozhatja, hogy egyes megfigyelők tisztán lássák a domainkeresést, de nem változtatja a teljes internetkapcsolatot titkosított alagúttá . Amint az eszköz megismeri az IP-címet, a kapcsolat többi része a szokásos útvonalát követi, kivéve, ha egy másik adatvédelmi eszköz megváltoztatja ezt az útvonalat. A DoH nem rejti el a valódi IP-címedet a webhelyek, alkalmazások vagy szolgáltatások elől, amelyekhez csatlakozol, és nem is úgy tűnik, mintha egy másik városban vagy országban lennél. Ha bejelentkezel egy fiókba, a szolgáltatás tudja, hogy te vagy az. Ha a böngésző sütiket, mentett munkameneteket, hirdetési azonosítókat vagy felismerhető ujjlenyomatot tartalmaz, a DoH nem törli ezeket a jeleket.
Nem véd minden alkalmazást, kivéve, ha rendszerszinten van konfigurálva, és az alkalmazás tiszteletben tartja ezt a beállítást. Az egyik böngésző biztonságos DNS-t használhat, míg egy másik alkalmazás ugyanazon az eszközön eltérő DNS-útvonalat . Egyes alkalmazások a saját hálózatukat kezelik, és nem mindig igazodnak a rendszer- vagy böngészőbeállításokhoz. Ezért a DoH a teljes védelem hamis érzetét keltheti: javítja a DNS-lekérdezések adatvédelmét, de nem védi a fájlátvitelt, az üzenetküldő forgalmat, a videohívásokat, a játékkapcsolatokat, a háttérszinkronizálást vagy a streaming alkalmazásokat úgy, ahogy egy VPN tenné.
Mit véd egy VPN, és mit nem tud elrejteni
A VPN az utazásod egy másik részét védi. Titkosított alagutat hoz létre az eszközöd és egy VPN-kiszolgáló között, és ezen a kiszolgálón keresztül irányítja az internetes forgalmadat . Az internetszolgáltatód vagy a helyi Wi-Fi-hálózat a VPN-kiszolgálóval való titkosított kapcsolatot látja, nem pedig az összes webhely és szolgáltatás tiszta képét, amelyhez csatlakozol. Ezenkívül a VPN megváltoztatja a webhelyek és alkalmazások által látott nyilvános IP-címet: az otthoni vagy a mobilszolgáltatód IP-címe helyett a cél a VPN-kiszolgáló IP-címét látja. Ez csökkentheti a helyalapú követést, segíthet bizonyos internetszolgáltatói profilok megkerülésében, és biztonságosabbá teheti a nyilvános Wi-Fi használatát.
Egy átfogó VPN képes megvédeni a böngészőket, streaming alkalmazásokat, e-mail klienseket, felhőalapú biztonsági mentési eszközöket, üzenetküldő alkalmazásokat, játékokat és háttérszolgáltatásokat. Megfelelő konfigurálás esetén a DNS-kéréseket is képes a titkosított alagúton keresztül továbbítani , ezért érdemes DNS-szivárgástesztet futtatni. Ennek ellenére a VPN nem varázslat. Ha bejelentkezel egy közösségi hálózatba, e-mail fiókba, streaming szolgáltatásba vagy online áruházba, az a szolgáltatás továbbra is tudja, hogy ki vagy. Elrejtheti az eredeti IP-címedet, de nem anonimizálja a bejelentkezésedet. Ugyanez vonatkozik mindenre, amit közvetlenül küldesz: a nevedre, e-mail címedre, fizetési adataidra, szállítási címedre, fotóidra vagy üzeneteidre.
A sütik és a böngésző ujjlenyomat-kezelése továbbra is fontos. Az alkalmazások hasonló problémákat okozhatnak a hirdetési azonosítók, engedélyek, helymeghatározás, Bluetooth-szkennelés, közeli Wi-Fi-nevek és szkennelőeszközök révén. A rosszindulatú programok egy másik nagy akadályt jelentenek, mivel már a VPN-alagút elérése előtt is képesek adatokat rögzíteni . Röviden, a VPN sok tevékenységet elrejt és titkosít, de nem rejt el minden digitális ujjlenyomatot.
Az egészségügyi szolgálat és a VPN egyszerre is használható
Igen, kombinálhatók, de az ideális beállítás attól függ, hogy az eszköz, a böngésző és a VPN-alkalmazás hogyan kezeli a DNS-t. Sok esetben a legegyszerűbb megoldás, ha a VPN kezeli a DNS-t . Egy jó alkalmazásnak titkosított alagúton keresztül kell küldenie a DNS-lekérdezéseket, hogy az internetszolgáltatója ne kapja meg azokat közvetlenül. Így a VPN-kapcsolat részeként DNS-adatvédelmet élvezhet anélkül, hogy külön kellene módosítania a böngésző beállításait.
A probléma akkor merül fel, amikor a böngésző a saját Domain Authority (DoH) konfigurációját használja, miközben a VPN megpróbálja rendszerszinten kezelni a DNS-t. Lehet, hogy semmi sem fog elromlani, de zavar adódhat : azt gondolhatnánk, hogy minden lekérdezés a VPN-en keresztül halad, de a valóságban a böngésző saját maga küld néhányat egy másik DNS-feloldónak. Itt jön jól egy DNS-szivárgásteszt. Ha a VPN-hez való csatlakozás után látjuk az internetszolgáltatónk DNS-kiszolgálóit, akkor valami nem a várt módon működik; ha a VPN-hez társított kiszolgálókat látunk, akkor valószínűbb, hogy a konfiguráció megfelelően működik.
Mikor elegendő a DoH, és mikor ajánlott egy VPN?
A DoH elegendő lehet, ha elsődleges szempont a böngésző DNS-lekérdezéseinek alapvető adatvédelme. Egy megbízható otthoni hálózaton a biztonságos DNS engedélyezése csökkenti a sima szöveges információk kitettségét anélkül, hogy meg kellene változtatnia a tartózkodási helyét, vagy biztosítania kellene az összes alkalmazását . Hasznos olyan hálózatokon is, ahol a DNS-szűrés vagy -manipuláció aggodalomra ad okot, mert a HTTPS-en keresztüli utazás megnehezíti az egyszerű ellenőrzést vagy módosítást. Ez nem jelenti azt, hogy megkerüli az összes korlátozást, vagy cenzúramentes, de jelentős előrelépés a titkosítatlan DNS-hez képest. Továbbá pehelykönnyű: nem kell VPN-kiszolgálót választania, vagy jelentősen módosítania az útvonalat, és általában nem veszi észre a sebesség jelentős csökkenését.
A VPN akkor a legértelmesebb, ha eszközszintű védelmet szeretnénk, nem csak a DNS-kereséseket. Ide tartoznak a repülőterek, szállodák, iskolák, közösségi irodák, kávézók és bérelhető szálláshelyek . Megosztott hálózatokon nem tudhatjuk, ki irányítja a routert, ki más csatlakozik, vagy hogy valaki megpróbálja-e elfogni a forgalmat. A VPN akkor is segít, ha nem szeretnénk, hogy az internetszolgáltatónk profilt készítsen a böngészési mintáinkról: bár a HTTPS védi az oldalak tartalmát, a hálózati metaadatok továbbra is hasznos mintákat tárhatnak fel. Az utazás egy másik jó példa: a VPN konzisztensebbé teheti a kapcsolatot, védelmet nyújthat ismeretlen hálózatokon, és lehetővé teheti, hogy a webhelyek a VPN-kiszolgáló helyét lássák az ideiglenes helyi kapcsolat helyett.
A Google Public DNS DoH API-k technikai részletei
A Google Public DNS két különböző DoH API-t kínál. Az egyik az RFC 8484-hez készült, és GET és POST kéréseket fogad a https://dns.google/dns-query címen; a másik egy JSON API, amely csak a GET kéréseket támogatja a https://dns.google/resolve címen . Van egy webes felület is a https://dns.google/ címen, amely JSON eredményeket jelenít meg a böngészőben, de nem valósít meg teljes API-t. Ezt a felületet nem szabad összekeverni az API URL-ekkel vagy a https://dns.google/query címmel. A szolgáltatás nem támogatja a nem biztonságos HTTP URL-eket, és a DoH-t a Google nyilvános DNS64 szolgáltatása is támogatja, bár ebben az esetben csak az IPv6 támogatott. A Google biztonságos átviteli dokumentációja curl példákat és részleteket tartalmaz a TLS-ről, a DoT-ról és a DoH-ról.
Elérhető HTTP-metódusok
A GET metódus csökkentheti a késleltetést, mivel hatékonyabban gyorsítótáraz. Az RFC 8484 GET kéréseknek tartalmazniuk kell egy `?dns=` paramétert egy Base64Url kódolású DNS üzenettel , és ez az egyetlen metódus, amelyet a JSON API támogat. A POST metódus szintén csak az RFC 8484-ben érhető el, és egy bináris DNS üzenetet használ, amelynek mind a kérés, mind a válasz törzsében `application/dns-message` szerepel. A HEAD metódus jelenleg nem támogatott, és 400 Bad Request hibát ad vissza. Más metódusok 501 Not Implemented hibákat adnak vissza.
Állapotkódok és hibák
Az API számos olyan HTTP kódot ad vissza, amelyeket érdemes ismerni. A 200 OK azt jelzi, hogy a HTTP elemzés és a DNS-feloldóval való kommunikáció sikeres volt ; a válasz törzse lehet bináris DNS-válasz vagy JSON a végponttól, az Accept fejléctől és a GET paraméterektől függően. Megjegyzés: egy HTTP-hiba is lehet DNS-hiba, ezért célszerű ellenőrizni a DNS-válaszkódot, például a JSON "Status" mezőjét, olyan hibák után kutatva, mint a SERVFAIL, FORMERR, REFUSED vagy NOTIMP.
- 301 Véglegesen áthelyezve: A kliensnek újra kell próbálkoznia a kéréssel a Location paraméterben megadott URL-címen. Ha az eredeti kérés POST volt, akkor csak akkor szabad GET paranccsal újrapróbálkoznia, ha az új URL DNS-paramétert ad meg; ellenkező esetben POST paranccsal kell ismételnie a kérést. A 302-es, 307-es és 308-as állapotkódok is megjelenhetnek, és a DoH klienseknek mind a négyet kezelniük kell. Az állandó 301-es és 308-as állapotkódok határozatlan ideig gyorsítótárazhatók. A 307-es vagy 308-as állapotkódot kapó POST kéréseket mindig POST paranccsal kell újrapróbálkozni.
- 400 rossz kérés: Problémák a GET paraméterek vagy érvénytelen DNS-kérésüzenet elemzésével. A legtöbb érvénytelen DNS-üzenet FORMERR utasítással 200 OK választ kap, de HTTP-hibák fordulnak elő olvashatatlan üzenetek esetén, amelyekben nincs kérdés szakasz, QR-kód jelzi a választ, vagy értelmetlen kódkombinációkat tartalmaznak.
- 413 Túl nagy hasznos teher: Egy POST RFC 8484 kérés törzse meghaladja az 512 bájtos maximális üzenetméretet.
- 414 Túl hosszú URI: A GET lekérdezés fejléce túl nagy volt, vagy a dns paraméter meghaladta az 512 bájtot.
- 415 Nem támogatott médiatípus: A POST törzsében nem volt az application/dns-message tartalomtípusú fejléc.
- 429 Túl sok kérés: Túl sok kérést küldtek egy adott időszakban. Az ügyfélnek meg kell várnia a Retry-After fejlécben megadott időpontig.
- 500 belső kiszolgáló hiba: Belső hibák a DoH szolgáltatásban.
- 501 Nincs implementálva: Csak a GET és a POST metódusok vannak implementálva; a többiek ezt a hibát adják vissza.
- 502 Hibás átjáró: A DoH szolgáltatás nem tudott kommunikálni a Google nyilvános DNS-feloldóival. Egy másik cím kipróbálása működhet, de hatékonyabb biztonsági megoldás egy másik DoH szolgáltatás kipróbálása, vagy a hagyományos DNS-re váltás UDP vagy TCP használatával a 8.8.8.8-as verzión.
Adatvédelmi és teljesítménybeli legjobb gyakorlatok
A DoH alkalmazásfejlesztőknek korlátozniuk kell a HTTP fejlécek használatát. Az olyan fejlécek, mint a Cookie, a User-Agent és az Accept-Language, információkat árulhatnak el a kliens implementációjáról, és hozzájárulhatnak a deanonimizáláshoz . Ajánlott csak a DoH-hoz szükséges fejlécek küldése: Host, Content-Type (POST kérésekhez) és ha szükséges, az Accept. A User-Agent fejlécet a fejlesztői vagy tesztverziókban kell szerepeltetni. Célszerű EDNS kitöltést is használni, hogy a lekérdezéseket a szokásos hosszúságúra rövidítsék, és megnehezítsék a forgalomelemzést. A HTTP/2 kitöltés lehetséges, de az EDNS kitöltéstől eltérően nem generál kitöltést a DoH szerver válaszaiban.
Az RFC 8484-ben szereplő POST metódust csak adatvédelmi szempontból érzékeny alkalmazásokban vagy böngésző módokban szabad használni. A POST használata csökkenti a gyorsítótár kapacitását és növelheti a késleltetést, ezért általában nem ajánlott . A gyorsítótár méretének csökkentése azonban tanácsos lehet azoknak az alkalmazásoknak, amelyek meg akarják akadályozni a webes alkalmazásszinkronizációs támadásokat, amelyek célja, hogy felderítsék, mely domaineket látogatta meg a felhasználó a közelmúltban. A HTTPS megközelítésnek gyakorlati előnyei is vannak: a HTTPS API-k széles körben elérhetők és támogatottak, ami leegyszerűsíti a megvalósítást; egy HTTPS szolgáltatás hozzáférést biztosít a webes alkalmazásoknak minden típusú DNS-rekordhoz, elkerülve a böngésző vagy operációs rendszer API-k korlátait, amelyek jellemzően a hoszt-cím keresésekre korlátozódnak; és az UDP-n keresztül QUIC-kel megvalósító kliensek elkerülhetik a TCP-vel előforduló olyan problémákat, mint a sorfejlécek blokkolása. Ha hibát észlel, vagy új funkciót szeretne kérni, a DoH-val kapcsolatos problémát a szokásos csatornákon keresztül kell jelentenie.
Gyakori kérdések az egészségügyi ellátásról és a VPN-ről
Az egyik leggyakrabban feltett kérdés, hogy van-e értelme DoH-t használni, ha már használunk VPN-t. Lehetséges, de a legpraktikusabb megközelítés általában az, ha a VPN kezeli a DNS-t , és szivárgásteszttel ellenőrizzük, hogy a lekérdezések a megfelelő csatornákon haladnak-e át. Ha a böngésző az egyik, a VPN pedig a másik irányba küldi a saját lekérdezéseit, kellemetlen meglepetés érhet minket.
Egy másik gyakori kérdés, hogy vajon a DoH megakadályozza-e az internetszolgáltatódat abban, hogy lássa, mely webhelyeket látogatod. A DoH sok megfigyelő elől elrejti a DNS-lekérdezéseket, de nem távolít el minden metaadatot, és nem rejti el az IP-címedet : az internetszolgáltatód továbbra is láthatja, hogy mely IP-címekhez csatlakozol, valamint egyéb hálózati információkat. Szélesebb körű védelemhez VPN-re vagy több adatvédelmi réteg kombinációjára van szükséged.
Azt is érdemes megkérdezni, hogy a DomainHost (DoH) elegendő-e nyilvános Wi-Fi-n. Segíthet megakadályozni, hogy a hálózat üzemeltetője könnyen elolvassa a DNS-lekérdezéseidet, de nem védi a teljes kapcsolatot vagy az összes alkalmazás forgalmát . Repülőtereken, szállodákban és kávézókban a VPN használata általában átfogóbb, különösen akkor, ha nem tudod, ki irányítja a routert, vagy ha mások is csatlakoznak-e.
A Domain Name System (DoH) és a VPN-ek nem közvetlen riválisok, hanem eltérő képességekkel rendelkező eszközök. A DoH titkosítja a domainkeresést, és csökkenti a folyamat ezen részének kitettségét; a VPN titkosítja az eszköz és a szerver közötti utat, és megváltoztatja a célállomások által látott IP-címet . Egyik sem tesz láthatatlanná: a fiókok, sütik, böngésző ujjlenyomatok, alkalmazásengedélyek, rosszindulatú programok és a közvetlenül megosztott adatok továbbra is azonosíthatnak téged. De ez nem teszi őket haszontalanná. Egyszerűen azt jelenti, hogy mindegyiknek megvan a maga szerepe. A DoH védi a címkeresést; a VPN az adataid útvonalának sokkal nagyobb részét védi.