Passa al contenuto principale

3. Serving (Servizio)

Questa sezione descrive il comportamento delle entità che includono funzioni di server dei nomi consapevoli della sicurezza. In molti casi tali funzioni faranno parte di un server dei nomi ricorsivo consapevole della sicurezza, ma un server dei nomi autorevole consapevole della sicurezza ha alcuni degli stessi requisiti.

Un server dei nomi consapevole della sicurezza deve (MUST) supportare l'estensione della dimensione del messaggio EDNS0 ([RFC2671]), deve (MUST) supportare una dimensione del messaggio di almeno 1220 ottetti e dovrebbe (SHOULD) supportare una dimensione del messaggio di 4000 ottetti.

Un server dei nomi consapevole della sicurezza che riceve una query DNS che non include lo pseudo-RR OPT EDNS o che ha il bit DO cancellato deve (MUST) trattare i RR RRSIG, DNSKEY e NSEC come farebbe con qualsiasi altro RRset e non deve (MUST NOT) eseguire alcuna delle elaborazioni aggiuntive descritte di seguito.

DNSSEC alloca due nuovi bit nell'intestazione del messaggio DNS:

  • Bit CD (Checking Disabled): Controllato dai resolver
  • Bit AD (Authentic Data): Controllato dai server dei nomi

Un server dei nomi consapevole della sicurezza deve (MUST) copiare il bit CD da una query nella risposta corrispondente. Un server dei nomi consapevole della sicurezza deve (MUST) ignorare l'impostazione del bit AD nelle query.

3.1. Authoritative Name Servers (Server dei nomi autorevoli)​

Alla ricezione di una query pertinente che ha il bit DO dello pseudo-RR OPT EDNS impostato, un server dei nomi autorevole consapevole della sicurezza per una zona firmata deve (MUST) includere RR RRSIG, NSEC e DS aggiuntivi, secondo le seguenti regole:

  • I RR RRSIG che possono essere utilizzati per autenticare una risposta devono (MUST) essere inclusi nella risposta secondo le regole della sezione 3.1.1
  • I RR NSEC che possono essere utilizzati per fornire una negazione dell'esistenza autenticata devono (MUST) essere inclusi automaticamente nella risposta secondo le regole della sezione 3.1.3
  • Un RRset DS o un RR NSEC che prova che non esistono RR DS deve (MUST) essere incluso automaticamente nelle deleghe secondo le regole della sezione 3.1.4

3.1.1. Including RRSIG RRs in a Response (Inclusione di RR RRSIG in una risposta)​

Quando risponde a una query che ha il bit DO impostato, un server dei nomi autorevole consapevole della sicurezza dovrebbe (SHOULD) tentare di inviare RR RRSIG che un resolver consapevole della sicurezza può utilizzare per autenticare gli RRset nella risposta.

Regole:

  • Quando si posiziona un RRset firmato nella sezione Answer, il server dei nomi deve (MUST) anche posizionare i suoi RR RRSIG nella sezione Answer
  • Quando si posiziona un RRset firmato nella sezione Authority, il server dei nomi deve (MUST) anche posizionare i suoi RR RRSIG nella sezione Authority
  • Quando si posiziona un RRset firmato nella sezione Additional, il server dei nomi deve (MUST) anche posizionare i suoi RR RRSIG nella sezione Additional
  • Se lo spazio non consente l'inclusione di RR RRSIG nelle sezioni Answer o Authority, il server dei nomi deve (MUST) impostare il bit TC

3.1.2. Including DNSKEY RRs in a Response (Inclusione di RR DNSKEY in una risposta)​

Quando risponde a una query che ha il bit DO impostato e che richiede i RR SOA o NS all'apice di una zona firmata, un server dei nomi autorevole consapevole della sicurezza per quella zona può (MAY) restituire l'RRset DNSKEY dell'apice della zona nella sezione Additional.

L'RRset DNSKEY e i RR RRSIG associati hanno una priorità inferiore rispetto a qualsiasi altra informazione che verrebbe posizionata nella sezione Additional.

3.1.3. Including NSEC RRs in a Response (Inclusione di RR NSEC in una risposta)​

Quando risponde a una query che ha il bit DO impostato, un server dei nomi autorevole consapevole della sicurezza per una zona firmata deve (MUST) includere RR NSEC in ciascuno dei seguenti casi:

No Data (Nessun dato): La zona contiene RRset che corrispondono esattamente a <SNAME, SCLASS> ma non contiene alcun RRset che corrisponde esattamente a <SNAME, SCLASS, STYPE>.

Name Error (Errore di nome): La zona non contiene alcun RRset che corrisponde a <SNAME, SCLASS> esattamente o tramite espansione di nome wildcard.

Wildcard Answer (Risposta wildcard): La zona non contiene alcun RRset che corrisponde esattamente a <SNAME, SCLASS> ma contiene un RRset che corrisponde a <SNAME, SCLASS, STYPE> tramite espansione di nome wildcard.

Wildcard No Data (Wildcard senza dati): La zona non contiene alcun RRset che corrisponde esattamente a <SNAME, SCLASS> e contiene uno o più RRset che corrispondono a <SNAME, SCLASS> tramite espansione di nome wildcard, ma non contiene alcun RRset che corrisponde a <SNAME, SCLASS, STYPE> tramite espansione di nome wildcard.

3.1.3.1. Including NSEC RRs: No Data Response (Inclusione di RR NSEC: Risposta senza dati)​

Se la zona contiene RRset che corrispondono a <SNAME, SCLASS> ma non contiene alcun RRset che corrisponde a <SNAME, SCLASS, STYPE>, allora il server dei nomi deve (MUST) includere il RR NSEC per <SNAME, SCLASS> insieme ai suoi RR RRSIG associati nella sezione Authority.

3.1.3.2. Including NSEC RRs: Name Error Response (Inclusione di RR NSEC: Risposta di errore di nome)​

Se la zona non contiene alcun RRset che corrisponde a <SNAME, SCLASS> esattamente o tramite espansione di nome wildcard, allora il server dei nomi deve (MUST) includere i seguenti RR NSEC nella sezione Authority:

  • Un RR NSEC che prova che non esiste una corrispondenza esatta per <SNAME, SCLASS>
  • Un RR NSEC che prova che la zona non contiene RRset che corrisponderebbero a <SNAME, SCLASS> tramite espansione di nome wildcard

3.1.3.3. Including NSEC RRs: Wildcard Answer Response (Inclusione di RR NSEC: Risposta wildcard)​

Se la zona non contiene alcun RRset che corrisponde esattamente a <SNAME, SCLASS> ma contiene un RRset che corrisponde a <SNAME, SCLASS, STYPE> tramite espansione di nome wildcard, il server dei nomi deve (MUST) includere la risposta espansa con wildcard e i RR RRSIG espansi con wildcard corrispondenti nella sezione Answer e deve (MUST) includere nella sezione Authority un RR NSEC che prova che la zona non contiene una corrispondenza più vicina.

3.1.3.4. Including NSEC RRs: Wildcard No Data Response (Inclusione di RR NSEC: Risposta wildcard senza dati)​

Il server dei nomi deve (MUST) includere i seguenti RR NSEC nella sezione Authority:

  • Un RR NSEC che prova che non ci sono RRset che corrispondono a STYPE al nome di proprietario wildcard
  • Un RR NSEC che prova che non ci sono RRset nella zona che sarebbero stati una corrispondenza più vicina

3.1.4. Including DS RRs in a Response (Inclusione di RR DS in una risposta)​

I RR DS sono presenti solo ai punti di delega. Il RR DS a un punto di delega stabilisce la catena di autenticazione nella zona figlia. Un server dei nomi consapevole della sicurezza che restituisce una delega deve (MUST) tentare di restituire l'RRset DS insieme ai suoi RR RRSIG associati nella sezione Authority.

Se un RRset DS non esiste al punto di delega, il server dei nomi deve (MUST) restituire un RR NSEC che prova che l'RRset DS non esiste.

3.1.5. Responding to Queries for Type AXFR or IXFR (Risposta alle query di tipo AXFR o IXFR)​

DNSSEC non modifica il protocollo di trasferimento di zona DNS. Un server dei nomi autorevole consapevole della sicurezza deve (MUST) includere i RR DNSSEC appropriati (RR RRSIG, NSEC, DS e DNSKEY) nei trasferimenti di zona.

3.1.6. The AD and CD Bits in an Authoritative Response (I bit AD e CD in una risposta autorevole)​

Un server dei nomi autorevole consapevole della sicurezza deve (MUST) cancellare il bit AD nelle risposte a meno che il server dei nomi non sia autorevole per la zona che contiene tutti gli RRset nelle sezioni Answer e Authority e tutti i RR RRSIG e NSEC necessari siano inclusi.

Un server dei nomi autorevole consapevole della sicurezza deve (MUST) copiare il bit CD dalla query alla risposta.

3.2. Recursive Name Servers (Server dei nomi ricorsivi)​

Un server dei nomi ricorsivo consapevole della sicurezza è un'entità che agisce come resolver consapevole della sicurezza (vedere Sezione 4) e fornisce anche servizio di query consapevole della sicurezza ad altri resolver o resolver stub.

3.2.1. The DO Bit (Il bit DO)​

Un server dei nomi ricorsivo consapevole della sicurezza deve (MUST) impostare il bit DO nelle query che invia ai server dei nomi autorevoli quando il bit DO era impostato nella query ricevuta dal server dei nomi ricorsivo.

3.2.2. The CD Bit (Il bit CD)​

Il bit CD (Checking Disabled) controlla se un server dei nomi ricorsivo consapevole della sicurezza esegue la convalida DNSSEC. Quando il bit CD è impostato, un server dei nomi ricorsivo consapevole della sicurezza non dovrebbe (SHOULD NOT) eseguire la convalida DNSSEC ma dovrebbe (SHOULD) comunque recuperare i RR DNSSEC.

3.2.3. The AD Bit (Il bit AD)​

Il bit AD (Authentic Data) indica se i dati nelle sezioni Answer e Authority sono stati verificati da un resolver consapevole della sicurezza in conformità con le politiche della politica di sicurezza locale di quel resolver.

Un server dei nomi ricorsivo consapevole della sicurezza deve (MUST) impostare il bit AD in una risposta se:

  • Gli RRset nelle sezioni Answer e Authority sono stati convalidati con successo
  • Oppure la risposta è stata ricevuta con il bit AD impostato da un server upstream che è affidabile

3.3. Example DNSSEC Responses (Esempi di risposte DNSSEC)​

L'appendice B contiene esempi dettagliati di risposte DNSSEC per vari scenari tra cui:

  • Risposte positive
  • Errori di nome
  • Errori senza dati
  • Deleghe a zone firmate e non firmate
  • Espansioni wildcard
Ultimo aggiornamento il