Propongo, con il permesso dell’autore, la mia versione dall’inglese di questo interessante articolo di Geoff Huston apparso nel mese di agosto 2014 su The ISP column dal titolo “The Cost of DNSSEC“.

Ti occupi di DNS e non hai ancora abilitato DNSSEC? Dovresti proprio considerare di farlo sui server che gestisci. Esistono diverse forme di insidiosi attacchi che prima compromettono il DNS e poi dirottano un ignaro utente dove vogliono. DNSSEC invece consente a un risolutore dei nomi di evitare che una richiesta valida conduca a una errata ridirezione. Ma non si può avere la botte piena e la moglie ubriaca, dunque la decisione di implementare DNSSEC comporta un certo costo addizionale in termini di maggior traffico e maggior durata del processo di risoluzione del nome. In questo articolo considererò quanto abbiamo osservato durante un esperimento su vasta scala circa l’adozione di DNSSEC nell’ottica di poter rispondere alla seguente domanda: qual è il maggior costo di implementare DNSSEC?

Come si sa, ci sono due punti di vista nel DNS: quello del risolutore (o del client) e quello di un server autoritativo, quindi esaminiamoli entrambi, prima uno poi l’altro.

DNSSEC sul risolutore dei nomi

Innanzitutto la prospettiva di un client del DNS. Qual è il costo di impiegare DNSSEC per la validazione delle risposte DNS?

A intuito ci aspetteremmo che un risolutore impiegasse un po’ più di tempo per risolvere un nome e per inviare richieste aggiuntive come parte del processo di validazione della risposta quando si risolve un nome associato a una zona firmata DNSSEC. Le risposte che il risolutore in questo caso riceverà saranno anche più lunghe dato che le risposte ricevute includeranno i dati della firma DNSSEC.

Possiamo quantificare la differenza?

Esaminiamo il comportamento di un risolutore confrontando cosa succede con e senza DNSSEC.

Prima osserviamo un tracciato di risoluzione DNS richiedendo un nome a 5 etichette quando il risolutore non ha cache e non esercita alcuna validazione DNSSEC (vedi Registro Pacchetti 1). L’intero processo di risoluzione impiega 4 richieste al DNS per una durata totale di 0,535 secondi. In termini di traffico DNS la risoluzione di questa richiesta ha generato 292 byte di traffico in uscita e un totale di 1.622 byte di risposte ricevute. Tuttavia le richieste al server radice dei nomi e al server dei nomi per .net, hanno attivato, in una qualche misura, la cache locale del DNS. Se facessimo una seconda richiesta usando lo stesso risolutore entro pochi secondi dalla prima modificando solo l’etichetta finale, il processo di risoluzione del nome sarebbe molto più rapido ed efficiente generando una singola richiesta e una singola risposta, per una durata totale di 191 millisecondi, 83 byte per la richiesta e 134 byte per la risposta (vedi Registro pacchetti 2).

Possiamo confrontare questo risultato con una richiesta DNS fatta per risolvere un nome simile ma avendo configurato il risolutore per operare la validazione DNS e con il nome richiesto firmato DNSSEC (vedi Registro pacchetti 3). Comprese le richieste della chiave del server radice, il risolutore, con cache completamente vuota, ha inviato 20 richieste al DNS in 2,102 secondi generando un traffico di 1.446 byte in uscita e 13.026 byte in entrata come risposte. Una durata quattro volte maggiore e un traffico otto volte quello del caso senza DNSSEC. Ovviamente una volta popolata la cache l’ingombro del DNSSEC è minore e un cambio nell’etichetta finale comporta una sola richiesta (vedi Registro pacchetti 4). Ciononostante, la risposta del DNS è otto volte più lunga nel caso firmato. L’uso della cache nel risolutore è uno strumento molto potente e di sicuro migliora le prestazioni del DNS, ancora di più nel caso di DNSSEC. La Tabella 1 mostra un confronto tra questi casi.

Tabella 1. Risoluzione DNS di un nome da 5 etichette con e senza validazione DNSSEC

Seriale vs Parallelo nelle richieste di validazione

La prestazione del risolutore basato su Bind 9.9 [ISC BIND, ndt], quello usato per generare questi log, può essere notevolmente migliorata cambiando la natura seriale della procedura di validazione della firma di DNSSEC in una procedura in parallelo all’interno del risolutore DNS. In questo caso ci sono 14 richieste consecutive che sono impiegate per il processo di validazione della firma DNSSEC e questo comporta 12 diversi intervalli di richiesta/risposta. Tranne solo due eccezioni, tutte le richieste vengono poste in una coda seriale e attendono il positivo completamente della richiesta precedente prima di venire immesse sulla rete.

Tuttavia, come provato in altri esperimenti con varie permutazioni di configurazioni per validare firme appositamente rese difettose, il processo di validazione attraverso il confronto delle chiavi fatto dal risolutore non viene cominciato fino a che l’intero processo di richiesta DNS di RR DNSKEY e DS non sia terminato. Un approccio più rapido sarebbe quello di mettere una più grande quantità di queste richieste in parallelo. Se Bind fosse in grado di mettere in parallelo questo processo e avesse, per dire, venti richieste in sospeso in un qualsiasi momento, il tempo per preparare la cache di un risolutore con validazione sarebbe ridotto da 2,102 secondi a 0,725 secondi, o impiegherebbe solo un maggiore intervallo (190 millisecondi) richiesta/risposta rispetto al caso non firmato senza validazione.

Inoltre non è chiaro perché il risolutore Bind 9.9 ridiriga le richieste di un record DS di una zona al nonno prima di chiedere nuovamente la zona padre. Queste richieste al server della zona nonno falliscono poiché il servizio autoritativo della zona nonno in questo caso non conosce i record DS della zona nipote. Se questo è un qualche tentativo di ottimizzazione delle richieste DNS è difficile comprendere con precisione cosa venga ottimizzato attraverso questo comportamento.

Si possono confrontare questi risultati di laboratorio con ciò che capita dal vero? Come parte di un programma di misurazione dell’adozione di DNSSEC su Internet, abbiamo chiesto agli utenti finali di recuperare due URL distinti (non presenti in cache). Uno è un nome firmato con DNSSEC, l’altro non è firmato.

Quanto tempo in più occorre ai client per usare dei risolutori che facciano validazione DNSSEC di un nome firmato e non presente in cache, rispetto a usare un risolutore che non consideri il DNSSEC nella risoluzione di un nome non firmato?

Operiamo delle misure lato server contando quanto tempo trascorre dalla ricezione della prima richiesta DNS per un predeterminato nome fino alla ricezione del comando HTTP GET. Quando osserviamo client che non usano risolutori DNSSEC e confrontiamo il tempo per risolvere un nome DNS non firmato e non presente in cache con quello per risolvere un nome DNS firmato e non presente in cache, registriamo una distribuzione cumulativa come mostrato in Figura 1 alla voce “No-DNSSEC”. Il 20% circa degli utenti finali riesce a risolvere il nome firmato DNSSEC più rapidamente di quello non firmato. Questo sembra essere parte della variazione sperimentale riscontrata all’interno del sistema di scripting Flash usato nel processo sperimentale dove il processo di risoluzione DNS sembra non essere strettamente correlato con il sottosistema di recupero URL. Allo stesso modo, il 20% circa degli utenti impiega maggior tempo per processare il nome a dominio firmato DNSSEC, nonostante i risolutori usati non operino alcuna richiesta dei Resource Record (RR) legati al DNSSEC. Dunque la serie di dati “No-DNSSEC” rappresenta, in questo esperimento, il profilo di “controllo”. La serie di dati “DNSSEC-Validating” rappresenta la medesima misura rilevata per utenti che usano risolutori DNS abilitati alla validazione DNSSEC. In questo caso il punto mediano di questa seconda serie di dati rappresenta una componente di tempo maggiore di 300ms per risolvere un nome firmato DNSSEC, cosa che è coerente con l’osservazione che in questo caso le richieste in più che vengono effettuate sono per Resource Record (RR) DNSKEY della zona finale e una richiesta RR DS delle chiavi KSK e ZSK, come riportato dalla zona padre, e sembra che molti risolutori effettuino queste richieste addizionali in modo sequenziale. Mentre la validazione coinvolgerebbe necessariamente la ricostruzione della catena delle chiavi DNSSEC attraverso la chiave radice, molti di questi dati vengono messi in cache dai risolutori impiegati da questi client dato che la quantità di richieste delle chiavi di zona per le comuni zone padri è nettamente inferiore rispetto alla quantità di richieste delle singole zone finali.

Concentrazione dei risolutori DNS su Internet

La cache del DNS è assai efficace su Internet e probabilmente il DNS gode, caso unico, di una alto rapporto di efficienza della cache se confrontato con qualsiasi altra applicazione o servizio Internet. La ragione risiede in parte nella concentrazione dell’uso di un piccolo insieme di risolutori DNS da parte di una stragrande moltitudine di utenti finali.

Nel corso del nostro esperimento, su circa 40 milioni di singole misurazioni DNS condotte negli ultimi sei mesi, il 20% dei dispositivi degli utenti finali usa appena 100 risolutori e solo l’1% dei 500mila risolutori visibili sono usati dall’82% dei dispositivi degli utenti finali. Ne consegue che appena uno di questi super-attivi risolutori visibili mette in cache una risposta, sùbito una grandissima porzione di dispositivi finali trae vantaggio dalla cache del risolutore.

Distribuzione di risolutori DNS nei client

Sembra che la maggiore componente del “costo” del DNSSEC per il client sia il maggior tempo impiegato per recuperare le credenziali DNSSEC e questo costo viene esacerbato dalla serializzazione che molti resolver adottano per recuperare queste firme. Tuttavia questo costo viene efficacemente mitigato dalla cache e l’aumento del costo per risolvere nomi DNS comunemente richiesti è minimo per l’enorme numero di utenti finali grazie ai due fattori della concentrazione dei risolutori ricorsivi e della cache. Se l’utente finale si appoggiasse al risolutore locale per la validazione DNSSEC, il risultato di usare la cache eliminerebbe quel maggior costo per il client. Se il client operasse autonomamente la validazione delle risposte DNS, allora la componente della validazione aggiungerebbe un ulteriore ciclo di richieste al risolutore locale per recuperare i dati della firma DNSSEC laddove non fosse già presente nella cache del risolutore locale.

Osserviamo che in questi casi dove il client può risolvere il nome DNS in una singola richiesta (tra l’80% e il 90% di tutti i client), il maggior tempo impiegato per la validazione DNSSEC ammonta a circa 500ms in più rispetto alla risoluzione di un nome non in cache. Si ricordi che i dati presentati sopra si riferiscono a un nome DNS non in cache. La cache DNS riduce efficacemente questa penalizzazione di durata così che la reale esperienza non sarebbe peggiore rispetto ai dati qui mostrati e, anzi, sarebbe di gran lunga migliore.

C’è da considerare un ulteriore aspetto potenzialmente rilevante per l’esperienza del client. Le firme DNSSEC comportano grandi risposte DNS e sussiste un persistente sospetto che alcune parti di Internet risiedano ancora dietro del middleware convinto che il DNS sia un protocollo UDP quando sia la richiesta sia la risposta non superino i 512 byte. Se fosse vero allora esisterebbe un visibile sottoinsieme di utenti finali incapaci di risolvere nomi firmati DNSSEC.

Si capisce questo dai dati dell’esperimento?

Un metodo per cercare tali modelli d’uso è di isolare l’esperimento DNSSEC e cercare un modello di comportamento che possa derivare dall’impossibilità per un client di risolvere un nome firmato DNSSEC. In questo esperimento usiamo tre URL. Uno non firmato, uno firmato con una firma DNSSEC valida e un altro pure firmato ma con la catena di validazione deliberatamente resa difettosa. Una volta che l’utente finale porta a termine l’esperimento allora si danno questi casi:

– se non riesce a risolvere nessun nome firmato DNSSEC, vediamo allora tre tentativi di risoluzione per tutti e tre i singoli URL ma richieste web per il solo URL con il nome DNS non firmato;
– se non riesce a risolvere un nome firmato DNSSEC ci aspettiamo anche di vedere che tutte le richieste DNS per il nome firmato includano l’estensione EDNS0 con il flag DNSSEC OK (DO, ndt) impostato.

Il problema nel contesto di questo specifico esperimento che abbiamo usato per raccogliere i dati DNS è che non possiamo essere certi che tutti gli utenti completino il recupero di tutti e tre gli URL. L’esperimento termina prematuramente quando l’utente abbandona la pagina web che contiene l’esperimento e lo script di controllo dell’esperimento, Adobe Flash, sembra eseguire le tre connessioni in un ordine casuale. Quindi possiamo anticipare una quantità di “abbandono” per ciascuno dei tre URL. Se c’è un segnale legato all’impossibilità di risolvere nomi firmati DNSSEC allora ci aspettiamo che la quantità di abbandono conseguenti alle condizioni spiegate sopra sia più alta di quella conseguente ad altre combinazioni di abbandono e connessioni. Ci occorre un paio di esperimenti di controllo per evidenziare il sottostante modello di abbandoni casuali. Il primo controllo è il numero degli utenti finali che recuperano i nomi firmati DNSSEC ma non quelli non firmati. Il secondo è il numero di utenti che recuperano l’URL non firmato e quello con firma difettosa. Il terzo controllo è il numero di utenti che recuperano l’URL non firmato ma non quello firmato e non hanno necessariamente impostato il bit DNSSEC OK in modo esclusivo nelle loro richieste. La Figura 2 mostra il risultato di questa misura su 56milioni di punti di campionamento durante 9 mesi. I tre tassi di abbandono usati come controllo sono coerenti l’uno con l’altro e si attestano attorno allo 0,1%-0,3% degli utenti, mentre il tasso di abbandono nella risoluzione DNSSEC è dello 0,02% inferiore rispetto ai tre controlli e non più alto. Questi dati portano all’evidenza che a questo livello di risoluzione non vi è alcun segnale visibile che possa indicare che esiste una popolazione di utenti non in grado di risolvere un nome DNS firmato DNSSEC. I dati non rivelano alcun significativo “tasso di abbandono” del DNSSEC nella Rete di oggi.

È doveroso ora un avvertimento circa i limiti di questo particolare esperimento. Nessuna delle risposte firmate alle richieste DNSSEC è più grande di 1.280 ottetti, figuriamoci 1.500 ottetti. Questo comporta che non stiamo generando alcun tipo di frammentazione del pacchetto UDP né in IPv4 né in IPv6. Dunque lo specifico punto di fallimento in questo particolare esperimento consisterebbe in quei risolutori residenti dietro sistemi che impostano un limite di 512 byte nella grandezza massima delle risposte DNS, tranne il caso in cui il risolutore abbia abilitato EDNS0 nelle richieste. Sarebbe utile ripetere questo esperimento utilizzando una risposta DNSSEC più grande di 1.500 ottetti per vedere dove la frammentazione UDP, o IPv4 o IPv6, causi un elevato tasso di scarto dovuto alla mancata risoluzione DNS con così grandi risposte. Si potrà fare in un futuro percorso di questo esperimento.

Quanto costa dunque ai client se il loro risolutore abilita la validazione DNSSEC? Considerando la presenza della cache, il maggior costo sembra essere largamente trascurabile. L’aggiornamento della cache assorbe ulteriori cicli e il tempo di aggiornamento varia a seconda della profondità dell’etichetta, lo stato delle cache locali e il percorso di rete tra il risolutore e il server dei nomi autoritativo.

DNSSEC sul server

Qual è il maggior costo del DNSSEC quando si considerano i server dei nomi autoritativi? Che differenza di carico c’è quando si deve servire una zona firmata rispetto a una non firmata? E quali previsioni si possono fare se si considera l’ipotetico scenario dove ogni risolutore DNS effettui la validazione DNSSEC?

In questo esperimento usiamo un nome con 5 etichette significative. La quinta si traduce in un jolly nella zona finale mentre la quarta è volutamente univoca e noi osserviamo il carico che queste zone, con nomi univoci e firmate, provocano sul server autoritativo dei nomi.

Ci si aspetta che la delega del nome e le informazioni di chiave dalle tre etichette iniziali siano messe in cache così che il carico della richiesta che viene qui considerata sia effettivamente quello della quarta etichetta. Per una zona non firmata osserviamo una singola richiesta al server autoritativo, una richiesta da 128 byte e una risposta da 179 byte.

Quando la zona è firmata DNSSEC e il risolutore è abilitato DNSSEC, si notano comunemente altre 2 richieste, una per la chiave di firma della zona nella zona stessa (il Resource Record DNSKEY) e una seconda per KSK e ZSK, dove la richiesta viene diretta alla zona padre del server (il RR DS). In questo caso, dato che il server è autoritativo per entrambe le zone firmate e la zona padre, entrambe le richieste sono visibili sul server autoritativo dei nomi. Il risultato è che il server ha ora tre richieste per un totale di 287 byte e 2.251 byte di risposte, nel caso del nostro esperimento. La qual cosa ci porterebbe a concludere che il costo di servire una zona firmata DNSSEC comporta un aumento nel carico della richiesta di un fattore due (o di tre se il server autoritativo serve anche la zona padre) e un aumento nel traffico della risposta per un fattore di 11 (o di 12 se serve pure la zona padre) quando risponde a un risolutore abilitato DNSSEC.

Cosa apprendiamo da questo esperimento?

In questo esperimento il server autoritativo dei nomi era autoritativo per entrambe le zone finali firmate e per la zona padre comune e dunque c’era da aspettarsi che il server vedesse entrambe le richieste di RR DNSKEY per la zona finale firmata e la richiesta di RR DS per la stessa zona che è stata inviata alla zona padre. I risultati su un periodo di 8 mesi, da dicembre 2013 a luglio 2014, sono mostrati nella Figura 3.

Il traffico di risposta alla richiesta della zona firmata ha superato, a dicembre 2013, di 7 volte quello della zona non firmata e di 8 volte a luglio 2014. Molto probabilmente l’aumento è dovuto alla crescita del numero dei risolutori DNSSEC che eseguono la validazione DNSSEC avvenuta in questo stesso periodo rispetto a qualsiasi cambiamento nel comportamento dei singoli risolutori.

Quello che i dati sembrano voler dire è che se prendi una zona DNS non firmata e la firmi, allora il server autoritativo dei nomi vedrà un aumento di circa 8 volte nel traffico di risposta DNS in uscita. Oggi circa il 20% dei client su Internet usa dei risolutori DNS in grado di effettuare validazione DNSSEC. Se tutti i risolutori effettuassero la validazione DNSSEC osserveremmo un aumento nelle risposte DNS fino a 40 volte il carico prodotto da un nome non firmato? E se così fosse, come potremmo spiegare questi dati con una teorica previsione di circa 12 volte il traffico?

La risposta si trova nell’uso dell’estensione EDNS0 e nell’uso, all’interno di quella estensione, dell’impostazione DNSSEC OK. Mentre circa l’80% dei client su Internet stan usando risolutori DNS che non effettuano alcuna validazione delle firme DNSSEC, circa l’85% dei client usa risolutori che includono l’estensione EDNS0 nelle loro richieste e impostano il bit DNSSEC OK di questa estensione. In altre parole, circa due terzi degli utenti di Internet usano risolutori DNS che stanno già chiedendo che le firme DNSSEC siano incluse nella risposta alle loro richieste ma poi non si curano di validare le firme! Quindi oggi abbiamo solo circa il 20% dei client che usa risolutori DNS in grado di operare qualche forma di validazione della firma DNSSEC, ma a causa della diffusione del meccanismo EDNS0, notiamo già un traffico di risposta alle richieste aumentato di 7-8 volte. Se questo 20% crescesse fino al 100%, quando cioè tutti i risolutori fossero capaci di effettuare la validazione DNSSEC, allora l’aumento della quantità di traffico presso il server autoritativo dei nomi non sarebbe di 40 volte, ma di un più modesto fattore intorno a 11 o 12, un dato che sarebbe coerente con il calcolo teorico fatto all’inizio.

Se ignorassimo il fattore grandezza e considerassimo solo il numero delle richieste, allora la zona firmata DNSSEC ne conterebbe circa una volta e mezza rispetto a quella non firmata. (vedi Figura 4). La teoria ci dice che la zona firmata DNSSEC riceve 3 richieste da parte dei risolutori con validazione DNSSEC, dunque se il 20% dei client usasse risolutori con validazione DNSSEC allora il server autoritativo dei nomi vedrebbe moltiplicato il carico delle richieste per 1,4. L’aumento per 1,6 del carico di richieste è coerente con la zona firmata DNSSEC che riceve 4 volte le richieste della zona non firmata. Il motivo di questa discrepanza è dovuto in parte a un lento aumento nel numero delle richieste duplicate osservate sul server autoritativo dei nomi, dove altri risolutori DNS fanno al server la stessa domanda virtualmente in parallelo. Questo è stato notato su risolutori che sembrano far parte di un cluster, dove la richiesta originaria viene inviata a più risolutori in parallelo per ottenere un miglioramento in robustezza e prestazioni della cache della batteria di risolutori.

In questo caso gli effetti della cache del nome non sono necessariamente un elemento di queste speculazioni. Mentre l’esperimento usa nomi univoci che non sono reperibili nella cache di un risolutore DNS, la situazione è simile a quella di un nome altamente usato dove singoli risolutori aggiornano periodicamente la loro cache dal server autoritativo dei nomi. Quello che ci interessa non è il numero esatto delle richieste e dei byte, ma il rapporto di questi numeri tra il servire un nome firmato DNSSEC e un nome non firmato.

Oggigiorno, l’implementazione del DNSSEC di un nome a dominio provocherebbe un aumento nel carico totale della richiesta ai server autoritativi dei nomi di circa una volta e mezza e moltiplicherebbe il traffico in uscita di circa 8 volte. Possiamo anche prevedere che, se tutti su Internet utilizzassero risolutori con validazione DNSSEC, la firma di un nome comporterebbe un costo sul server autoritativo pari a circa 4 volte il carico di richieste e circa 12 volte il carico di traffico per le risposte.

Firma corretta vs firma difettosa

I risultati finora confrontano la risoluzione DNS di un nome che non è firmato con quella di uno firmato DNSSEC. Ma, al di là delle migliori intenzioni, ci sono volte in cui la validazione di una firma DNSSEC fallisce. Questo può accadere per molte ragioni. Le chiavi di firma possono scadere, la relazione tra chiavi padre/figlio possono fallire oppure la zona può essere corrotta in diversi modi. Inoltre, il problema potrebbe non essere esclusivamente correlato al file di zona e ai suoi server autoritativi dei nomi. Il risolutore potrebbe non supportare l’algoritmo di firma o il priming della chiave radice potrebbe essere scaduto (vedi ad esempio “Rollover and Die“).

Che succede quando la validazione fallisce?

Dal punto di vista dell’utente finale risulta chiaro che ci sia un problema, ma non è chiaro quale sia. Quando un risolutore abilitato alla validazione DNSSEC incontra un problema di validazione, restituisce una risposta alla richiesta originaria con un codice che, in modo piuttosto criptico, dice che si tratta di un “errore del server”. L’interpretazione autentica di questo codice è che il nome di cui si chiede la risoluzione può essere perfettamente valido, ma il server che ha tentato la risoluzione non è stato in grado di farla. Ora ecco spiegata la ragione per cui molti client utilizzano più di un risolutore. Se la richiesta a un risolutore fallisce, il passo seguente è di inoltrare la richiesta all’altro. Anche quando la richiesta fallisce con lo stesso codice di errore, non tutto è perduto. La richiesta può essere ripetuta con l’opzione di dimensione in EDNS0 impostata a 512. Quindi i client tendono a reiterare le richieste quando usano risolutori che fanno validazione DNSSEC e quando la firma DNSSEC è difettosa.

Non sono soltanto i client finali che ripetono le richieste. Come illustrato nell’articolo “Rollover and Die“, alcune vecchie versioni di risolutori DNS risalgono la gerarchia della delega e tentano di validare la firma DNSSEC usando tutti i possibili vettori dei server della zona nella sequenza della richiesta di firma. Solo quando questa lunga richiesta fallisce allora il risolutore restituisce un codice di “errore del server”.

L’impatto di questa diligenza da parte dei risolutori nel tentare di trovare un buon percorso per la validazione della firma digitale, viene illustrato nella Figura 5. Un quarto di tutti i client che effettuano la validazione DNSSEC usa risolutori capaci di validazione che fanno richieste di un nome con firma DNSSEC difettosa per più di 6 secondi. Un sesto di questi client usa risolutori capaci di validazione che insistono nel tentativo di trovare un buon percorso di validazione per più di 20 secondi. Quindi l’impatto su un client, che fa uso di risolutori capaci di validazione DNSSEC quando la firma è difettosa, è ovviamente che il nome non può essere risolto, ma per molti di loro questa brutta notizia impiega un tempo estremamente lungo ad arrivare.

Dunque si può quantificare il fattore di amplificazione delle richieste a un server dei nomi autoritativo quando una firma DNSSEC fallisce? Il profilo di traffico derivante dal servire un nome correttamente firmato e un nome con firma difettosa è illustrato nella Figura 6. Il nome con firma malformata genera un traffico tre volte superiore a quello di un nome con firma corretta. Da ciò si deduce che se tutti i risolutori DNS fossero capaci di DNSSEC allora il server autoritativo dei nomi vedrebbe un aumento di 24 volte il traffico rispetto a un nome non firmato. Tuttavia, il confronto tra nomi firmati in modo giusto e quelli in modo sbagliato non è poi così ampio e l’impatto osservato di una firma errata è circa tre volte il traffico rispetto a quello di una corretta.

Si tratta comunque più di un limite inferiore piuttosto che di un indicatore realistico su cosa aspettarsi. Quando abbiamo esaminato nella Figura 4 il rapporto del traffico generato dalla risoluzione di un nome non firmato rispetto a uno correttamente firmato, abbiamo commentato che tale rapporto non sarebbe stato alterato se il nome fosse stato messo in cache poiché i parametri della cache erano identici per entrambi i nomi. Quello che il server autoritativo dei nomi vede come richieste in ingresso sono quelle che hanno generato un MISS nella cache del risolutore locale.

D’altronde, se il nome è firmato male, i risolutori capaci di DNSSEC non dovrebbero mettere in cache la risposta dato che il prodotto della risoluzione del nome non è attendibile. Ne consegue che il relativo fattore di carico di 10 volte si riferisce solo al confronto della risoluzione di nomi non presenti in cache. Se convenzionalmente è possibile mettere in cache il nome e la firma DNSSEC fallisce, allora l’aumento nel tasso di richieste e traffico presso il server autoritativo dei nomi è più grande poiché ogni risolutore capace di DNSSEC genererà un MISS nella cache per ciascun tentativo di risoluzione del nome.

L’aumento del carico di traffico come risultato di una errata firma DNSSEC dipende dagli originari parametri della cache e dal tasso di successo della cache originaria. L’aumento nel carico presso il server autoritativo dei nomi come conseguenza di una firma DNSSEC non valida potrebbe essere arbitrariamente grande dato che il risultato è il prodotto di un fattore di amplificazione di 3 volte moltiplicato per il tasso di successo della cache per un nome equivalente e correttamente firmato.

Il costo di DNSSEC

L’efficiente esercizio del DNS si poggia su una cache efficace e aggiungere DNSSEC alla miscela non altera questa osservazione. Il costo per il client di aggiungere la firma DNSSEC a un nome è efficacemente assorbita dalla cache del DNS.

Il costo per i server dei nomi è in qualche modo più grande dato che le risposte più corpose del DNSSEC implicano un carico di traffico più alto. Al giorno d’oggi, firmare un nome implicherebbe che il carico della richiesta aumentasse di una volta e mezza e che il traffico aumentasse di 8 volte. Se tutti su Internet usassero risolutori capaci di validazione DNSSEC, allora firmare un nome implicherebbe un costo sul server autoritativo dei nomi di circa 4 volte il carico di richieste e circa 12 volte il carico di traffico per le risposte.

È essenziale che le firme DNSSEC siano mantenute in modo corretto. Se le firme non sono buone, il carico di richieste è assai più pesante. Come minimo c’è da aspettarsi un carico di richieste doppio rispetto a quello per un nome correttamente firmato e un simile raddoppio nei volumi di traffico. Ma dicevo come minimo. Probabilmente sarebbe molto di più. E l’aggravio lato server non sarebbe affatto compensato. Quando la firma non è valida, i risolutori capaci di validazione DNSSEC, e i loro client, non sono in grado di risolvere il nome.

Qui di seguito ci sono quattro treni di log registrati mentre si esaminavano i pacchetti inviati e ricevuti da un risolutore DNS nell’intento di risolvere particolari nomi. I log sono stati ottenuti usando lo strumento tcpdump.

04:11:29.066564 IP6 (hlim 64, next-header UDP (17) payload length: 63)
   2001:388:1000:120:d267:e5ff:feef:a842.52696 > 2001:500:2f::f.53: 
   61077% [1au] A? z.00001.z.dashnxdomain.net. (55)
04:11:29.246097 IP6 (hlim 52, next-header UDP (17) payload length: 755) 
   2001:500:2f::f.53 > 2001:388:1000:120:d267:e5ff:feef:a842.52696: 
   61077- 0/15/16 (747)

04:11:29.247225 IP6 (hlim 64, next-header UDP (17) payload length: 63) 
   2001:388:1000:120:d267:e5ff:feef:a842.65467 > 2001:503:a83e::2:30.53:
   43390% [1au] A? z.00001.z.dashnxdomain.net. (55)
04:11:29.394609 IP6 (hlim 53, next-header UDP (17) payload length: 616) 
   2001:503:a83e::2:30.53 > 2001:388:1000:120:d267:e5ff:feef:a842.65467: 
   43390- 0/6/3 (608)

04:11:29.395087 IP (ttl 64, id 6961, flags [none], proto UDP (17), length 83)
    202.158.221.222.60314 > 203.133.248.6.53: 44653% [1au]
    A? z.00001.z.dashnxdomain.net. (55)
04:11:29.414115 IP (ttl 57, id 33300, flags [none], proto UDP (17), length 117)
    203.133.248.6.53 > 202.158.221.222.60314: 44653- 0/1/2 (89)

    202.158.221.222.55384 > 199.102.79.186.53: 43617% [1au] A?
    z.00001.z.dashnxdomain.net. (55)
04:11:29.602066 IP (ttl 48, id 18278, flags [none], proto UDP (17), length 134)
    199.102.79.186.53 > 202.158.221.222.55384: 43617*- 1/1/2 z.00001.z.dashnxdomain.net. 
    A 199.102.79.188 (106)

04:12:56.345153 IP (ttl 64, id 7083, flags [none], proto UDP (17), length 83)
    202.158.221.222.51999 > 199.102.79.186.53: 17516% [1au]
    A? w.00001.z.dashnxdomain.net. (55)0
04:12:56.536598 IP (ttl 48, id 33266, flags [none], proto UDP (17), length 134)
    199.102.79.186.53 > 202.158.221.222.51999: 17516*-1/1/2
    w.00001.z.dashnxdomain.net. A 199.102.79.188 (106)

04:17:21.754342 IP6 (flowlabel 0xb1650, hlim 64, next-header UDP (17) payload length: 62)
    2001:388:1000:120:d267:e5ff:feef:a842.59944 > 2001:500:2f::f.53:  17055% [1au]
    A? z.00001.z.dotnxdomain.net. (54)
04:17:21.914905 IP6 (hlim 56, next-header UDP (17) payload length: 754)
    2001:500:2f::f.53 > 2001:388:1000:120:d267:e5ff:feef:a842.59944:  17055- 0/15/16 (746)
04:17:21.916212 IP (ttl 64, id 7264, flags [none], proto UDP (17), length 82)
    202.158.221.222.56998 > 192.33.14.30.53: 19606% [1au] A? z.00001.z.dotnxdomain.net. (54)
04:17:21.922049 IP (ttl 58, id 22212, flags [none], proto UDP (17), length 397)
    192.33.14.30.53 > 202.158.221.222.56998: 19606- 0/5/3 (369)
04:17:21.922450 IP (ttl 64, id 7265, flags [none], proto UDP (17), length 82)
    202.158.221.222.57617 > 203.133.248.6.53: 12845% [1au] A? z.00001.z.dotnxdomain.net. (54)
04:17:21.941541 IP (ttl 57, id 45515, flags [none], proto UDP (17), length 550)
    203.133.248.6.53 > 202.158.221.222.57617: 12845- 0/4/3 (522)

04:17:21.941932 IP (ttl 64, id 7266, flags [none], proto UDP (17), length 82)
    202.158.221.222.61327 > 199.102.79.186.53: 27943% [1au] A? z.00001.z.dotnxdomain.net. (54)
04:17:22.136331 IP (ttl 48, id 16765, flags [none], proto UDP (17), length 1123)
    199.102.79.186.53 > 202.158.221.222.61327: 27943*- 2/4/3 z.00001.z.dotnxdomain.net. 
    A 199.102.79.186, z.00001.z.dotnxdomain.net. RRSIG (1095)

04:17:22.137317 IP (ttl 64, id 7267, flags [none], proto UDP (17), length 79)
    202.158.221.222.64950 > 199.102.79.186.53: 38854% [1au] A? nsz1.z.dotnxdomain.net. (51)
04:17:22.137485 IP (ttl 64, id 7268, flags [none], proto UDP (17), length 79)
    202.158.221.222.55912 > 199.102.79.186.53: 55544% [1au] AAAA? nsz1.z.dotnxdomain.net. (51)
04:17:22.325473 IP (ttl 48, id 16815, flags [none], proto UDP (17), length 527)
    199.102.79.186.53 > 202.158.221.222.55912: 55544*- 0/4/1 (499)
04:17:22.330897 IP (ttl 48, id 16816, flags [none], proto UDP (17), length 467)
    199.102.79.186.53 > 202.158.221.222.64950: 38854*- 2/2/1 nsz1.z.dotnxdomain.net.
    A 199.102.79.186, nsz1.z.dotnxdomain.net. RRSIG (439)

04:17:22.331245 IP (ttl 64, id 7269, flags [none], proto UDP (17), length 80)
    202.158.221.222.51650 > 199.102.79.186.53: 22395% [1au] DNSKEY?
    00001.z.dotnxdomain.net.
    (52)
04:17:22.525114 IP (ttl 48, id 16838, flags [none], proto UDP (17), length 742)
    199.102.79.186.53 > 202.158.221.222.51650: 22395*- 4/0/1 00001.z.dotnxdomain.net.
    DNSKEY, 00001.z.dotnxdomain.net. DNSKEY, 00001.z.dotnxdomain.net.
    RRSIG, 00001.z.dotnxdomain.net. RRSIG (714)

04:17:22.525953 IP (ttl 64, id 7270, flags [none], proto UDP (17), length 80)
    202.158.221.222.62192 > 203.133.248.110.53: 50645% [1au] DS? 00001.z.dotnxdomain.net. (52)
04:17:22.545016 IP (ttl 57, id 45537, flags [none], proto UDP (17), length 548)
    203.133.248.110.53 > 202.158.221.222.62192: 50645- 0/4/3 (520)

04:17:22.545423 IP (ttl 64, id 7271, flags [none], proto UDP (17), length 80)
    202.158.221.222.63384 > 199.102.79.186.53: 25291% [1au] DS? 00001.z.dotnxdomain.net. (52)
04:17:22.733439 IP (ttl 48, id 16868, flags [none], proto UDP (17), length 341)
    199.102.79.186.53 > 202.158.221.222.63384: 25291*- 3/0/1 00001.z.dotnxdomain.net. 
    DS, 00001.z.dotnxdomain.net. DS, 00001.z.dotnxdomain.net. RRSIG (313)

    202.158.221.222.57741 > 199.102.79.186.53: 48709% [1au] DNSKEY? z.dotnxdomain.net. (46)
04:17:22.925279 IP (ttl 48, id 16891, flags [none], proto UDP (17), length 724)
    199.102.79.186.53 > 202.158.221.222.57741: 48709*- 4/0/1 z.dotnxdomain.net.
    DNSKEY, z.dotnxdomain.net. DNSKEY, z.dotnxdomain.net. RRSIG, z.dotnxdomain.net. 
    RRSIG (696)

04:17:22.926187 IP (ttl 64, id 7282, flags [none], proto UDP (17), length 74)
    202.158.221.222.53393 > 192.31.80.30.53: 158% [1au] DS? z.dotnxdomain.net. (46)
04:17:23.127342 IP (ttl 52, id 33537, flags [none], proto UDP (17), length 389)
    192.31.80.30.53 > 202.158.221.222.53393: 158- 0/5/3 (361)

04:17:23.127725 IP (ttl 64, id 7283, flags [none], proto UDP (17), length 74)
    202.158.221.222.52792 > 203.133.248.6.53: 45200% [1au] DS? z.dotnxdomain.net. (46)
04:17:23.146763 IP (ttl 57, id 45572, flags [none], proto UDP (17), length 333)
    203.133.248.6.53 > 202.158.221.222.52792: 45200*- 3/0/1 z.dotnxdomain.net.
    DS, z.dotnxdomain.net. DS, z.dotnxdomain.net. RRSIG (305)

    202.158.221.222.49204 > 203.133.248.110.53: 48280% [1au] DNSKEY? dotnxdomain.net. (44)
04:17:23.166491 IP (ttl 57, id 45573, flags [none], proto UDP (17), length 718)
    203.133.248.110.53 > 202.158.221.222.49204: 48280*- 4/0/1 dotnxdomain.net.
    DNSKEY, dotnxdomain.net. DNSKEY, dotnxdomain.net. RRSIG, dotnxdomain.net. 
    RRSIG (690)

  2001:388:1000:120:d267:e5ff:feef:a842.62536 > 2001:500:3::42.53:  26784% [1au]
  DS? dotnxdomain.net. (44)
04:17:23.167623 IP6 (flowlabel 0x9f528, hlim 64, next-header UDP (17) payload length: 36)
  2001:388:1000:120:d267:e5ff:feef:a842.62841 > 2001:500:3::42.53:  21863% [1au] NS? . (28)
04:17:23.175688 IP6 (hlim 60, next-header UDP (17) payload length: 744)
  2001:500:3::42.53 > 2001:388:1000:120:d267:e5ff:feef:a842.62536:  26784- 0/15/16 (736)
04:17:23.175753 IP6 (hlim 60, next-header UDP (17) payload length: 921)
  2001:500:3::42.53 > 2001:388:1000:120:d267:e5ff:feef:a842.62841:  21863*- 14/0/25 .
  NS a.root-servers.net., . NS b.root-servers.net., . NS c.root-servers.net., . 
  NS d.root-servers.net., . NS e.root-servers.net., . NS f.root-servers.net., . 
  NS g.root-servers.net., . NS h.root-servers.net., . NS i.root-servers.net., . 
  NS j.root-servers.net., . NS k.root-servers.net., . NS l.root-servers.net., . 
  NS m.root-servers.net., . RRSIG (913)

04:17:23.176537 IP (ttl 64, id 7285, flags [none], proto UDP (17), length 72)
    202.158.221.222.59876 > 192.35.51.30.53: 63121% [1au] DS? dotnxdomain.net. (44)
04:17:23.345507 IP (ttl 52, id 56065, flags [none], proto UDP (17), length 967)
    192.35.51.30.53 > 202.158.221.222.59876: 63121*- 3/14/16 dotnxdomain.net.
    DS, dotnxdomain.net. DS, dotnxdomain.net. RRSIG (939)

04:17:23.346507 IP (ttl 64, id 7286, flags [none], proto UDP (17), length 60)
    202.158.221.222.57105 > 192.5.6.30.53: 26828% [1au] DNSKEY? net. (32)
04:17:23.578772 IP (ttl 51, id 39710, flags [none], proto UDP (17), length 771)
    192.5.6.30.53 > 202.158.221.222.57105: 26828*- 3/0/1 net. DNSKEY, net. DNSKEY, net. 
    RRSIG (743)

    202.158.221.222.50844 > 202.12.27.33.53: 40321% [1au] DS? net. (32)
04:17:23.855605 IP (ttl 51, id 36436, flags [none], proto UDP (17), length 267)
    202.12.27.33.53 > 202.158.221.222.50844: 40321*- 2/0/1 net. DS, net. RRSIG (239)

08:08:31.984563 IP (ttl 64, id 12492, flags [none], proto UDP (17), length 82)
    202.158.221.222.64377 > 199.102.79.186.53: 39737% [1au] A?
    x.00001.z.dotnxdomain.net. (54)
08:08:32.175677 IP (ttl 48, id 46947, flags [none], proto UDP (17), length 1123)
    199.102.79.186.53 > 202.158.221.222.64377: 39737*- 2/4/3
    x.00001.z.dotnxdomain.net. A 199.102.79.186, x.00001.z.dotnxdomain.net. 
    RRSIG (1095)

Avvertenza

I punti di vista sopra esposti non rappresentano necessariamente quelli di APNIC (Asia Pacific Network Information Centre)

L’autore

GEOFF HUSTON è Primo scienziato presso APNIC, il Registro Regionale di Internet che serve l’Asia e il Pacifico.

“Il costo di DNSSEC” di Geoff Huston by Antonio Prado is licensed under a Creative Commons Attribution-ShareAlike 4.0 International