7. Authoritative Server Considerations (Considerazioni sui server autoritativi)

7.1. Zone Signing (Firma della zona)

Le zone che usano NSEC3 devono soddisfare le proprietà seguenti:

Ogni nome del titolare nella zona che possiede RRSet autoritativi DEVE avere un corrispondente RR NSEC3. I nomi del titolare che corrispondono a deleghe non firmate POSSONO avere un corrispondente RR NSEC3. Tuttavia, se non c'è un corrispondente RR NSEC3, DEVE esserci un RR NSEC3 Opt-Out che copre il nome "next closer" della delega. Altri RR non autoritativi non sono rappresentati da RR NSEC3.
Ogni non terminale vuoto DEVE avere un corrispondente RR NSEC3, a meno che il non terminale vuoto sia derivato solo da una delega non sicura coperta da un RR NSEC3 Opt-Out.
Il valore TTL per qualsiasi RR NSEC3 DOVREBBE essere uguale al valore del campo minimum TTL nel RR SOA della zona.
Il campo Type Bit Maps di ogni RR NSEC3 in una zona firmata DEVE indicare la presenza di tutti i tipi presenti al nome del titolare originale, eccetto i tipi contribuiti unicamente da un RR NSEC3 stesso. Si noti che ciò significa che il tipo NSEC3 stesso non sarà mai presente in Type Bit Maps.

I passi seguenti descrivono un metodo di costruzione corretta degli RR NSEC3. Non è l'unico metodo possibile.

Selezionare l'algoritmo di hash e i valori per salt e iterazioni.
Per ogni nome del titolare originale univoco nella zona aggiungere un RR NSEC3.
- Se si usa Opt-Out, i nomi del titolare delle deleghe non firmate POSSONO essere esclusi.
- Il nome del titolare dell'RR NSEC3 è l'hash del nome del titolare originale, prefissato come singola etichetta al nome della zona.
- Il campo Next Hashed Owner Name è lasciato vuoto per il momento.
- Se si usa Opt-Out, impostare il bit Opt-Out a uno.
- Ai fini del rilevamento delle collisioni, tenere facoltativamente traccia del nome del titolare originale con l'RR NSEC3.
- Inoltre, ai fini del rilevamento delle collisioni, creare facoltativamente un RR NSEC3 aggiuntivo corrispondente al nome del titolare originale con l'etichetta asterisco prefissa (cioè come se esistesse un jolly come figlio di questo nome del titolare) e tenere traccia di questo nome del titolare originale. Contrassegnare questo RR NSEC3 come temporaneo.
Per ogni RRSet al nome del titolare originale, impostare il bit corrispondente nel campo Type Bit Maps.
Se la differenza nel numero di etichette tra l'apice e il nome del titolare originale è maggiore di 1, devono essere aggiunti RR NSEC3 aggiuntivi per ogni non terminale vuoto tra l'apice e il nome del titolare originale. Questo processo può generare RR NSEC3 con nomi del titolare sottoposti a hash duplicati. Facoltativamente, per il rilevamento delle collisioni, tenere traccia dei nomi del titolare originale di questi RR NSEC3 e creare RR NSEC3 temporanei per collisioni con jolly in modo analogo al passo 1.
Ordinare l'insieme di RR NSEC3 nell'ordine di hash.
Combinare gli RR NSEC3 con nomi del titolare sottoposti a hash identici sostituendoli con un singolo RR NSEC3 il cui campo Type Bit Maps consiste nell'unione dei tipi rappresentati dall'insieme di RR NSEC3. Se il nome del titolare originale era tracciato, le collisioni possono essere rilevate in fase di combinazione, poiché tutti gli RR NSEC3 corrispondenti dovrebbero avere lo stesso nome del titolare originale. Eliminare eventuali RR NSEC3 temporanei.
In ciascun RR NSEC3 inserire il nome del titolare sottoposto a hash successivo usando il valore dell'RR NSEC3 successivo nell'ordine di hash. Il nome del titolare sottoposto a hash successivo dell'ultimo RR NSEC3 nella zona contiene il valore del nome del titolare sottoposto a hash del primo RR NSEC3 nell'ordine di hash.
Infine, aggiungere un RR NSEC3PARAM con gli stessi campi Hash Algorithm, Iterations e Salt all'apice della zona.

Se viene rilevata una collisione di hash, occorre scegliere un nuovo salt e riavviare il processo di firma.

7.2. Zone Serving (Erogazione della zona)

La presente specifica modifica le risposte DNS abilitate a DNSSEC generate dai server autoritativi. In particolare, sostituisce l'uso degli RR NSEC in tali risposte con RR NSEC3 che dimostrano gli stessi fatti.

Nei casi di risposta seguenti, gli RR NSEC prescritti da DNSSEC [RFC4035] sono sostituiti con RR NSEC3 che dimostrano gli stessi fatti. Le risposte che non conterrebbero RR NSEC restano invariate dalla presente specifica.

Quando si restituiscono risposte contenenti più RR NSEC3, tutti gli RR NSEC3 DEVONO usare gli stessi valori di algoritmo di hash, iterazioni e salt. Il valore del campo Flags DEVE essere zero oppure uno.

7.2.1. Closest Encloser Proof (Prova dell'incapsulante più vicino)

Per molte risposte NSEC3 è richiesta una prova dell'incapsulante più vicino. È una prova che qualche antenato del QNAME è l'incapsulante più vicino del QNAME.

Questa prova consiste in (fino a) due RR NSEC3 diversi:

Un RR NSEC3 che corrisponde all'incapsulante (dimostrabile) più vicino.
Un RR NSEC3 che copre il nome "next closer" rispetto all'incapsulante più vicino.

Il primo RR NSEC3 propone essenzialmente un possibile incapsulante più vicino e dimostra che tale incapsulante esiste effettivamente. Il secondo RR NSEC3 dimostra che il possibile incapsulante più vicino è effettivamente il più vicino e dimostra che il QNAME (e qualsiasi antenato tra QNAME e l'incapsulante più vicino) non esiste.

Questi RR NSEC3 sono collettivamente denominati "prova dell'incapsulante più vicino" nelle descrizioni successive.

Ad esempio, la prova dell'incapsulante più vicino per il nome del titolare inesistente "alpha.beta.gamma.example." potrebbe dimostrare che "gamma.example." è l'incapsulante più vicino. Questa risposta conterrebbe l'RR NSEC3 che corrisponde a "gamma.example." e conterrebbe anche l'RR NSEC3 che copre "beta.gamma.example." (che è il nome "next closer").

È possibile, usando Opt-Out (sezione 6), non poter dimostrare l'incapsulante più vicino effettivo perché esso è, o fa parte di, una delega non sicura coperta da un'estensione Opt-Out. In questo caso, invece di dimostrare l'incapsulante più vicino effettivo, si usa l'incapsulante più vicino dimostrabile. Cioè si usa il nome autoritativo incapsulante più vicino. In questo caso, l'insieme di RR NSEC3 usato per questa prova è denominato "prova dell'incapsulante più vicino dimostrabile".

7.2.2. Name Error Responses (Risposte Name Error)

Per dimostrare la non esistenza del QNAME, una prova dell'incapsulante più vicino e un RR NSEC3 che copre il RR jolly (inesistente) all'incapsulante più vicino DEVONO essere inclusi nella risposta. Questa raccolta di (fino a) tre RR NSEC3 dimostra sia che il QNAME non esiste sia che non esiste un jolly che avrebbe potuto corrispondere al QNAME.

Ad esempio, se "gamma.example." è l'incapsulante più vicino dimostrabile al QNAME, allora un RR NSEC3 che copre "*.gamma.example." è incluso nella sezione authority della risposta.

7.2.3. No Data Responses, QTYPE is not DS (Risposte No Data, QTYPE non è DS)

Il server DEVE includere l'RR NSEC3 che corrisponde al QNAME. Questo RR NSEC3 NON DEVE avere i bit corrispondenti né al QTYPE né a CNAME impostati nel suo campo Type Bit Maps.

7.2.4. No Data Responses, QTYPE is DS (Risposte No Data, QTYPE è DS)

Se esiste un RR NSEC3 che corrisponde al QNAME, il server DEVE restituirlo nella risposta. I bit corrispondenti a DS e CNAME NON DEVONO essere impostati nel campo Type Bit Maps di questo RR NSEC3.

Se nessun RR NSEC3 corrisponde al QNAME, il server DEVE restituire una prova dell'incapsulante più vicino dimostrabile per il QNAME. L'RR NSEC3 che copre il nome "next closer" DEVE avere il bit Opt-Out impostato (si noti che ciò è vero per definizione: se il bit Opt-Out non è impostato, qualcosa è andato storto).

Se un server è autoritativo per entrambi i lati di un taglio di zona al QNAME, il server DEVE restituire la prova dal lato padre del taglio di zona.

7.2.5. Wildcard No Data Responses (Risposte Wildcard No Data)

Se c'è una corrispondenza jolly per il QNAME ma il QTYPE non è presente a quel nome, la risposta DEVE includere una prova dell'incapsulante più vicino per il QNAME e DEVE includere l'RR NSEC3 che corrisponde al jolly. Questa combinazione dimostra sia che il QNAME stesso non esiste sia che esiste un jolly che corrisponde al QNAME. Si noti che l'incapsulante più vicino al QNAME DEVE essere l'antenato immediato dell'RR jolly (se non è così, qualcosa è andato storto).

7.2.6. Wildcard Answer Responses (Risposte Wildcard Answer)

Se c'è una corrispondenza jolly per il QNAME e il QTYPE, allora, oltre all'RRSet jolly espanso restituito nella sezione answer della risposta, deve essere restituita la prova che la corrispondenza jolly era valida.

Questa prova si ottiene dimostrando sia che il QNAME non esiste sia che l'incapsulante più vicino del QNAME e l'antenato immediato del jolly coincidono (cioè è stato usato il jolly corretto).

A tal fine DEVE essere restituito l'RR NSEC3 che copre il nome "next closer" dell'antenato immediato del jolly. Non è necessario restituire un RR NSEC3 che corrisponde all'incapsulante più vicino, poiché l'esistenza di questo incapsulante più vicino è dimostrata dalla presenza del jolly espanso nella risposta.

7.2.7. Referrals to Unsigned Subzones (Referral verso sottozone non firmate)

Se esiste un RR NSEC3 che corrisponde al nome della delega, quell'RR NSEC3 DEVE essere incluso nella risposta. Il bit DS nelle mappe di bit di tipo dell'RR NSEC3 NON DEVE essere impostato.

Se la zona è Opt-Out, può non esserci un RR NSEC3 corrispondente alla delega. In questo caso la prova dell'incapsulante più vicino dimostrabile DEVE essere inclusa nella risposta. L'RR NSEC3 incluso che copre il nome "next closer" della delega DEVE avere il flag Opt-Out impostato a uno. (Si noti che sarà così a meno che qualcosa non sia andato storto.)

7.2.8. Responding to Queries for NSEC3 Owner Names (Risposta alle interrogazioni per nomi del titolare NSEC3)

I nomi del titolare degli RR NSEC3 non sono rappresentati nella catena di RR NSEC3 come altri nomi del titolare. Di conseguenza, ogni nome del titolare NSEC3 è coperto da un altro RR NSEC3, negando in effetti l'esistenza dell'RR NSEC3. È un paradosso, poiché l'esistenza di un RR NSEC3 può essere dimostrata dal suo RRSet RRSIG.

Se tutte le condizioni seguenti sono vere:

il QNAME è uguale al nome del titolare di un RR NSEC3 esistente, e
non esistono tipi di RR al QNAME, né a alcun discendente del QNAME,

allora la risposta DEVE essere costruita come una risposta Name Error (sezione 7.2.2). In altre parole, il name server autoritativo si comporterà come se il nome del titolare dell'RR NSEC3 non esistesse.

Si noti che gli RR NSEC3 sono restituiti come risultato di un'interrogazione AXFR o IXFR.

7.2.9. Server Response to a Run-Time Collision (Risposta del server a una collisione in esecuzione)

Se l'hash di un QNAME inesistente collide con il nome del titolare di un RR NSEC3 esistente, il server non sarà in grado di restituire una risposta che dimostri che il QNAME non esiste. In questo caso il server DEVE restituire una risposta con RCODE 2 (guasto del server).

Si noti che con l'algoritmo di hash specificato nel presente documento, SHA-1, tali collisioni sono altamente improbabili.

7.3. Secondary Servers (Server secondari)

I server secondari (e forse altre entità) devono determinare in modo affidabile quali parametri NSEC3 (cioè hash, salt e iterazioni) sono presenti a ogni nome del titolare sottoposto a hash, per poter scegliere un insieme appropriato di RR NSEC3 per le risposte negative. Ciò è indicato da un RR NSEC3PARAM presente all'apice della zona.

Se sono presenti più RR NSEC3PARAM, esistono più catene NSEC3 valide. Il server deve sceglierne una, ma può usare qualsiasi criterio.

7.4. Zones Using Unknown Hash Algorithms (Zone con algoritmi di hash sconosciuti)

Le zone firmate secondo la presente specifica ma che usano un valore di hash NSEC3 non riconosciuto non possono essere erogate efficacemente. Tali zone DOVREBBERO essere rifiutate al caricamento. I server DOVREBBERO rispondere con risposte RCODE=2 (guasto del server) quando gestiscono interrogazioni che ricadrebbero in tali zone.

7.5. Dynamic Update (Aggiornamento dinamico)

Una zona firmata con NSEC3 può accettare aggiornamenti dinamici [RFC2136]. Tuttavia NSEC3 introduce alcune considerazioni particolari per gli aggiornamenti dinamici.

L'aggiunta e la rimozione di nomi in una zona DEVE tenere conto della creazione o rimozione di non terminali vuoti.

Quando si rimuove un nome con un corrispondente RR NSEC3, eventuali RR NSEC3 corrispondenti a non terminali vuoti creati da quel nome DEVONO essere rimossi. Si noti che più di un nome può asserire l'esistenza di un particolare non terminale vuoto.
Quando si aggiunge un nome che richiede l'aggiunta di un RR NSEC3, DEVONO essere aggiunti anche RR NSEC3 per qualsiasi non terminale vuoto creato. Cioè, se non esiste un RR NSEC3 corrispondente a un non terminale vuoto, esso deve essere creato e aggiunto.

La presenza di Opt-Out in una zona significa che alcune aggiunte o deleghe di nomi non richiederanno modifiche agli RR NSEC3 in una zona.

Quando si rimuove un RRSet di delega, se quella delega non ha un RR NSEC3 corrispondente, era stata esclusa (opted out). In questo caso non occorre altro.
Quando si aggiunge un RRSet di delega, se il nome "next closer" della delega è coperto da un RR NSEC3 Opt-Out esistente, la delega PUÒ essere aggiunta senza modificare gli RR NSEC3 nella zona.

La presenza di Opt-Out in una zona significa che, aggiungendo o rimuovendo RR NSEC3, il valore del flag Opt-Out da impostare in RR NSEC3 nuovi o modificati è ambiguo. I server DOVREBBERO seguire questo insieme di regole di base per risolvere l'ambiguità.

Il concetto centrale di queste regole è che lo stato del flag Opt-Out dell'RR NSEC3 coprente è preservato.

Quando si rimuove un RR NSEC3, il valore del flag Opt-Out per l'RR NSEC3 precedente (quello il cui nome del titolare sottoposto a hash successivo è modificato) non dovrebbe essere cambiato.
Quando si aggiunge un RR NSEC3, il valore del flag Opt-Out è impostato al valore del flag Opt-Out dell'RR NSEC3 che in precedenza copriva il nome del titolare dell'RR NSEC3. Cioè l'RR NSEC3 ora precedente.

Se la zona in questione è coerente nell'uso del flag Opt-Out (cioè tutti gli RR NSEC3 nella zona hanno lo stesso valore per il flag), queste regole manterranno tale coerenza. Se la zona non è coerente nell'uso del flag (cioè è una zona parzialmente Opt-Out), queste regole non manterranno lo stesso schema d'uso del flag Opt-Out.

Per le zone che usano parzialmente il flag Opt-Out, se esiste uno schema logico per tale uso, lo schema potrebbe essere mantenuto usando una policy locale sul server.