{"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\/it\/blog\/novosti-interneta\/reliz-powerdns-recursor-4-2-i-initsiativa-dns-flag-day-2020","title":{"rendered":"Rilascio di PowerDNS Recursor 4.2 e iniziativa DNS flag day 2020","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dopo un anno e mezzo di sviluppo presentato<\/a><\/noindex> rilascio del server DNS con caching PowerDNS Recursor 4.2<\/a><\/noindex>, responsabile della risoluzione dei nomi. PowerDNS Recursor \u00e8 costruito su una singola base di codice con PowerDNS Authoritative Server, ma i server DNS ricorsivi e autoritativi di PowerDNS si sviluppano in cicli di sviluppo diversi e vengono rilasciati come prodotti separati. Il codice del progetto distribuito<\/a><\/noindex> \u00e8 sotto licenza GPLv2. <\/p>\n

Nella nuova versione sono stati risolti tutti i problemi relativi alla gestione dei pacchetti DNS con flag EDNS. Nelle versioni precedenti di PowerDNS Recursor fino al 2016, si era soliti ignorare i pacchetti con flag EDNS non supportati, senza inviare una risposta nel vecchio formato, scartando i flag EDNS, come richiesto dalla specifica. In passato, questo comportamento non standard era supportato in BIND come una soluzione alternativa, ma nel gioco<\/a><\/noindex> di febbraio dell'iniziativa DNS flag day<\/a><\/noindex>, gli sviluppatori di server DNS hanno deciso di abbandonare questo hack. <\/p>\n

In PowerDNS, the main issues with packet processing using EDNS were resolved back in 2017 with the release of version 4.1. However, certain incompatibilities arose in the 4.0 branch released in 2016 under specific circumstances, which generally did not interfere with normal operation. In PowerDNS Recursor 4.2, as in BIND 9.14<\/a><\/noindex>, workarounds for supporting authoritative servers that incorrectly respond to requests with EDNS flags have been removed. Previously, if a response was not received after sending a request with EDNS flags within a certain time frame, the DNS server assumed that extended flags were not supported and re-sent the request without EDNS flags. This behavior is now disabled, as such code increased latency due to repeated packet transmissions, heightened network load, and ambiguity in the absence of a response due to network failures, as well as hindered the implementation of EDNS-based features like the use of DNS Cookies for DDoS attack protection. <\/p>\n

Next year, it has been decided to hold an event DNS flag day 2020<\/a><\/noindex>, aimed at focusing attention on the solution<\/a><\/noindex> di problemi<\/a><\/noindex> con frammentazione IP durante l'elaborazione di messaggi DNS di grandi dimensioni. Nell'ambito dell'iniziativa \u00e8 previsto<\/a><\/noindex> fissare le dimensioni consigliate dei buffer per EDNS a valori intorno ai 1200 byte, cos\u00ec come tradurre<\/a><\/noindex> l'elaborazione delle richieste TCP in una funzione obbligatoria sui server. Attualmente, \u00e8 obbligatoria la supporto per l'elaborazione delle richieste UDP, mentre TCP \u00e8 desiderabile ma non essenziale per il funzionamento (lo standard prevede la possibilit\u00e0 di disattivare TCP). Si propone di rimuovere dalllo standard l'opzione di disattivazione di TCP e di standardizzare il passaggio dall'invio di richieste UDP all'uso di TCP nei casi in cui la dimensione del buffer EDNS non sia sufficiente.<\/p>\n

Le modifiche proposte nell'ambito dell'iniziativa elimineranno la confusione riguardo alla scelta delle dimensioni del buffer EDNS e risolveranno il problema della frammentazione di grandi messaggi UDP, il cui trattamento spesso porta a perdite di pacchetti e timeout da parte del client. Dato che sul lato client la dimensione del buffer EDNS sar\u00e0 costante, le risposte grandi verranno immediatamente inviate al client tramite TCP. L'esclusione dell'invio di grandi messaggi tramite UDP consentir\u00e0 anche di bloccare di attacco<\/a><\/noindex> per la manipolazione della cache DNS, che si basa sulla manipolazione di pacchetti UDP frammentati (quando viene suddiviso in frammenti, il secondo frammento non include l'intestazione con l'identificatore, quindi pu\u00f2 essere falsificato a condizione che la somma di controllo corrisponda).<\/p>\n

In PowerDNS Recursor 4.2 sono stati considerati i problemi con pacchetti UDP di grandi dimensioni e c'\u00e8 stata una transizione all'utilizzo della dimensione del buffer EDNS (edns-outgoing-bufsize) a 1232 byte, invece del limite precedente di 1680 byte, il che dovrebbe ridurre significativamente la probabilit\u00e0 di perdita di pacchetti UDP. Il valore 1232 \u00e8 stato scelto perch\u00e9 rappresenta il massimo in cui la dimensione della risposta DNS, tenendo conto di IPv6, rientra nel valore minimo di MTU (1280). Fino a 1232 \u00e8 stato ridotto anche il valore del parametro truncation-threshold, che gestisce il taglio delle risposte al client.<\/p>\n

Altre modifiche in PowerDNS Recursor 4.2:<\/p>\n