DNSSEC ir DNS saugumas jūsų vietiniame tinkle

Informatec Digital » Ištekliai » DNSSEC ir DNS saugumas jūsų vietiniame tinkle

Internetas sukurtas remiantis keletu pagrindinių komponentų, kurių beveik niekada nematome, bet kurie yra šalia kiekvieną kartą atidarius naršyklę. Vienas svarbiausių yra domenų vardų sistema (DNS), ir kalbėdami apie DNSSEC ir saugumą vietiniame tinkle , iš tikrųjų turime omenyje šio pagrindo stiprinimą, siekiant užkirsti kelią apgaulingiems peradresavimams, klastojimui ir kitoms rimtoms atakoms.

Anksčiau prioritetas buvo tiesiog užtikrinti, kad viskas veiktų; šiandien žinome, kad to nepakanka. DNS atsirado devintajame dešimtmetyje, neatsižvelgiant į masines kibernetines atakas, tačiau dabar mums reikia, kad ji ne tik išspręstų vardus, bet ir patvirtintų kiekvieno atsakymo autentiškumą ir vientisumą . Čia praverčia DNSSEC, o pastaruoju metu atsirado tokių pasiūlymų kaip E-DNSSEC, kuriais siekiama padidinti konfidencialumą – tai yra pagrindinis veiksnys, jei nerimaujate dėl savo vietinio ar įmonės tinklo saugumo.

Kas yra DNS ir kodėl jis toks svarbus saugumui?

Domenų vardų sistema (DNS ) yra interneto telefonų knyga: ji lengvai įsimenamus vardus (pvz., www.example.com) verčia į skaitmeninius IP adresus, kuriuos supranta kompiuteriai (pvz., 192.168.2.15 arba IPv6 adresas). Be šio mechanizmo turėtume įsiminti skaičius, o ne vardus, o tai visiškai nepraktiška.

Ši infrastruktūra organizuota kaip paskirstyta duomenų bazė medžio struktūroje , kurios viršuje yra šakninė zona, po jos eina aukščiausio lygio domenai (pvz., .es, .com, .org), o žemiau – domenai ir subdomenai. Kiekviena šios duomenų bazės dalis vadinama „ zona “ ir yra talpinama viename ar keliuose autoritetinguose vardų serveriuose, kurie skelbia „oficialią“ informaciją apie kiekvieną domeną.

Kai jūsų kompiuteris, mobilusis telefonas ar bet kuris kitas įrenginys nori pasiekti svetainę, jis pirmiausia pateikia užklausą DNS serveriui , kuris yra operacinės sistemos dalis. Šis serveris siunčia užklausą į rekursinį DNS serverį (paprastai jūsų interneto paslaugų teikėjo, jūsų įmonės arba viešąjį, pvz., „Google Public DNS“ , „OpenDNS“ arba „Quad9“). Tada šis rekursinis serveris ieško atsakymo, užklausdamas kelis autoritetingus serverius, kol suranda teisingą IP adresą.

Rekursyvūs DNS užklausų teikėjai kaupia gautus atsakymus talpykloje, kad pagreitintų vėlesnes užklausas. Tai labai efektyvu, tačiau taip pat atveria duris užpuolikui „užkrėsti DNS talpyklą“ ir įterpti melagingus duomenis , kad daugelis vėlesnių užklausų būtų išspręstos naudojant šią manipuliuojamą informaciją vartotojui to nepastebint.

Pagrindinė problema yra ta, kad pagal pradinę DNS konstrukciją nėra patikimo būdo patikrinti atsakymų autentiškumą . Resolveris iš esmės patikrina, ar atsakymas atrodo siunčiamas iš to paties IP adreso, į kurį buvo užklausta, tačiau tą šaltinio IP adresą galima gana lengvai suklastoti. Tai leidžia tyliai nukreipti atakas į apgaulingas svetaines, kurios imituoja, pavyzdžiui, jūsų banko svetainę.

Tradicinio DNS saugumo apribojimai

DNS protokolas buvo sukurtas tuo metu, kai saugumas nebuvo svarbiausias rūpestis. Štai kodėl dabar žinome, kad DNS užklausos ir atsakymai perduodami paprastu tekstu , be šifravimo, ir kad įrašų duomenys gali būti suklastoti be papildomos apsaugos.

Tai atveria duris įvairių tipų atakoms, ypač DNS talpyklos užkrėtimui ir „man-in-the-middle“ atakoms. Abiem atvejais užpuolikas įterpia suklastotus atsakymus, todėl vartotojai patenka į jų kontroliuojamas svetaines nepastebėdami nieko neįprasto, nes naršyklėje rodomas domeno vardas išlieka teisėtas.

Įsivaizduokite, kad prisijungiate prie savo banko svetainės: jūsų kompiuteris kreipiasi į rekursinį serverį dėl banko domeno IP adreso, tačiau užpuolikas apgavo serverį ir privertė jį priimti netikrą atsakymą su identiškos, jo paties kontroliuojamos svetainės IP adresu . Vartotojas įveda savo prisijungimo duomenis, manydamas, kad viskas normalu, ir kibernetinis nusikaltėlis juos gauna paprastu tekstu, kad vėliau galėtų naudoti tikroje svetainėje.

Tokie mechanizmai kaip operacijų parašai (TSIG) , apibrėžti RFC 2845, skirti apsaugoti tam tikras operacijas tarp DNS serverių (pavyzdžiui, zonų perkėlimą tarp pagrindinio ir pavaldžių serverių bei dinaminius atnaujinimus). TSIG leidžia dviem mašinoms dalytis slaptu raktu, kad būtų galima patikrinti kito galo tapatybę ir perduodamų pranešimų vientisumą.

Tačiau TSIG taikymo sritis yra labai ribota: ji neautentifikuoja „tikrosios“ DNS duomenų kilmės ; ji tik užtikrina, kad mainai tarp dviejų konkrečių serverių nebuvo pakeisti. Jei pradinė informacija zonoje jau buvo pažeista arba manipuliuojama prieš pasiekiant tuos serverius, TSIG jos neaptiks. Todėl, nors ji dažnai naudojama zonų perdavimui, ji neišsprendžia pagrindinės paskelbtų DNS duomenų autentiškumo problemos.

Kas yra DNSSEC ir kaip jis prisideda prie saugumo?

Reaguojant į visus šiuos trūkumus, buvo sukurti domenų vardų sistemos saugumo plėtiniai (DNSSEC) . DNSSEC nepakeičia klasikinio DNS, o jį išplečia saugumo sluoksniu, leidžiančiu patikrinti, ar gauti duomenys yra teisėti ir nebuvo pakeisti.

DNSSEC pagrįsta viešojo rakto kriptografija (asimetrine kriptografija) . Kiekviena DNS zona turi raktų porą: privatų raktą, kuris laikomas paslaptyje, ir viešąjį raktą, kuris skelbiamas pačiame DNS serveryje. Zonos savininkas naudoja privatų raktą, kad skaitmeniniu būdu pasirašytų įrašus toje zonoje; viešasis raktas naudojamas tiems parašams patikrinti.

Kai rekursinis serveris pateikia užklausą domenui naudodamas DNSSEC, kartu su įprasta informacija (pvz., su vardu susietu IP adresu), jis taip pat gauna skaitmeninius parašus ir viešuosius raktus, reikalingus patvirtinimui . Rekursinis serveris patvirtina parašus pagal paskelbtus viešuosius raktus; jei patvirtinimas sėkmingas, duomenys laikomi autentiškais ir nepakitę nuo pasirašymo.

Jei patvirtinimas nepavyksta, duomenų sprendėjas supranta, kad kažkas negerai (pavyzdžiui, bandymas apsimesti arba klastoti perdavimo metu) ir atsako klientui klaidos kodu, paprastai SERVFAIL . Tokiu būdu vartotojas negauna potencialiai kenkėjiškų duomenų, nors iš jo perspektyvos jis matys tik tai, kad puslapis „neįkeliamas“ arba rodoma klaida.

DNSSEC taip pat pristato pasitikėjimo grandinės koncepciją , kuri naudoja esamą DNS hierarchiją. Šakninė zona pasirašo aukščiausio lygio domenų (pvz., .es, .com) raktus, o šie savo ruožtu pasirašo savo antrinių domenų raktus ir taip toliau, kad bet kurį domeną būtų galima patvirtinti naudojant vieną patikimumo tašką: šakninės zonos viešąjį raktą.

KSK ir ZSK raktai, įrašai ir pasitikėjimo grandinė

Siekdama geriau organizuoti saugumą, DNSSEC naudoja dviejų skirtingų tipų raktus: rakto pasirašymo raktą (KSK) ir zonos pasirašymo raktą (ZSK) . Nors techniškai jie yra vienodi (kriptografiškai kalbant), jų funkcija sistemoje skiriasi.

ZSK raktas naudojamas visiems zonos išteklių įrašams (A, AAAA, MX ir kt.) pasirašyti. Paprastai jis dažnai keičiamas, siekiant sumažinti riziką, nes bet koks šio rakto pažeidimas paveiktų visus zonos įrašus. Kita vertus, KSK daugiausia naudojamas pačiam zonos raktui (ZSK) pasirašyti, o jo maišos kodas (hash) skelbiamas kaip DS (delegacijos pasirašytojo) įrašas pagrindinėje zonoje.

Dėl šio vaidmenų atskyrimo ZSK keitimas yra paprastesnis: tereikia sugeneruoti naują ZSK, pasirašyti jį su KSK, paskelbti zonos DNSKEY įrašuose ir leisti sprendėjams atnaujinti savo informaciją. Nereikia liesti pagrindinės zonos, nes DS ir toliau nurodo į tą pačią KSK, kuri ilgiau išlieka stabili.

DNSSEC į DNS protokolą įtraukia kelis specifinių įrašų tipus, skirtus duomenų pasirašymui ir patvirtinimui palaikyti. Tarp svarbiausių yra DNSKEY, RRSIG, DS, NSEC/NSEC3 ir NSEC3PARAM . Visi jie leidžia kurti autentifikavimo logiką nekeičiant pagrindinio užklausų veikimo.

DNSKEY įraše saugomas zonos viešasis raktas , kuris būtinas parašams patikrinti. RRSIG įraše yra skaitmeninis parašas, susietas su konkrečiu įrašų rinkiniu („Išteklių įrašų rinkinys“). DS įrašas yra antrinės zonos DNSKEY maišos formatas, kuris skelbiamas pirminėje zonoje ir yra patikima grandinės grandis.

NSEC ir NSEC3 įrašai naudojami autentifikuotam egzistavimo paneigimui užtikrinti ; tai yra, kriptografiškai įrodyti, kad domeno vardas ar įrašas neegzistuoja, užkertant kelią atakoms, kuriomis bandoma pateikti klaidingus atsakymus, rodančius, kad kažkas neegzistuoja, kai iš tikrųjų egzistuoja (arba atvirkščiai).

Pasitikėjimo grandinės ir DNSSEC atsakymo patvirtinimas

Vadinamoji pasitikėjimo grandinė DNSSEC sistemoje kuriama susiejant DNSKEY ir DS įrašus nuo šakninio domeno iki domeno, kurį norime patvirtinti . Pradinis taškas yra šakninės zonos viešasis raktas, kuris veikia kaip pasitikėjimo inkaras ir paprastai konfigūruojamas tiesiogiai rekursiniuose sprendikliuose.

Pavyzdžiui, jei norite patvirtinti tokį domeną kaip mywebsite.es, loginis procesas būtų toks: verifikavimo programa pasitiki šakninio domeno viešuoju raktu, kuris pasirašo .es raktą; .es zona paskelbia DS įrašą, atitinkantį mywebsite.es KSK raktą; patvirtindama tą DS su .es raktu, verifikavimo programa pasitiki mywebsite.es DNSKEY ir iš ten gali patikrinti RRSIG visuose savo įrašuose.

Jei bet kuriame grandinės taške trūksta galiojančio parašo arba jei DS (duomenų parašas) nėra ten, kur turėtų būti, pasitikėjimo grandinė nutrūksta. Tokiu atveju rekursinis serveris, atliekantis patvirtinimą, nelaiko duomenų saugiais ir, priklausomai nuo savo konfigūracijos, neatsako pateikdamas prašomus įrašus arba pažymi atsakymą kaip negaliojantį.

Šis hierarchinis ryšys taip pat reiškia, kad norint, jog DNSSEC būtų tikrai veiksmingas, nepakanka pasirašyti tik savo zoną : pagrindinė zona (pvz., .es) ir šakninė zona taip pat turi būti pasirašytos, o jų DNS įrašai turi būti teisingai paskelbti. Šiuo metu DNS šakninė zona ir praktiškai visi bendriniai aukščiausio lygio domenai (gTLD) ir daugelis šalies kodo aukščiausio lygio domenų (ccTLD) jau yra pasirašyti.

Kai rekursinis serveris su įjungtu DNSSEC patvirtinimu aptinka, kad parašas nesutampa arba trūksta nuorodos, klientui grąžinamas atsakymas paprastai pateikiamas kartu su klaidos kodu RCODE SERVFAIL. Tai gali būti painu galutiniam vartotojui („svetainė neveikia“), tačiau saugumo požiūriu tai yra apsaugos priemonė nuo potencialiai manipuliuojamų duomenų.

DNSSEC taip pat pristato dvi pagrindines funkcijas: duomenų kilmės autentifikavimą , kuris leidžia patikrinti, ar įrašai iš tikrųjų yra iš numatytos zonos, ir vientisumo apsaugą , kuri užtikrina, kad informacija nebuvo pakeista nuo tada, kai ją pasirašė zonos savininkas savo privačiuoju raktu.

DNSSEC sušvelnintos atakos ir jų ryšys su TLS/HTTPS

DNSSEC įdiegimas padeda apsisaugoti nuo kelių dažniausiai pasitaikančių grėsmių. Pirma, tai labai apsunkina DNS atsakymų klastojimą , nes užpuolikas turėtų generuoti galiojančius parašus nežinodamas zonos privačiojo rakto, o tai kriptografiškai neįmanoma, jei raktai tvarkomi teisingai.

Be to, DNSSEC sumažina talpyklos užkrėtimo riziką rekursiniuose serveriuose, neleisdama priimti manipuliuojamų atsakymų, kurie nepavyksta patikrinti parašo. Tai taip pat apsunkina „žmogaus tarpo“ (MITM) atakas prieš DNS srautą, kai užpuolikas modifikuoja atsakymus perdavimo metu: jei atsakymas nepavyksta patikrinti, serveris jį atmeta.

Tačiau svarbu suprasti, ko DNSSEC neatlieka. Šie plėtiniai nėra skirti užklausų ar atsakymų turiniui šifruoti . Visas DNS srautas, net ir naudojant DNSSEC, vis tiek keliauja paprastu tekstu, nebent naudojate kitas papildomas technologijas (pvz., DoT, DoH arba E-DNSSEC tipo sprendimus). DNSSEC tikslas – užtikrinti, kad tai, ką gaunate, būtų autentiška ir nebūtų pakeista, o ne slėpti, ko klausiate.

Tai aiškiai skiria jį nuo tokių protokolų kaip TLS ir HTTPS . Nors HTTPS šifruoja srautą tarp naršyklės ir žiniatinklio serverio, kad trečiosios šalys negalėtų šnipinėti ar modifikuoti ryšio, DNSSEC tiesiog pasirašo DNS duomenis, kad aptiktų klastojimą. Svetainėje gali būti HTTPS be DNSSEC arba DNSSEC be HTTPS, tačiau abiejų derinys suteikia daug išsamesnę apsaugą nuo klastojimo ir šnipinėjimo.

Tokios organizacijos kaip ICANN ir IETF jau daugelį metų skatina platų DNSSEC diegimą tarp registrų tvarkytojų, registratorių, interneto paslaugų teikėjų ir tinklo operatorių. Tikslas – kad būtų pasirašyta vis daugiau zonų ir kad daugiau identifikatorių jas aktyviai patvirtintų, jog vidutinis vartotojas galėtų pasinaudoti šiomis kriptografinėmis garantijomis nesiimdamas jokių specialių veiksmų.

DNSSEC .es domenuose ir savininko įsipareigojimai

Konkrečiai Ispanijos atveju „ Red.es“ valdomas „.es“ domenų padalinys jau seniai įdiegė papildomas technologijas ir procedūras, siekdamas pagerinti DNS paslaugos, teikiamos su šalies kodu .es, kokybę ir saugumą. Tarp šių priemonių yra DNSSEC saugumo protokolo įdiegimas pagal IETF specifikacijas.

.es domenai yra atsakingi už .ES aukščiausio lygio zonos pasirašymą ir autorizacijos gavimą iš DNS šakninio serverio, taip integruodamiesi į pasaulinę pasitikėjimo grandinę. Tai reiškia, kad jei turite .es domeną, galite pasinaudoti šia infrastruktūra, kad apsaugotumėte savo domeną naudodami DNSSEC.

Domeno savininkui įprasta DNSSEC įjungimo procedūra apima užtikrinimą, kad jūsų autoritetingi DNS serveriai publikuotų pasirašytą zoną. Paprastai tai reiškia, kad sugeneruojamas viešasis jūsų zonos raktas, pasirašomi įrašai, publikuojamas DNS raktas ir pateikiamas rakto medžiaga (arba pats DS įrašas) registrui arba registratoriui, kad jie galėtų sukurti atitinkamą DS įrašą pagrindinėje zonoje.

Praktiškai daugelis DNS prieglobos paslaugų teikėjų ir registratorių jau siūlo gana paprastą DNSSEC įjungimo parinktį, kartais tai padaryti tereikia pažymėti langelį valdymo skydelyje. Tačiau už šią funkciją gali būti taikomas nedidelis metinis mokestis, priklausomai nuo teikėjo ir paslaugų lygio.

Kai zona pasirašoma ir sėkmingai publikuojama domenų vardų sistema (DNS), jūsų domenas tampa DNSSEC pasitikėjimo grandinės dalimi. Nuo to momento jūsų domeno DNS sprendimus gali kriptografiškai patvirtinti sprendimus teikiančios įmonės, turinčios įjungtą DNSSEC patvirtinimą, taip padidindamos vartotojų pasitikėjimą ir sumažindamos apgavysčių atakų riziką.

DNSSEC vietiniame tinkle: vartotojo pusės patvirtinimas

Galutinio vartotojo ar įmonės, susirūpinusios dėl savo vietinio tinklo saugumo, požiūriu, pagrindinis klausimas yra: ko reikia, kad būtų galima pasinaudoti DNSSEC? Geros žinios yra tai, kad jums nereikia nieko konfigūruoti kiekviename kompiuteryje atskirai , jei tik jūsų rekursinis DNS serveris (kurį naudoja jūsų kompiuteriai) patvirtina DNSSEC.

Norėdami tai padaryti, jums tereikia, kad jūsų DNS teikėjas (jūsų interneto paslaugų teikėjas, viešasis DNS serveris arba jūsų organizacijos vidinis DNS serveris) turėtų rekursinį serverį su įjungtu ir tinkamai sukonfigūruotu DNSSEC patvirtinimu . Beveik visi šiuolaikiniai DNS serveriai palaiko DNSSEC jau daugelį metų; norint jį įjungti, paprastai reikia atlikti tik kelis konfigūracijos failo pakeitimus ir pridėti šakninį pasitikėjimo inkarą.

Įjungus patvirtinimą, kai vienas iš jūsų kompiuterių vietiniame tinkle pateikia užklausą pasirašytam domenui, rekursinis vertintojas patikrina visus parašus ir patikimumo grandinę prieš grąžindamas atsakymą. Jei kas nors nesutampa, jis negrąžina jokių įrašų, o vartotojas mato klaidą, faktiškai neleisdamas jam prisijungti prie potencialiai nesąžiningos svetainės.

Norėdami patikrinti, ar jūsų domenas yra apsaugotas DNSSEC, galite pasinaudoti keliais internetiniais įrankiais, tokiais kaip „DNSSEC Analyzer“ ir kitomis patvirtinimo priemonėmis . Įvedę savo domeną, turėtumėte matyti tokius įrašus kaip RRSIG (kriptografiniai parašai), DNSKEY (viešieji raktai) ir DS (DNSKEY maišos kodas pagrindinėje zonoje). Jei įrankis rodo, kad su įrašais nėra susieto skaitmeninio parašo, jūsų domenas bus laikomas „nepasirašytu“ arba „nesaugiu“.

Jei atlikus šį patikrinimą pastebėsite, kad jūsų domenas arba vietiniame tinkle naudojami DNS serveriai nenaudoja DNSSEC, patartina susisiekti su savo paslaugų teikėju arba interneto paslaugų teikėju ir paprašyti jį aktyvuoti. Jei jie nesiūlo šios parinkties, gali būti tinkamas metas apsvarstyti galimybę pereiti prie teikėjo , kuris palaiko DNSSEC patvirtinimą, taip padidinant tiek jūsų įmonės, tiek klientų saugumo lygį.

DNSSEC apribojimai: privatumas ir kiti aspektai

Nepaisant visų savo privalumų, DNSSEC nėra stebuklinga priemonė visoms DNS saugumo problemoms išspręsti. Pagrindinė problema yra ta, kad ji neužtikrina užklausų konfidencialumo . DNS paketai, net ir naudojant DNSSEC, vis tiek keliauja paprasto teksto formatu, todėl kiekvienas, turintis prieigą prie srauto (pavyzdžiui, neapsaugotame viešajame „Wi-Fi“ tinkle ), gali matyti, į kuriuos domenus yra užklausiama.

Taip pat nėra prieigos kontrolės ar specialios apsaugos nuo paslaugų teikimo trikdymo (DoS arba DDoS) atakų . Iš tiesų, pridėjus daugiau duomenų (parašų, raktų, papildomų įrašų), padidėja DNS atsakymų dydis, o tai gali būti panaudota amplifikacijos atakose, jei infrastruktūra nėra tinkamai sukonfigūruota ir apsaugota.

Kita vertus, DNSSEC sukelia tam tikrą operacinį sudėtingumą: reikia valdyti raktų poras , ZSK ir KSK turi būti keičiami, DS publikavimas pagrindinėje zonoje turi būti koordinuojamas ir turi būti užtikrinta, kad nebūtų neatitikimų, kurie nutrauktų pasitikėjimo grandinę. Šių procedūrų klaida gali sustabdyti domeno teisingą patvirtinimą ir sukelti akivaizdžius paslaugų sutrikimus.

Pačiame DNSSEC procese pranešimuose yra valdymo bitų (pvz., CD bitas užklausose ir AD bitas atsakymuose), kurie turi įtakos patvirtinimo atlikimui ir ataskaitų teikimui. Užpuolikas, galintis manipuliuoti šiais bitais nesaugioje aplinkoje, gali bandyti sumažinti rekursinio sprendiklio siūlomą apsaugą . Todėl rekomenduojama, kad ryšys tarp sprendiklių ir klientų, naudojančių DNSSEC, vyktų saugiais kanalais.

Nepaisant šių apribojimų, DNSSEC išlieka esminiu DNS autentiškumo ir vientisumo stiprinimo komponentu. Tačiau norint žengti dar vieną žingsnį ir užtikrinti užklausų konfidencialumą, būtina jį derinti su kitomis technologijomis arba vystytis link pažangesnių sprendimų.

E-DNSSEC: link autentifikuoto ir užšifruoto DNS

Siekiant išspręsti DNSSEC paliktą privatumo spragą, buvo pasiūlyta E-DNSSEC (užšifruoto DNSSEC) koncepcija . Šio metodo idėja – pridėti šifravimą prie DNSSEC užklausų, kad jos būtų ne tik autentifikuojamos ir pasirašomos, bet ir apsaugotos nuo trečiųjų šalių patikrinimo keliaujant internetu ar vietiniame tinkle.

E-DNSSEC tikslas – sujungti DNSSEC savybes (autentiškumą ir vientisumą) su šifravimo mechanizmais, kurie užtikrina užklausų tarp DNSSEC kliento ir DNSSEC serverio konfidencialumą . Tai padidina bendrą DNS paslaugos saugumą, neleisdama išoriniams stebėtojams matyti, kurie domenų vardai yra sprendžiami.

Konceptualus procesas apimtų užklausos analizę rekursiniame serveryje, jos užšifravimą prieš siunčiant į autoritetingą serverį, o tada iššifravimą ir įprastą apdorojimą naudojant DNSSEC . Atsakymas, savo ruožtu, galėtų būti pasirašytas ir užšifruotas atgal į rekursinį serverį arba klientą, išlaikant konfidencialumą viso proceso metu.

Šis derinys užtikrintų, kad DNS pranešimas būtų apsaugotas nuo sprendimo proceso pradžios iki pabaigos: autentifikuotas ir vientisas dėl DNSSEC, o nuo smalsių akių – dėl papildomo šifravimo. Vietiniame arba įmonės tinkle tokį metodą būtų galima integruoti su kitais perimetro saugumo sprendimais.

Šiandien tokie pasiūlymai kaip E-DNSSEC yra platesnių pastangų stiprinti DNS privatumą dalis , kartu su tokiomis technologijomis kaip DNS per TLS (DoT) ir DNS per HTTPS (DoH). Pagrindinė kryptis aiški: ateities DNS turi būti autentiškas ir konfidencialus, ir nepakanka tiesiog greitai išspręsti vardus; tai taip pat turi būti daroma saugiai.

Aplinkoje, kurioje vyksta vis sudėtingesnės kibernetinės atakos, apsimetinėjimai ir grėsmės, nukreiptos prieš pagrindinę infrastruktūrą, DNSSEC jau yra svarbus bet kurio rimto domeno saugumo reikalavimas, o perėjimas prie šifruotų sprendimų, tokių kaip E-DNSSEC ar panašūs, tampa logišku kitu žingsniu siekiant dar labiau sustiprinti tinklų, įskaitant vietinius tinklus, apsaugą.

Visa ši ekosistema – nuo ​​klasikinio DNS iki DNSSEC ir užšifruotų sprendimų, tokių kaip E-DNSSEC, – rodo, kad DNS saugumas nėra pasirenkamas priedas, o esminis interneto architektūros ir bet kurio šiuolaikinio vietinio tinklo komponentas. Tikrinantys sprendikliai, pasirašytos zonos, gerai prižiūrimi pasitikėjimo grandiniai ir, ateityje, užšifruoti užklausų kanalai yra esminis skirtumas tarp pažeidžiamo tinklo ir infrastruktūros, paruoštos dabartiniams ir būsimiems iššūkiams.