Rilascio di PowerDNS Recursor 4.2 e dell'iniziativa DNS Flag Day 2020

Dopo un anno e mezzo di sviluppo presentata rilascio della memorizzazione nella cache del server DNS Risorsa PowerDNS 4.2, responsabile della conversione ricorsiva dei nomi. PowerDNS Recursor è basato sulla stessa base di codice del server autorevole PowerDNS, ma i server DNS ricorsivi e autorevoli PowerDNS vengono sviluppati attraverso cicli di sviluppo diversi e vengono rilasciati come prodotti separati. Codice del progetto distribuito da concesso in licenza con GPLv2.

La nuova versione elimina tutte le problematiche legate all'elaborazione dei pacchetti DNS con flag EDNS. Le versioni precedenti di PowerDNS Recursor precedenti al 2016 avevano la pratica di ignorare i pacchetti con flag EDNS non supportati senza inviare una risposta nel vecchio formato, scartando i flag EDNS come richiesto dalle specifiche. In precedenza, questo comportamento non standard era supportato in BIND sotto forma di soluzione alternativa, ma nell'ambito di eseguito nelle iniziative di febbraio Giorno della bandiera DNS, gli sviluppatori di server DNS hanno deciso di abbandonare questo attacco.

In PowerDNS, i principali problemi nell'elaborazione dei pacchetti con EDNS sono stati eliminati nel 2017 nella versione 4.1 e nel ramo 2016 rilasciato nel 4.0 sono emerse incompatibilità individuali che si verificano in un determinato insieme di circostanze e, in generale, non interferiscono con il normale operazione. In PowerDNS Recursor 4.2, come in ASSOCIAZIONE 9.14, Rimosse soluzioni alternative per supportare server autorevoli che rispondono in modo errato alle richieste con flag EDNS. Finora, se dopo l'invio di una richiesta con flag EDNS non si riceveva risposta dopo un certo periodo di tempo, il server DNS presumeva che i flag estesi non fossero supportati e inviava una seconda richiesta senza flag EDNS. Questo comportamento è stato ora disabilitato poiché questo codice comportava un aumento della latenza a causa delle ritrasmissioni dei pacchetti, un aumento del carico di rete e dell'ambiguità quando non si rispondeva a causa di errori di rete e impediva l'implementazione di funzionalità basate su EDNS come i cookie DNS per la protezione dagli attacchi DDoS.

Si è deciso di tenere l'evento l'anno prossimo Giorno della bandiera DNS 2020progettato per focalizzare l'attenzione la decisione проблем con frammentazione IP durante l'elaborazione di messaggi DNS di grandi dimensioni. Nell'ambito dell'iniziativa pianificato correggere le dimensioni del buffer consigliate per EDNS su 1200 byte e tradurre l'elaborazione delle richieste tramite TCP è una funzionalità indispensabile sui server. Ora è richiesto il supporto per l'elaborazione delle richieste tramite UDP e TCP è auspicabile, ma non richiesto per il funzionamento (lo standard richiede la possibilità di disabilitare TCP). Si propone di rimuovere dallo standard l'opzione di disabilitare TCP e di standardizzare la transizione dall'invio di richieste tramite UDP all'utilizzo di TCP nei casi in cui la dimensione del buffer EDNS stabilita non è sufficiente.

Le modifiche proposte nell'ambito dell'iniziativa elimineranno la confusione nella scelta della dimensione del buffer EDNS e risolveranno il problema della frammentazione dei messaggi UDP di grandi dimensioni, la cui elaborazione spesso porta alla perdita di pacchetti e al timeout sul lato client. Sul lato client, la dimensione del buffer EDNS sarà costante e le risposte di grandi dimensioni verranno inviate immediatamente al client tramite TCP. Anche evitare di inviare messaggi di grandi dimensioni tramite UDP ti consentirà di bloccare атаки per avvelenare la cache DNS, basato sulla manipolazione di pacchetti UDP frammentati (se suddiviso in frammenti, il secondo frammento non include un'intestazione con un identificatore, quindi può essere contraffatto, per il quale è sufficiente che corrisponda solo il checksum) .

PowerDNS Recursor 4.2 tiene conto dei problemi con i pacchetti UDP di grandi dimensioni e passa all'utilizzo della dimensione del buffer EDNS (edns-outgoing-bufsize) di 1232 byte, invece del limite precedentemente utilizzato di 1680 byte, che dovrebbe ridurre significativamente la probabilità di perdere pacchetti UDP . È stato scelto il valore 1232 perché è il massimo al quale la dimensione della risposta DNS, tenendo conto di IPv6, rientra nel valore MTU minimo (1280). Anche il valore del parametro della soglia di troncamento, responsabile della riduzione delle risposte al client, è stato ridotto a 1232.

Altre modifiche in PowerDNS Recursor 4.2:

  • Aggiunto supporto per il meccanismo XPF (X-Proxied-For), che è l'equivalente DNS dell'intestazione HTTP X-Forwarded-For, che consente l'inoltro delle informazioni sull'indirizzo IP e sul numero di porta del richiedente originale tramite proxy intermedi e bilanciatori del carico (come dnsdist) . Per abilitare XPF ci sono opzioni "xpf-allow-from"E"xpf-rr-codice";
  • Supporto migliorato per l'estensione EDNS Sottorete cliente (ECS), che consente di trasmettere nelle query DNS a un server DNS autorevole informazioni sulla sottorete da cui è stata avvelenata la richiesta iniziale trasmessa lungo la catena (i dati sulla sottorete di origine del client sono necessari per l'efficace funzionamento delle reti di distribuzione dei contenuti) . La nuova versione aggiunge impostazioni per il controllo selettivo sull'uso della sottorete client EDNS: "ecs-add-for» con l'elenco delle maschere di rete per le quali verrà utilizzato l'IP in ECS nelle richieste in uscita. Per gli indirizzi che non rientrano nelle maschere previste vale l'indirizzo generale indicato nella direttiva"indirizzo-ecs-scope-zero". Attraverso la direttiva"usa-sottorete-edns in entrata» è possibile definire sottoreti da cui non verranno sostituite le richieste in entrata con valori ECS compilati;
  • Per i server che elaborano un numero elevato di richieste al secondo (più di 100mila), la direttiva “thread del distributore", che determina il numero di thread per ricevere le richieste in entrata e distribuirle tra i thread di lavoro (ha senso solo quando si utilizza il "pdns-distributes-queries=sì").
  • Aggiunta impostazione file-elenco-suffisso-pubblico con cui definire il proprio file elenco dei suffissi pubblici domini in cui gli utenti possono registrare i propri sottodomini, invece dell'elenco integrato in PowerDNS Recursor.

Il progetto PowerDNS ha inoltre annunciato il passaggio a un ciclo di sviluppo di sei mesi, con la prossima major release di PowerDNS Recursor 4.3 prevista per gennaio 2020. Nel corso dell'anno verranno sviluppati aggiornamenti per rilasci significativi, dopodiché le correzioni delle vulnerabilità verranno rilasciate per altri sei mesi. Pertanto, il supporto per il ramo PowerDNS Recursor 4.2 durerà fino a gennaio 2021. Simili modifiche al ciclo di sviluppo sono state apportate per PowerDNS Authoritative Server, di cui si prevede il rilascio della versione 4.2 nel prossimo futuro.

Caratteristiche principali di PowerDNS Recursor:

  • Strumenti per la raccolta statistica remota;
  • Riavvio istantaneo;
  • Motore integrato per la connessione di gestori nella lingua Lua;
  • Supporto DNSSEC completo e DNS64;
  • Supporto per RPZ (Response Policy Zones) e possibilità di definire blacklist;
  • Meccanismi anti-spoofing;
  • Possibilità di registrare i risultati della risoluzione come file di zona BIND.
  • Per garantire prestazioni elevate, in FreeBSD, Linux e Solaris vengono utilizzati moderni meccanismi di multiplexing della connessione (kqueue, epoll, /dev/poll), nonché un parser di pacchetti DNS ad alte prestazioni in grado di elaborare decine di migliaia di richieste parallele.

Fonte: opennet.ru

Aggiungi un commento