DNSSEC at seguridad ng DNS sa iyong lokal na network

Informatec Digital » Kayamanan » DNSSEC at seguridad ng DNS sa iyong lokal na network

Ang internet ay binuo sa ilang mahahalagang bahagi na halos hindi natin nakikita, ngunit naroon sa tuwing magbubukas tayo ng browser. Isa sa pinakamahalaga ay ang Domain Name System (DNS), at kapag pinag-uusapan natin ang DNSSEC at seguridad sa isang lokal na network , ang tinutukoy natin ay ang pagpapatibay ng pundasyong iyon upang maiwasan ang mga mapanlinlang na pag-redirect, spoofing, at iba pang malubhang pag-atake.

Dati, ang prayoridad ay ang pagtiyak lamang na gumagana ang lahat; ngayon alam natin na hindi sapat iyon. Ang DNS ay isinilang noong dekada 80 nang hindi isinasaalang-alang ang malawakang pag-atake sa cyber, ngunit ngayon kailangan natin ito hindi lamang upang lutasin ang mga pangalan kundi pati na rin patunayan ang pagiging tunay at integridad ng bawat tugon . Diyan pumapasok ang DNSSEC, at kamakailan lamang, ang mga panukala tulad ng E-DNSSEC, na naglalayong magdagdag din ng pagiging kompidensiyal—isang mahalagang salik kung nag-aalala ka tungkol sa seguridad ng iyong lokal o korporasyong network.

Ano ang DNS at bakit ito napakahalaga para sa seguridad?

Ang Domain Name System (DNS ) ay ang phone book ng internet: isinasalin nito ang mga pangalang madaling tandaan (tulad ng www.example.com) sa mga numerical IP address na naiintindihan ng mga computer (halimbawa, 192.168.2.15 o isang IPv6 address). Kung wala ang mekanismong ito, kakailanganin nating isaulo ang mga numero sa halip na mga pangalan, na talagang hindi praktikal.

Ang imprastrakturang ito ay nakaayos bilang isang distributed database sa isang tree structure , na may root zone sa itaas, na sinusundan ng mga top-level domain (mga TLD tulad ng .es, .com, .org), at sa ibaba nito, mga domain at subdomain. Ang bawat bahagi ng database na ito ay tinatawag na " zone " at naka-host sa isa o higit pang mga authoritative name server, na naglalathala ng "opisyal" na impormasyon para sa bawat domain.

Kapag gustong mag-access ng website ang iyong computer, mobile phone, o anumang iba pang device, nagsisimula ito sa pamamagitan ng pag-query sa isang stub resolver , na bahagi ng operating system. Ipinapadala ng resolver na ito ang query sa isang recursive DNS server (karaniwan ay sa iyong internet service provider, sa iyong kumpanya, o sa isang pampublikong server tulad ng Google Public DNS , OpenDNS, o Quad9). Pagkatapos, hahanapin ng recursive server na ito ang sagot sa pamamagitan ng pag-query sa ilang authoritative server hanggang sa matagpuan nito ang tamang IP address.

Nililinis ng mga recursive resolver ang mga tugon na natatanggap nila upang mapabilis ang mga kasunod na query. Ito ay lubos na mabisa, ngunit nagbubukas din ito ng pinto para sa isang attacker na "lasunin ang DNS cache" at maglagay ng maling data , kaya maraming kasunod na kahilingan ang nareresolba gamit ang minamanipulang impormasyong ito nang hindi napapansin ng user.

Ang pangunahing problema ay, sa orihinal nitong disenyo, ang DNS ay walang matibay na paraan upang beripikahin ang pagiging tunay ng mga tugon . Sinusuri ng resolver na ang tugon ay tila nagmumula sa parehong IP address na kino-query nito, ngunit ang pinagmulang IP address na iyon ay maaaring madaling ma-spoof. Nagbibigay-daan ito para sa tahimik na pag-redirect ng mga pag-atake sa mga mapanlinlang na site na gumagaya, halimbawa, sa website ng iyong bangko.

Mga limitasyon sa seguridad ng tradisyonal na DNS

Ang DNS protocol ay nilikha noong panahon na ang seguridad ay hindi pa pangunahing pinag-aalala. Kaya naman alam na natin ngayon na ang mga DNS query at tugon ay naglalakbay sa plain text , nang walang encryption, at ang record data ay maaaring pekein nang walang karagdagang proteksyon.

Nagbubukas ito ng pinto sa ilang uri ng pag-atake, lalo na ang DNS cache poisoning at man-in-the-middle attacks. Sa parehong kaso, ang attacker ay naglalagay ng mga pekeng tugon sa proseso, na nagiging sanhi ng pagkapunta ng mga user sa mga website na nasa ilalim ng kanilang kontrol nang hindi napapansin ang anumang kakaiba, dahil ang domain name na ipinapakita sa browser ay nananatiling lehitimo.

Isipin mong ina-access mo ang website ng iyong bangko: hinihiling ng iyong computer ang domain IP address ng bangko mula sa recursive server, ngunit nilinlang ng isang attacker ang server para tumanggap ng pekeng tugon na may IP address ng isang kaparehong website na kontrolado nila . Inilalagay ng user ang kanilang mga kredensyal, sa pag-aakalang normal ang lahat, at natatanggap ito ng cybercriminal sa plain text para magamit sa totoong site sa ibang pagkakataon.

Ang mga mekanismo tulad ng Transaction Signatures (TSIG) , na tinukoy sa RFC 2845, ay nagsisilbing protektahan ang ilang partikular na operasyon sa pagitan ng mga DNS server (halimbawa, mga zone transfer sa pagitan ng mga master at slave server at mga dynamic update). Pinapayagan ng TSIG ang dalawang makinang nagbabahagi ng isang secret key na beripikahin ang pagkakakilanlan ng kabilang dulo at ang integridad ng mga mensaheng ipinapadala.

Gayunpaman, limitado lamang ang saklaw ng TSIG: hindi nito pinapatunayan ang "tunay" na pinagmulan ng datos ng DNS ; tinitiyak lamang nito na ang palitan sa pagitan ng dalawang partikular na server ay hindi napakialaman. Kung ang orihinal na impormasyon sa isang zone ay nakompromiso o namanipula na bago pa man makarating sa mga server na iyon, hindi ito matutukoy ng TSIG. Samakatuwid, bagama't karaniwang ginagamit ito para sa mga paglilipat ng zone, hindi nito nalulutas ang pinagbabatayang problema ng pagiging tunay ng nailathalang datos ng DNS.

Ano ang DNSSEC at ano ang naidudulot nito sa seguridad?

Bilang tugon sa lahat ng mga kahinaang ito, binuo ang mga Domain Name System Security Extensions (DNSSEC) . Hindi pinapalitan ng DNSSEC ang klasikong DNS, sa halip ay pinalalawak ito ng isang patong ng seguridad na nagbibigay-daan sa pagpapatunay na ang natanggap na datos ay lehitimo at hindi binago.

Ang DNSSEC ay batay sa public-key cryptography (asymmetric cryptography) . Ang bawat DNS zone ay may pares ng susi: isang private key, na pinananatiling lihim, at isang public key, na inilalathala mismo sa DNS server. Ginagamit ng may-ari ng zone ang private key upang digital na lagdaan ang mga talaan sa zone na iyon; ang public key ay ginagamit upang i-verify ang mga lagdang iyon.

Kapag ang isang recursive server ay nag-query sa isang domain gamit ang DNSSEC, kasama ang karaniwang impormasyon (halimbawa, ang IP address na nauugnay sa isang pangalan), natatanggap din nito ang mga digital signature at public key na kinakailangan para sa pagpapatunay . Pinapatunayan ng recursive server ang mga lagda laban sa mga nai-publish na public key; kung matagumpay ang pagpapatunay, ang data ay itinuturing na tunay at hindi nagbago simula nang ito ay nilagdaan.

Kung mabigo ang pagpapatunay, mauunawaan ng resolver na may mali (halimbawa, isang tangkang panggagaya o pakikialam habang ipinapadala) at tutugon sa client gamit ang isang error code, karaniwang SERVFAIL . Sa ganitong paraan, hindi makakatanggap ang user ng potensyal na malisyosong data, bagama't mula sa kanilang pananaw, ang makikita lang nila ay "hindi naglo-load" o nagpapakita ng error ang pahina.

Ipinakikilala rin ng DNSSEC ang konsepto ng isang chain of trust , na gumagamit ng umiiral na hierarchy ng DNS. Ang root zone ay pumipirma sa mga key ng mga top-level domain (tulad ng .es, .com), ang mga ito naman ay pumipirma sa mga key ng kanilang mga child domain, at iba pa, upang ang anumang domain ay ma-validate gamit ang isang punto ng trust: ang public key ng root zone.

Mga susi, rekord, at kadena ng tiwala ng KSK at ZSK

Para mas maayos na maisaayos ang seguridad, gumagamit ang DNSSEC ng dalawang magkaibang uri ng susi: ang Key Signing Key (KSK) at ang Zone Signing Key (ZSK) . Bagama't teknikal na magkapareho ang mga ito (sa kriptograpiya), magkaiba ang kanilang tungkulin sa loob ng sistema.

Ang ZSK key ay ginagamit upang lagdaan ang lahat ng resource record sa zone (A, AAAA, MX, atbp.). Karaniwan itong madalas na iniikot upang mabawasan ang panganib, dahil ang anumang paglabag sa key na ito ay makakaapekto sa lahat ng record sa zone. Ang KSK, sa kabilang banda, ay pangunahing ginagamit upang lagdaan ang zone key (ZSK) mismo, at ang hash nito ay inilalathala bilang DS (Delegation Signer) record sa parent zone.

Dahil sa paghihiwalay ng mga tungkulin, mas simple na ang pagpapalit ng ZSK: bumuo lang ng bagong ZSK, pirmahan ito gamit ang KSK, i-publish ito sa mga DNSKEY record ng zone, at hayaang i-update ng mga resolver ang kanilang impormasyon. Hindi na kailangang hawakan ang parent zone, dahil patuloy na nakaturo ang DS sa parehong KSK, na nananatiling matatag nang mas matagal.

Nagdaragdag ang DNSSEC ng ilang uri ng mga partikular na tala sa DNS protocol, na idinisenyo upang suportahan ang paglagda at pagpapatunay ng datos. Kabilang sa mga pinakamahalaga ay ang DNSKEY, RRSIG, DS, NSEC/NSEC3, at NSEC3PARAM . Ang lahat ng ito ay nagbibigay-daan sa iyong bumuo ng lohika ng pagpapatotoo nang hindi binabago ang pangunahing operasyon ng mga query.

Iniimbak ng DNSKEY record ang public key ng zone , na kinakailangan upang mapatunayan ang mga lagda. Ang RRSIG record ay naglalaman ng digital signature na nauugnay sa isang partikular na hanay ng mga tala (isang "Resource Record Set"). Ang DS record ay isang hash ng DNSKEY ng child zone, na inilalathala sa parent zone at nagsisilbing link sa chain of trust.

Ang mga rekord ng NSEC at NSEC3 ay ginagamit upang magbigay ng awtentikadong pagtanggi sa pag-iral ; ibig sabihin, upang patunayan sa pamamagitan ng kriptograpiko na ang isang pangalan ng domain o rekord ay hindi umiiral, na pumipigil sa mga pag-atake na nagtatangkang maglagay ng mga maling tugon na nagpapahiwatig na ang isang bagay ay hindi umiiral gayong ito ay umiiral (o kabaliktaran).

Kadena ng tiwala at pagpapatunay ng tugon ng DNSSEC

Ang tinatawag na chain of trust sa DNSSEC ay binubuo sa pamamagitan ng pag-uugnay ng mga DNSKEY at DS record mula sa root patungo sa domain na gusto nating i-validate . Ang panimulang punto ay ang public key ng root zone, na gumaganap bilang trust anchor at karaniwang direktang kino-configure sa mga recursive resolver.

Halimbawa, kung gusto mong i-validate ang isang domain tulad ng mywebsite.es, ang lohikal na proseso ay magiging: pinagkakatiwalaan ng resolver ang public key ng root, na siyang pipirma sa .es key; inilalathala ng .es zone ang isang DS record na katumbas ng mywebsite.es KSK key; sa pamamagitan ng pag-validate sa DS na iyon gamit ang .es key, pinagkakatiwalaan ng resolver ang mywebsite.es DNSKEY at, mula roon, maaaring i-verify ang mga RRSIG sa lahat ng record nito.

Kung may nawawalang wastong lagda sa anumang punto sa kadena, o kung wala ang DS (Data Signature) kung saan ito dapat naroroon, masisira ang kadena ng tiwala. Sa ganitong kaso, hindi itinuturing ng recursive server na nagsasagawa ng pagpapatunay na ligtas ang datos at, depende sa configuration nito, hindi tutugon gamit ang hiniling na mga rekord o minamarkahan ang tugon bilang hindi wasto.

Ang hierarchical na ugnayang ito ay nangangahulugan din na, para maging tunay na epektibo ang DNSSEC, hindi sapat na lagdaan lamang ang iyong zone : ang parent zone (halimbawa, .es) at ang root zone ay dapat ding lagdaan at mailathala nang tama ang kanilang mga DNS record. Sa kasalukuyan, ang DNS root zone at halos lahat ng generic top-level domains (gTLDs) at maraming country code top-level domains (ccTLDs) ay nilagdaan na.

Kapag nakita ng isang recursive server na may naka-enable na DNSSEC validation na hindi tugma ang signature o may nawawalang link, ang tugon na ibinabalik nito sa client ay karaniwang may kasamang RCODE SERVFAIL error code. Maaari itong maging nakakalito para sa end user ("hindi gumagana ang website"), ngunit mula sa pananaw ng seguridad, ito ay isang proteksiyon laban sa posibleng manipuladong data.

Ipinakikilala rin ng DNSSEC ang dalawang pangunahing tampok: data origin authentication , na nagbibigay-daan sa pag-verify na ang mga rekord ay talagang nagmula sa inaasahang sona, at proteksyon sa integridad , na tinitiyak na ang impormasyon ay hindi nabago simula nang ito ay pirmahan ng may-ari ng sona gamit ang kanilang pribadong susi.

Mga pag-atakeng pinagaan ng DNSSEC at ang kanilang kaugnayan sa TLS/HTTPS

Ang pagpapatupad ng DNSSEC ay nakakatulong na maprotektahan laban sa ilang karaniwang banta. Una, ginagawang lubhang mahirap ang DNS response spoofing , dahil ang attacker ay kailangang bumuo ng mga wastong lagda nang hindi nalalaman ang pribadong key ng zone, na imposibleng cryptography kung ang mga key ay pinamamahalaan nang tama.

Bukod pa rito, binabawasan ng DNSSEC ang panganib ng cache poisoning sa mga recursive server sa pamamagitan ng pagpigil sa pagtanggap ng mga manipuladong tugon na hindi sumasailalim sa signature validation. Pinapakomplikado rin nito ang mga man-in-the-middle (MITM) na pag-atake sa trapiko ng DNS, kung saan binabago ng isang attacker ang mga tugon habang isinasagawa: kung ang tugon ay hindi sumasailalim sa validation, itatapon ito ng resolver.

Mahalagang maunawaan, gayunpaman, kung ano ang hindi nagagawa ng DNSSEC. Ang mga extension na ito ay hindi idinisenyo upang i-encrypt ang nilalaman ng mga query o tugon . Lahat ng trapiko ng DNS, kahit na may DNSSEC, ay naglalakbay pa rin sa plain text maliban kung gumagamit ka ng iba pang mga komplementaryong teknolohiya (tulad ng DoT, DoH, o mga solusyon na uri ng E-DNSSEC). Nakatuon ang DNSSEC sa pagtiyak na ang iyong natatanggap ay tunay at hindi binago, hindi sa pagtatago ng iyong hinihiling.

Malinaw na pinagkaiba ito ng mga protocol tulad ng TLS at HTTPS . Bagama't ine-encrypt ng HTTPS ang trapiko sa pagitan ng browser at ng web server upang maiwasan ang mga ikatlong partido sa pag-espiya o pagbabago ng komunikasyon, nilalagdaan lamang ng DNSSEC ang data ng DNS upang matukoy ang spoofing. Ang isang site ay maaaring magkaroon ng HTTPS nang walang DNSSEC o DNSSEC nang walang HTTPS, ngunit ang kombinasyon ng pareho ay nag-aalok ng mas komprehensibong proteksyon laban sa spoofing at pag-eespiya.

Matagal nang itinataguyod ng mga organisasyong tulad ng ICANN at IETF ang malawakang pag-aampon ng DNSSEC ng mga registry, registrar, ISP, at mga operator ng network. Ang layunin ay para sa mas maraming zone na mapirmahan at para sa mas maraming resolver na aktibong mag-validate sa mga ito, upang ang karaniwang gumagamit ay makinabang mula sa mga garantiyang kriptograpikong ito nang hindi gumagawa ng anumang espesyal na aksyon.

DNSSEC sa mga .es domain at mga obligasyon ng may-ari

Sa partikular na kaso ng Espanya, ang yunit ng ".es" Domains na pinamamahalaan ng Red.es ay matagal nang nagsasama ng mga karagdagang teknolohiya at pamamaraan upang mapabuti ang kalidad at seguridad ng serbisyo ng DNS sa ilalim ng .es country code. Kabilang sa mga hakbang na ito ay ang pagpapatupad ng isang protocol ng seguridad ng DNSSEC alinsunod sa mga detalye ng IETF.

Ang mga .es domain ang may pananagutan sa paglagda sa .ES top-level zone at pagkuha ng awtorisasyon mula sa DNS root, sa gayon ay maisasama sa pandaigdigang kadena ng tiwala. Nangangahulugan ito na kung nagmamay-ari ka ng .es domain, maaari mong gamitin ang imprastrakturang ito upang ma-secure ang iyong sariling domain gamit ang DNSSEC.

Bilang may-ari ng domain, ang pangkalahatang pamamaraan para sa pagpapagana ng DNSSEC ay kinabibilangan ng pagtiyak na ilalathala ng iyong mga awtoritatibong DNS server ang signed zone. Kadalasan, kinabibilangan ito ng pagbuo ng public key para sa iyong zone, pagpirma sa mga record, paglalathala ng DNS key, at pagkatapos ay pagsusumite ng key material (o ang DS record mismo) sa registry o sa iyong registrar upang makalikha sila ng kaukulang DS record sa parent zone.

Sa pagsasagawa, maraming DNS hosting provider at registrar ang nag-aalok na ng medyo simpleng opsyon para paganahin ang DNSSEC, minsan ay kasingdali lang ng paglalagay ng tsek sa isang kahon sa control panel. Gayunpaman, maaaring may maliit na taunang gastos na kaugnay ng functionality na ito, depende sa provider at antas ng serbisyo.

Kapag nalagdaan na ang zone at matagumpay na nai-publish ang Domain Name System (DNS), ang iyong domain ay magiging bahagi ng DNSSEC chain of trust. Mula sa sandaling iyon, ang mga DNS resolution para sa iyong domain ay maaaring i-cryptographyly validate ng mga resolver na may naka-enable na DNSSEC validation, na nagpapataas ng tiwala ng user at binabawasan ang panganib ng mga spoofing attack.

DNSSEC sa lokal na network: pagpapatunay sa panig ng gumagamit

Mula sa pananaw ng isang end user o isang kumpanyang nag-aalala tungkol sa seguridad ng lokal na network nito, ang pangunahing tanong ay: ano ang kailangan para makinabang mula sa DNSSEC? Ang magandang balita ay hindi mo kailangang i-configure ang kahit ano sa bawat computer nang paisa-isa , hangga't ang iyong recursive DNS server (ang ginagamit ng iyong mga computer) ay nagpapatunay sa DNSSEC.

Para magawa ito, ang kailangan mo lang ay magkaroon ang iyong DNS provider (iyong ISP, isang pampublikong resolver, o internal DNS ng iyong organisasyon) ng recursive server na may naka-enable at maayos na na-configure na DNSSEC validation . Halos lahat ng modernong resolver ay matagal nang sumusuporta sa DNSSEC; ang pag-enable nito ay karaniwang nangangailangan lamang ng ilang pagbabago sa kanilang configuration file at pagdaragdag ng root trust anchor.

Kapag na-enable na ang validation, kapag ang isa sa iyong mga computer sa lokal na network ay nag-query sa isang signed domain, beripikahin ng recursive resolver ang lahat ng signature at ang chain of trust bago ibalik ang tugon. Kung may anumang hindi tugma, wala itong ibabalik na record, at makakakita ang user ng error, na epektibong pumipigil sa kanila na kumonekta sa isang potensyal na mapanlinlang na site.

Para masuri kung ang iyong domain ay protektado ng DNSSEC, mayroong ilang online tool na magagamit, tulad ng DNSSEC Analyzer at iba pang mga utility sa pagpapatunay . Kapag ipinasok mo ang iyong domain, dapat mong makita ang mga record tulad ng RRSIG (mga cryptographic signature), DNSKEY (mga pampublikong key), at DS (hash ng DNSKEY sa parent zone). Kung ipinapahiwatig ng tool na walang digital signature na nauugnay sa mga record, ang iyong domain ay ituturing na "unsigned" o "insecure."

Kung, pagkatapos ng pagsusuring ito, matuklasan mong hindi ginagamit ng iyong domain o ng mga DNS server na ginagamit mo sa iyong lokal na network ang DNSSEC, ipinapayong makipag-ugnayan sa iyong service provider o ISP upang humiling ng pag-activate nito. Kung hindi nila inaalok ang opsyong ito, maaaring magandang panahon na isaalang-alang ang paglipat sa isang provider na sumusuporta sa pagpapatunay ng DNSSEC, sa gayon ay pinapataas ang antas ng seguridad para sa iyong kumpanya at sa iyong mga customer.

Mga Limitasyon ng DNSSEC: privacy at iba pang aspeto

Sa kabila ng lahat ng bentahe nito, ang DNSSEC ay hindi isang mahiwagang solusyon para sa lahat ng problema sa seguridad ng DNS. Ang isang pangunahing isyu ay hindi nito ibinibigay ang pagiging kumpidensyal ng query . Ang mga DNS packet, kahit na may DNSSEC, ay naglalakbay pa rin sa plain text, kaya makikita ng sinumang may access sa trapiko (halimbawa, sa isang hindi secure na pampublikong Wi-Fi network ) kung aling mga domain ang kinukuwestiyon.

Wala rin itong iniaalok na access control o partikular na depensa laban sa mga denial-of-service (DoS o DDoS) na pag-atake . Sa katunayan, sa pamamagitan ng pagdaragdag ng mas maraming data (mga lagda, key, karagdagang mga tala), pinapataas nito ang laki ng mga tugon ng DNS, na maaaring magamit sa mga amplification attack kung ang imprastraktura ay hindi maayos na na-configure at protektado.

Sa kabilang banda, ang DNSSEC ay nagpapakilala ng ilang komplikasyon sa operasyon: dapat pamahalaan ang mga key pair , dapat i-rotate ang ZSK at KSK, dapat i-coordinate ang paglalathala ng DS sa parent zone , at dapat tiyakin na walang mga hindi pagkakatugma na makakasira sa kadena ng tiwala. Ang isang error sa mga pamamaraang ito ay maaaring maging sanhi ng paghinto ng wastong pag-validate ng isang domain, na magdudulot ng maliwanag na mga pagkawala ng serbisyo.

Sa loob mismo ng proseso ng DNSSEC, may mga control bit sa mga mensahe (tulad ng CD bit sa mga query at AD bit sa mga tugon) na nakakaimpluwensya sa kung paano isinasagawa at iniuulat ang pagpapatunay. Ang isang attacker na maaaring manipulahin ang mga bit na ito sa isang hindi ligtas na kapaligiran ay maaaring subukang sirain ang proteksyong iniaalok ng isang recursive resolver. Samakatuwid, inirerekomenda na ang komunikasyon sa pagitan ng mga resolver at mga kliyente na gumagamit ng DNSSEC ay maganap sa pamamagitan ng mga secure na channel.

Sa kabila ng mga limitasyong ito, ang DNSSEC ay nananatiling isang mahalagang bahagi para sa pagpapalakas ng pagiging tunay at integridad ng DNS. Gayunpaman, upang higit pang makahakbang at magarantiya ang pagiging kumpidensyal ng mga query, kinakailangang pagsamahin ito sa iba pang mga teknolohiya o umunlad patungo sa mas advanced na mga solusyon.

E-DNSSEC: Tungo sa isang napatotohanan at naka-encrypt na DNS

Upang matugunan ang kakulangan sa privacy na iniwan ng DNSSEC, iminungkahi ang konsepto ng E-DNSSEC (DNSSEC encrypted) . Ang ideya sa likod ng pamamaraang ito ay ang pagdaragdag ng encryption sa mga query ng DNSSEC upang, bukod sa pagiging authenticated at nalagdaan, maprotektahan din ang mga ito mula sa inspeksyon ng ikatlong partido habang naglalakbay sa internet o sa pamamagitan ng lokal na network.

Ang layunin ng E-DNSSEC ay pagsamahin ang mga katangian ng DNSSEC (pagiging tunay at integridad) sa mga mekanismo ng pag-encrypt na nagbibigay ng pagiging kumpidensyal para sa mga query sa pagitan ng DNSSEC client at ng DNSSEC server . Pinapataas nito ang pangkalahatang seguridad ng serbisyo ng DNS, na pumipigil sa mga panlabas na tagamasid na makita kung aling mga domain name ang nireresolba.

Ang konseptwal na proseso ay kinabibilangan ng pagsusuri ng query sa recursive server, pag-encrypt nito bago ipadala sa awtoritatibong server, at pagkatapos ay pag-decrypt at pagproseso nito nang normal gamit ang DNSSEC . Ang tugon, naman, ay maaaring ibalik nang may lagda at i-encrypt pabalik sa recursive server o sa client, na pinapanatili ang pagiging kumpidensyal sa buong proseso.

Titiyakin ng kombinasyong ito na ang mensahe ng DNS ay ligtas mula simula hanggang katapusan ng proseso ng paglutas: napatotohanan at may integridad salamat sa DNSSEC, at protektado mula sa mga mapanlinlang na mata salamat sa karagdagang pag-encrypt. Sa konteksto ng lokal o enterprise network, ang ganitong pamamaraan ay maaaring maisama sa iba pang mga solusyon sa perimeter security.

Sa kasalukuyan, ang mga panukala tulad ng E-DNSSEC ay bahagi ng mas malawak na pagsisikap na palakasin ang privacy ng DNS , kasama ang mga teknolohiyang tulad ng DNS over TLS (DoT) at DNS over HTTPS (DoH). Malinaw ang pinagbabatayang direksyon: ang DNS ng hinaharap ay dapat na parehong tunay at kumpidensyal, at hindi sapat ang simpleng mabilis na paglutas ng mga pangalan; dapat din itong gawin nang ligtas.

Sa isang kapaligirang kung saan parami nang parami ang mga sopistikadong cyberattack, panggagaya, at mga banta na tumatarget sa mga pangunahing imprastraktura, ang pagkakaroon ng DNSSEC ay isa nang mahalagang kinakailangan sa seguridad para sa anumang seryosong larangan, at ang paglipat patungo sa mga naka-encrypt na solusyon tulad ng E-DNSSEC o katulad nito ay umuusbong bilang isang lohikal na susunod na hakbang upang higit pang palakasin ang proteksyon ng mga network, kabilang ang mga lokal na network.

Ang buong ecosystem na ito—mula sa klasikong DNS hanggang sa DNSSEC at mga naka-encrypt na solusyon tulad ng E-DNSSEC—ay nagpapakita na ang seguridad ng DNS ay hindi isang opsyonal na karagdagan, kundi isang pangunahing bahagi ng arkitektura ng internet at anumang modernong local area network. Ang pagkakaroon ng mga resolver na nagpapatunay, mga nilagdaang zone, maayos na pinapanatiling mga kadena ng tiwala, at, sa hinaharap, mga naka-encrypt na channel para sa mga query, ay gumagawa ng malaking pagkakaiba sa pagitan ng isang nakalantad na network at isang imprastraktura na inihanda para sa kasalukuyan at hinaharap na mga hamon.

Kaugnay na artikulo:

Paano paganahin ang DNS sa pamamagitan ng HTTPS (DoH) sa Windows 11 at pagbutihin ang iyong privacy