Efter halvandet års udvikling udgivelsen af den cachede DNS-server , som er ansvarlig for rekursiv navneomdannelse. PowerDNS Recursor er bygget på et fælles kodegrundlag med PowerDNS Authoritative Server, men de rekursive og autoritative DNS-servere fra PowerDNS udvikles under forskellige udviklingscyklusser og frigives som separate produkter. Koden for projektet er under GPLv2-licensen.
I den nye version er alle bemærkninger vedrørende behandling af DNS-pakker med EDNS-flag fjernet. I ældre versioner af PowerDNS Recursor før 2016 blev pakker med ikke-understøttede EDNS-flag ignoreret uden at sende svar i det gamle format, ved at kassere EDNS-flagene som foreskrevet af specifikationen. Tidligere blev denne ikke-standardiserede adfærd understøttet i BIND i form af en omgåelse, men i februar , har udviklerne af DNS-servere besluttet at opgive denne hack.
I PowerDNS blev de vigtigste problemer med behandling af pakker med EDNS stadig løst tilbage i 2017 i version 4.1, og i den version 4.0, der blev udgivet i 2016, opstod der enkle inkompatibiliteter, som i almindelighed ikke hæmmede normal drift. I PowerDNS Recursor 4.2, som i , er omgåelser for støtte af autoritative servere, der svarer forkert på forespørgsler med EDNS-flag, blevet fjernet. Hidtil, hvis der ikke kom et svar efter at have sendt en forespørgsel med EDNS-flag efter et bestemt tidsrum, betragtede DNS-serveren, at de udvidede flag ikke blev understøttet og sendte en gentaget forespørgsel uden EDNS-flag. Fremadrettet er denne adfærd deaktiveret, da tilstedeværelsen af sådan kode førte til øget latency på grund af gentagne pakkeoverførsler, øget belastning på netværket og tvetydighed i mangel af svar på grund af netværksfejl samt besværliggjorde implementeringen af EDNS-baserede funktioner, såsom brugen af DNS Cookies til at beskytte mod DDoS-angreb.
Det næste år er det besluttet at afholde et arrangement , der har til formål at fokusere opmærksomheden på om IP-fragmentering ved behandling af store DNS-beskeder. I rammerne af initiativet fastslå de anbefalede bufferstørrelser for EDNS til niveauer på 1200 byte samt behandling af forespørgsler over TCP som obligatorisk understøttet på serverne. I øjeblikket er støtte til behandling af forespørgsler over UDP obligatorisk, mens TCP er ønskeligt, men ikke obligatorisk for driften (standarden foreskriver muligheden for at deaktivere TCP). Det foreslås at fjerne muligheden for at deaktivere TCP fra standarden og standardisere overgangen fra at sende forespørgsler over UDP til at anvende TCP i de tilfælde, hvor den fastsatte bufferstørrelse for EDNS ikke er tilstrækkelig.
De foreslåede ændringer vil fjerne forvirringen omkring valg af EDNS-bufferstørrelse og løse problemet med fragmentering af store UDP-beskeder, hvis behandling ofte fører til tab af pakker og timeout på klientens side. På klientsiden vil EDNS-bufferstørrelsen være konstant, og store svar vil straks blive sendt til klienten via TCP. Undtagelsen for at sende store beskeder via UDP vil også muliggøre blokering af DNS-cache-forgiftning baseret på manipulation af fragmenterede UDP-pakker (ved fragmentering inkluderer det andet fragment ikke overskriften med identificeringen, hvorfor det kan forfalskes, så længe kontrolsummen passer).
I PowerDNS Recursor 4.2 er der taget højde for problemer med store UDP-pakker, og der er sket et skift til at bruge en EDNS-bufferstørrelse (edns-outgoing-bufsize) på 1232 bytes i stedet for den tidligere anvendte grænse på 1680 bytes, hvilket bør reducere sandsynligheden for tab af UDP-pakker betydeligt. Værdien 1232 er valgt, da den er maksimum, hvor DNS-svarstørrelsen under hensyntagen til IPv6 passer inden for den minimale MTU-værdi (1280). Værdien for parameteren truncation-threshold, som styrer beskæringen af svar til klienten, er også reduceret til 1232.
Andre ændringer i PowerDNS Recursor 4.2:
- Tilføjet support for mekanismen (X-Proxied-For), som er ækvivalent med HTTP-headeren X-Forwarded-For for DNS, der gør det muligt at overføre oplysninger om IP-adressen og portnummeret fra den oprindelige initiator af anmodningen, som er omdirigeret gennem mellemliggende proxyer og belastningsbalancere (f.eks. dnsdist). For at aktivere XPF er der muligheder for "" og "«;
- Forbedret support til EDNS-udvidelsen (ECS), som gør det muligt at overføre oplysninger om det subnet, hvorfra den oprindelige forespørgsel blev sendt, til den autoritative DNS-server (oplysninger om den oprindelige klientsubnet er nødvendige for effektiv drift af indholdsleveringsnetværk). I den nye version er der tilføjet indstillinger til selektive kontrol af anvendelsen af EDNS Client Subnet: "" med en liste over netmasker, for hvilke IP vil blive brugt i ECS i udgående forespørgsler. For adresser, der ikke falder ind under de angivne maskerer, vil en fælles adresse, der er angivet i direktivet "". Gennem direktivet "" kan der defineres subnetter, hvor indgående forespørgsler med udfyldte ECS-værdier ikke vil blive erstattet;
- For servere, der håndterer et stort antal forespørgsler pr. sekund (mere end 100.000), er der foreslået et direktiv "«, der bestemmer antallet af tråde til modtagelse af indgående anmodninger og deres fordeling mellem arbejdstorve (giver mening kun ved brug af «-modus.«).
- Tilføjet indstilling til at definere sin egen fil med af domæner, hvor brugere kan registrere deres underdomæner i stedet for den indbyggede liste i PowerDNS Recursor.
PowerDNS-projektet har også annonceret overgangen til en seks-måneders udviklingscyklus, hvor den næste store version af PowerDNS Recursor 4.3 forventes i januar 2020. Opdateringer til betydelige udgivelser vil blive dannet i løbet af året, hvorefter der vil blive udgivet sikkerhedsrettelser i yderligere seks måneder. Dermed vil supporten for versionen PowerDNS Recursor 4.2 strække sig til januar 2021. Tilsvarende ændringer i udviklingscyklussen er blevet vedtaget for produktet PowerDNS Authoritative Server, hvis version 4.2 forventes snart.
Hovedfunktionerne i PowerDNS Recursor:
- Værktøjer til fjernindhentning af statistikker;
- Øjeblikkelig genstart;
- Indbygget motor til tilslutning af håndteringsprogrammer på Lua-sprog;
- Fuldt support for DNSSEC og ;
- Support for RPZ (Response Policy Zones) og mulighed for at definere sortlister;
- Mekanismer til at bekæmpe spoofing;
- Mulighed for at gemme resultaterne af opløsning som BIND zonefiler.
- For at sikre høj ydeevne anvendes moderne mekanismer til multiplexing af forbindelser i FreeBSD, Linux og Solaris (kqueue, epoll, /dev/poll), samt en højtydende DNS-pakker-parser, der kan håndtere titusinder af parallelle forespørgsler.
Kilde: opennet.ru
