{"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\/news\/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 caching PowerDNS Recursor 4.2<\/a><\/noindex>, responsabile della trasformazione ricorsiva dei nomi. PowerDNS Recursor \u00e8 costruito sulla stessa base di codice del PowerDNS Authoritative Server, ma i server DNS ricorsivi e autorizzativi di PowerDNS si sviluppano nell'ambito di cicli di sviluppo diversi e vengono rilasciati sotto forma di prodotti separati. Il codice del progetto \u00e8 distribuito<\/a><\/noindex> \u00e8 sotto licenza GPLv2. <\/p>\n

Nella nuova versione sono stati risolti tutti i problemi legati al trattamento dei pacchetti DNS con i flag EDNS. Nelle vecchie versioni di PowerDNS Recursor fino al 2016, era prassi ignorare i pacchetti con flag EDNS non supportati, senza inviare una risposta nel vecchio formato, scartando i flag EDNS, come richiesto dalla specifica. In precedenza, tale comportamento non standard era sostenuto in BIND come un modo di aggirare, ma nel contesto dell'iniziativa<\/a><\/noindex> di febbraio DNS flag day<\/a><\/noindex>, gli sviluppatori dei server DNS hanno deciso di rinunciare a questo hack. <\/p>\n

In PowerDNS, i principali problemi nel trattamento dei pacchetti con EDNS sono stati risolti gi\u00e0 nel 2017 con il rilascio della versione 4.1, mentre nella versione 4.0 pubblicata nel 2016 si riscontravano alcune incompatibilit\u00e0 occulte che si manifestavano in particolari circostanze e che generalmente non ostacolavano il normale funzionamento. In PowerDNS Recursor 4.2, come in BIND 9.14<\/a><\/noindex>, sono state rimosse le soluzioni alternative per la supporto dei server autoritativi che rispondono in modo errato alle richieste con i flag EDNS. Finora, se dopo l'invio di una richiesta con i flag EDNS, non perveniva risposta dopo un certo intervallo, il server DNS presumeva che i flag estesi non fossero supportati e inviava una richiesta ripetuta senza i flag EDNS. Questo comportamento \u00e8 stato disattivato, poich\u00e9 la presenza di un codice simile portava a un aumento dei ritardi a causa dell'invio ripetuto dei pacchetti, a un maggiore carico sulla rete e all'ambiguit\u00e0 in assenza di risposta a causa di guasti di rete, oltre a ostacolare l'implementazione di funzionalit\u00e0 basate su EDNS, come l'uso dei DNS Cookies per proteggere dagli attacchi DDoS. <\/p>\n

L'anno prossimo si prevede di organizzare un evento DNS flag day 2020<\/a><\/noindex>, finalizzato a concentrare l'attenzione su come risolvere<\/a><\/noindex> di problemi<\/a><\/noindex> della frammentazione IP nel trattamento di messaggi DNS di grandi dimensioni. Nell'ambito dell'iniziativa \u00e8 previsto<\/a><\/noindex> si prevede di fissare le dimensioni raccomandate dei buffer per EDNS a valori intorno ai 1200 byte e di rendere obbligatoria<\/a><\/noindex> il trattamento delle richieste TCP un requisito obbligatorio sui server. Attualmente, \u00e8 obbligatorio supportare il trattamento delle richieste tramite UDP, mentre TCP \u00e8 consigliato ma non obbligatorio per il funzionamento (lo standard prevede la possibilit\u00e0 di disabilitare TCP). Si propone di rimuovere dall standard l'opzione di disabilitare TCP e di standardizzare il passaggio dall'invio delle richieste tramite UDP all'utilizzo di TCP nei casi in cui la dimensione del buffer EDNS disponibile non sia sufficiente.<\/p>\n

Le modifiche proposte nell'ambito dell'iniziativa impediranno la confusione nella scelta della dimensione del buffer EDNS e risolveranno il problema della frammentazione dei grandi messaggi UDP, la cui elaborazione spesso porta a perdite di pacchetti e timeout sul lato client. Sul lato client, la dimensione del buffer EDNS sar\u00e0 costante, e le risposte di grandi dimensioni saranno immediatamente inviate al client tramite TCP. L'eccezione per l'invio di grandi messaggi tramite UDP permetter\u00e0 anche di bloccare attacchi<\/a><\/noindex> l'avvelenamento della cache DNS, basato sulla manipolazione dei pacchetti UDP frammentati (nella suddivisione in frammenti, il secondo frammento non include l'intestazione con l'identificatore, quindi pu\u00f2 essere falsificato semplicemente per far corrispondere il checksum).<\/p>\n

In PowerDNS Recursor 4.2 sono stati considerati i problemi legati ai grandi pacchetti UDP e si \u00e8 passati ad utilizzare una dimensione del buffer EDNS (edns-outgoing-bufsize) di 1232 byte, rispetto al limite precedente di 1680 byte, il che dovrebbe ridurre significativamente la probabilit\u00e0 di perdita di pacchetti UDP. Il valore 1232 \u00e8 stato scelto in quanto rappresenta il massimo in cui la dimensione della risposta DNS, tenendo conto di IPv6, rientra nel valore minimo dell'MTU (1280). \u00c8 stato ridotto anche il valore del parametro truncation-threshold, responsabile del taglio delle risposte al client, fino a 1232.<\/p>\n

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