NSD 4.14 riduce l'uso di memoria del server DNS con nuovo storage RDATA e opzioni opzionali in fase di compilazione

I server DNS traducono i nomi di dominio leggibili in indirizzi numerici usati dai computer, e i server autorevoli detengono i record ufficiali per un dominio. NLnet Labs, l'organizzazione no-profit olandese dietro al software NSD per server autorevoli, ha rilasciato NSD 4.14.0 il 4 dicembre con un cambiamento importante: i dati dei record di risorse (RDATA) non sono più memorizzati come una lista di puntatori a singoli campi, ma come un blob binario opaco per la maggior parte dei tipi di record. Questo approccio 'pigro' risparmia memoria e tempo di elaborazione perché i server autorevoli raramente devono ispezionare i singoli campi all'interno di un record, a meno che non stiano scrivendo un file di zona. Il risultato è un'impronta di memoria più piccola per le zone, specialmente per quelle con molti record che hanno un gran numero di campi.

Prima della versione 4.14.0, NSD manteneva ogni campo di un record di risorse separatamente in memoria, insieme ai puntatori a quei campi e allo spazio sprecato per l'allineamento dei dati su confini di 64 bit. Il nuovo approccio memorizza la maggior parte dei tipi di record come un singolo blob binario opaco. I campi dei nomi di dominio che possono essere compressi nelle risposte sono ancora memorizzati per riferimento, così la compressione rimane efficiente. I tipi di record con molti campi beneficiano maggiormente, come NSEC3 e RRSIG, che hanno entrambi otto campi RDATA. La zona .nl è un esempio lampante: ha più di 6 milioni di deleghe, più del 62% delle quali sono sicure (firmate DNSSEC), e utilizza NSEC3 opt-in, il che significa che c'è un record NSEC3 per ogni nome. NLnet Labs ha un accordo di lunga data con SIDN, il registro per .nl, per utilizzare la zona per ricerca e miglioramento del software. Con il nuovo storage, NSD richiede il 14,9% di memoria in meno per la zona .nl.

Due opzioni di compilazione possono ridurre ulteriormente la memoria. L'opzione --enable-packed elimina il requisito che i membri delle strutture siano allineati su un tipico confine di 4 byte, eliminando gli spazi tra i membri. Non tutte le architetture CPU supportano l'accesso alla memoria non allineato, e su alcune può comportare una penalità nelle prestazioni, quindi è disabilitata per impostazione predefinita. In pratica, il team di NLnet Labs ha osservato solo miglioramenti delle prestazioni, probabilmente perché i dati correlati sono più vicini nella cache della CPU. L'opzione --disable-radix-tree passa dalla struttura dati predefinita ad albero radix a un albero rosso-nero, che usa meno memoria ma a scapito delle prestazioni; per zone molto grandi questo può essere comunque pratico. Combinato con il nuovo storage RDATA, l'opzione packed produce un'ulteriore riduzione del 16,2% oltre al proprio risparmio del 14,2% per .nl. Per la zona .com, che ha relativamente poche deleghe sicure (4,2%) e usa NSEC3 opt-out, il nuovo approccio RDATA da solo dà solo una riduzione del 2,4%, ma combinando tutte le opzioni di riduzione della memoria si porta la memoria necessaria per servire .com comodamente sotto il limite di 64 gigabyte.

La Tabella 1 nel post originale elenca le riduzioni su sei zone: .lol 18,3%, .se 17,7%, .nl 14,9%, .net 2,6%, .org 2,6%, .com 2,4%. Con --enable-packed, le riduzioni salgono al 33,4% per .lol, 28,1% per .se, 30,4% per .nl, 19,6% per .net, 19,4% per .org e 19,3% per .com. Con --disable-radix-tree da solo, i numeri sono rispettivamente 41,4%, 31,8%, 46,5%, 32,9%, 33,1% e 31,3%. Combinando entrambe le opzioni si ottiene 51,0% per .lol, 39,5% per .se, 55,2% per .nl, 44,0% per .net, 43,9% per .org e 42,6% per .com. Le zone hanno proprietà diverse: .com è una grande zona firmata NSEC3 opt-out con il 4,2% di deleghe sicure, .net e .org sono simili con circa il 5% di deleghe sicure, .nl usa NSEC3 opt-in con il 62,2% di deleghe sicure, .se è una zona firmata NSEC un po' più grande con il 61,3% di deleghe sicure, e .lol è una piccola zona firmata NSEC con il 9,0% di deleghe sicure.

Dopo il rilascio della 4.14.0, un utente ha segnalato che il consumo di memoria in realtà aumentava nella sua configurazione. Le zone interessate avevano un numero relativamente piccolo di RRset ma un numero molto grande di record di risorse per set, spesso migliaia. NSD faceva crescere questi RRset aggiungendo ogni record singolarmente, allocando nuovo spazio e deallocando vecchio spazio in un cestino di riciclo che non riutilizzava mai le dimensioni dispari. La correzione in NSD 4.14.1 fa crescere gli RRset in lotti anziché un record alla volta. L'uso di memoria segnalato con la correzione è quasi un sesto di quello che era prima della 4.14.0 per quel tipo di zona. Questo è importante per gli operatori che servono zone con molti record in un singolo RRset, come grandi liste di blocco basate su DNS o server di posta con molti record MX della stessa preferenza.

Anche il caricamento e la scrittura delle zone sono diventati più rapidi. Scrivere o stampare le zone è più veloce anche senza opzioni extra, e con --enable-packed è circa il 18% più veloce per .nl, il 6,7% più veloce per .net e .org, e il 25% più veloce per .se e .lol. I tempi di caricamento delle zone migliorano ulteriormente quando combinati: 21,7% per .lol, 19,6% per .se, 12,4% per .nl, 7,9% per .com, 3,9% per .org e 4,7% per .net. Questi miglioramenti contano perché l'infrastruttura DNS alimenta ogni visita a siti web e ogni email, e server efficienti riducono i costi operativi e la latenza. Per i proprietari di siti web e i team IT che gestiscono il proprio DNS o si affidano a provider di hosting, questo tipo di efficienza di memoria nei server autorevoli mantiene la rubrica di Internet veloce e affidabile; allo stesso tempo, usare un servizio DNS crittografato che mette la privacy al primo posto come AEU DNS per le proprie query aggiunge un livello di protezione contro tracciamento e manipolazione.