2. Messaggi AXFR

Una sessione AXFR consiste in una singola connessione TCP ed è avviata da un messaggio di query DNS. Quel messaggio di query determina la zona da trasferire e certe caratteristiche della sessione. Dopo la query viene il trasferimento dei contenuti della zona, assumendo una query riuscita, e poi una terminazione della connessione.

Le seguenti definizioni sono utilizzate in questo documento. Il "client AXFR" è l'host che avvia la connessione TCP e invia la query DNS AXFR. Il "server AXFR" è l'host che riceve la query AXFR e invia la o le risposte AXFR. Una "sessione AXFR" consiste in una query AXFR e la sequenza di risposte AXFR corrispondenti a quella query.

Un AXFR è uno dei diversi tipi di query (QTYPE) definiti per il DNS; tuttavia, a differenza della maggior parte dei tipi di query, AXFR può richiedere diversi messaggi DNS per rispondere completamente a una query. Il formato della query iniziale e dei messaggi di risposta sono messaggi DNS standard, definiti in RFC 1035 e documenti successivi. Alcuni campi nel messaggio DNS sono ulteriormente ristretti quando il tipo di query è un AXFR.

In tutto questo documento, le query e le risposte AXFR saranno divise in sezioni seguendo la struttura del messaggio DNS. Le cinque sezioni sono: (1) Intestazione, (2) Domanda, (3) Risposta, (4) Autorità, e (5) Aggiuntiva.

Questa sezione documenta i messaggi di query e risposta, includendo restrizioni sulle query e requisiti sui server. Questo affronta anche l'uso della connessione TCP.

2.1. Query AXFR

Questa sottosezione descrive il formato e la semantica del messaggio di query che avvia una sessione AXFR. Il termine "DNS normale" sarà utilizzato per descrivere il comportamento governato dalla specifica DNS standard (RFC 1034, RFC 1035 e aggiornamenti).

Una query AXFR è come un normale messaggio di query DNS con QTYPE AXFR; tuttavia, ci sono restrizioni aggiuntive imposte su una "query AXFR ben formata". Un client AXFR che invia una query AXFR DOVREBBE conformarsi alle regole per una query ben formata. Un server AXFR DEVE rispondere a una query AXFR che non si conforme a queste regole nello stesso modo in cui risponderebbe a qualsiasi query formattata in modo improprio. (Questa è tipicamente una risposta FORMERR.)

Una query AXFR ben formata ha le seguenti caratteristiche:

1. L'OPCODE dell'intestazione DNS DEVE essere zero (una query standard).

2. Il conteggio della sezione domanda dell'intestazione DNS (QDCOUNT) DEVE essere 1.

3. Il conteggio della sezione risposta dell'intestazione DNS (ANCOUNT), il conteggio della sezione autorità (NSCOUNT) e il conteggio della sezione aggiuntiva (ARCOUNT) DEVONO tutti essere 0.

4. La sezione domanda DEVE contenere una singola domanda con:

   • QTYPE uguale a AXFR [RFC5395] (252 decimale);
   • QCLASS uguale alla classe di zona o ANY;
   • QNAME uguale al nome della zona da trasferire.

5. Le risposte AXFR POSSONO essere di una versione del protocollo DNS superiore alla query.

2.1.1. Valori dell'intestazione

QR: DEVE essere 0 (Query)

OPCODE: DEVE essere 0 (Query standard)

AA: Non esaminato (irrilevante per una query)

TC: DEVE essere 0 (Non troncato) - Una query AXFR con TC impostato a 1 è formattata in modo improprio.

RD: PUÒ essere 0 o 1 - Il bit Recursion Desired è ignorato dal server AXFR; non influenza il comportamento di una query AXFR né gioca un ruolo nei trasferimenti autoritativi. L'impostazione del bit RD in un messaggio di query AXFR non è un indicatore affidabile che la query sia una query ricorsiva.

RA: Non esaminato (utilizzato solo nelle risposte)

Z: DEVE essere 0 (riservato per uso futuro) - Secondo il requisito della specifica DNS, i bit riservati DEVONO essere zero in una query e DEVONO essere ignorati in una risposta. Pertanto, un client AXFR DEVE impostare i bit Z a zero, e un server AXFR DEVE ignorare il loro valore. Una query AXFR con uno qualsiasi dei bit riservati (Z) impostato a un valore diverso da zero è formattata in modo improprio.

AD: DEVE essere 0 - Il bit Authentic Data è definito solo per le risposte [RFC4035].

CD: PUÒ essere 0 o 1 - Il bit Checking Disabled è rilevante solo per le risposte, quindi non ha significato definito per una query di trasferimento di zona. Un client AXFR PUÒ impostare questo bit; un server AXFR DEVE ignorare il suo valore.

RCODE: DEVE essere 0 (Nessun errore) - Il campo del codice di risposta è definito solo per le risposte.

QDCOUNT: DEVE essere 1

ANCOUNT: DEVE essere 0

NSCOUNT: DEVE essere 0

ARCOUNT: DEVE essere 0 o PUÒ essere maggiore di zero se la query include opzioni EDNS(0) [RFC2671], TSIG [RFC2845] o SIG(0) [RFC2931].

Per considerazioni su EDNS(0), TSIG e SIG(0), vedere la Sezione 2.2.5.

2.1.2. Sezione domanda

La sezione domanda DEVE conformarsi a quella specificata in RFC 1035, contenente una singola domanda con le seguenti caratteristiche:

QNAME: Il nome della zona da trasferire, che DEVE essere un nome di dominio DNS valido.

QTYPE: Il valore è 252 (per AXFR) secondo [RFC5395].

QCLASS: La classe della zona da trasferire. Poiché le query AXFR possono essere un rischio di sicurezza importante, un server AXFR probabilmente limiterà l'accesso al trasferimento di zona attraverso qualche politica (tramite liste di controllo accessi, autenticazione TSIG, ecc.), e un trasferimento di zona non dovrebbe essere servito a qualsiasi richiedente. Il valore QCLASS speciale * (ANY, 255 decimale) PUÒ essere utilizzato per scopi di compatibilità retroattiva. Quando QCLASS è ANY, un server AXFR non deve restituire dati di zona per tutte le classi di dati disponibili, ma può scegliere una classe e trasferire quella zona o può rifiutare la query. (Quest'ultima è RACCOMANDATA per un'implementazione DNS per uso generale.) I client AXFR accuratamente scritti richiedono trasferimenti di zona tramite classi specifiche.

2.1.3. Sezione risposta

La sezione risposta DEVE essere vuota (ANCOUNT deve essere 0) in una query AXFR.

2.1.4. Sezione autorità

La sezione autorità DEVE essere vuota (NSCOUNT deve essere 0) in una query AXFR.

2.1.5. Sezione aggiuntiva

La sezione aggiuntiva di un messaggio di query AXFR può contenere record di risorse (RR) EDNS(0) [RFC2671] per indicare supporto e parametri EDNS. Può anche contenere RR TSIG [RFC2845] o SIG(0) [RFC2931] per scopi di autenticazione. La presenza di opzioni TSIG o SIG(0) consente l'autenticazione della query AXFR, potenzialmente abilitando politiche di autorizzazione più permissive sul server AXFR.

Quando viene utilizzato EDNS(0), il pseudo-RR OPT è posizionato nella sezione aggiuntiva, e ARCOUNT viene incrementato di conseguenza. Il numero di versione pubblicizzato da EDNS(0) indica la volontà di accettare pacchetti formattati per quella versione. Un client AXFR che non è consapevole di EDNS imposterà ARCOUNT a 0 e non includerà un RR OPT. Un server AXFR che non è consapevole di EDNS ignorerà il RR OPT e può scegliere di trattare la query come mal formata se ARCOUNT è maggiore di 0 e l'elaborazione aggiuntiva (esame di quei RR aggiuntivi) è abilitata.

Una query AXFR con un SIG(0) avrà ARCOUNT uguale a 1 più il numero di RR OPT nella sezione aggiuntiva. Un RR TSIG non viene conteggiato in ARCOUNT, poiché TSIG è una tecnica di autenticazione dei messaggi alternativa in DNS. Vedere [RFC2845] per le considerazioni su TSIG.

TSIG ed EDNS(0) POSSONO essere utilizzati simultaneamente.

2.2. Risposta AXFR

Questa sottosezione descrive il formato e la semantica delle risposte alle query AXFR. Le risposte vengono inviate dopo che una connessione TCP è stabilita e una query AXFR è analizzata.

Un server AXFR DEVE essere in grado di gestire una query con flag o attributi inaspettati, non definiti o non supportati rispondendo con una risposta di errore DNS standard. Le condizioni che causano vari errori sono elaborate nelle sottosezioni seguenti.

Ci sono quattro categorie di risposte del server AXFR a una query AXFR:

1. Una risposta mal formata: Ciò risulta se la query AXFR ricevuta tramite TCP non è un messaggio di query DNS legale o se il messaggio DNS non si conforma ai requisiti di una query AXFR ben formata come specificato nella Sezione 2.1. La risposta a una query mal formata DOVREBBE essere un singolo messaggio di risposta DNS con un RCODE appropriato (FORMERR, NOTIMP, REFUSED, ecc.).

2. Una risposta rifiutata: Se un messaggio DNS ricevuto è una query AXFR legale, ma considerazioni di politica dettano che questo particolare client AXFR non è autorizzato a eseguire trasferimenti di zona (per la zona in questione o in generale), la risposta DOVREBBE essere un singolo messaggio di risposta DNS con RCODE REFUSED.

3. Una risposta vuota: Se la zona trasferita è vuota (tutti i dati autoritativi all'apice della zona sono al di fuori della zona), il server AXFR DOVREBBE restituire un singolo messaggio di risposta con solo un RR SOA nella sezione risposta. Questo RR SOA sarà l'unico RR nella zona. Le condizioni per una zona vuota sono molto insolite e sono il risultato di operazioni fuori banda (modifiche di zona, aggiornamenti dinamici o altri mezzi) che hanno rimosso tutto tranne il SOA obbligatorio dalla zona.

4. Una risposta riuscita: Assumendo che non ci siano problemi di politica o malformazione, il server AXFR risponde con uno o più messaggi di risposta DNS che contengono collettivamente tutti i dati autoritativi dalla zona trasferita, soggetti ad alcune inclusioni ed esclusioni specifiche descritte nella Sezione 3.

I primi tre tipi di risposta sono consegnati tramite un singolo messaggio DNS. L'ultimo tipo, la risposta riuscita, può consistere in uno o più messaggi di risposta DNS inviati sequenzialmente sulla connessione TCP.

Un server AXFR che implementa EDNS(0), TSIG o SIG(0) DEVE essere preparato a ricevere messaggi di query AXFR che non contengono le opzioni corrispondenti. Al contrario, un server AXFR PUÒ scegliere di ignorare la presenza di opzioni EDNS(0), TSIG o SIG(0) nel messaggio di query (ad esempio, se non le supporta o non le richiede). Tuttavia, se un server AXFR implementa EDNS(0), TSIG o SIG(0) e sceglie di utilizzare informazioni da quelle opzioni nella richiesta, DEVE includere le informazioni di opzione appropriate nei suoi messaggi di risposta AXFR.

Un client AXFR DEVE essere preparato a ricevere risposte AXFR in cui il bit TC (troncamento) non è utilizzato o significativo. Poiché AXFR opera su TCP ed è consentito utilizzare più messaggi DNS in una sequenza di risposta, il troncamento non è necessario. (L'uso del bit TC è esplicitamente coperto nella Sezione 2.2.1.)

2.2.1. Valori dell'intestazione

QR: DEVE essere 1 (Risposta)

OPCODE: DEVE essere 0 (Query standard)

AA: Il bit AA (Risposta autoritativa) DOVREBBE essere impostato a 1 in tutti i messaggi di risposta. Mentre il server AXFR è probabilmente autoritativo per la zona trasferita, non c'è un requisito rigoroso che debba essere così.

TC: DEVE essere 0 (Non troncato) - Poiché AXFR opera su TCP e può utilizzare più messaggi di risposta, non è necessario impostare il bit TC.

RD: Il bit RD nella risposta copia il bit RD dalla query (secondo la specifica DNS). Il bit RD non ha significato per AXFR; il suo valore non influenza il comportamento AXFR.

RA: Il bit RA (Ricorsione disponibile) PUÒ essere impostato o cancellato nella risposta secondo le politiche generali del server AXFR. Nel caso di un trasferimento di zona, la ricorsione non è applicabile, quindi il valore di RA non è significativo in questo contesto.

Z: DEVE essere 0 (Riservato) - I bit riservati DEVONO essere impostati a zero da un server AXFR e DEVONO essere ignorati da un client AXFR.

AD: PUÒ essere 0 o 1 - Per i server AXFR consapevoli di DNSSEC che servono zone firmate DNSSEC, il bit AD (Dati autentici) PUÒ essere impostato nelle risposte AXFR secondo i requisiti DNSSEC [RFC4035]. Per le zone che non sono firmate DNSSEC, il bit AD DOVREBBE essere 0. Un client AXFR che non è consapevole di DNSSEC ignora il bit AD.

CD: DOVREBBE essere 0 - Il bit CD (Controllo disabilitato) è rilevante solo per i resolver, non per i server autoritativi. Per le risposte AXFR, il bit CD DOVREBBE essere 0 e non ha significato definito.

RCODE: Il codice di risposta indica il risultato della query AXFR. I valori comuni includono:

• NOERROR (0): Trasferimento riuscito (tutti i messaggi di risposta in una sequenza di risposta AXFR riuscita hanno RCODE impostato a NOERROR).
• FORMERR (1): Errore di formato nella query.
• SERVFAIL (2): Fallimento del server durante l'elaborazione della richiesta.
• NOTIMP (4): Tipo di query non implementato.
• REFUSED (5): Trasferimento di zona rifiutato per politica.
• NOTAUTH (9): Il server non è autoritativo per la zona richiesta (definito in [RFC2136]).

Per una risposta AXFR riuscita, tutti i messaggi di risposta DNS nella sessione AXFR DEVONO avere RCODE impostato a NOERROR. Se un messaggio di risposta DNS in una sessione AXFR ha RCODE impostato a qualcosa di diverso da NOERROR, il client AXFR DEVE considerare il trasferimento di zona fallito.

QDCOUNT: DEVE essere 1 - La sezione domanda è ripetuta in ogni messaggio di risposta, copiando la domanda dalla query.

ANCOUNT: Indica il numero di RR nella sezione risposta. Il valore varia a seconda di quanti RR si adattano in ogni messaggio di risposta.

NSCOUNT: DEVE essere 0 - Nessuna sezione autorità è inclusa nei messaggi di risposta AXFR.

ARCOUNT: DEVE essere 0 o maggiore se viene utilizzato EDNS(0), TSIG o SIG(0). Tipicamente, ARCOUNT è 0 per le risposte AXFR.

2.2.2. Sezione domanda

La sezione domanda nella risposta DEVE essere identica alla sezione domanda nella query AXFR corrispondente. Questo significa che QDCOUNT DEVE essere 1, e la singola domanda DEVE corrispondere alla domanda dalla query.

2.2.3. Sezione risposta

La sezione risposta contiene i dati di zona trasferiti. I requisiti per i contenuti della sezione risposta sono:

1. RR SOA: Il primo RR nel primo messaggio di risposta di una risposta AXFR DEVE essere il RR SOA per la zona. L'ultimo RR nell'ultimo messaggio di risposta di una risposta AXFR DEVE anche essere il RR SOA per la zona (cioè, lo stesso RR SOA appare all'inizio e alla fine del trasferimento).

2. RR intermedi: Tra i due RR SOA (il primo e l'ultimo), la sezione risposta del o dei messaggi di risposta contiene tutti gli altri RR autoritativi per la zona (soggetti alle restrizioni nella Sezione 3).

3. Ordine: L'ordine dei RR nella sezione risposta (diversi dai primi e ultimi RR SOA) non è definito. Tuttavia, tutti i RR dello stesso RRset (stesso nome proprietario, classe e tipo) DOVREBBERO essere raggruppati insieme per efficienza.

4. Messaggi multipli: Se i dati di zona non si adattano in un singolo messaggio di risposta DNS, il server AXFR invia più messaggi di risposta. Ogni messaggio di risposta dopo il primo continua con dati di zona aggiuntivi, e l'ultimo messaggio termina con il RR SOA finale.

2.2.4. Sezione autorità

La sezione autorità DEVE essere vuota (NSCOUNT = 0) nei messaggi di risposta AXFR. L'inclusione di record NS o altri dati di autorità nella sezione autorità di una risposta AXFR è esplicitamente vietata.

2.2.5. Sezione aggiuntiva

La sezione aggiuntiva dei messaggi di risposta AXFR è generalmente vuota, ma PUÒ contenere RR EDNS(0), TSIG o SIG(0) se tali opzioni sono state negoziate o sono in uso.

EDNS(0): Se la query AXFR conteneva un RR OPT EDNS(0), il server AXFR PUÒ includere RR OPT nelle sezioni aggiuntive dei suoi messaggi di risposta. EDNS(0) nelle risposte AXFR è utilizzato principalmente per segnalare capacità estese e dimensioni del buffer.

TSIG: Se TSIG è utilizzato per l'autenticazione, i RR TSIG sono inclusi nella sezione aggiuntiva dei messaggi di risposta AXFR. La firma TSIG è applicata in modo diverso nelle risposte AXFR multi-messaggio:

• Il primo messaggio di risposta in una sequenza AXFR riuscita DEVE includere un RR TSIG.
• I messaggi intermedi POSSONO omettere il RR TSIG (intermedi non firmati sono consentiti).
• L'ultimo messaggio di risposta DEVE includere un RR TSIG.

Vedere [RFC2845] per considerazioni dettagliate su TSIG.

SIG(0): Se viene utilizzato SIG(0), ogni messaggio di risposta contenente un SIG(0) avrà ARCOUNT incrementato di conseguenza.

2.3. Interruzioni della connessione TCP

Un client AXFR o un server AXFR PUÒ interrompere una sessione AXFR in corso chiudendo la connessione TCP. Le ragioni per interrompere una connessione includono:

• Messaggi DNS mal formati o inaspettati.
• Timeout (timeout di lettura o scrittura).
• Fallimenti di autorizzazione (ad esempio, fallimento della validazione TSIG).
• Errori interni del server.
• Esaurimento delle risorse.

Una connessione interrotta DEVE essere interpretata dal client AXFR come un trasferimento di zona fallito. Il client AXFR NON DOVREBBE committare alcun dato di zona parziale ricevuto prima della chiusura della connessione.

Un server AXFR PUÒ utilizzare la chiusura della connessione TCP come indicazione al client AXFR che il trasferimento di zona è fallito.