KSK Key Signing Ceremony

Read Full Post »

Riguardo alla firma della root-zone…

…in mancanza di canali più ufficiali, ICANN e Verisign hanno provveduto a mettere online un sito che contenga quantomeno la timeline e un minimo di dettaglio.

Opportuno dargli un occhio di tanto in tanto.

Read Full Post »

Preoccupazioni da radici firmate

Nonostante alla cosa stia venendo data ben poca pubblicità, rispetto a quella che l’evento meriterebbe, ci stiamo avvicinando -un giorno per volta- alle date previste per il deploy delle firme DNSSEC nella root zone.

Le ragioni della scarsa pubblicizzazione della questione possono essere fatte risalire -pare- alla melassa burocratica che -nel corso degli ultimi 10 anni in particolare- ha avvolto i processi decisionali riguardanti la governance di Internet, e la cosa preoccupa un poco chi si occupa degli aspetti tecnici ed operazionali dell’infrastruttura delle rete.

Indipendentemente dal fatto che decidiate di attivare o meno le funzionalità di DNSSEC, infatti, qualche problema lo potreste incontrare, ed è bene saperlo con buon anticipo. La dimensione di parecchie risoluzioni DNS, infatti, aumenterà.

Ma perchè questo è un problema?

La spiegazione è un po’ lunga…

Nella notte dei tempi (RFC 1035) venne apposto un limite superiore alle dimensioni di un messaggio DNS (53/UDP), pari a 512 byte. Zone DNS corpose potevano comunque superare tale limite, come risposta alle interrogazioni, quindi la regola è: se la risposta non ci sta nei 512 byte, viene troncata e inviata ugualmente, aggiungendo un flag (TC) negli header del mesaggio per informare del fatto il resolver che ha eseguito la query. Quest’ultimo dovrà quindi provvedere ad instaurare una sessione TCP (sempre su porta 53) in direzione del DNS remoto -per la quale il limite dei 512 byte ovviamente non si applica- e provvederà in tal modo a reperire la risposta completa.

Già con questo meccanismo, purtroppo, spesso capita che la risoluzione di determinati domini incontri problemi a causa sostanzialmente della mancanza di conoscenza, anche da parte di molti tecnici, della indispensabilità della porta 53/TCP per il corretto funzionamento del DNS, con il risultato che i firewall perimetrali del client o del server spesso non la lasciano transitare…

Proprio in virtù dell’avanzamento di DNSSEC, comunque, questo meccanismo è stato in qualche misura superato (o, perlomeno, integrato) dall’introduzione di EDNS0 (definito in RFC 2671), il quale consente a client e server di passare di comune accordo ad una dimensione massima per i messaggi UDP pari a 4096 byte.

Problema risolto quindi?

Purtroppo, no.

Nonostante la definizione di EDNS0 sia cosa di 10 anni fa, accade tutt’oggi infatti che molti apparati (firewall, router, ecc) in giro per la rete si occupino solertemente di segare i pacchetti diretti o provenienti da porta 53/UDP che superino i fatidici 512 byte, in quanto li considerano sospetti, malformati o quel che loro pare.

Per sopperire a questo potenziale problema, le implementazioni di EDNS0 (bind nello specifico) provvedono ad adattare la massima dimensione del messaggio in funzione dell’andamento delle risoluzioni con determinati sistemi remoti:

Dec 11 11:42:02 dns2 named[28944]: too many timeouts resolving ‘ns.shelter.it/AAAA’ (in ‘shelter.it’?): reducing the advertised EDNS UDP packet size to 512 octets
Dec 11 11:42:02 dns2 named[28944]: too many timeouts resolving ‘ns.shelter.it/A’ (in ‘shelter.it’?): reducing the advertised EDNS UDP packet size to 512 octets
Dec 11 11:42:02 dns2 named[28944]: too many timeouts resolving ‘ns.scelta.com/AAAA’ (in ‘scelta.com’?): reducing the advertised EDNS UDP packet size to 512 octets

Se già oggi questo può portare a problemi, la dimensione delle difficoltà potrebbe facilmente ingigantirsi a seguito del deploy di DNSSEC nella root zone, dato che anche le query dirette a quest’ultima (che, per i non addetti, è appunto la radice da cui parte l’intera struttura DNS di Internet) supereranno il fatidico limite.

Come verificare da sè di non avere problemi simili? Un test lo fornisce OARC.

Assumendo di avere dig installato sulla vostra macchina, eseguite la seguente query:

dig +short rs.dns-oarc.net txt

Dovreste ottenere una cosa simile alla seguente:

skull@mithrandir:~$ dig +short rs.dns-oarc.net txt
rst.x4001.rs.dns-oarc.net.
rst.x3985.x4001.rs.dns-oarc.net.
rst.x4023.x3985.x4001.rs.dns-oarc.net.
“147.123.1.3 sent EDNS buffer size 4096”
“147.123.1.3 DNS reply size limit is at least 4023 bytes”

La parte interessante della risposta sono le ultime due righe, che dicono sostanzialmente che il vostro resolver (147.123.1.3 è il mio, il vostro lo saprete voi) ha annunciato la disponibilità a gestire messaggi per una dimensione massima pari agli attesi 4096 byte, e che si è verificato come un messaggio di 4023 riesca a transitare correttamente.

Se la penultima riga riporta il mancato supporto ad EDNS, è meglio investigare (e/o cambiare resolver).

Analogamente è opportuno investigare (o far investigare chi gestisce il resolver) nel caso in cui l’ultima riga riporti valori troppo bassi (sensibilmente inferiori a 4000 byte), poichè ciò potrebbe significare la presenza di filtri inopportuni nel mezzo.

Per ulteriori spiegazioni sul funzionamento del test e sull’interpretazione dei risultati da esso ottenuti, rimando con piacere alla stessa pagina di OARC, ma invito caldamente a mettere in moto le verifiche del caso, onde evitare di trovarsi per le mani problemi da cui dover uscire in emergenza… 😉

Read Full Post »