Dopo un anno e mezzo di sviluppo rilascio del server DNS con caching , responsabile della risoluzione dei nomi. PowerDNS Recursor è 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 è sotto licenza GPLv2.
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 di febbraio dell'iniziativa , gli sviluppatori di server DNS hanno deciso di abbandonare questo hack.
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 , 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.
Next year, it has been decided to hold an event , aimed at focusing attention on con frammentazione IP durante l'elaborazione di messaggi DNS di grandi dimensioni. Nell'ambito dell'iniziativa fissare le dimensioni consigliate dei buffer per EDNS a valori intorno ai 1200 byte, così come l'elaborazione delle richieste TCP in una funzione obbligatoria sui server. Attualmente, è obbligatoria la supporto per l'elaborazione delle richieste UDP, mentre TCP è desiderabile ma non essenziale per il funzionamento (lo standard prevede la possibilità 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.
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à costante, le risposte grandi verranno immediatamente inviate al client tramite TCP. L'esclusione dell'invio di grandi messaggi tramite UDP consentirà anche di bloccare 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ò essere falsificato a condizione che la somma di controllo corrisponda).
In PowerDNS Recursor 4.2 sono stati considerati i problemi con pacchetti UDP di grandi dimensioni e c'è 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à di perdita di pacchetti UDP. Il valore 1232 è stato scelto perché rappresenta il massimo in cui la dimensione della risposta DNS, tenendo conto di IPv6, rientra nel valore minimo di MTU (1280). Fino a 1232 è stato ridotto anche il valore del parametro truncation-threshold, che gestisce il taglio delle risposte al client.
Altre modifiche in PowerDNS Recursor 4.2:
- È stato aggiunto il supporto per il meccanismo (X-Proxied-For), che rappresenta l'equivalente dell'intestazione HTTP X-Forwarded-For per DNS, consentendo il passaggio di informazioni sull'indirizzo IP e sul numero di porta dell'originatore della richiesta, reindirizzata attraverso proxy intermedi e bilanciatori di carico (ad esempio dnsdist). Per abilitare XPF sono previste opzioni «» e ««;
- Migliore supporto per l'estensione EDNS (ECS), che consente di trasmettere nelle richieste DNS a un server DNS autoritativo informazioni sulla sottorete da cui è stata inviata la richiesta originale, tramite una catena di trasmissione (i dati sulla sottorete originaria del cliente sono necessari per il funzionamento efficace delle reti di distribuzione dei contenuti). Nella nuova versione sono state aggiunte impostazioni per il controllo selettivo dell'applicazione del Client Subnet EDNS: «» con un elenco di maschere di rete per le quali l'IP sarà utilizzato in ECS nelle richieste in uscita. Per gli indirizzi che non rientrano nelle maschere specificate, verrà utilizzato l'indirizzo generale indicato nella direttiva ««. Tramite la direttiva «» è possibile definire le sottoreti da cui le richieste in arrivo con valori ECS compilati non saranno sostituite;
- Per i server che gestiscono un alto numero di richieste al secondo (oltre 100.000), è stata proposta la direttiva ««, che determina il numero di thread per la ricezione delle richieste in entrata e la loro distribuzione tra i thread di lavoro (ha senso solo quando si utilizza la modalità ««).
- È stata aggiunta l'impostazione per definire un proprio file con dei domini in cui gli utenti possono registrare i propri sottodomini, invece dell'elenco incorporato in PowerDNS Recursor.
Il progetto PowerDNS ha anche annunciato il passaggio a un ciclo di sviluppo di sei mesi, secondo il quale il prossimo rilascio significativo di PowerDNS Recursor 4.3 è previsto per gennaio 2020. Aggiornamenti per rilasci significativi saranno formati nel corso dell'anno, dopodiché per sei mesi verranno rilasciate correzioni per le vulnerabilità. Pertanto, il supporto per il ramo PowerDNS Recursor 4.2 durerà fino a gennaio 2021. Cambiamenti simili nel ciclo di sviluppo sono stati adottati anche per il prodotto PowerDNS Authoritative Server, il rilascio 4.2 del quale è atteso a breve.
Caratteristiche principali di PowerDNS Recursor:
- Strumenti per la raccolta remota delle statistiche;
- Riavvio istantaneo;
- Motore integrato per collegare i gestori in linguaggio Lua;
- Supporto completo per DNSSEC e ;
- Supporto per RPZ (Response Policy Zones) e possibilità di definire liste nere;
- Meccanismi di lotta contro lo spoofing;
- Possibilità di registrare i risultati della risoluzione come file di zone BIND.
- Per garantire alte prestazioni vengono utilizzati moderni meccanismi di multiplexing delle connessioni su FreeBSD, Linux e Solaris (kqueue, epoll, /dev/poll), oltre a un parser DNS ad alte prestazioni in grado di gestire decine di migliaia di richieste parallele.
Fonte: opennet.ru
