1. Introduzione

Le strutture standard del Domain Name System per il mantenimento di server coerenti per una zona consistono in tre elementi. Il trasferimento autoritativo (AXFR) è definito in "Domain Names - Concepts and Facilities" [RFC1034] (indicato in questo documento come RFC 1034) e "Domain Names - Implementation and Specification" [RFC1035] (d'ora in poi RFC 1035). Il trasferimento di zona incrementale (IXFR) è definito in "Incremental Zone Transfer in DNS" [RFC1995]. Un meccanismo per la notifica tempestiva delle modifiche di zona (NOTIFY) è definito in "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)" [RFC1996]. L'obiettivo di questi meccanismi è consentire a un insieme di server dei nomi DNS di rimanere coerentemente autoritativi per una data zona.

Questo documento rispecifica il meccanismo AXFR come è distribuito nell'Internet in generale, si spera con la precisione attesa dagli standard Internet moderni, e pertanto aggiorna RFC 1034 e RFC 1035.

1.1. Definizione dei termini

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in "Key words for use in RFCs to Indicate Requirement Levels" [BCP14].

L'uso di "newer"/"new" e "older"/"old" DNS si riferisce alle implementazioni scritte rispettivamente dopo e prima della pubblicazione di questo documento.

"Implementazione DNS per uso generale" si riferisce al software DNS sviluppato per un uso diffuso. Ciò include resolver e server liberamente accessibili come librerie e processi autonomi. Ciò include anche implementazioni proprietarie utilizzate solo a supporto delle offerte di servizi DNS.

"Implementazione DNS chiavi in mano" si riferisce a implementazioni DNS personalizzate monouso. Tali implementazioni consistono in software che impiega il formato del messaggio del protocollo DNS ma non è conforme all'intera gamma di funzionalità DNS.

I termini "sessione AXFR", "server AXFR" e "client AXFR" saranno introdotti nel primo paragrafo della Sezione 2, dopo aver stabilito ulteriore contesto.

1.2. Ambito

In termini generali, i server dei nomi autoritativi per una data zona possono utilizzare vari mezzi per ottenere la coerenza dei contenuti di zona che servono. Ad esempio, ci sono implementazioni DNS che assemblano risposte da dati memorizzati in database relazionali (in contrapposizione ai file master), facendo affidamento sui mezzi non-DNS del database per sincronizzare le istanze del database. Alcune di queste soluzioni non-DNS interoperano in qualche modo. Tuttavia, AXFR, IXFR e NOTIFY sono gli unici meccanismi in-band definiti dal protocollo per fornire coerenza a un insieme di server dei nomi, e sono gli unici meccanismi specificati dall'IETF.

Questo documento non copre situazioni DNS incoerenti. Ci sono applicazioni del DNS in cui i server per una zona non sono destinati a essere coerenti.

1.3. Contesto

Un client AXFR emette una query per ricevere i contenuti di una zona da un server AXFR. Tali trasferimenti sono un tipo di query DNS e conformi alle specifiche del protocollo DNS, inclusi messaggi di intestazione di query e risposta.

I contenuti di zona sono i RR DNS autoritativi di proprietà dei nomi di dominio all'interno della zona. Tipicamente, tutti i RR autoritativi per una zona vengono trasferiti da una sessione AXFR, con un'eccezione. Quando si segue un taglio di zona, i record di colla non vengono trasferiti.

Un trasferimento di zona viene avviato dal timer di refresh SOA DNS, un messaggio NOTIFY o un intervento dell'operatore (sebbene altri mezzi non siano preclusi). Un AXFR è spesso limitato ai server specificamente configurati come secondari ai server primari per la zona, e le query da altri client vengono rifiutate.

La definizione originale del 1035 di AXFR specificava che dovesse essere eseguito su TCP. Questa specifica supporta solo AXFR su TCP. Per completezza, tuttavia, questa specifica menziona AXFR-su-UDP in un'appendice informativa.

Una sessione AXFR consiste in un messaggio di query AXFR, uno o più messaggi di risposta AXFR e, infine, la terminazione della connessione TCP. Una sessione AXFR è detta "riuscita" se si verificano le seguenti due condizioni: (1) il client AXFR ha ricevuto una sequenza di risposta AXFR riuscita, e (2) il client AXFR ha chiuso la connessione TCP o il client ha ricevuto conferma che il server AXFR ha chiuso la connessione TCP.

Questo documento non affronta la sicurezza del trasferimento di zona. Le considerazioni di sicurezza rilevanti sono discusse nella Sezione 8.

1.4. Copertura e relazione con la specifica AXFR originale

Questo documento copre una sessione AXFR autoritativa, non consapevole di DNS UPDATE, da primario a secondario senza sicurezza impiegata, e la zona trasferita è una zona DNS "normale", per il trasporto IPv4. Cioè, il server è un master o primario per la zona e il client è un server secondario o slave. La definizione è stata scritta in un modo inteso a permettere un meccanismo di estensione per indicare la copertura di valori di parametri aggiuntivi.

Per riferimento, questo documento nota quanto segue (ma non definisce nessuna di queste varianti):

• I trasferimenti di zona possono essere condotti tra uno slave e un altro slave (tutti sono server autoritativi).

• Un client di trasferimento di zona può essere un resolver o un validatore di zona che raccoglie dati (applicazioni non autoritative).

• Esiste un'estensione di protocollo opzionale che permette "trasferimenti incrementali" -- Trasferimento di zona incrementale (IXFR) [RFC1995].

• DNSSEC (tramite RFC 4033 [RFC4033], RFC 4034 [RFC4034] e RFC 4035 [RFC4035]) definisce un protocollo di sicurezza per DNS.

• DNS UPDATE (RFC 2136 [RFC2136]) fornisce un mezzo tramite il quale una zona può essere aggiornata dinamicamente.

• Può essere utilizzato il trasporto IPv6.

L'obiettivo nel menzionare questi è rendere chiaro che, sebbene i meccanismi descritti in questo documento si applichino solo a uno scenario specifico, ci sono scenari correlati che si riferiscono a questo documento per fornire contesto. Le varianti elencate non sono tutte equivalenti, certamente non sono indipendenti l'una dall'altra, e possono o meno rientrare nell'ambito di questo documento.

Questo documento ha intenzionalmente un ambito ristretto, ma è scritto in modo da indicare che descrive un meccanismo estensibile.