Dopo un anno e mezzo di sviluppo rilascio del server DNS caching , responsabile della trasformazione ricorsiva dei nomi. PowerDNS Recursor è 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 è sotto licenza GPLv2.
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 di febbraio , gli sviluppatori dei server DNS hanno deciso di rinunciare a questo hack.
In PowerDNS, i principali problemi nel trattamento dei pacchetti con EDNS sono stati risolti già nel 2017 con il rilascio della versione 4.1, mentre nella versione 4.0 pubblicata nel 2016 si riscontravano alcune incompatibilità occulte che si manifestavano in particolari circostanze e che generalmente non ostacolavano il normale funzionamento. In PowerDNS Recursor 4.2, come in , 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 è stato disattivato, poiché 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à in assenza di risposta a causa di guasti di rete, oltre a ostacolare l'implementazione di funzionalità basate su EDNS, come l'uso dei DNS Cookies per proteggere dagli attacchi DDoS.
L'anno prossimo si prevede di organizzare un evento , finalizzato a concentrare l'attenzione su della frammentazione IP nel trattamento di messaggi DNS di grandi dimensioni. Nell'ambito dell'iniziativa si prevede di fissare le dimensioni raccomandate dei buffer per EDNS a valori intorno ai 1200 byte e il trattamento delle richieste TCP un requisito obbligatorio sui server. Attualmente, è obbligatorio supportare il trattamento delle richieste tramite UDP, mentre TCP è consigliato ma non obbligatorio per il funzionamento (lo standard prevede la possibilità 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.
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à 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à anche di bloccare 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ò essere falsificato semplicemente per far corrispondere il checksum).
In PowerDNS Recursor 4.2 sono stati considerati i problemi legati ai grandi pacchetti UDP e si è 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à di perdita di pacchetti UDP. Il valore 1232 è 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). È stato ridotto anche il valore del parametro truncation-threshold, responsabile del taglio delle risposte al client, fino a 1232.
Altre modifiche in PowerDNS Recursor 4.2:
- Aggiunta la supporto al meccanismo (X-Proxied-For), che rappresenta l'equivalente dell'intestazione HTTP X-Forwarded-For per DNS, consentendo di trasmettere informazioni sull'indirizzo IP e sul numero di porta dell'iniziale autore della richiesta, reindirizzata attraverso proxy intermedi e bilanciatori di carico (ad esempio dnsdist). Per attivare XPF sono previste le opzioni ‘" e "«;
- Migliorato il supporto per l'estensione EDNS (ECS), che consente di trasmettere nelle richieste DNS al server DNS autoritativo informazioni sulla subnet da cui è stata inviata la richiesta originale inoltrata in cascata (i dati sulla subnet originale del client sono necessari per un’efficace operatività delle reti di distribuzione dei contenuti). Nella nuova versione sono state aggiunte impostazioni per il controllo selettivo dell’applicazione dell’EDNS Client Subnet: ‘’ con l’elenco delle maschere di rete per cui l'IP sarà utilizzato nell'ECS nelle richieste in uscita. Per gli indirizzi che non rientrano in queste maschere, sarà utilizzato l'indirizzo generale specificato nella direttiva ‘’. Tramite la direttiva ‘» è possibile definire le sottoreti, le richieste in ingresso con valori ECS riempiti che non verranno sostituiti;
- Per i server che elaborano un numero elevato di richieste al secondo (più di 100.000), è stata proposta la direttiva ««, che definisce il numero di thread per la ricezione delle richieste in ingresso e la loro distribuzione tra i thread di lavoro (ha senso solo quando si utilizza la modalità ««).
- Aggiunta l'impostazione per definire il proprio file con dei domini in cui gli utenti possono registrare i propri sottodomini, invece dell'elenco integrato nel PowerDNS Recursor.
Il progetto PowerDNS ha anche annunciato il passaggio a un ciclo di sviluppo di sei mesi, secondo il quale il prossimo significativo rilascio di PowerDNS Recursor 4.3 è previsto per gennaio 2020. Gli aggiornamenti per le versioni significative saranno elaborati nel corso dell'anno, dopodiché per altri sei mesi verranno rilasciate le correzioni delle vulnerabilità. Pertanto, il supporto per il ramo PowerDNS Recursor 4.2 durerà fino a gennaio 2021. Modifiche analoghe al ciclo di sviluppo sono state adottate per il prodotto PowerDNS Authoritative Server, il rilascio 4.2 del quale è previsto a breve.
Caratteristiche principali di PowerDNS Recursor:
- Strumenti per la raccolta remota delle statistiche;
- Riavvio istantaneo;
- Motore integrato per la connessione di gestori in linguaggio Lua;
- Supporto completo per DNSSEC e ;
- Supporto per RPZ (Response Policy Zones) e possibilità di definire liste nere;
- Meccanismi di protezione contro lo spoofing;
- Possibilità di registrare i risultati della risoluzione in forma di file di zone BIND.
- Per garantire elevate prestazioni, vengono utilizzati moderni meccanismi di multiplexing delle connessioni in FreeBSD, Linux e Solaris (kqueue, epoll, /dev/poll), così come un parser DNS ad alte prestazioni in grado di gestire decine di migliaia di richieste parallele.
Fonte: opennet.ru
