Másfél év fejlesztés után gyorsítótárazó DNS-kiszolgáló kiadása , felelős a rekurzív névkonverzióért. A PowerDNS Recursor ugyanarra a kódbázisra épül, mint a PowerDNS Authoritative Server, de a PowerDNS rekurzív és hiteles DNS-kiszolgálókat különböző fejlesztési ciklusokon keresztül fejlesztik, és külön termékként adják ki. Projekt kód GPLv2 licenccel.
Az új verzió kiküszöböli az EDNS-jelzőkkel ellátott DNS-csomagok feldolgozásával kapcsolatos összes problémát. A PowerDNS Recursor régebbi, 2016 előtti verzióiban az volt a gyakorlat, hogy figyelmen kívül hagyták a nem támogatott EDNS-jelzőket tartalmazó csomagokat anélkül, hogy a régi formátumban küldtek volna választ, és a specifikációnak megfelelően elvetették az EDNS-jelzőket. Korábban ezt a nem szabványos viselkedést a BIND egy megkerülő megoldás formájában támogatta, de a februári kezdeményezések , a DNS-kiszolgáló fejlesztői úgy döntöttek, hogy felhagynak ezzel a feltöréssel.
A PowerDNS-ben a csomagok EDNS-sel történő feldolgozásának fő problémái már 2017-ben megszűntek a 4.1-es kiadásban, a 2016-ban megjelent 4.0-s ágban pedig olyan egyedi inkompatibilitások jelentek meg, amelyek bizonyos körülmények között jelentkeznek, és általában nem zavarják a normál működést. művelet. A PowerDNS Recursor 4.2-ben, mint a , Megkerülő megoldások eltávolítva a hiteles kiszolgálók támogatására, amelyek helytelenül válaszolnak az EDNS-jelzőkkel ellátott kérésekre. Mostanáig, ha az EDNS-jelzőkkel ellátott kérés elküldése után egy bizonyos idő elteltével nem érkezett válasz, a DNS-kiszolgáló feltételezte, hogy a kiterjesztett jelzők nem támogatottak, és egy második kérést küldött EDNS-jelzők nélkül. Ezt a viselkedést most letiltottuk, mivel ez a kód a csomagok újraküldése miatt megnövekedett késleltetést, megnövekedett hálózati terhelést és kétértelműséget eredményezett, amikor hálózati hibák miatt nem válaszol, valamint megakadályozta az EDNS-alapú szolgáltatások, például a DNS-cookie-k megvalósítását a DDoS-támadások elleni védelem érdekében.
Elhatározták, hogy a rendezvényt jövőre tartják meg úgy tervezték, hogy összpontosítsák a figyelmet nagy DNS-üzenetek feldolgozásakor az IP-töredezettséggel. A kezdeményezés részeként rögzítse az EDNS ajánlott pufferméretét 1200 bájtra, és A kérések TCP-n keresztüli feldolgozása kötelező szolgáltatás a szervereken. Most már támogatni kell a kérések UDP-n keresztüli feldolgozását, és a TCP kívánatos, de nem szükséges a működéshez (a szabvány megköveteli a TCP letiltásának lehetőségét). Javasoljuk, hogy töröljék a szabványból a TCP letiltásának lehetőségét, és szabványosítsák az átmenetet az UDP-n keresztüli kérések küldéséről a TCP használatára olyan esetekben, amikor a megállapított EDNS pufferméret nem elegendő.
A kezdeményezés részeként javasolt változtatások megszüntetik az EDNS pufferméret kiválasztásával kapcsolatos zavart, és megoldják a nagyméretű UDP-üzenetek töredezettségének problémáját, amelyek feldolgozása gyakran csomagvesztéshez és időkorlátokhoz vezet a kliens oldalon. A kliens oldalon az EDNS puffer mérete állandó lesz, és a nagy válaszok azonnal elküldésre kerülnek a kliensnek TCP-n keresztül. A nagy üzenetek UDP-n keresztüli küldésének elkerülése lehetővé teszi a blokkolást is DNS-gyorsítótár mérgezésére, töredezett UDP-csomagok manipulálása alapján (fragmentekre bontva a második töredék nem tartalmaz azonosítóval ellátott fejlécet, így hamisítható, amihez elég csak az ellenőrzőösszeg egyezése) .
A PowerDNS Recursor 4.2 figyelembe veszi a nagy UDP-csomagokkal kapcsolatos problémákat, és átvált az 1232 bájtos EDNS pufferméretre (edns-outgoing-bufsize) a korábban használt 1680 bájtos korlát helyett, ami jelentősen csökkenti az UDP-csomagok elvesztésének valószínűségét . Az 1232-es értéket azért választottuk, mert ez az a maximum, amelynél a DNS-válasz mérete, figyelembe véve az IPv6-ot, belefér a minimális MTU-értékbe (1280). A kliensnek adott válaszok levágásáért felelős csonkítás-küszöb paraméter értéke szintén 1232-re csökkent.
Egyéb változások a PowerDNS Recursor 4.2-ben:
- Hozzáadott mechanizmus támogatás (X-Proxied-For), amely az X-Forwarded-For HTTP fejléc DNS megfelelője, lehetővé téve az eredeti kérő IP-címére és portszámára vonatkozó információk továbbítását köztes proxykon és terheléselosztókon (például dnsdist) keresztül. . Az XPF engedélyezéséhez vannak lehetőségek ""És"";
- Továbbfejlesztett támogatás az EDNS kiterjesztéshez (ECS), amely lehetővé teszi, hogy DNS-lekérdezésekben információkat továbbítson egy hiteles DNS-kiszolgálónak arról az alhálózatról, amelyről a lánc mentén továbbított kezdeti kérés megmérgeződött (az ügyfél forrás-alhálózatára vonatkozó adatok szükségesek a tartalomszolgáltató hálózatok hatékony működéséhez) . Az új kiadás az EDNS Client Subnet használatának szelektív vezérlésére vonatkozó beállításokat ad hozzá: "» azon hálózati maszkok listájával, amelyekhez az IP-t az ECS-ben fogják használni a kimenő kérésekben. Azon címek esetében, amelyek nem esnek a megadott maszkok közé, a " irányelvben meghatározott általános cím". Az irányelven keresztül"» meghatározhat olyan alhálózatokat, amelyekről a kitöltött ECS-értékekkel rendelkező bejövő kérések nem cserélődnek le;
- A másodpercenként nagy számú (több mint 100 ezer) kérelmet feldolgozó szervereknél a „", amely meghatározza a szálak számát a bejövő kérések fogadásához és azok munkaszálak közötti elosztásához (csak akkor van értelme, ha a "").
- Beállítás hozzáadva a saját fájl meghatározásához A PowerDNS Recursorba beépített lista helyett a felhasználók regisztrálhatják altartományaikat.
A PowerDNS projekt egy hat hónapos fejlesztési ciklusra való átállást is bejelentette, a PowerDNS Recursor 4.3 következő jelentős kiadása 2020 januárjában várható. A jelentős kiadásokhoz az év folyamán frissítéseket fejlesztenek, ezt követően pedig további hat hónapig kiadják a sebezhetőség javításait. Így a PowerDNS Recursor 4.2 ág támogatása 2021 januárjáig tart. Hasonló fejlesztési ciklus változások történtek a PowerDNS Authoritative Server esetében is, amely a közeljövőben várhatóan megjelenik a 4.2-es verzióban.
A PowerDNS Recursor főbb jellemzői:
- Eszközök távoli statisztikagyűjtéshez;
- Azonnali újraindítás;
- Beépített motor a kezelők csatlakoztatásához Lua nyelven;
- Teljes DNSSEC támogatás és ;
- Az RPZ (Response Policy Zones) támogatása és a feketelisták meghatározásának lehetősége;
- Hamisítás elleni mechanizmusok;
- Képes a felbontási eredményeket BIND zónafájlként rögzíteni.
- A nagy teljesítmény érdekében a FreeBSD-ben, Linuxban és Solarisban modern kapcsolati multiplexelési mechanizmusokat (kqueue, epoll, /dev/poll), valamint egy nagy teljesítményű DNS-csomagelemzőt használnak, amely több tízezer párhuzamos kérés feldolgozására képes.
Forrás: opennet.ru