Lansare PowerDNS Recursor 4.2 și inițiativa DNS flag day 2020

După un an și jumătate de dezvoltare la sfârșitul anului 2019. Pe lângă protocoalele ActivityPub și diaspora, Hubzilla se federează în cadrul rețelei prin propriul său protocol lansare a unui server DNS caching PowerDNS Recursor 4.2, care se ocupă de transformarea recursivă a numelui. PowerDNS Recursor este construit pe aceeași bază de cod cu PowerDNS Authoritative Server, dar serverele DNS recursive și autoritative PowerDNS evoluează în cadrul unor cicluri diferite de dezvoltare și sunt lansate sub formă de produse separate. Codul proiectului se răspândește sub licența GPLv2.

În noua versiune, toate observațiile legate de procesarea pachetelor DNS cu steaguri EDNS au fost remediate. În versiunile anterioare ale PowerDNS Recursor, până în 2016, s-a practicat ignorarea pachetelor cu steaguri EDNS neacceptate, fără a trimite un răspuns în vechiul format, eliminând stindardele EDNS, așa cum cere specificația. Această comportare non-standard a fost anterior susținută în BIND sub formă de ocol, dar în cadrul inițiativei din februarie DNS flag day, dezvoltatorii serverelor DNS au decis să renunțe la această soluție.

În PowerDNS, principalele probleme legate de procesarea pachetelor cu EDNS au fost rezolvate încă din 2017 în versiunea 4.1, iar în ramura lansată în 2016, 4.0, au apărut incompatibilități sporadice care, în general, nu afectau funcționarea normală. În PowerDNS Recursor 4.2, ca și în BIND 9.14, au fost eliminate ocolurile de suport pentru serverele autoritative care răspundeau incorect la cereri cu steaguri EDNS. Până acum, dacă după trimiterea unei cereri cu steaguri EDNS, nu se primea un răspuns după un anumit interval de timp, serverul DNS considera că steagurile extinse nu sunt acceptate și trimitea o cerere repetată fără steaguri EDNS. De acum înainte, acest comportament este dezactivat, deoarece prezența unui astfel de cod a dus la creșteri de latență din cauza retransmiterii pachetelor, la o încărcare mai mare a rețelei și la ambiguitate în absența unui răspuns din cauza căderilor de rețea, precum și a afectat implementarea funcționalităților bazate pe EDNS, cum ar fi utilizarea cookie-urilor DNS pentru protecția împotriva atacurilor DDoS.

Anul viitor s-a decis organizarea unui eveniment DNS flag day 2020, destinat să concentreze atenția asupra soluționării problemelor fragmentării IP la procesarea mesajelor DNS de dimensiuni mari. În cadrul inițiativei se preconizează se va fixa dimensiunea recomandată a bufferelor pentru EDNS la valori de 1200 de octeți, precum și a traduce procesarea cererilor TCP este absolut necesară pe servere. Acum suportul pentru procesarea cererilor UDP este obligatoriu, iar TCP este de dorit, dar nu esențial pentru funcționare (standardul prevede o opțiune de dezactivare a TCP). Se propune eliminarea opțiunii de dezactivare a TCP din standard și standardizarea trecerii de la trimiterea cererilor prin UDP la utilizarea TCP în cazurile când dimensiunea buffer-ului EDNS nu este suficientă.

Modificările propuse în cadrul inițiativei vor elimina confuzia legată de alegerea dimensiunii buffer-ului EDNS și vor rezolva problema fragmentării mesajelor UDP mari, a căror procesare duce frecvent la pierderi de pachete și timeout-uri pe partea clientului. Pe partea clientului, dimensiunea buffer-ului EDNS va fi constantă, iar răspunsurile mari vor fi trimise imediat clientului prin TCP. Excluderea trimiterii mesajelor mari prin UDP va permite, de asemenea, blocarea... atacuri atacurilor de îmbunătățire a cache-ului DNS, bazate pe manipularea pachetelor UDP fragmentate (la fragmentare, al doilea fragment nu conține antetul cu identificatorul, astfel poate fi falsificat, având doar nevoie să se potrivească cu suma de control).

În PowerDNS Recursor 4.2 au fost luate în considerare problemele cu pachetele UDP mari și s-a realizat trecerea la dimensiunea buffer-ului EDNS (edns-outgoing-bufsize) de 1232 octeți, în loc de limita anterioară de 1680 octeți, ceea ce ar trebui să reducă semnificativ probabilitatea pierderii pachetelor UDP. Valoarea 1232 a fost aleasă deoarece este maximul la care dimensiunea răspunsului DNS, având în vedere IPv6, se încadrează în valoarea minimă MTU (1280). De asemenea, valoarea parametrului truncation-threshold, care răspunde de tăierea răspunsurilor către client, a fost redusă la 1232.

Alte modificări în PowerDNS Recursor 4.2:

  • S-a adăugat suport pentru mecanismul XPF (X-Proxied-For), care reprezintă echivalentul antetului HTTP X-Forwarded-For pentru DNS, permițând transmiterea informațiilor despre adresa IP și numărul portului inițiatorului cererii, redirecționată prin intermediul proxy-urilor și echilibratorilor de sarcină (de exemplu, dnsdist). Pentru activarea XPF sunt prevăzute opțiunile „xpf-allow-from” și „xpf-rr-code«;
  • Suportul pentru extensia EDNS a fost îmbunătățit Client Subnet (ECS), care permite transmiterea informațiilor despre subrețea către serverul DNS autoritativ în cererile DNS, din care a fost trimisă cererea inițială transformată (informațiile despre subrețeaua originală a clientului sunt necesare pentru funcționarea eficientă a rețelelor de livrare a conținutului). În noua versiune au fost adăugate setări pentru controlul selectiv al aplicării EDNS Client Subnet: „ecs-add-for» cu lista de măști de rețea pentru care IP-ul va fi utilizat în ECS în cererile ieșite. Pentru adresele care nu se încadrează în măștile specificate, va fi utilizată adresa comună specificată în directiva „ecs-scope-zero-address« . Prin directiva „use-incoming-edns-subnet» se pot defini subrețelele din care cererile de intrare cu valori completate ECS nu vor fi înlocuite;
  • Pentru serverele care procesează un număr mare de cereri pe secundă (peste 100.000), a fost propusă directiva „distributor-threads«, care determină numărul de fire pentru primirea cererilor de intrare și distribuirea acestora între firele de lucru (are sens doar în cazul utilizării modului „pdns-distributes-queries=yes«).
  • A fost adăugată setarea public-suffix-list-file pentru a defini propriul fișier cu lista sufixelor publice de domenii în care utilizatorii își pot înregistra subdomeni, în locul listei încorporate în PowerDNS Recursor.

Proiectul PowerDNS a anunțat, de asemenea, trecerea la un ciclu de dezvoltare de șase luni, conform căruia următoarea versiune semnificativă PowerDNS Recursor 4.3 este așteptată în ianuarie 2020. Actualizările pentru versiunile semnificative vor fi formulate pe parcursul anului, după care vor fi emise corecții pentru vulnerabilități timp de încă șase luni. Astfel, suportul pentru ramura PowerDNS Recursor 4.2 va dura până în ianuarie 2021. Modificări similare ale ciclului de dezvoltare au fost acceptate pentru produsul PowerDNS Authoritative Server, versiunea 4.2 a cărei lansare este așteptată în curând.

Caracteristicile principale ale PowerDNS Recursor:

  • Instrumente pentru colectarea statisticilor de la distanță;
  • Repornire instantanee;
  • Motor încorporat pentru conectarea handler-elor în limbajul Lua;
  • Suport complet pentru DNSSEC și DNS64;
  • Suport pentru RPZ (Response Policy Zones) și posibilitatea de a defini liste negre;
  • Mecanisme de combatere a spoofing-ului;
  • Posibilitatea de a înregistra rezultatele rezolvării sub formă de fișiere de zonă BIND.
  • Pentru a asigura o performanță ridicată, se folosesc mecanisme moderne de multiplexare a conexiunilor în FreeBSD, Linux și Solaris (kqueue, epoll, /dev/poll), precum și un parser DNS de înaltă performanță, capabil să proceseze zeci de mii de cereri paralele.

Sursa: opennet.ro

Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS 🔥 Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS | ProHoster