10. Special Considerations (Considerazioni particolari)

10.1. Domain Name Length Restrictions (Restrizioni sulla lunghezza dei nomi di dominio)

Le zone firmate secondo la presente specifica hanno restrizioni aggiuntive sulla lunghezza dei nomi di dominio. In particolare, le zone con nomi che, convertiti in nomi del titolare sottoposti a hash, superano il limite di 255 ottetti imposto da [RFC1035], non possono usare la presente specifica.

La lunghezza massima effettiva di un nome di dominio in una particolare zona dipende sia dalla lunghezza del nome della zona (rispetto al nome di dominio completo) sia dalla particolare funzione di hash usata.

Come esempio, SHA-1 produce un hash di 160 bit. La codifica base-32 di 160 bit produce 32 caratteri. I 32 caratteri sono prefissati al nome della zona come singola etichetta, che include un campo di lunghezza di un ottetto. La lunghezza massima del nome della zona, usando SHA-1, è 222 ottetti (255 − 33).

10.2. DNAME at the Zone Apex (DNAME all'apice della zona)

La specifica DNAME nella sezione 3 di [RFC2672] ha una limitazione «no-descendants»: se è presente un RR DNAME al nodo N, NON DEVE esserci dati in alcun discendente di N.

Se N è l'apice della zona, saranno presenti tipi NSEC3 e RRSIG ai discendenti di N. La presente specifica aggiorna la specifica DNAME per consentire i tipi NSEC3 e RRSIG ai discendenti dell'apice indipendentemente dall'esistenza di DNAME all'apice.

10.3. Iterations (Iterazioni)

Impostare il numero di iterazioni usate consente al titolare della zona di scegliere il costo del calcolo di un hash e quindi il costo di generare un dizionario. Si noti che ciò è distinto dall'effetto del salt, che impedisce l'uso di un singolo dizionario precalcolato per tutti i tempi.

Ovviamente il numero di iterazioni influisce anche sul costo per il titolare della zona di firmare ed erogare la zona, nonché sul costo del validatore nel verificare le risposte dalla zona. Si impone pertanto un limite superiore al numero di iterazioni. Lo si basa sul numero di iterazioni che approssima il costo di verificare un RRSet.

I limiti sono quindi basati sulla dimensione della chiave di firma della zona più piccola, arrotondata per eccesso al valore di tabella più vicino (o per difetto se la chiave è più grande del valore di tabella più grande).

Il titolare della zona NON DEVE usare un valore superiore a quello mostrato nella tabella sotto per le iterazioni per la data dimensione di chiave. Un resolver PUÒ trattare una risposta con un valore più alto come non sicura, dopo che il validatore ha verificato che la firma sull'RR NSEC3 è corretta.

Key Size (dimensione chiave)	Iterations (iterazioni)
1024	150
2048	500
4096	2.500

Questa tabella si basa su un'approssimazione del rapporto tra il costo di un calcolo SHA-1 e il costo di una verifica RSA per chiavi di dimensione 1024 bit (150 a 1), 2048 bit (500 a 1) e 4096 bit (2500 a 1).

Il rapporto tra calcolo SHA-1 e verifica DSA è più alto (1500 a 1 per chiavi di dimensione 1024). Un conteggio di iterazioni più alto degrada le prestazioni, mentre la verifica DSA è già più costosa di RSA per la stessa dimensione di chiave. Pertanto i valori nella tabella DEVONO essere usati indipendentemente dall'algoritmo di chiave.

10.4. Transitioning a Signed Zone from NSEC to NSEC3 (Transizione di una zona firmata da NSEC a NSEC3)

Quando si transita una zona già firmata e attendibile alla presente specifica, occorre prestare attenzione per evitare guasti di convalida del client durante il processo.

La procedura di base è la seguente:

Transizionare tutte le DNSKEY a DNSKEY che usano gli alias di algoritmo descritti nella sezione 2. Il metodo effettivo per cambiare in modo sicuro l'RRSet DNSKEY della zona è fuori ambito dalla presente specifica. Tuttavia il risultato finale DEVE essere che tutti gli RR DS nel genitore usano gli alias di algoritmo specificati.

Dopo il completamento di questa transizione, tutti i client non consapevoli di NSEC3 tratteranno la zona come non sicura. A questo punto il server autoritativo restituisce ancora risposte negative e jolly che contengono RR NSEC.
Aggiungere RR NSEC3 firmati alla zona, in modo incrementale o tutti in una volta. Se si aggiunge in modo incrementale, l'ultimo RRSet aggiunto DEVE essere l'RRSet NSEC3PARAM.
Con l'aggiunta dell'RRSet NSEC3PARAM, il server passa a erogare risposte negative e jolly con RR NSEC3 secondo la presente specifica.
Rimuovere gli RR NSEC in modo incrementale o tutti in una volta.

10.5. Transitioning a Signed Zone from NSEC3 to NSEC (Transizione di una zona firmata da NSEC3 a NSEC)

Per transire in sicurezza a una zona firmata DNSSEC [RFC4035], invertire semplicemente la procedura sopra:

Aggiungere RR NSEC in modo incrementale o tutti in una volta.
Rimuovere l'RRSet NSEC3PARAM. Ciò segnala al server di usare gli RR NSEC per le risposte negative e jolly.
Rimuovere gli RR NSEC3 in modo incrementale o tutti in una volta.
Transizionare tutte le DNSKEY agli identificatori di algoritmo DNSSEC. Dopo il completamento di questa transizione, tutti i client non consapevoli di NSEC3 tratteranno la zona come sicura.