Liberigo de PowerDNS Recursor 4.2 kaj DNS flagtago 2020 iniciato

Post jaro kaj duono de evoluo prezentita liberigo de kaŝmemoriga DNS-servilo PowerDNS-Rimedo 4.2, respondeca por rekursiva nomkonverto. PowerDNS Recursor estas konstruita sur la sama kodbazo kiel PowerDNS Authoritative Server, sed PowerDNS rekursivaj kaj aŭtoritataj DNS-serviloj estas evoluigitaj tra malsamaj evolucikloj kaj estas liberigitaj kiel apartaj produktoj. Projekta kodo distribuita de licencita laŭ GPLv2.

La nova versio forigas ĉiujn problemojn ligitajn al la prilaborado de DNS-pakoj kun EDNS-flagoj. Pli malnovaj versioj de PowerDNS Recursor antaŭ 2016 havis la praktikon de ignorado de pakaĵetoj kun nesubtenitaj EDNS-flagoj sen sendado de respondo en la malnova formato, forĵetante la EDNS-flagojn kiel postulite per la specifo. Antaŭe, ĉi tiu ne-norma konduto estis subtenata en BIND en la formo de solvo, sed en la amplekso de efektivigita en februare iniciatoj DNS flagtago, DNS-servilaj programistoj decidis forlasi ĉi tiun hakon.

En PowerDNS, la ĉefaj problemoj pri prilaborado de pakaĵoj kun EDNS estis eliminitaj en 2017 en eldono 4.1, kaj en la branĉo 2016 publikigita en 4.0, individuaj nekongruoj ekaperis, kiuj ŝprucas sub certa aro de cirkonstancoj kaj, ĝenerale, ne malhelpas normalon. operacio. En PowerDNS Recursor 4.2, kiel en LIGA 9.14, Forigitaj solvoj por subteni aŭtoritatajn servilojn, kiuj malĝuste respondas al petoj per EDNS-flagoj. Ĝis nun, se post sendado de peto kun EDNS-flagoj ne estis respondo post certa tempodaŭro, la DNS-servilo supozis, ke plilongigitaj flagoj ne estis subtenataj kaj sendis duan peton sen EDNS-flagoj. Ĉi tiu konduto nun estis malfunkciigita ĉar ĉi tiu kodo rezultigis pliigitan latentecon pro pakaĵetaj retranssendoj, pliigita retŝarĝo kaj ambigueco kiam ne respondas pro retaj fiaskoj, kaj malhelpis la efektivigon de EDNS-bazitaj funkcioj kiel DNS-kuketoj por protekti kontraŭ DDoS-atakoj.

Oni decidis okazigi la eventon venontjare DNS flagtago 2020desegnita por enfokusigi atenton la decido problemoj kun IP-fragmentiĝo dum prilaborado de grandaj DNS-mesaĝoj. Kadre de la iniciato estas planita ripari la rekomenditajn bufrograndojn por EDNS al 1200 bajtoj, kaj traduki prilabori petojn per TCP estas nepra funkcio en serviloj. Nun subteno por prilaborado de petoj per UDP estas bezonata, kaj TCP estas dezirinda, sed ne necesa por funkciado (la normo postulas la kapablon malŝalti TCP). Estas proponite forigi la opcion por malfunkciigi TCP de la normo kaj normigi la transiron de sendado de petoj super UDP al uzado de TCP en kazoj kie la establita EDNS-bufrgrandeco ne sufiĉas.

La ŝanĝoj proponitaj kiel parto de la iniciato eliminos konfuzon kun elektado de la EDNS-bufrgrandeco kaj solvos la problemon de fragmentiĝo de grandaj UDP-mesaĝoj, kies prilaborado ofte kondukas al paka perdo kaj tempoforpasoj ĉe la klienta flanko. Ĉe la kliento, la EDNS-bufrgrandeco estos konstanta kaj grandaj respondoj tuj estos senditaj al la kliento per TCP. Eviti sendi grandajn mesaĝojn super UDP ankaŭ permesos vin bloki atakoj por veneni la DNS-kaŝmemoron, surbaze de la manipulado de fragmentaj UDP-pakaĵoj (kiam dividite en fragmentojn, la dua fragmento ne inkluzivas kapon kun identigilo, do ĝi povas esti forĝita, por kio sufiĉas nur por ke la ĉeksumo kongruu) .

PowerDNS Recursor 4.2 enkalkulas problemojn kun grandaj UDP-pakaĵoj kaj ŝanĝas al uzado de la EDNS-bufrgrandeco (edns-outgoing-bufsize) de 1232 bajtoj, anstataŭe de la antaŭe uzita limo de 1680 bajtoj, kiu devus signife redukti la verŝajnecon de perdado de UDP-pakaĵoj. . La valoro 1232 estis elektita ĉar ĝi estas la maksimumo ĉe kiu la grandeco de la DNS-respondo, konsiderante IPv6, konvenas al la minimuma MTU-valoro (1280). La valoro de la detranĉa sojla parametro, kiu respondecas pri tondado de respondoj al la kliento, ankaŭ estis reduktita al 1232.

Aliaj ŝanĝoj en PowerDNS Recursor 4.2:

  • Aldonita mekanismo subteno XPF (X-Proxied-For), kiu estas la DNS-ekvivalento de la X-Forwarded-For HTTP-titolo, permesante informojn pri la IP-adreso kaj havennumero de la origina petanto esti plusendita tra mezaj prokuriloj kaj ŝarĝbalanciloj (kiel ekzemple dnsdist) . Por ebligi XPF estas opcioj "xpf-permesi-de"Kaj"xpf-rr-kodo";
  • Plibonigita subteno por EDNS-etendo Klienta Subreto (ECS), kiu permesas vin transdoni en DNS-demandoj al aŭtoritata DNS-servilo informojn pri la subreto de kiu la komenca peto transdonita laŭ la ĉeno estis venenita (datenoj pri la fonta subreto de la kliento estas necesaj por la efika funkciado de enhavo-liveraj retoj) . La nova eldono aldonas agordojn por selektema kontrolo super la uzo de EDNS Klienta Subreto: "ecs-add-for» kun listo de retaj maskoj por kiuj la IP estos uzata en ECS en eksiĝintaj petoj. Por adresoj, kiuj ne apartenas al la specifitaj maskoj, la ĝenerala adreso specifita en la direktivo "ecs-scope-zero-adreso". Per la direktivo "uzu-envenanta-edns-subreto» Vi povas difini subretojn el kiuj envenantaj petoj kun plenigitaj ECS-valoroj ne estos anstataŭigitaj;
  • Por serviloj traktantaj grandan nombron da petoj sekundo (pli ol 100 mil), la direktivo "distribuisto-fadenoj", kiu determinas la nombron da fadenoj por ricevi envenantajn petojn kaj distribui ilin inter laborfadenoj (estas senco nur kiam oni uzas la "pdns-distributes-queries=jes").
  • Aldonita agordo publika-sufikso-listo-dosiero por difini vian propran dosieron per listo de publikaj sufiksoj domajnoj en kiuj uzantoj povas registri siajn subdomajnojn, anstataŭe de la listo konstruita en PowerDNS Recursor.

La PowerDNS-projekto ankaŭ anoncis movon al ses-monata evoluciklo, kun la venonta grava eldono de PowerDNS Recursor 4.3 atendita en januaro 2020. Ĝisdatigoj por signifaj eldonoj estos evoluigitaj tutjare, post kiuj vundeblecoj estos publikigitaj dum aliaj ses monatoj. Tiel, subteno por la branĉo PowerDNS Recursor 4.2 daŭros ĝis januaro 2021. Similaj evoluciklaj ŝanĝoj estis faritaj por PowerDNS Aŭtoritata Servilo, kiu estas atendita liberigos 4.2 en proksima estonteco.

Ĉefaj trajtoj de PowerDNS Recursor:

  • Iloj por fora statistika kolekto;
  • Tuja rekomenco;
  • Enkonstruita motoro por konekti traktilojn en la Lua lingvo;
  • Plena DNSSEC-subteno kaj DNS64;
  • Subteno por RPZ (Response Policy Zones) kaj la kapablo difini nigrajn listojn;
  • Mekanismoj kontraŭ-falsaj;
  • Kapablo registri rezoluciajn rezultojn kiel BIND-zondosieroj.
  • Por certigi altan efikecon, modernaj konektmultiplexaj mekanismoj estas uzitaj en FreeBSD, Linukso kaj Solaris (kqueue, epoll, /dev/poll), same kiel alt-efikecan DNS-pakaĵannalizilon kapablan prilabori dekojn de miloj da paralelaj petoj.

fonto: opennet.ru

Aldoni komenton