ProHoster > blog > habari za mtandao > Kutolewa kwa BIND DNS Server 9.18.0 kwa kutumia DNS-over-TLS na DNS-over-HTTPS

Kutolewa kwa BIND DNS Server 9.18.0 kwa kutumia DNS-over-TLS na DNS-over-HTTPS

Baada ya miaka miwili ya maendeleo, muungano wa ISC umetoa toleo la kwanza thabiti la tawi jipya la seva ya BIND 9.18 DNS. Usaidizi kwa tawi la 9.18 utatolewa kwa miaka mitatu hadi robo ya 2 ya 2025 kama sehemu ya mzunguko uliopanuliwa wa usaidizi. Usaidizi kwa tawi la 9.11 utakamilika Machi, na uungwaji mkono kwa tawi la 9.16 katikati ya 2023. Ili kukuza utendakazi wa toleo thabiti linalofuata la BIND, tawi la majaribio la BIND 9.19.0 limeundwa.

Kutolewa kwa BIND 9.18.0 kunajulikana kwa utekelezaji wa usaidizi wa DNS kupitia HTTPS (DoH, DNS juu ya HTTPS) na DNS juu ya TLS (DoT, DNS juu ya TLS), pamoja na utaratibu wa XoT (XFR-over-TLS) kwa uhamishaji salama wa maudhui ya DNS. maeneo kati ya seva (zoni za kutuma na kupokea kupitia XoT zinatumika). Kwa mipangilio inayofaa, mchakato mmoja uliopewa jina sasa unaweza kutoa sio tu hoja za jadi za DNS, lakini pia hoja zinazotumwa kwa kutumia DNS-over-HTTPS na DNS-over-TLS. Usaidizi wa mteja kwa DNS-over-TLS umeundwa katika matumizi ya kuchimba, ambayo inaweza kutumika kutuma maombi kupitia TLS wakati alama ya "+tls" imebainishwa.

Utekelezaji wa itifaki ya HTTP/2 inayotumiwa katika DoH inategemea utumiaji wa maktaba ya nghttp2, ambayo imejumuishwa kama utegemezi wa hiari wa mkusanyiko. Vyeti vya DoH na DoT vinaweza kutolewa na mtumiaji au kuzalishwa kiotomatiki wakati wa kuanza.

Ombi la kuchakata kwa kutumia DoH na DoT limewezeshwa kwa kuongeza chaguo za "http" na "tls" kwenye maagizo ya kusikiliza. Ili kutumia DNS-over-HTTP ambayo haijasimbwa, unapaswa kubainisha "tls none" katika mipangilio. Vifunguo vimefafanuliwa katika sehemu ya "tls". Lango chaguomsingi za mtandao 853 za DoT, 443 za DoH na 80 za DNS-over-HTTP zinaweza kubatilishwa kupitia tls-port, https-port na vigezo vya http-port. Kwa mfano:

tls local-tls { key-file "/path/to/priv_key.pem"; cert-file "/path/to/cert_chain.pem"; }; http local-http-server { endpoints {"/dns-query"; }; }; chaguzi { https-bandari 443; listen-on port 443 tls local-tls http myserver {yoyote;}; }

Moja ya vipengele vya utekelezaji wa DoH katika BIND ni uwezo wa kuhamisha shughuli za usimbaji fiche za TLS hadi kwenye seva nyingine, ambayo inaweza kuwa muhimu katika hali ambapo vyeti vya TLS vinahifadhiwa kwenye mfumo mwingine (kwa mfano, katika miundombinu yenye seva za wavuti) na kudumishwa. na wafanyakazi wengine. Usaidizi wa DNS-over-HTTP ambayo haijasimbwa unatekelezwa ili kurahisisha utatuzi na kama safu ya kusambaza kwa seva nyingine kwenye mtandao wa ndani (kwa kuhamisha usimbaji fiche hadi seva tofauti). Kwenye seva ya mbali, nginx inaweza kutumika kutengeneza trafiki ya TLS, sawa na jinsi ufungaji wa HTTPS unavyopangwa kwa tovuti.

Kipengele kingine ni ujumuishaji wa DoH kama usafiri wa jumla ambao unaweza kutumika sio tu kushughulikia maombi ya mteja kwa kisuluhishi, lakini pia wakati wa kuwasiliana kati ya seva, wakati wa kuhamisha maeneo na seva iliyoidhinishwa ya DNS, na wakati wa kushughulikia maswali yoyote yanayoungwa mkono na DNS nyingine. husafirisha.

Miongoni mwa mapungufu ambayo yanaweza kulipwa kwa kuzima jengo na DoH/DoT au kuhamisha usimbuaji kwa seva nyingine, utata wa jumla wa msingi wa msimbo unaonekana wazi - seva ya HTTP iliyojengwa ndani na maktaba ya TLS huongezwa, ambayo inaweza kuwa na udhaifu na hufanya kama visambazaji vya ziada vya mashambulizi. Pia, unapotumia DoH, trafiki huongezeka.

Tukumbuke kwamba DNS-over-HTTPS inaweza kuwa na manufaa kwa kuzuia uvujaji wa taarifa kuhusu majina ya seva pangishi yaliyoombwa kupitia seva za DNS za watoa huduma, kupambana na mashambulizi ya MITM na uharibifu wa trafiki wa DNS (kwa mfano, wakati wa kuunganisha kwenye Wi-Fi ya umma), kukabiliana. kuzuia kwa kiwango cha DNS (DNS-over-HTTPS haiwezi kuchukua nafasi ya VPN katika kuzuia kuzuia kutekelezwa katika kiwango cha DPI) au kwa ajili ya kupanga kazi wakati haiwezekani kufikia seva za DNS moja kwa moja (kwa mfano, wakati wa kufanya kazi kupitia proksi). Ikiwa katika hali ya kawaida maombi ya DNS yanatumwa moja kwa moja kwa seva za DNS zilizofafanuliwa katika usanidi wa mfumo, basi katika kesi ya DNS-over-HTTPS ombi la kuamua anwani ya IP ya mwenyeji imefungwa kwenye trafiki ya HTTPS na kutumwa kwa seva ya HTTP, ambapo msuluhishi huchakata maombi kupitia API ya Wavuti.

"DNS juu ya TLS" inatofautiana na "DNS juu ya HTTPS" katika utumiaji wa itifaki ya kawaida ya DNS (mlango wa mtandao wa 853 kawaida hutumiwa), iliyofungwa katika njia iliyosimbwa ya mawasiliano iliyopangwa kwa kutumia itifaki ya TLS na ukaguzi wa uhalali wa mwenyeji kupitia vyeti vya TLS/SSL vilivyoidhinishwa. na mamlaka ya uthibitisho. Kiwango kilichopo cha DNSSEC kinatumia usimbaji fiche ili tu kuthibitisha mteja na seva, lakini hailindi trafiki dhidi ya kuingiliwa na haihakikishi usiri wa maombi.

Baadhi ya ubunifu mwingine:

  • Imeongeza mipangilio ya tcp-receive-bafa, tcp-send-bafa, udp-receive-bafa na udp-send-bafa mipangilio ili kuweka ukubwa wa vihifadhi vinavyotumika kutuma na kupokea maombi kupitia TCP na UDP. Kwenye seva zenye shughuli nyingi, kuongeza buffers zinazoingia zitasaidia kuzuia pakiti kudondoshwa wakati wa kilele cha trafiki, na kuzipunguza kutasaidia kuondoa kuziba kwa kumbukumbu na maombi ya zamani.
  • Kitengo kipya cha kumbukumbu "rpz-passthru" kimeongezwa, ambacho hukuruhusu kuweka kando vitendo vya usambazaji wa RPZ (Maeneo ya Sera ya Majibu).
  • Katika sehemu ya sera ya majibu, chaguo la "nsdname-wait-recurse" limeongezwa, likiwekwa kuwa "hapana", sheria za RPZ NSDNAME zitatumika tu ikiwa seva za majina zilizoidhinishwa zilizopo kwenye kache zinapatikana kwa ombi, vinginevyo ombi Sheria ya RPZ NSDNAME imepuuzwa, lakini maelezo yanarejeshwa chinichini na yanatumika kwa maombi yanayofuata.
  • Kwa rekodi zilizo na aina za HTTPS na SVCB, uchakataji wa sehemu ya "ADDITIONAL" umetekelezwa.
  • Imeongeza aina za sheria za usasishaji-sera maalum - krb5-subdomain-self-rhs na ms-subdomain-self-rhs, ambayo inakuruhusu kuweka kikomo usasishaji wa rekodi za SRV na PTR. Vizuizi vya sera ya sasisho pia huongeza uwezo wa kuweka vikomo kwa idadi ya rekodi, za kibinafsi kwa kila aina.
  • Taarifa iliyoongezwa kuhusu itifaki ya usafiri (UDP, TCP, TLS, HTTPS) na viambishi awali vya DNS64 kwenye towe la matumizi ya kuchimba. Kwa madhumuni ya utatuzi, dig imeongeza uwezo wa kubainisha kitambulisho maalum cha ombi (dig +qid= )
  • Usaidizi ulioongezwa kwa maktaba ya OpenSSL 3.0.
  • Ili kushughulikia masuala na mgawanyiko wa IP wakati wa kuchakata ujumbe mkubwa wa DNS unaotambuliwa na Siku ya Bendera ya DNS 2020, msimbo unaorekebisha ukubwa wa bafa ya EDNS wakati hakuna jibu kwa ombi umeondolewa kwenye kitatuzi. Saizi ya bafa ya EDNS sasa imewekwa kuwa ya kawaida (edns-udp-size) kwa maombi yote yanayotoka.
  • Mfumo wa kujenga umebadilishwa kwa kutumia mchanganyiko wa autoconf, automake na libtool.
  • Usaidizi wa faili za eneo katika umbizo la "ramani" (ramani ya umbizo la faili kuu) umekatishwa. Watumiaji wa umbizo hili wanapendekezwa kubadilisha kanda hadi umbizo mbichi kwa kutumia matumizi ya eneo-compilezone.
  • Usaidizi kwa viendeshi vya zamani vya DLZ (Eneo Zinazoweza Kupakia Zinazoweza Kupakia) umekatishwa, na nafasi yake kuchukuliwa na moduli za DLZ.
  • Usaidizi wa kujenga na kuendesha kwa jukwaa la Windows umekatishwa. Tawi la mwisho ambalo linaweza kusakinishwa kwenye Windows ni BIND 9.16.

Chanzo: opennet.ru

Kuongeza maoni