Passa al contenuto principale

4. Trasporto

Questa sezione descrive i requisiti del protocollo di trasporto per AXFR. La specifica DNS originale definiva AXFR per operare su TCP, e questo rimane l'unico trasporto standardizzato per AXFR.

4.1. TCP​

AXFR DEVE utilizzare TCP come protocollo di trasporto. TCP fornisce consegna dati affidabile, ordinata e verificata per errori, che è essenziale per l'integrità dei trasferimenti di zona.

4.1.1. TCP del client AXFR​

Un client AXFR stabilisce una connessione TCP alla porta DNS del server AXFR (tipicamente porta 53, sebbene altre porte POSSANO essere configurate).

Stabilimento della connessione:

  1. Il client AXFR avvia l'handshake TCP a tre vie per stabilire una connessione con il server AXFR.

  2. Una volta stabilita la connessione TCP, il client AXFR invia il messaggio di query AXFR come specificato nella Sezione 2.1.

  3. Il client AXFR attende quindi che il server AXFR risponda con uno o più messaggi di risposta DNS contenenti i dati di zona.

Persistenza della connessione:

  1. Il client AXFR DOVREBBE mantenere la connessione TCP aperta fino a quando il trasferimento di zona completo viene ricevuto, come indicato dalla ricezione del RR SOA finale nella sezione di risposta di un messaggio di risposta.

  2. Dopo aver ricevuto il trasferimento di zona completo, il client AXFR PUÒ chiudere la connessione TCP o PUÒ mantenerla aperta per inviare query aggiuntive (sebbene questo non sia un comportamento tipico per AXFR).

  3. Il client AXFR DEVE essere preparato per il fatto che il server AXFR chiuda la connessione TCP in qualsiasi momento, incluso immediatamente dopo aver completato il trasferimento di zona.

Timeout:

  1. Il client AXFR DOVREBBE implementare timeout di lettura e scrittura per rilevare server che non rispondono o problemi di rete.

  2. I valori di timeout raccomandati variano a seconda della dimensione della zona e delle condizioni di rete, ma un timeout di lettura tipico potrebbe essere nell'ordine di minuti (ad esempio, 5-10 minuti) per accogliere zone grandi.

  3. Se si verifica un timeout, il client AXFR DOVREBBE chiudere la connessione TCP e trattare il trasferimento di zona come fallito.

Gestione degli errori:

  1. Se il client AXFR riceve un messaggio di risposta DNS con un RCODE diverso da NOERROR, DEVE trattare il trasferimento di zona come fallito e chiudere la connessione TCP.

  2. Se il client AXFR riceve un messaggio DNS mal formato o un messaggio che non si conforma al protocollo AXFR, DOVREBBE chiudere la connessione TCP e trattare il trasferimento di zona come fallito.

  3. Se la connessione TCP viene chiusa prematuramente (prima che il RR SOA finale sia ricevuto), il client AXFR DEVE trattare il trasferimento di zona come fallito e scartare tutti i dati di zona parziali ricevuti.

Query multiple:

  1. Un client AXFR PUÒ inviare più query AXFR sulla stessa connessione TCP, una pratica conosciuta come "pipelining" o "riutilizzo della connessione". Tuttavia, questo comportamento non è ampiamente implementato o richiesto.

  2. Se un client AXFR invia più query, DEVE attendere la risposta completa alla prima query (incluso il RR SOA finale) prima di inviare la query successiva.

  3. Un server AXFR non è tenuto a supportare più query per connessione e PUÒ chiudere la connessione dopo aver risposto a una singola query.

4.1.2. TCP del server AXFR​

Un server AXFR ascolta le connessioni TCP in arrivo sulla sua porta DNS (tipicamente porta 53).

Gestione della connessione:

  1. Dopo aver accettato una connessione TCP, il server AXFR attende di ricevere un messaggio di query DNS dal client AXFR.

  2. Il server AXFR analizza il messaggio di query per determinare se è una query AXFR valida (come definito nella Sezione 2.1).

  3. In base alla query e alle politiche applicabili (ad esempio, ACL, autenticazione TSIG), il server AXFR risponde con i dati di zona o con un messaggio di errore.

Trasmissione della risposta:

  1. Se il trasferimento di zona è autorizzato, il server AXFR invia uno o più messaggi di risposta DNS contenenti i dati di zona, come specificato nella Sezione 2.2.

  2. Ogni messaggio di risposta viene inviato come messaggio DNS completo sulla connessione TCP. Il server AXFR DEVE assicurarsi che i confini del messaggio siano preservati (cioè, ogni messaggio DNS è preceduto da un campo di lunghezza di 2 byte, come specificato in RFC 1035 Sezione 4.2.2).

  3. Il server AXFR continua a inviare messaggi di risposta fino a quando tutti i dati di zona (incluso il RR SOA finale) sono stati trasmessi.

Terminazione della connessione:

  1. Dopo aver trasmesso il messaggio di risposta finale (contenente il RR SOA finale), il server AXFR PUÒ chiudere la connessione TCP immediatamente o PUÒ mantenerla aperta per accettare query aggiuntive.

  2. Il server AXFR DOVREBBE chiudere le connessioni inattive dopo un periodo di timeout ragionevole per liberare risorse.

  3. Il server AXFR PUÒ chiudere la connessione in qualsiasi momento se si verifica un errore (ad esempio, un errore di scrittura, un timeout o un errore interno).

Concorrenza:

  1. Un server AXFR DOVREBBE essere capace di gestire più sessioni AXFR concorrenti (cioè, più connessioni TCP da client diversi).

  2. Il server AXFR PUÒ imporre limiti sul numero di trasferimenti di zona concorrenti per prevenire l'esaurimento delle risorse.

4.2. UDP​

AXFR su UDP non è standardizzato e NON DEVE essere utilizzato nelle implementazioni DNS per uso generale. Sebbene le prime specifiche DNS menzionassero la possibilità di AXFR su UDP per zone piccole, questo approccio presenta limitazioni significative:

  1. Affidabilità: UDP è un protocollo non affidabile e non garantisce la consegna o l'ordine dei pacchetti.

  2. Dimensione del messaggio: I messaggi DNS su UDP sono limitati in dimensione (tipicamente 512 byte senza EDNS(0), o fino a 4096 byte con EDNS(0)), rendendolo impraticabile per la maggior parte dei trasferimenti di zona.

  3. Nessuna standardizzazione: Non esiste un formato o comportamento standardizzato per AXFR su UDP nelle specifiche DNS moderne.

Per queste ragioni, AXFR su UDP è considerato obsoleto e NON DEVE essere implementato in nuovi software DNS. Qualsiasi riferimento ad AXFR su UDP in documenti DNS più vecchi è storico e dovrebbe essere ignorato.

Raccomandazione: I client e server AXFR DEVONO utilizzare TCP. Se è necessaria una sincronizzazione di zona basata su UDP per qualche motivo, gli implementatori dovrebbero considerare l'utilizzo di IXFR [RFC1995] su UDP, sebbene anche IXFR sia tipicamente condotto su TCP.

Ultimo aggiornamento il