7. Compatibilità con le versioni precedenti

Descrivere la compatibilità con le versioni precedenti è difficile a causa della mancanza di specificità nella definizione originale. In questa sezione, vengono forniti alcuni suggerimenti per costruire la compatibilità con le versioni precedenti, principalmente ripetuti dalle sezioni precedenti pertinenti.

La compatibilità con le versioni precedenti non è necessaria, ma maggiore è l'estensione della compatibilità di un'implementazione, maggiore è la sua interoperabilità. Per le implementazioni chiavi in mano, questo di solito non è un problema. Per le implementazioni per uso generale, questo assume livelli di importanza variabili, a seconda del desiderio dell'implementatore di mantenere l'interoperabilità.

È sfortunato che la necessità di tornare al comportamento più vecchio non possa essere scoperta, e quindi debba essere annotata in un file di configurazione. Un'implementazione DOVREBBE, nella sua documentazione, incoraggiare gli operatori a rivedere periodicamente i client e server AXFR su cui ha preso note ripetutamente, poiché i vecchi software vengono aggiornati di tanto in tanto.

7.1. Server

Un server AXFR ha il lusso di poter reagire alle capacità di un client AXFR, con l'eccezione di sapere se il client può accettare più record di risorse per messaggio di risposta AXFR. La conoscenza che un client è così limitato non può essere scoperta; quindi, deve essere impostata tramite configurazione.

Un'implementazione di un server AXFR PUÒ permettere di configurare, su base per client AXFR, la necessità di tornare a un singolo record di risorsa per messaggio; in tal caso, il valore predefinito DOVREBBE essere di utilizzare più record per messaggio.

Considerazioni per i client legacy :

1. Singolo RR per messaggio : Alcune implementazioni DNS molto vecchie si aspettano solo un singolo record di risorsa nella sezione di risposta di ogni messaggio di risposta AXFR. I server AXFR moderni DOVREBBERO supportare più RR per messaggio per efficienza, ma POSSONO fornire un'opzione di configurazione per tornare al comportamento a singolo RR per client legacy specifici.

2. Dimensione del messaggio : I client più vecchi possono avere limitazioni sulla dimensione massima dei messaggi DNS che possono elaborare. I server AXFR POSSONO fornire opzioni di configurazione per limitare la dimensione dei singoli messaggi di risposta quando interagiscono con tali client.

3. EDNS(0), TSIG e SIG(0) : I client più vecchi potrebbero non supportare EDNS(0), TSIG o SIG(0). Un server AXFR DOVREBBE gestire con grazia le query dai client che non includono queste opzioni e NON DOVREBBE richiederne la presenza a meno che non sia specificamente configurato per farlo per motivi di sicurezza.

Raccomandazioni per le implementazioni di server :

• Predefinito per comportamento moderno ed efficiente (più RR per messaggio, supporto per EDNS(0)/TSIG/SIG(0)).
• Fornire opzioni di configurazione per accogliere i client legacy su base per client.
• Documentare i problemi di compatibilità noti e le impostazioni di configurazione raccomandate per interoperare con software più vecchi.

7.2. Client

Un client AXFR ha l'opportunità di provare altre funzionalità (cioè, quelle non definite da questo documento) quando interroga un server AXFR.

Tentare di emettere più query DNS su un trasporto TCP per una sessione AXFR DOVREBBE essere interrotto se interrompe la richiesta originale, e DOVREBBE prendere in considerazione se il server AXFR intende chiudere la connessione immediatamente al completamento del trasferimento di zona originale (causante la connessione).

Considerazioni per i server legacy :

1. Più RR per messaggio : I client AXFR moderni DEVONO essere preparati a ricevere più record di risorse in un singolo messaggio di risposta AXFR. Questo è un comportamento standard ed è stato ampiamente distribuito per molti anni.

2. Gestione della connessione : I server più vecchi potrebbero chiudere la connessione TCP immediatamente dopo aver inviato il RR SOA finale, mentre altri potrebbero mantenere la connessione aperta per un periodo di tempo. I client AXFR DOVREBBERO essere preparati per entrambi i comportamenti e NON DOVREBBERO fare affidamento sul fatto che la connessione rimanga aperta dopo il completamento del trasferimento di zona.

3. Risposte di errore : Alcuni server più vecchi potrebbero restituire risposte di errore non standard o potrebbero non conformarsi rigorosamente al formato del messaggio DNS. I client AXFR DOVREBBERO implementare una gestione degli errori robusta per gestire con grazia risposte inaspettate.

Raccomandazioni per le implementazioni di client :

• Supportare tutte le funzionalità standard definite in questo documento.
• Implementare una gestione degli errori robusta per tollerare deviazioni minori dalla specifica.
• Evitare di fare affidamento sulla persistenza della connessione o altri comportamenti non standard.
• Essere preparati a tornare a comportamenti più semplici (ad esempio, non utilizzare EDNS(0)) se un server sembra non supportarlo.