{"id":36194,"date":"2019-10-31T22:10:13","date_gmt":"2019-10-31T19:10:13","guid":{"rendered":"https:\/\/prohoster.info\/blog\/reliz-powerdns-recursor-4-2-i-initsiativa-dns-flag-day-2020\/"},"modified":"2019-10-31T22:10:13","modified_gmt":"2019-10-31T19:10:13","slug":"reliz-powerdns-recursor-4-2-i-initsiativa-dns-flag-day-2020","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/news\/reliz-powerdns-recursor-4-2-i-initsiativa-dns-flag-day-2020","title":{"rendered":"Release van PowerDNS Recursor 4.2 en initiatief DNS flag day 2020","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Na anderhalf jaar ontwikkeling is gepresenteerd<\/a><\/noindex> uitgifte van de cache-dns-server PowerDNS Recursor 4.2<\/a><\/noindex>, 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 wordt verspreid<\/a><\/noindex> onder GPLv2-licentie. <\/p>\n

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 de<\/a><\/noindex> initiatief genomen in februari DNS flag day<\/a><\/noindex>, hebben de ontwikkelaars van DNS-servers besloten om deze hack achter te laten. <\/p>\n

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 BIND 9.14<\/a><\/noindex>, 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\u00efteit 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. <\/p>\n

Volgend jaar is besloten een evenement DNS flag day 2020<\/a><\/noindex>, te houden om aandacht te vestigen op de oplossing<\/a><\/noindex> problemen<\/a><\/noindex> van IP-fragmentatie bij de verwerking van grote DNS-berichten. In het kader van het initiatief gepland<\/a><\/noindex> zijn aanbevolen bufferformaten voor EDNS vastgelegd tot waarden van 1200 bytes, evenals te vertalen<\/a><\/noindex> 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.<\/p>\n

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 aanval<\/a><\/noindex> 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).<\/p>\n

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.<\/p>\n

Andere wijzigingen in PowerDNS Recursor 4.2:<\/p>\n