2. Formato del Messaggio di Aggiornamento

Il formato del messaggio DNS è definito da [RFC1035 4.1]. Sono necessarie alcune estensioni (ad esempio, sono possibili più codici di errore sotto UPDATE che sotto QUERY) e alcuni campi devono essere sovraccaricati (vedi la descrizione dei campi CLASS di seguito).

Il formato complessivo di un messaggio UPDATE è, seguendo [ibid]:

+---------------------+
|        Header       |
+---------------------+
|         Zone        | specifica la zona da aggiornare
+---------------------+
|     Prerequisite    | RR o RRset che devono (non) preesistere
+---------------------+
|        Update       | RR o RRset da aggiungere o eliminare
+---------------------+
|   Additional Data   | dati aggiuntivi
+---------------------+

La sezione Header specifica che questo messaggio è un UPDATE e descrive la dimensione delle altre sezioni. La sezione Zone nomina la zona che deve essere aggiornata da questo messaggio. La sezione Prerequisite specifica gli invarianti di partenza (in termini di contenuto della zona) richiesti per questo aggiornamento. La sezione Update contiene le modifiche da apportare e la sezione Additional Data contiene dati che potrebbero essere necessari per completare, ma non fanno parte di questo aggiornamento.

2.1 Problemi di Trasporto

Una transazione di aggiornamento può essere trasportata in un datagramma UDP, se la richiesta si adatta, o in una connessione TCP (a discrezione del richiedente). Quando viene utilizzato TCP, il messaggio è nel formato descritto in [RFC1035 4.2.2].

2.2 Intestazione del Messaggio

L'intestazione del formato del messaggio DNS è definita da [RFC 1035 4.1]. Non tutti gli opcode definiscono lo stesso insieme di bit di flag, anche se in pratica la maggior parte dei bit definiti per QUERY (in [ibid]) sono definiti in modo identico dagli altri opcode. UPDATE utilizza solo un bit di flag (QR).

Il formato del messaggio DNS specifica i conteggi dei record per le sue quattro sezioni (Question, Answer, Authority e Additional). UPDATE utilizza gli stessi campi e gli stessi formati di sezione, ma la denominazione e l'uso di queste sezioni differiscono come mostrato nella seguente intestazione modificata, dopo [RFC1035 4.1.1]:

                                  1  1  1  1  1  1
    0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                      ID                       |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |QR|   Opcode  |          Z         |   RCODE   |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                    ZOCOUNT                    |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                    PRCOUNT                    |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                    UPCOUNT                    |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                    ADCOUNT                    |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Questi campi sono utilizzati come segue:

ID
Un identificatore a 16 bit assegnato dall'entità che genera qualsiasi tipo di richiesta. Questo identificatore viene copiato nella risposta corrispondente e può essere utilizzato dal richiedente per abbinare le risposte alle richieste in sospeso, o dal server per rilevare richieste duplicate da qualche richiedente.

QR
Un campo a un bit che specifica se questo messaggio è una richiesta (0) o una risposta (1).

Opcode
Un campo a quattro bit che specifica il tipo di richiesta in questo messaggio. Questo valore è impostato dall'originatore di una richiesta e copiato nella risposta. Il valore dell'opcode che identifica un messaggio UPDATE è cinque (5).

Z
Riservato per uso futuro. Dovrebbe essere zero (0) in tutte le richieste e risposte. Un campo Z diverso da zero dovrebbe essere ignorato dalle implementazioni di questa specifica.

RCODE
Codice di risposta - questo campo a quattro bit è indefinito nelle richieste e impostato nelle risposte. I valori e i significati di questo campo all'interno delle risposte sono i seguenti:

Mnemonico	Valore	Descrizione
NOERROR	0	Nessuna condizione di errore.
FORMERR	1	Il name server non è stato in grado di interpretare la richiesta a causa di un errore di formato.
SERVFAIL	2	Il name server ha incontrato un errore interno durante l'elaborazione di questa richiesta, ad esempio un errore del sistema operativo o un timeout di inoltro.
NXDOMAIN	3	Qualche nome che dovrebbe esistere non esiste.
NOTIMP	4	Il name server non supporta l'opcode specificato.
REFUSED	5	Il name server rifiuta di eseguire l'operazione specificata per motivi di policy o di sicurezza.
YXDOMAIN	6	Qualche nome che non dovrebbe esistere esiste.
YXRRSET	7	Qualche RRset che non dovrebbe esistere esiste.
NXRRSET	8	Qualche RRset che dovrebbe esistere non esiste.
NOTAUTH	9	Il server non è autorevole per la zona denominata nella sezione Zone.
NOTZONE	10	Un nome utilizzato nella sezione Prerequisite o Update non si trova all'interno della zona denotata dalla sezione Zone.

ZOCOUNT
Il numero di RR nella sezione Zone.

PRCOUNT
Il numero di RR nella sezione Prerequisite.

UPCOUNT
Il numero di RR nella sezione Update.

ADCOUNT
Il numero di RR nella sezione Additional Data.

2.3 Sezione Zone

La sezione Zone ha lo stesso formato di quello specificato in [RFC1035 4.1.2], con i campi ridefiniti come segue:

                                  1  1  1  1  1  1
    0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                                               |
  /                     ZNAME                     /
  /                                               /
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                     ZTYPE                     |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                     ZCLASS                    |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

UPDATE utilizza questa sezione per denotare la zona dei record aggiornati. Tutti i record da aggiornare devono essere nella stessa zona e pertanto la sezione Zone è autorizzata a contenere esattamente un record. ZNAME è il nome della zona, ZTYPE deve essere SOA e ZCLASS è la classe della zona.

2.4 Sezione Prerequisite

Questa sezione contiene un insieme di prerequisiti RRset che devono essere soddisfatti al momento in cui il pacchetto UPDATE viene ricevuto dal server master principale. Il formato di questa sezione è come specificato da [RFC1035 4.1.3]. Ci sono cinque possibili insiemi di semantiche che possono essere espressi qui, riassunti come segue e poi spiegati di seguito.

L'RRset esiste (indipendente dal valore). Almeno un RR con NAME e TYPE specificati (nella zona e nella classe specificate dalla sezione Zone) deve esistere.
L'RRset esiste (dipendente dal valore). Un insieme di RR con NAME e TYPE specificati esiste e ha gli stessi membri con gli stessi RDATA dell'RRset specificato qui in questa sezione.
L'RRset non esiste. Nessun RR con NAME e TYPE specificati (nella zona e nella classe denotate dalla sezione Zone) può esistere.
Il nome è in uso. Almeno un RR con un NAME specificato (nella zona e nella classe specificate dalla sezione Zone) deve esistere. Si noti che questo prerequisito NON è soddisfatto dai non-terminali vuoti.
Il nome non è in uso. Nessun RR di alcun tipo è posseduto da un NAME specificato. Si noti che questo prerequisito È soddisfatto dai non-terminali vuoti.

La sintassi di questi è la seguente:

2.4.1 - L'RRset Esiste (Indipendente dal Valore)

Almeno un RR con NAME e TYPE specificati (nella zona e nella classe specificate nella sezione Zone) deve esistere.

Per questo prerequisito, un richiedente aggiunge alla sezione un singolo RR il cui NAME e TYPE sono uguali a quello dell'RRset di zona la cui esistenza è richiesta. RDLENGTH è zero e RDATA è quindi vuoto. CLASS deve essere specificato come ANY per differenziare questa condizione da quella di un RR effettivo il cui RDLENGTH è naturalmente zero (0) (ad esempio, NULL). TTL è specificato come zero (0).

2.4.2 - L'RRset Esiste (Dipendente dal Valore)

Un insieme di RR con NAME e TYPE specificati esiste e ha gli stessi membri con gli stessi RDATA dell'RRset specificato qui in questa sezione. Mentre l'ordinamento dell'RRset è indefinito e quindi non significativo per questo confronto, gli insiemi devono essere identici nella loro estensione.

Per questo prerequisito, un richiedente aggiunge alla sezione un RRset intero la cui preesistenza è richiesta. NAME e TYPE sono quelli dell'RRset denotato. CLASS è quella della zona. TTL deve essere specificato come zero (0) ed è ignorato quando si confrontano gli RRset per l'identità.

2.4.3 - L'RRset Non Esiste

Nessun RR con NAME e TYPE specificati (nella zona e nella classe denotate dalla sezione Zone) può esistere.

Per questo prerequisito, un richiedente aggiunge alla sezione un singolo RR il cui NAME e TYPE sono uguali a quello dell'RRset la cui non esistenza è richiesta. Il RDLENGTH di questo record è zero (0) e il campo RDATA è quindi vuoto. CLASS deve essere specificato come NONE per distinguere questa condizione da un RR valido il cui RDLENGTH è naturalmente zero (0) (ad esempio, il RR NULL). TTL deve essere specificato come zero (0).

2.4.4 - Il Nome è in Uso

Il nome è in uso. Almeno un RR con un NAME specificato (nella zona e nella classe specificate dalla sezione Zone) deve esistere. Si noti che questo prerequisito NON è soddisfatto dai non-terminali vuoti.

Per questo prerequisito, un richiedente aggiunge alla sezione un singolo RR il cui NAME è uguale a quello del nome la cui proprietà di un RR è richiesta. RDLENGTH è zero e RDATA è quindi vuoto. CLASS deve essere specificato come ANY per differenziare questa condizione da quella di un RR effettivo il cui RDLENGTH è naturalmente zero (0) (ad esempio, NULL). TYPE deve essere specificato come ANY per differenziare questo caso da quello di un test di esistenza dell'RRset. TTL è specificato come zero (0).

2.4.5 - Il Nome Non è in Uso

Il nome non è in uso. Nessun RR di alcun tipo è posseduto da un NAME specificato. Si noti che questo prerequisito È soddisfatto dai non-terminali vuoti.

Per questo prerequisito, un richiedente aggiunge alla sezione un singolo RR il cui NAME è uguale a quello del nome la cui non proprietà di RR è richiesta. RDLENGTH è zero e RDATA è quindi vuoto. CLASS deve essere specificato come NONE. TYPE deve essere specificato come ANY. TTL deve essere specificato come zero (0).

2.5 Sezione Update

Questa sezione contiene RR da aggiungere o eliminare dalla zona. Il formato di questa sezione è come specificato da [RFC1035 4.1.3]. Ci sono quattro possibili insiemi di semantiche, riassunti di seguito e con dettagli a seguire.

Aggiungere RR a un RRset.
Eliminare un RRset.
Eliminare tutti gli RRset da un nome.
Eliminare un RR da un RRset.

La sintassi di questi è la seguente:

2.5.1 - Aggiungere a un RRset

Gli RR vengono aggiunti alla sezione Update il cui NAME, TYPE, TTL, RDLENGTH e RDATA sono quelli aggiunti, e CLASS è la stessa della classe di zona. Eventuali RR duplicati saranno silenziosamente ignorati dal master principale.

2.5.2 - Eliminare un RRset

Viene aggiunto un RR alla sezione Update il cui NAME e TYPE sono quelli dell'RRset da eliminare. TTL deve essere specificato come zero (0) e non è altrimenti utilizzato dal master principale. CLASS deve essere specificato come ANY. RDLENGTH deve essere zero (0) e RDATA deve quindi essere vuoto. Se tale RRset non esiste, allora questo RR Update sarà silenziosamente ignorato dal master principale.

2.5.3 - Eliminare Tutti gli RRset da un Nome

Viene aggiunto un RR alla sezione Update il cui NAME è quello del nome da pulire degli RRset. TYPE deve essere specificato come ANY. TTL deve essere specificato come zero (0) e non è altrimenti utilizzato dal master principale. CLASS deve essere specificato come ANY. RDLENGTH deve essere zero (0) e RDATA deve quindi essere vuoto. Se tali RRset non esistono, allora questo RR Update sarà silenziosamente ignorato dal master principale.

2.5.4 - Eliminare un RR da un RRset

Gli RR da eliminare vengono aggiunti alla sezione Update. NAME, TYPE, RDLENGTH e RDATA devono corrispondere all'RR eliminato. TTL deve essere specificato come zero (0) e sarà altrimenti ignorato dal master principale. CLASS deve essere specificato come NONE per distinguere questo da un'aggiunta di RR. Se tali RR non esistono, allora questo RR Update sarà silenziosamente ignorato dal master principale.

2.6 Sezione Additional Data

Questa sezione contiene RR correlati all'aggiornamento stesso o ai nuovi RR aggiunti dall'aggiornamento. Ad esempio, il glue fuori zona (RR A riferiti dai nuovi RR NS) dovrebbe essere presentato qui. Il server può utilizzare o ignorare il glue fuori zona, a discrezione dell'implementatore del server. Il formato di questa sezione è come specificato da [RFC1035 4.1.3].