Na anderhalf jaar ontwikkeling uitgifte van de cache-dns-server , verantwoordelijk voor de recursieve naamtransformatie. PowerDNS Recursor is gebouwd op dezelfde codebasis als PowerDNS Authoritative Server, maar de recursieve en autoritatieve DNS-servers van PowerDNS worden ontwikkeld binnen verschillende ontwikkelingscycli en worden uitgebracht als aparte producten. De code van het project onder GPLv2-licentie.
In de nieuwe versie zijn alle opmerkingen over de verwerking van DNS-pakketten met EDNS-vlaggen verwijderd. In eerdere versies van PowerDNS Recursor tot 2016 werd het genegeerd dat pakketten met niet-ondersteunde EDNS-vlaggen geen antwoord kregen in het oude formaat, waarbij de EDNS-vlaggen werden weggegooid, zoals de specificatie vereist. Eerder werd dit niet-standaard gedrag ondersteund in BIND in de vorm van een workaround, maar in het kader van initiatief genomen in februari , hebben de ontwikkelaars van DNS-servers besloten om deze hack achter te laten.
In PowerDNS zijn de belangrijkste problemen bij de verwerking van pakketten met EDNS al in 2017 opgelost in release 4.1, en in de in 2016 uitgekomen tak 4.0 kwamen afzonderlijke incompatibiliteiten naar voren die onder bepaalde omstandigheden voorkwamen en in het algemeen de normale werking niet belemmerden. In PowerDNS Recursor 4.2, evenals in , zijn de workarounds voor autoritatieve servers die incorrect reageren op aanvragen met EDNS-vlaggen verwijderd. Tot nu toe, als na het versturen van een aanvraag met EDNS-vlaggen na een bepaalde tijd geen antwoord werd ontvangen, ging de DNS-server ervan uit dat de uitgebreide vlaggen niet werden ondersteund en stuurde een herhalingsaanvraag zonder EDNS-vlaggen. Dit gedrag is nu uitgeschakeld, omdat de aanwezigheid van dergelijke code leidde tot verhoogde latentie door herhaalde pakketverzending, een verhoogde netwerkbelasting en ambiguïteit bij het ontbreken van antwoorden als gevolg van netwerkstoringen, en bemoeilijkte de implementatie van EDNS-gebaseerde mogelijkheden, zoals het gebruik van DNS Cookies ter bescherming tegen DDoS-aanvallen.
Volgend jaar is besloten een evenement , te houden om aandacht te vestigen op van IP-fragmentatie bij de verwerking van grote DNS-berichten. In het kader van het initiatief zijn aanbevolen bufferformaten voor EDNS vastgelegd tot waarden van 1200 bytes, evenals De verwerking van aanvragen via TCP wordt verplicht ondersteund op servers. Op dit moment is ondersteuning voor het verwerken van aanvragen via UDP verplicht, terwijl TCP wenselijk is maar niet verplicht voor de werking (de standaard vereist de mogelijkheid om TCP uit te schakelen). Er wordt voorgesteld om de optie voor het uitschakelen van TCP uit de standaard te verwijderen en de overgang van het verzenden van aanvragen via UDP naar het gebruik van TCP te standaardiseren in gevallen waarin de ingestelde EDNS-buffergrootte onvoldoende is.
De wijzigingen die in het kader van het initiatief worden voorgesteld, zullen verwarring over de keuze van de EDNS-buffergrootte wegnemen en het probleem van fragmentatie van grote UDP-berichten oplossen, wat vaak leidt tot pakketverlies en time-outs aan de klantzijde. Aan de klantzijde zal de EDNS-buffergrootte constant zijn, en grote antwoorden zullen onmiddellijk via TCP naar de klant worden verzonden. Het uitsluiten van het verzenden van grote berichten via UDP zal ook blokkeren voor DNS-cachevergiftiging, gebaseerd op manipulatie van gefragmenteerde UDP-pakketten (bij fragmentatie bevat het tweede fragment geen header met de identificatie, waardoor het kan worden vervalst zolang de controle som overeenkomt).
In PowerDNS Recursor 4.2 zijn de problemen met grote UDP-pakketten aangepakt en is de overstap gemaakt naar het gebruik van de EDNS-buffergrootte (edns-outgoing-bufsize) van 1232 bytes, in plaats van de eerder gehanteerde limiet van 1680 bytes, wat de kans op verlies van UDP-pakketten aanzienlijk zou moeten verminderen. De waarde 1232 is gekozen omdat dit het maximum is waarbij de grootte van het DNS-antwoord inclusief IPv6 binnen de minimale MTU-waarde (1280) valt. Tot 1232 is ook de waarde van de truncation-threshold parameter verlaagd, die verantwoordelijk is voor het afkappen van antwoorden aan de klant.
Andere wijzigingen in PowerDNS Recursor 4.2:
- Ondersteuning voor mechanisme toegevoegd (X-Proxied-For), dat de tegenhanger is van de HTTP-header X-Forwarded-For voor DNS, waardoor informatie over het IP-adres en het poortnummer van de oorspronkelijke aanvrager, die via tussenliggende proxies en load balancers (zoals dnsdist) is doorgestuurd, kan worden doorgegeven. Voor het inschakelen van XPF zijn de opties "» en ««;
- Verbeterde ondersteuning voor EDNS-extensie (ECS), waarmee informatie over het subnet, waarvandaan het oorspronkelijke verzoek in de keten is verzonden, naar de autoritatieve DNS-server kan worden doorgegeven in DNS-verzoeken (gegevens over het oorspronkelijke subnet van de klant zijn nodig voor een effectieve werking van content delivery netwerken). In deze nieuwe uitgave zijn instellingen toegevoegd voor selectieve controle over het gebruik van EDNS Client Subnet: «» met een lijst van netwerk masks waarvoor IP in ECS zal worden gebruikt in uitgaande verzoeken. Voor adressen die niet onder de opgegeven masks vallen, wordt het algemene adres gebruikt dat is opgegeven in de richtlijn ««. Via de richtlijn «» kan een subnet worden gedefinieerd waarvan binnenkomende verzoeken met ingevulde ECS-waarden niet zullen worden vervangen;
- Voor servers die een groot aantal verzoeken per seconde verwerken (meer dan 100.000), is de richtlijn ««, gedefinieerd, die het aantal threads bepaalt voor het ontvangen van binnenkomende verzoeken en het distribueren daarvan over werkthreads (heeft alleen zin bij het gebruik van de modus ««).
- Er is een instelling toegevoegd voor het definiëren van een eigen bestand met de van domeinen waarin gebruikers hun subdomeinen kunnen registreren, in plaats van de ingebouwde lijst in PowerDNS Recursor.
Het PowerDNS-project heeft ook aangekondigd over te stappen naar een zesmaandelijkse ontwikkelingscyclus, waarbij de volgende belangrijke release van PowerDNS Recursor 4.3 wordt verwacht in januari 2020. Updates voor belangrijke releases worden gedurende het jaar samengesteld, waarna er nog eens zes maanden beveiligingspatches komen. Hierdoor zal de ondersteuning voor de PowerDNS Recursor 4.2 tak duren tot januari 2021. Vergelijkbare wijzigingen in de ontwikkelingscyclus zijn aangenomen voor het product PowerDNS Authoritative Server, waarvan de release 4.2 binnenkort wordt verwacht.
Belangrijkste kenmerken van PowerDNS Recursor:
- Middelen voor externe statistiekverzameling;
- Instant opnieuw opstarten;
- Ingebouwde engine voor het aansluiten van handlers in Lua;
- Volledige ondersteuning voor DNSSEC en ;
- Ondersteuning voor RPZ (Response Policy Zones) en de mogelijkheid om zwarte lijsten te definiëren;
- Mechanismen voor het bestrijden van spoofing;
- Mogelijkheid om resolvingsresultaten op te slaan in de vorm van BIND-zonebestanden.
- Om hoge prestaties te waarborgen, worden moderne mechanismen voor het multiplexen van verbindingen toegepast in FreeBSD, Linux en Solaris (kqueue, epoll, /dev/poll), evenals een hoogpresterende DNS-pakketparser die in staat is om tienduizenden gelijktijdige verzoeken te verwerken.
Bron: opennet.ru
