PowerDNS Recursor 4.2 ir DNS vėliavėlės dienos 2020 iniciatyvos išleidimas

Po pusantrų metų plėtros pateiktas talpyklos DNS serverio išleidimas PowerDNS šaltinis 4.2, atsakingas už rekursinį vardo konvertavimą. „PowerDNS Recursor“ sukurtas ant tos pačios kodo bazės kaip „PowerDNS Authoritative Server“, tačiau „PowerDNS“ rekursyvūs ir autoritetingi DNS serveriai kuriami per skirtingus kūrimo ciklus ir išleidžiami kaip atskiri produktai. Projekto kodas išplatino licencijuota pagal GPLv2.

Naujoji versija pašalina visas problemas, susijusias su DNS paketų apdorojimu EDNS vėliavėlėmis. Senesnėse „PowerDNS Recursor“ versijose iki 2016 m. buvo įprasta ignoruoti paketus su nepalaikomomis EDNS vėliavėlėmis, nesiunčiant atsakymo senuoju formatu, atmetant EDNS vėliavėles, kaip reikalaujama specifikacijoje. Anksčiau šis nestandartinis elgesys buvo palaikomas BIND kaip išeitis, tačiau tai buvo taikoma atliko vasario mėn. iniciatyvas DNS vėliavėlės diena, DNS serverio kūrėjai nusprendė atsisakyti šio įsilaužimo.

„PowerDNS“ pagrindinės problemos, susijusios su paketų apdorojimu EDNS, buvo pašalintos dar 2017 m. 4.1 versijoje, o 2016 m. išleistoje 4.0 šakoje išryškėjo individualūs nesuderinamumai, atsirandantys tam tikromis aplinkybėmis ir apskritai netrukdantys normaliam darbui. operacija. „PowerDNS Recursor 4.2“, kaip ir 9.14 PRIEMONĖ, Pašalinti sprendimai, skirti palaikyti autoritetingus serverius, kurie neteisingai atsako į užklausas su EDNS vėliavėlėmis. Iki šiol, jei išsiuntus užklausą su EDNS vėliavėlėmis, po tam tikro laiko nebuvo atsakyta, DNS serveris padarė prielaidą, kad išplėstinės vėliavėlės nepalaikomos ir išsiuntė antrą užklausą be EDNS vėliavėlių. Šis elgesys dabar buvo išjungtas, nes dėl šio kodo pailgėjo delsa dėl pakartotinio paketų siuntimo, padidėjo tinklo apkrova ir dviprasmiškumas, kai neatsakoma dėl tinklo gedimų, ir neleido įdiegti EDNS pagrįstų funkcijų, tokių kaip DNS slapukai, apsaugantys nuo DDoS atakų.

Nutarta renginį surengti kitais metais DNS vėliavos diena 2020 mskirtas sutelkti dėmesį sprendimas problemų su IP fragmentacija apdorojant didelius DNS pranešimus. Kaip iniciatyvos dalis planuojama nustatyti rekomenduojamus EDNS buferio dydžius iki 1200 baitų ir versti užklausų apdorojimas per TCP yra privaloma serverių funkcija. Dabar reikalingas užklausų apdorojimo per UDP palaikymas, o TCP pageidautinas, bet nebūtinas darbui (standartas reikalauja galimybės išjungti TCP). Siūloma iš standarto išbraukti TCP išjungimo galimybę ir standartizuoti perėjimą nuo užklausų siuntimo per UDP prie TCP naudojimo tais atvejais, kai neužtenka nustatyto EDNS buferio dydžio.

Įgyvendinant iniciatyvą siūlomi pakeitimai pašalins painiavą renkantis EDNS buferio dydį ir išspręs didelių UDP pranešimų, kurių apdorojimas dažnai lemia paketų praradimą ir skirtojo laiko pabaigą, suskaidymo problemą kliento pusėje. Kliento pusėje EDNS buferio dydis bus pastovus, o dideli atsakymai bus nedelsiant siunčiami klientui per TCP. Vengdami siųsti didelių pranešimų per UDP, taip pat galėsite blokuoti išpuolių už DNS talpyklos apnuodijimą, remiantis manipuliavimu suskaidytais UDP paketais (padalijus į fragmentus, antrame fragmente nėra antraštės su identifikatoriumi, todėl jis gali būti suklastotas, kuriam pakanka tik, kad sutaptų kontrolinė suma) .

„PowerDNS Recursor 4.2“ atsižvelgia į problemas, susijusias su dideliais UDP paketais, ir pereina prie 1232 baitų EDNS buferio dydžio (edns-outgoing-bufsize), o ne anksčiau naudotos 1680 baitų ribos, o tai turėtų žymiai sumažinti UDP paketų praradimo tikimybę. . Vertė 1232 pasirinkta, nes tai yra didžiausias DNS atsako dydis, atsižvelgiant į IPv6, telpa į mažiausią MTU reikšmę (1280). Sutrumpinimo slenksčio parametro, atsakingo už atsakymų klientui apkarpymą, reikšmė taip pat sumažinta iki 1232.

Kiti PowerDNS Recursor 4.2 pakeitimai:

  • Pridėtas mechanizmo palaikymas XPF (X-Proxied-For), kuri yra X-Forwarded-For HTTP antraštės DNS atitikmuo, leidžianti persiųsti informaciją apie pradinio užklausos teikėjo IP adresą ir prievado numerį per tarpinius tarpinius serverius ir apkrovos balansavimo priemones (pvz., dnsdist). . Norėdami įjungti XPF, yra parinktys "xpf-allow-from"Ir"xpf-rr-kodas";
  • Pagerintas EDNS plėtinio palaikymas Kliento potinklis (ECS), leidžianti perduoti DNS užklausas autoritetingam DNS serveriui informaciją apie potinklį, iš kurio buvo užnuodyta pradinė užklausa, perduota grandinėje (duomenys apie kliento šaltinio potinklį būtini efektyviam turinio pristatymo tinklų veikimui) . Nauja versija prideda parametrus, leidžiančius pasirinktinai valdyti EDNS kliento potinklio naudojimą: „ecs-add-for» su tinklo kaukių, kurių IP bus naudojamas ECS siunčiamose užklausose, sąrašu. Adresams, kurie nepatenka į nurodytas kaukes, bendrasis adresas, nurodytas direktyvoje "ecs-scope-zero-adresas“. Per direktyvą "use-incoming-edns-subnet» galite apibrėžti potinklius, iš kurių gaunamos užklausos su užpildytomis ECS reikšmėmis nebus pakeistos;
  • Serveriams, apdorojantiems daug užklausų per sekundę (daugiau nei 100 tūkst.), direktyva „platintojas-siūlai", kuris nustato gijų, skirtų gaunamoms užklausoms gauti ir paskirstyti jas tarp darbuotojų gijų, skaičių (prasminga tik naudojant "pdns-distributes-queries=yes").
  • Pridėtas nustatymas viešas-sąrašo-sąrašo failas norėdami apibrėžti savo failą viešųjų priesagų sąrašas domenai, kuriuose vartotojai gali registruoti savo padomenius, o ne sąrašą, įtaisytą PowerDNS Recursor.

PowerDNS projektas taip pat paskelbė apie perėjimą prie šešių mėnesių kūrimo ciklo, o kitas svarbus PowerDNS Recursor 4.3 leidimas turėtų pasirodyti 2020 m. sausio mėn. Svarbių leidimų atnaujinimai bus kuriami visus metus, o po to pažeidžiamumo pataisymai bus išleisti dar šešis mėnesius. Taigi „PowerDNS Recursor 4.2“ šakos palaikymas tęsis iki 2021 m. sausio mėn. Panašūs kūrimo ciklo pakeitimai buvo atlikti ir PowerDNS Authoritative Server, kuris artimiausiu metu turėtų išleisti 4.2 versiją.

Pagrindinės „PowerDNS Recursor“ savybės:

  • Nuotolinio statistikos rinkimo įrankiai;
  • Momentinis paleidimas iš naujo;
  • Integruotas variklis, skirtas prijungti tvarkykles Lua kalba;
  • Visiškas DNSSEC palaikymas ir DNS64;
  • RPZ (Response Policy Zones) palaikymas ir galimybė apibrėžti juoduosius sąrašus;
  • Apsaugos nuo sukčiavimo mechanizmai;
  • Galimybė įrašyti skiriamosios gebos rezultatus kaip BIND zonos failus.
  • Siekiant užtikrinti aukštą našumą, FreeBSD, Linux ir Solaris sistemose naudojami modernūs ryšio tankinimo mechanizmai (kqueue, epoll, /dev/poll), taip pat didelio našumo DNS paketų analizatorius, galintis apdoroti dešimtis tūkstančių lygiagrečių užklausų.

Šaltinis: opennet.ru

Добавить комментарий