{"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\/da\/blog\/news\/reliz-powerdns-recursor-4-2-i-initsiativa-dns-flag-day-2020","title":{"rendered":"Udgivelsen af PowerDNS Recursor 4.2 og initiativet DNS flag dag 2020","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Efter halvandet \u00e5rs udvikling pr\u00e6senteret<\/a><\/noindex> udgivelsen af den cachede DNS-server PowerDNS Recursor 4.2<\/a><\/noindex>, som er ansvarlig for rekursiv navneomdannelse. PowerDNS Recursor er bygget p\u00e5 et f\u00e6lles 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 distribueres<\/a><\/noindex> er under GPLv2-licensen. <\/p>\n

I den nye version er alle bem\u00e6rkninger vedr\u00f8rende behandling af DNS-pakker med EDNS-flag fjernet. I \u00e6ldre versioner af PowerDNS Recursor f\u00f8r 2016 blev pakker med ikke-underst\u00f8ttede 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\u00e6rd underst\u00f8ttet i BIND i form af en omg\u00e5else, men i den gennemf\u00f8rte<\/a><\/noindex> februar DNS flag day<\/a><\/noindex>, har udviklerne af DNS-servere besluttet at opgive denne hack. <\/p>\n

I PowerDNS blev de vigtigste problemer med behandling af pakker med EDNS stadig l\u00f8st 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\u00e6mmede normal drift. I PowerDNS Recursor 4.2, som i BIND 9.14<\/a><\/noindex>, er omg\u00e5elser for st\u00f8tte af autoritative servere, der svarer forkert p\u00e5 foresp\u00f8rgsler med EDNS-flag, blevet fjernet. Hidtil, hvis der ikke kom et svar efter at have sendt en foresp\u00f8rgsel med EDNS-flag efter et bestemt tidsrum, betragtede DNS-serveren, at de udvidede flag ikke blev underst\u00f8ttet og sendte en gentaget foresp\u00f8rgsel uden EDNS-flag. Fremadrettet er denne adf\u00e6rd deaktiveret, da tilstedev\u00e6relsen af s\u00e5dan kode f\u00f8rte til \u00f8get latency p\u00e5 grund af gentagne pakkeoverf\u00f8rsler, \u00f8get belastning p\u00e5 netv\u00e6rket og tvetydighed i mangel af svar p\u00e5 grund af netv\u00e6rksfejl samt besv\u00e6rliggjorde implementeringen af EDNS-baserede funktioner, s\u00e5som brugen af DNS Cookies til at beskytte mod DDoS-angreb. <\/p>\n

Det n\u00e6ste \u00e5r er det besluttet at afholde et arrangement DNS flag day 2020<\/a><\/noindex>, der har til form\u00e5l at fokusere opm\u00e6rksomheden p\u00e5 l\u00f8sningen<\/a><\/noindex> problemer<\/a><\/noindex> om IP-fragmentering ved behandling af store DNS-beskeder. I rammerne af initiativet er planlagt<\/a><\/noindex> fastsl\u00e5 de anbefalede bufferst\u00f8rrelser for EDNS til niveauer p\u00e5 1200 byte samt at g\u00f8re<\/a><\/noindex> behandling af foresp\u00f8rgsler over TCP som obligatorisk underst\u00f8ttet p\u00e5 serverne. I \u00f8jeblikket er st\u00f8tte til behandling af foresp\u00f8rgsler over UDP obligatorisk, mens TCP er \u00f8nskeligt, men ikke obligatorisk for driften (standarden foreskriver muligheden for at deaktivere TCP). Det foresl\u00e5s at fjerne muligheden for at deaktivere TCP fra standarden og standardisere overgangen fra at sende foresp\u00f8rgsler over UDP til at anvende TCP i de tilf\u00e6lde, hvor den fastsatte bufferst\u00f8rrelse for EDNS ikke er tilstr\u00e6kkelig.<\/p>\n

De foresl\u00e5ede \u00e6ndringer vil fjerne forvirringen omkring valg af EDNS-bufferst\u00f8rrelse og l\u00f8se problemet med fragmentering af store UDP-beskeder, hvis behandling ofte f\u00f8rer til tab af pakker og timeout p\u00e5 klientens side. P\u00e5 klientsiden vil EDNS-bufferst\u00f8rrelsen v\u00e6re konstant, og store svar vil straks blive sendt til klienten via TCP. Undtagelsen for at sende store beskeder via UDP vil ogs\u00e5 muligg\u00f8re blokering angreb<\/a><\/noindex> af DNS-cache-forgiftning baseret p\u00e5 manipulation af fragmenterede UDP-pakker (ved fragmentering inkluderer det andet fragment ikke overskriften med identificeringen, hvorfor det kan forfalskes, s\u00e5 l\u00e6nge kontrolsummen passer).<\/p>\n

I PowerDNS Recursor 4.2 er der taget h\u00f8jde for problemer med store UDP-pakker, og der er sket et skift til at bruge en EDNS-bufferst\u00f8rrelse (edns-outgoing-bufsize) p\u00e5 1232 bytes i stedet for den tidligere anvendte gr\u00e6nse p\u00e5 1680 bytes, hvilket b\u00f8r reducere sandsynligheden for tab af UDP-pakker betydeligt. V\u00e6rdien 1232 er valgt, da den er maksimum, hvor DNS-svarst\u00f8rrelsen under hensyntagen til IPv6 passer inden for den minimale MTU-v\u00e6rdi (1280). V\u00e6rdien for parameteren truncation-threshold, som styrer besk\u00e6ringen af svar til klienten, er ogs\u00e5 reduceret til 1232.<\/p>\n

Andre \u00e6ndringer i PowerDNS Recursor 4.2:<\/p>\n