Efter ett och ett halvt år av utveckling release av cachande DNS-server , ansvarig för rekursiv namnkonvertering. PowerDNS Recursor är byggd på samma kodbas som PowerDNS Authoritative Server, men PowerDNS rekursiva och auktoritativa DNS-servrar utvecklas genom olika utvecklingscykler och släpps som separata produkter. Projektkod licensierad under GPLv2.
Den nya versionen eliminerar alla problem relaterade till behandlingen av DNS-paket med EDNS-flaggor. Äldre versioner av PowerDNS Recursor före 2016 hade praxis att ignorera paket med EDNS-flaggor som inte stöds utan att skicka ett svar i det gamla formatet, och kassera EDNS-flaggorna enligt specifikationen. Tidigare stöddes detta icke-standardiserade beteende i BIND i form av en lösning, men inom ramen för i februari initiativ , DNS-serverutvecklare bestämde sig för att överge detta hack.
I PowerDNS eliminerades de största problemen med att bearbeta paket med EDNS redan 2017 i release 4.1, och i 2016-grenen som släpptes 4.0 dök individuella inkompatibiliteter upp som uppstår under en viss uppsättning omständigheter och i allmänhet inte stör normala drift. I PowerDNS Recursor 4.2, som i , Tog bort lösningar för att stödja auktoritativa servrar som felaktigt svarar på förfrågningar med EDNS-flaggor. Fram till nu, om det inte fanns något svar efter att ha skickat en begäran med EDNS-flaggor efter en viss tidsperiod, antog DNS-servern att utökade flaggor inte stöddes och skickade en andra begäran utan EDNS-flaggor. Detta beteende har nu inaktiverats eftersom den här koden resulterade i ökad latens på grund av paketåteröverföringar, ökad nätverksbelastning och oklarhet när de inte svarar på grund av nätverksfel, och förhindrade implementeringen av EDNS-baserade funktioner som DNS-kakor för att skydda mot DDoS-attacker.
Det har beslutats att arrangera evenemanget nästa år utformad för att fokusera uppmärksamheten på med IP-fragmentering vid behandling av stora DNS-meddelanden. Som en del av initiativet fixa de rekommenderade buffertstorlekarna för EDNS till 1200 byte, och Att bearbeta förfrågningar via TCP är en måstefunktion på servrar. Nu krävs stöd för bearbetning av förfrågningar via UDP, och TCP är önskvärt, men krävs inte för drift (standarden kräver möjligheten att inaktivera TCP). Det föreslås att alternativet att inaktivera TCP tas bort från standarden och standardisera övergången från att skicka förfrågningar över UDP till att använda TCP i de fall då den etablerade EDNS-buffertstorleken inte räcker.
De förändringar som föreslås som en del av initiativet kommer att eliminera förvirring med valet av EDNS-buffertstorlek och lösa problemet med fragmentering av stora UDP-meddelanden, vars bearbetning ofta leder till paketförlust och timeout på klientsidan. På klientsidan kommer EDNS-buffertstorleken att vara konstant och stora svar skickas omedelbart till klienten över TCP. Genom att undvika att skicka stora meddelanden över UDP kan du också blockera för förgiftning av DNS-cachen, baserat på manipulation av fragmenterade UDP-paket (när det delas upp i fragment innehåller det andra fragmentet inte en rubrik med en identifierare, så det kan förfalskas, för vilket det bara räcker för att kontrollsumman ska matcha) .
PowerDNS Recursor 4.2 tar hänsyn till problem med stora UDP-paket och går över till att använda EDNS-buffertstorleken (edns-outgoing-bufsize) på 1232 byte, istället för den tidigare använda gränsen på 1680 byte, vilket avsevärt borde minska sannolikheten för att förlora UDP-paket . Värdet 1232 valdes eftersom det är det maximala vid vilket storleken på DNS-svaret, med hänsyn till IPv6, passar in i det lägsta MTU-värdet (1280). Värdet på trunkeringströskelparametern, som är ansvarig för att trimma svar till klienten, har också reducerats till 1232.
Andra ändringar i PowerDNS Recursor 4.2:
- Tillagt mekanismstöd (X-Proxied-For), som är DNS-motsvarigheten till X-Forwarded-For HTTP-huvudet, vilket gör att information om IP-adressen och portnumret för den ursprungliga begäranden kan vidarebefordras via mellanliggande proxyservrar och lastbalanserare (som dnsdist) . För att aktivera XPF finns det alternativ ""Och"";
- Förbättrat stöd för EDNS-tillägg (ECS), som låter dig överföra i DNS-frågor till en auktoritativ DNS-server information om subnätet från vilket den ursprungliga begäran som överfördes längs kedjan förgiftades (data om klientens källsubnät är nödvändig för effektiv drift av innehållsleveransnätverk) . Den nya utgåvan lägger till inställningar för selektiv kontroll över användningen av EDNS Client Subnet: "» med en lista över nätverksmasker för vilka IP kommer att användas i ECS i utgående förfrågningar. För adresser som inte faller inom de angivna maskerna, den allmänna adressen som anges i direktivet "". Genom direktivet "» du kan definiera undernät från vilka inkommande förfrågningar med ifyllda ECS-värden inte kommer att ersättas;
- För servrar som behandlar ett stort antal förfrågningar per sekund (mer än 100 tusen), direktivet "", som bestämmer antalet trådar för att ta emot inkommande förfrågningar och distribuera dem mellan arbetartrådar (verkar bara meningsfullt när du använder "").
- Tillagd inställning att definiera din egen fil med domäner där användare kan registrera sina underdomäner, istället för listan inbyggd i PowerDNS Recursor.
PowerDNS-projektet tillkännagav också en övergång till en sexmånaders utvecklingscykel, med nästa stora utgåva av PowerDNS Recursor 4.3 förväntad i januari 2020. Uppdateringar för betydande utgåvor kommer att utvecklas under hela året, varefter sårbarhetskorrigeringar kommer att släppas under ytterligare sex månader. Således kommer stödet för PowerDNS Recursor 4.2-grenen att pågå till januari 2021. Liknande förändringar i utvecklingscykeln har gjorts för PowerDNS Authoritative Server, som förväntas släppa 4.2 inom en snar framtid.
Huvudfunktioner i PowerDNS Recursor:
- Verktyg för fjärrinsamling av statistik;
- Omedelbar omstart;
- Inbyggd motor för att ansluta hanterare på Lua-språket;
- Fullständigt DNSSEC-stöd och ;
- Stöd för RPZ (Response Policy Zones) och möjligheten att definiera svarta listor;
- Mekanismer mot spoofing;
- Möjlighet att spela in upplösningsresultat som BIND-zonfiler.
- För att säkerställa hög prestanda används moderna anslutningsmultiplexeringsmekanismer i FreeBSD, Linux och Solaris (kqueue, epoll, /dev/poll), såväl som en högpresterande DNS-paketparser som kan behandla tiotusentals parallella förfrågningar.
Källa: opennet.ru