Pagkatapos ng isang taon at kalahati ng pag-unlad paglabas ng cache ng DNS server , responsable para sa recursive na pagpapalit ng pangalan. Ang PowerDNS Recursor ay binuo sa parehong code base tulad ng PowerDNS Authoritative Server, ngunit ang PowerDNS recursive at authoritative DNS server ay binuo sa pamamagitan ng iba't ibang mga development cycle at inilabas bilang magkahiwalay na mga produkto. Code ng proyekto lisensyado sa ilalim ng GPLv2.
Tinatanggal ng bagong bersyon ang lahat ng isyu na nauugnay sa pagproseso ng mga DNS packet na may mga flag ng EDNS. Ang mga mas lumang bersyon ng PowerDNS Recursor bago ang 2016 ay nagkaroon ng kasanayan na huwag pansinin ang mga packet na may hindi sinusuportahang mga flag ng EDNS nang hindi nagpapadala ng tugon sa lumang format, na itinatapon ang mga flag ng EDNS ayon sa kinakailangan ng detalye. Noong nakaraan, ang hindi karaniwang pag-uugaling ito ay sinusuportahan sa BIND sa anyo ng isang solusyon, ngunit sa loob ng saklaw ng sa mga inisyatiba ng Pebrero , nagpasya ang mga developer ng DNS server na iwanan ang hack na ito.
Sa PowerDNS, ang mga pangunahing problema sa pagproseso ng mga packet na may EDNS ay inalis noong 2017 sa release 4.1, at sa 2016 branch na inilabas noong 4.0, ang mga indibidwal na hindi pagkakatugma ay lumitaw na lumitaw sa ilalim ng isang tiyak na hanay ng mga pangyayari at, sa pangkalahatan, ay hindi nakakasagabal sa normal. operasyon. Sa PowerDNS Recursor 4.2, tulad ng sa , Inalis ang mga workaround upang suportahan ang mga authoritative server na maling tumugon sa mga kahilingan gamit ang mga flag ng EDNS. Hanggang ngayon, kung pagkatapos magpadala ng kahilingan na may mga flag ng EDNS ay walang tugon pagkatapos ng isang tiyak na tagal ng panahon, ipinapalagay ng DNS server na ang mga pinalawig na flag ay hindi suportado at nagpadala ng pangalawang kahilingan nang walang mga flag ng EDNS. Na-disable na ngayon ang pag-uugaling ito dahil nagresulta ang code na ito sa tumaas na latency dahil sa mga muling pagpapadala ng packet, tumaas na pag-load ng network at kalabuan kapag hindi tumutugon dahil sa mga pagkabigo sa network, at pumigil sa pagpapatupad ng mga feature na nakabatay sa EDNS gaya ng DNS Cookies upang maprotektahan laban sa mga pag-atake ng DDoS.
Napagpasyahan na isagawa ang kaganapan sa susunod na taon dinisenyo upang ituon ang pansin sa na may IP fragmentation kapag nagpoproseso ng malalaking DNS message. Bilang bahagi ng inisyatiba ayusin ang inirerekomendang laki ng buffer para sa EDNS hanggang 1200 bytes, at ang pagpoproseso ng mga kahilingan sa pamamagitan ng TCP ay isang kailangang-kailangan na tampok sa mga server. Ngayon ang suporta para sa pagproseso ng mga kahilingan sa pamamagitan ng UDP ay kinakailangan, at ang TCP ay kanais-nais, ngunit hindi kinakailangan para sa operasyon (ang pamantayan ay nangangailangan ng kakayahang huwag paganahin ang TCP). Iminumungkahi na alisin ang opsyon na huwag paganahin ang TCP mula sa pamantayan at i-standardize ang paglipat mula sa pagpapadala ng mga kahilingan sa UDP hanggang sa paggamit ng TCP sa mga kaso kung saan ang itinatag na laki ng buffer ng EDNS ay hindi sapat.
Ang mga pagbabagong iminungkahi bilang bahagi ng inisyatiba ay mag-aalis ng kalituhan sa pagpili ng laki ng buffer ng EDNS at malulutas ang problema ng pagkapira-piraso ng malalaking mensahe ng UDP, na ang pagproseso nito ay kadalasang humahantong sa pagkawala ng packet at pag-timeout sa panig ng kliyente. Sa panig ng kliyente, ang laki ng buffer ng EDNS ay magiging pare-pareho at ang malalaking tugon ay ipapadala kaagad sa kliyente sa pamamagitan ng TCP. Ang pag-iwas sa pagpapadala ng malalaking mensahe sa UDP ay magbibigay-daan din sa iyong mag-block para sa pagkalason sa cache ng DNS, batay sa pagmamanipula ng mga pira-pirasong UDP packet (kapag nahati sa mga fragment, ang pangalawang fragment ay hindi kasama ang isang header na may isang identifier, kaya maaari itong mapeke, kung saan ito ay sapat lamang para sa checksum upang tumugma) .
Isinasaalang-alang ng PowerDNS Recursor 4.2 ang mga problema sa malalaking UDP packet at lumipat sa paggamit ng EDNS buffer size (edns-outgoing-bufsize) na 1232 bytes, sa halip na ang dating ginamit na limitasyon na 1680 bytes, na dapat makabuluhang bawasan ang posibilidad na mawala ang mga UDP packet . Napili ang value na 1232 dahil ito ang maximum kung saan ang laki ng tugon ng DNS, na isinasaalang-alang ang IPv6, ay umaangkop sa minimum na halaga ng MTU (1280). Ang halaga ng parameter ng truncation-threshold, na responsable para sa pag-trim ng mga tugon sa kliyente, ay binawasan din sa 1232.
Iba pang mga pagbabago sa PowerDNS Recursor 4.2:
- Nagdagdag ng suporta sa mekanismo (X-Proxied-For), na katumbas ng DNS ng X-Forwarded-For HTTP header, na nagpapahintulot sa impormasyon tungkol sa IP address at port number ng orihinal na humihiling na maipasa sa pamamagitan ng mga intermediate na proxy at load balancer (gaya ng dnsdist) . Upang paganahin ang XPF mayroong mga pagpipilian ""At"";
- Pinahusay na suporta para sa extension ng EDNS (ECS), na nagbibigay-daan sa iyong magpadala sa mga query sa DNS sa isang awtoritatibong impormasyon ng DNS server tungkol sa subnet kung saan nalason ang paunang kahilingang ipinadala sa kahabaan ng chain (ang data tungkol sa source subnet ng kliyente ay kinakailangan para sa epektibong operasyon ng mga network ng paghahatid ng nilalaman) . Ang bagong release ay nagdaragdag ng mga setting para sa piling kontrol sa paggamit ng EDNS Client Subnet: "Β» na may listahan ng mga network mask kung saan ang IP ay gagamitin sa ECS sa mga papalabas na kahilingan. Para sa mga address na hindi nasa loob ng tinukoy na mga maskara, ang pangkalahatang address na tinukoy sa direktiba "". Sa pamamagitan ng direktiba"Β» maaari mong tukuyin ang mga subnet kung saan hindi mapapalitan ang mga papasok na kahilingan na may mga punong halaga ng ECS;
- Para sa mga server na nagpoproseso ng malaking bilang ng mga kahilingan sa bawat segundo (higit sa 100 libo), ang direktiba "", na tumutukoy sa bilang ng mga thread para sa pagtanggap ng mga papasok na kahilingan at pamamahagi ng mga ito sa pagitan ng mga thread ng manggagawa (makatuwiran lamang kapag ginagamit ang "").
- Nagdagdag ng setting upang tukuyin ang iyong sariling file gamit ang mga domain kung saan maaaring irehistro ng mga user ang kanilang mga subdomain, sa halip na ang listahang nakapaloob sa PowerDNS Recursor.
Ang proyekto ng PowerDNS ay nag-anunsyo din ng paglipat sa isang anim na buwang cycle ng pag-unlad, na may susunod na pangunahing paglabas ng PowerDNS Recursor 4.3 na inaasahan sa Enero 2020. Ang mga update para sa mga makabuluhang release ay bubuo sa buong taon, pagkatapos nito ay ilalabas ang mga pag-aayos ng kahinaan para sa isa pang anim na buwan. Kaya, ang suporta para sa PowerDNS Recursor 4.2 branch ay tatagal hanggang Enero 2021. Ang mga katulad na pagbabago sa ikot ng pag-unlad ay ginawa para sa PowerDNS Authoritative Server, na inaasahang maglalabas ng 4.2 sa malapit na hinaharap.
Mga pangunahing tampok ng PowerDNS Recursor:
- Mga tool para sa malayuang pagkolekta ng istatistika;
- Instant restart;
- Built-in na makina para sa pagkonekta ng mga humahawak sa wikang Lua;
- Buong DNSSEC na suporta at ;
- Suporta para sa RPZ (Response Policy Zones) at ang kakayahang tukuyin ang mga blacklist;
- Mga mekanismo ng anti-spoofing;
- Kakayahang mag-record ng mga resulta ng resolusyon bilang mga file ng BIND zone.
- Upang matiyak ang mataas na pagganap, ginagamit ang mga modernong mekanismo ng multiplexing ng koneksyon sa FreeBSD, Linux at Solaris (kqueue, epoll, /dev/poll), pati na rin ang isang mataas na pagganap ng DNS packet parser na may kakayahang magproseso ng libu-libong mga parallel na kahilingan.
Pinagmulan: opennet.ru