Efter halvandet års udvikling frigivelse af caching DNS-server , ansvarlig for rekursiv navnekonvertering. PowerDNS Recursor er bygget på den samme kodebase som PowerDNS Authoritative Server, men PowerDNS rekursive og autoritative DNS-servere udvikles gennem forskellige udviklingscyklusser og frigives som separate produkter. Projektkode licenseret under GPLv2.
Den nye version eliminerer alle problemer relateret til behandlingen af DNS-pakker med EDNS-flag. Ældre versioner af PowerDNS Recursor før 2016 havde praksis med at ignorere pakker med ikke-understøttede EDNS-flag uden at sende et svar i det gamle format, og kassere EDNS-flag som krævet af specifikationen. Tidligere blev denne ikke-standard adfærd understøttet i BIND i form af en løsning, men inden for rammerne af i februar initiativer , DNS-serverudviklere besluttede at opgive dette hack.
I PowerDNS blev hovedproblemerne med at behandle pakker med EDNS elimineret tilbage i 2017 i release 4.1, og i 2016-grenen, der blev udgivet i 4.0, dukkede individuelle inkompatibiliteter op, som opstår under et bestemt sæt omstændigheder og generelt ikke forstyrrer normale operation. I PowerDNS Recursor 4.2, som i , Fjernede løsninger for at understøtte autoritative servere, der reagerer forkert på anmodninger med EDNS-flag. Indtil nu, hvis der efter afsendelse af en anmodning med EDNS-flag ikke var svar efter en vis periode, antog DNS-serveren, at udvidede flag ikke var understøttet, og sendte en anden anmodning uden EDNS-flag. Denne adfærd er nu blevet deaktiveret, da denne kode resulterede i øget latenstid på grund af pakketransmissioner, øget netværksbelastning og tvetydighed, når der ikke reageres på grund af netværksfejl, og forhindrede implementeringen af EDNS-baserede funktioner såsom DNS-cookies for at beskytte mod DDoS-angreb.
Det er besluttet at afholde arrangementet næste år designet til at fokusere opmærksomheden på med IP-fragmentering ved behandling af store DNS-meddelelser. Som en del af initiativet fastsætte de anbefalede bufferstørrelser for EDNS til 1200 bytes, og behandling af anmodninger via TCP er en must-have funktion på servere. Nu er support til behandling af anmodninger via UDP påkrævet, og TCP er ønskeligt, men ikke påkrævet for drift (standarden kræver mulighed for at deaktivere TCP). Det foreslås at fjerne muligheden for at deaktivere TCP fra standarden og standardisere overgangen fra at sende anmodninger over UDP til at bruge TCP i tilfælde, hvor den etablerede EDNS-bufferstørrelse ikke er nok.
De ændringer, der foreslås som en del af initiativet, vil eliminere forvirring med valg af EDNS-bufferstørrelse og løse problemet med fragmentering af store UDP-meddelelser, hvis behandling ofte fører til pakketab og timeouts på klientsiden. På klientsiden vil EDNS-bufferstørrelsen være konstant, og store svar sendes straks til klienten over TCP. Undgå at sende store beskeder over UDP vil også give dig mulighed for at blokere til forgiftning af DNS-cachen, baseret på manipulation af fragmenterede UDP-pakker (når det er opdelt i fragmenter, indeholder det andet fragment ikke en header med en identifikator, så den kan forfalskes, for hvilken det kun er nok for kontrolsummen at matche) .
PowerDNS Recursor 4.2 tager højde for problemer med store UDP-pakker og skifter til at bruge EDNS-bufferstørrelsen (edns-outgoing-bufsize) på 1232 bytes i stedet for den tidligere brugte grænse på 1680 bytes, hvilket skulle reducere sandsynligheden for at miste UDP-pakker markant . Værdien 1232 blev valgt, fordi det er det maksimum, hvor størrelsen af DNS-svaret, under hensyntagen til IPv6, passer ind i den minimale MTU-værdi (1280). Værdien af trunkeringstærskelparameteren, som er ansvarlig for trimning af svar til klienten, er også blevet reduceret til 1232.
Andre ændringer i PowerDNS Recursor 4.2:
- Tilføjet mekanismestøtte (X-Proxied-For), som er DNS-ækvivalenten til X-Forwarded-For HTTP-headeren, hvilket gør det muligt at videresende oplysninger om IP-adressen og portnummeret på den oprindelige anmoder via mellemliggende proxyer og load balancere (såsom dnsdist) . For at aktivere XPF er der muligheder ""Og"";
- Forbedret understøttelse af EDNS-udvidelse (ECS), som giver dig mulighed for at transmittere i DNS-forespørgsler til en autoritativ DNS-server information om det undernet, hvorfra den første anmodning, der blev transmitteret langs kæden, blev forgiftet (data om klientens kildeundernet er nødvendige for effektiv drift af indholdsleveringsnetværk) . Den nye udgivelse tilføjer indstillinger for selektiv kontrol over brugen af EDNS Client Subnet: "» med en liste over netværksmasker, for hvilke IP'en vil blive brugt i ECS i udgående anmodninger. For adresser, der ikke falder inden for de angivne masker, er den generelle adresse angivet i direktivet "". Gennem direktivet "» du kan definere undernet, hvorfra indgående anmodninger med udfyldte ECS-værdier ikke vil blive erstattet;
- For servere, der behandler et stort antal anmodninger pr. sekund (mere end 100 tusinde), direktivet "", som bestemmer antallet af tråde til at modtage indgående anmodninger og distribuere dem mellem arbejdstråde (giver kun mening, når du bruger "").
- Tilføjet indstilling at definere din egen fil med domæner, hvor brugere kan registrere deres underdomæner, i stedet for listen indbygget i PowerDNS Recursor.
PowerDNS-projektet annoncerede også et skift til en seks-måneders udviklingscyklus, hvor den næste store udgivelse af PowerDNS Recursor 4.3 forventes i januar 2020. Opdateringer til væsentlige udgivelser vil blive udviklet i løbet af året, hvorefter sårbarhedsrettelser vil blive frigivet i yderligere seks måneder. Således vil support til PowerDNS Recursor 4.2-grenen vare indtil januar 2021. Lignende ændringer i udviklingscyklussen er blevet foretaget for PowerDNS Authoritative Server, som forventes at udgive 4.2 i den nærmeste fremtid.
Hovedtræk ved PowerDNS Recursor:
- Værktøjer til fjernindsamling af statistik;
- Øjeblikkelig genstart;
- Indbygget motor til at forbinde handlere på Lua-sproget;
- Fuld DNSSEC-understøttelse og ;
- Understøttelse af RPZ (Response Policy Zones) og muligheden for at definere sorte lister;
- Anti-spoofing mekanismer;
- Evne til at optage opløsningsresultater som BIND-zonefiler.
- For at sikre høj ydeevne bruges moderne forbindelsesmultiplekseringsmekanismer i FreeBSD, Linux og Solaris (kqueue, epoll, /dev/poll), samt en højtydende DNS-pakkeparser, der er i stand til at behandle titusindvis af parallelle anmodninger.
Kilde: opennet.ru