DNS karoga diena 2020 iniciatīva, lai risinātu sadrumstalotības un TCP atbalsta problēmas

Šodien vairāki lieli DNS servisi un DNS serveru ražotāji rīkos kopīgu pasākumu DNS karoga diena 2020. gadāparedzēts, lai koncentrētu uzmanību uz lēmums problēmas ar IP sadrumstalotību, apstrādājot lielus DNS ziņojumus. Šis ir jau otrais šāds pasākums, pērn “DNS karoga diena” bija koncentrēts par pareizu EDNS pieprasījumu apstrādi.

DNS karoga diena 2020 iniciatīvas dalībnieki aicina noteikt ieteicamos bufera izmērus EDNS līdz 1232 baitiem (MTU lielums 1280 mīnus 48 baiti galvenēm), kā arī tulkot pieprasījumu apstrāde, izmantojot TCP, ir obligāta funkcija serveros. IN RFC 1035 Tikai atbalsts pieprasījumu apstrādei, izmantojot UDP, ir atzīmēts kā obligāts, un TCP ir norādīts kā vēlams, bet nav nepieciešams darbībai. Jauns RFC 7766 и RFC 5966 skaidri norādiet TCP kā nepieciešamo iespēju, lai DNS darbotos pareizi. Iniciatīva piedāvā piespiest pāriet no pieprasījumu sūtīšanas, izmantojot UDP, uz TCP izmantošanu gadījumos, kad noteiktais EDNS bufera lielums nav pietiekams.

Piedāvātās izmaiņas novērsīs neskaidrības ar EDNS bufera izmēra izvēli un atrisinās lielo UDP ziņojumu sadrumstalotības problēmu, kuru apstrāde bieži noved pie pakešu zuduma un taimauta klienta pusē. Klienta pusē EDNS bufera lielums būs nemainīgs, un lielas atbildes nekavējoties tiks nosūtītas klientam, izmantojot TCP. Izvairīšanās no lielu ziņojumu sūtīšanas, izmantojot UDP, atrisinās arī problēmas ar lielu pakešu nomešanu dažos ugunsmūros un ļaus bloķēt uzbrukumiem par DNS kešatmiņas saindēšanu, pamatojoties uz manipulācijām ar sadrumstalotām UDP paketēm (sadalot fragmentos, otrajā fragmentā nav iekļauta galvene ar identifikatoru, tāpēc to var viltot, kam pietiek tikai ar kontrolsummas atbilstību) .

Sākot ar šodienu, iesaistītie DNS pakalpojumu sniedzēji, tostarp CloudFlare, Quad 9, Cisco (OpenDNS) un Google, pamazām mainīsies EDNS bufera lielums no 4096 līdz 1232 baitiem DNS serveros (EDNS izmaiņas tiks sadalītas 4–6 nedēļu laikā un laika gaitā attieksies uz arvien lielāku pieprasījumu skaitu). Atbildes uz UDP pieprasījumiem, kas neatbilst jaunajam ierobežojumam, tiks nosūtītas, izmantojot TCP. DNS serveru pārdevēji, tostarp BIND, Unbound, Knot, NSD un PowerDNS, izlaidīs atjauninājumus, lai mainītu noklusējuma EDNS bufera lielumu no 4096 baitiem uz 1232 baitiem.

Galu galā šīs izmaiņas var izraisīt atrisināšanas problēmas, piekļūstot DNS serveriem, kuru UDP DNS atbildes pārsniedz 1232 baitus un nevar nosūtīt TCP atbildi. Google veiktais eksperiments parādīja, ka EDNS bufera lieluma maiņa praktiski neietekmē atteices biežumu - ar 4096 baitu buferi saīsināto UDP pieprasījumu skaits ir 0.345%, bet nesasniedzamo atkārtojumu skaits, izmantojot TCP, ir 0.115%. Ar 1232 baitu buferi šie skaitļi ir 0.367% un 0.116%. TCP atbalsta padarīšana par nepieciešamo DNS līdzekli radīs problēmas aptuveni 0.1% DNS serveru. Tiek atzīmēts, ka mūsdienu apstākļos bez TCP šo serveru darbība jau ir nestabila.

Autoritatīvu DNS serveru administratoriem jānodrošina, lai viņu serveris atbildētu, izmantojot TCP tīkla portā 53, un ka šo TCP portu nebloķē ugunsmūris. Cienījamam DNS serverim arī nevajadzētu sūtīt UDP atbildes, kas ir lielākas par
pieprasītais EDNS bufera lielums. Pašā serverī EDNS bufera lielums ir jāiestata uz 1232 baiti. Atrisinātājiem ir aptuveni vienādas prasības - obligāta iespēja atbildēt, izmantojot TCP, obligāts atbalsts atkārtotu pieprasījumu nosūtīšanai caur TCP, saņemot saīsinātu UDP atbildi, un EDNS bufera iestatīšana uz 1232 baitiem.

Par EDNS bufera lieluma iestatīšanu dažādos DNS serveros ir atbildīgi šādi parametri:

  • SAISTĪT

    iespējas {
    edns-udp-size 1232;
    max-udp-size 1232;
    };

  • Mezgla DNS

    max-udp-lietderīgā slodze: 1232

  • Mezglu atrisinātājs

    net.bufsize(1232)

  • PowerDNS autoritatīvs

    udp-truncation-threshold=1232

  • PowerDNS rekursors

    edns-outgoing-bufsize=1232
    udp-truncation-threshold=1232

  • Nav saistību

    edns-buffer-size: 1232

  • NSD

    ipv4-edns-size: 1232
    ipv6-edns-size: 1232

    Avots: opennet.ru

  • Pievieno komentāru