Table of Contents
DNS-salauksen tarve: Plaintext Queriesin ulkopuolella
Domain Name System (DNS) on peruskäytäntö, joka muuntaa ihmisen luettavissa olevat verkkotunnukset IP-osoitteisiin. Huolimatta sen kriittisestä roolista perinteinen DNS-liikenne on perinteisesti lähetetty selkokielellä UDP:n tai TCP:n yli, jolloin se on altis salakuuntelulle, manipuloinnille ja välimuistimyrkytykselle. Samassa verkossa tai kyselyn polulla olevat hyökkääjät voivat sieppata DNS-vastauksia ohjatakseen käyttäjät haitta-sivustoille tai kerätäkseen selailumetadataa. Koska internetin yksityisyyden kysymykset ovat lisääntyneet, on ilmennyt kaksi täydentävää salausprotokollaa DNS-liikenteen suojelemiseksi DNS HTTPS:n (DoH) [] ja [DNS TLS:n (DOT) [DNS:2] osalta.
Molemmat protokollia salata kysely- ja vastaustiedot, suojaamalla sitä tarkkailulta ja peukalointi. Kuitenkin ne eroavat toisistaan toteutuksen, portin käytön ja miten ne integroida olemassa olevat verkkopinot. Näiden erojen ymmärtäminen on välttämätöntä valita oikea lähestymistapa yksittäisten käyttäjien, verkon ylläpitäjien ja sovelluskehittäjien.
DNS yli HTTPS (DoH): Upotetaan hakuja Web Traffic
DNS HTTPS kietoo perinteiset DNS kyselyt ja vastaukset sisällä standardi HTTPS pyyntöjä ja vastauksia käyttäen samaa porttia 443 käytetään säännölliseen verkkoliikenteeseen. Tämä muotoilu tekee DoH liikennettä erotettavissa muusta HTTPS-liikenteen verkkotarkkailijat, elleivät he suorittavat syvä pakettitarkastus tai analysoida palvelimen IP-osoitteita. DoH standardisoitu RFC 8484 ja on hyväksynyt suuria selaimet kuten Mozilla Firefox ja Google Chrome
Miten DoH toimii
Kun asiakas (selain tai sovellus) haluaa ratkaista verkkotunnuksen, se lähettää HTTP-postin tai GET-pyynnön DOH-yhteensopivalle resolverille (kuten Cloudflare-ratkaisulle 1.1.1.1 tai Googlen 8.8.8). DNS-kysely on koodattu pyyntökehoon tai kyselyjonoon ja ratkaisija vastaa HTTP-vastauskehoon koodatulla DNS-vastauksella. Koska koko tapahtuma tapahtuu HTTPS:n kautta, kaikki TLS:n tarjoama salaus, tunnistus ja varmenteiden validointi on periy.
DoH:n tärkeimmät edut
- Kontakti:[ Käyttämällä porttia 443 ja HTTPS-kartoitusta DoH-liikenne sekoittuu normaaliin verkkoliikenteeseen, mikä vaikeuttaa verkkosuodatusta tai DNS-kyselyjen kohdistamista aiheuttamatta sivuvahinkoja verkkoselailulle.
- Helppo käyttöönotto sovelluksissa:[[] Selaimet ja sovellukset voivat toteuttaa DoH ilman muutoksia käyttöjärjestelmän DNS-asetuksiin. Käyttäjät voivat yksinkertaisesti mahdollistaa asetus- tai laajennustöiden.
- Juottaa olemassa olevaa HTTPS-infrastruktuuria:[] DoH voi käyttää uudelleen samoja HTTP/2- tai HTTP/3-yhteyksiä ja hyödyntää kypsän kuormituksen tasapainottamista, välimuistia ja sisällönjakeluverkkoja (CDN-verkkoja), jotka käyttävät modernia verkkoa.
Huomiot ja arvostelut
Yksityisyyden eduista huolimatta DoH on herättänyt keskustelua. Verkko-operaattorit menettävät usein näkyvyyttä DNS-liikenteessä, koska yksittäiset sovellukset voivat ohittaa järjestelmän tason DNS-asetukset. Tämä voi estää sisällön suodattamisen, vanhempien valvonnan ja yrityksen tietoturvapolitiikan. Lisäksi DoH tuo HTTP-kartoituksen ja erillisen TLS-kädenpuristuksen tarpeen (vaikka HTTP/2 multiplexxing lieventää tätä). Jotkut arvostelijat väittävät, että DoH keskittää DNS-resoluution muutamalle isolle tarjoajalle, mikä saattaa luoda uusia valvonta- tai valvontapisteitä.
DNS yli TLS (DOT): Järjestelmän tason turvallisuus erityissatamassa
DNS TLS (DoT) käyttää TLS-protokollaa, mutta kommunikoi sen sijaan, että se olisi HTTP-tilassa. Tämä lähestymistapa on määritelty [RFC 7858:ssa ja se on tyypillisesti määritetty käyttöjärjestelmän tasolla tai reitittimissä, varmistaen, että kaikki DNS-liikenne jokaisesta sovelluksesta on salattu.
Miten ART- t vaikuttaa
DoT-asiakas luo TCP-yhteyden ratkaisijaan portilla 853 ja suorittaa TLS-kädenpuristuksen. Kun ratkaisijan varmenteen todentaminen on onnistunut, DNS-viestit vaihdetaan suoraan TLS-istunnossa käyttäen samaa johtomuotoa kuin perinteinen DNS mutta salatussa tunnelissa. Koska DoT käyttää ainutlaatuista porttia, se voidaan helposti tunnistaa ja hallita verkon palomuurien ja reitityskäytäntöjen avulla.
DoT:n tärkeimmät edut
- Järjestelmän kokoinen valvonta:[ Kun DoT on määritetty käyttöjärjestelmän tai reitittimen tasolla, kaikki sovellukset hyötyvät salauksesta tarvitsematta yksilöllistä tukea. Tämä on erityisen arvokasta mobiililaitteille, IoT-laitteille ja yritysverkoille.
- Yksinkertainen seuranta ja suodatin:[ Hallinnoijat voivat sallia tai estää DoT-liikenteen, joka perustuu erityiseen satamaan ja tunnettuihin resolveri-IP-järjestelmiin, jolloin on helpompaa ylläpitää toimintaperiaatteita kuin DoH:n piilotettu luonne.
- Tehokas johtomuoto:[ DoT ei lisää HTTP-otsikkoja tai multipleksointi yläpuolella, mikä johtaa pienempi per-query latenssi monissa skenaarioissa. Binary DNS-protokolla säilytetään, mikä vähentää käsittelyvaatimuksia.
TE-aikaa koskevat huomiot
DoT:n riippuvuus erityisestä portista helpottaa sen estoa, jos verkko-operaattori tai ISP päättää rajoittaa salattua DNS-järjestelmää. Koska DoT on yleensä konfiguroitu järjestelmällisesti, tuki kulutuslaitteissa kasvaa edelleen. Android ja iOS alkoivat tukea DoT:tä vain OS-tasolla vain viimeaikaisissa versioissa, ja monilla reitittimillä ei ole sisäänrakennettuja vaihtoehtoja doT-virtausten konfigurointiin.
DoH vs. doT: A Side-by-side vertailu
| Feature | DNS over HTTPS (DoH) | DNS over TLS (DoT) |
|---|---|---|
| Standard | RFC 8484 | RFC 7858 |
| Transport port | 443 (HTTPS) | 853 (reserved) |
| Traffic visibility | Hidden among web traffic | Distinguishable by port |
| Typical deployment | Application level (browser, app) | System level (OS, router) |
| Authentication | HTTPS certificate validation | TLS certificate validation |
| Performance overhead | Higher due to HTTP framing | Lower; binary wire format |
| Ease of blocking | Difficult without breaking web | Easier via port 853 |
| Centralization risk | Higher (browser defaults) | Lower (admin-controlled) |
DoH tarjoaa kätevän tavan ohittaa paikallinen DNS-nuuskiminen muuttamatta järjestelmän asetuksia. Verkko-operaattoreille, jotka tarvitsevat johdonmukaista salausta kaikkien laitteiden kautta, DoT tarjoaa hallittavamman ja auditoitavamman ratkaisun.
Toteutus Salattu DNS: Käytännön näkökohtia
Asiakas-side- asetukset
Useimmat modernit selaimet ovat sisäänrakennettuja DoH-tuki. Firefox-käyttäjät voivat ottaa DoH-yhteyden verkkoasetuksissa, kun taas Chrome noudattaa järjestelmän DNS-over-HTTPS-käytäntöä, jos se on määritetty. Windows 11:ssä käyttäjät voivat asettaa DoH- tai DoT-järjestelmän tietyille resolvereille verkkosovittimen ominaisuuksissa. macOS- ja Linux-käyttäjät voivat määrittää stub-resolventaattorit kuten stubby[ (DOT) tai käyttää työkaluja kuten [dnscrypt-proxy[[], jotka tukevat molempia protokollia.
Ratkaisijan valinta
Sekä DoH:n että DoT:n tarjoamiin julkisiin ratkaisuihin kuuluvat Cloudflare (1.1.1), Quad9 (9.9.9) ja Google (8.8.8.8). Jokaisella on erilaiset tietosuojakäytännöt: Cloudflare sitoutuu olemaan kirjaamatta henkilökohtaisesti tunnistettavia tietoja, Quad9 estää haitta-alueiden oletuksena ja Google käyttää anonyymisoimistekniikoita. Käyttäjien tulisi varmistaa selvittäjän luotettavuus ja paikallisten lakien noudattaminen.
Mahdolliset takaiskut
Salattu DNS voi olla ristiriidassa verkkoturvatyökalujen kanssa, kuten tunkeutumisen havaitsemiseen perustuvat järjestelmät, jotka luottavat DNS-kyselyjen tarkastamiseen. Se voi myös rikkoa vankiportaalit (julkiset Wi-Fi-kirjautumissivut), jotka vaativat salattua DNS-järjestelmää käyttäjien uudelleensuuntaamiseen. Jotkut yritysympäristöt estävät kaikki ulkoiset salatut DNS-järjestelmät yrityksen suodatuskäytäntöjen noudattamisen valvomiseksi. Tällaisissa tapauksissa hallintoviranomaisten on otettava käyttöön strategia.Joko käyttämällä omaista sisäistä salattua ratkaisulaitetta tai käyttämällä DANE-järjestelmää (DNS-Based Authentation of Named Fortuations) DOT-järjestelmää.
DNS-salauksen tulevaisuus
DoH:n ja DoT:n lisäksi uudet protokollat työntävät kirjekuorta eteenpäin. []DNS QUIC:n (DoQ)[] vipuvoimaa QUIC-kuljetusprotokollaa, jotta voidaan vähentää latenssia ja parantaa selviytymiskykyä epäluotettavien verkkojen suhteen. []Epäilty DoH (ODoH)[[] lisää välityskerroksen, joka estää selvittäjää linkittämästä kyselyitä asiakkaan IP-osoitteisiin, mikä lisää metadatan yksityisyyttä. Samalla IETF:n []DNS HTTPS:n varmenteiden varastointiin [[] mahdollistaa CA:n julkaiseman varmenteiden läpinäkyvyyslokit DNS:n kautta, mikä lisää luottamusta.
Koska Internetin standardointiorganisaatiot jatkavat näiden protokollien tarkentamista, niiden käyttöönoton odotetaan kasvavan. Tärkeimmät selaimet ja käyttöjärjestelmät ovat jo nyt siirtyneet salatulla DNS-järjestelmällä, joka on oletusarvoisesti käytössä joillakin alueilla. Verkko-operaattorien ja DNS-infrastruktuurin tarjoajien on varauduttava tulevaisuuteen, jossa salaamattomasta DNS:stä tulee pikemminkin poikkeus kuin normi.
Päätelmät
DNS HTTPS ja DNS TLS edustavat kriittistä kehitystä käyttäjien yksityisyyden ja turvallisuuden säilyttämisessä internetissä. Molemmat protokollia salata verkkotunnuksen resoluutioprosessi, estää monia yhteisiä hyökkäyksiä, jotka hyödyntävät salaamatonta DNS. Vaikka DoH tarjoaa saumattoman integraation web-sovelluksia ja parempi salaus, DoT tarjoaa vankan, järjestelmän laajuinen ratkaisu, joka on helpompi hallita ammattiverkoissa. Ymmärtäminen niiden erot antaa käyttäjille, kehittäjille ja IT-ammattilaisille mahdollisuuden tehdä tietoon perustuvia valintoja, jotka vastaavat heidän tietoturvavaatimuksia ja toiminnallisia rajoituksia.
Lisätietoja saa virallisista RFC-rekistereistä: RFC 8484 (DoH)[], RFC 7858 (DOT)[], ja []Cloudflare's DoH-dokumentaatio[]. Internetin kehittyessä salattu DNS pysyy turvallisemman ja yksityisemmän verkon kulmakivenä.