5. Comportamento di Inoltro

5. Comportamento di Inoltro

Questa sezione descrive il comportamento di un server di inoltro, cioè un name server slave che inoltra le richieste UPDATE al master principale.

5.1. Quando un server slave riceve una richiesta UPDATE per una zona per cui è autorevole, dovrebbe inoltrare la richiesta al master principale per quella zona. L'indirizzo del master principale dovrebbe essere ottenuto dal campo SOA MNAME della zona o dalla configurazione del server.

5.2. Il server slave dovrebbe preservare l'indirizzo del richiedente originale e altri parametri della richiesta quando inoltra la richiesta. Questo permette al master principale di applicare politiche di sicurezza e di inviare la risposta direttamente al richiedente originale.

5.3. Se il server slave utilizza UDP per inoltrare la richiesta, dovrebbe essere preparato a riprovare utilizzando TCP se la richiesta UDP scade o se riceve un bit TC (troncamento) nella risposta.

5.4. Se un server slave riceve una richiesta UPDATE via TCP, DEVE inoltrare la richiesta al master principale utilizzando TCP. Questo garantisce che i richiedenti che richiedono codici di risposta accurati (che è il motivo per cui hanno utilizzato TCP in primo luogo) li riceveranno.

5.5. Un server slave può implementare un meccanismo di timeout di inoltro. Se una richiesta inoltrata non riceve una risposta dal master principale entro questo periodo di timeout, lo slave può restituire una risposta SERVFAIL al richiedente originale e chiudere la connessione (se è stato utilizzato TCP).

5.6. Se il server slave non è in grado di inoltrare la richiesta (ad esempio, perché non può connettersi al master principale), dovrebbe restituire una risposta SERVFAIL al richiedente.

5.7. È possibile che un server slave implementi una catena di inoltro, dove gli aggiornamenti vengono inoltrati attraverso più server slave prima di raggiungere il master principale. Tuttavia, tali configurazioni non sono raccomandate perché introducono punti aggiuntivi di guasto e ritardo. Se viene utilizzata una tale configurazione, ogni server di inoltro nella catena dovrebbe seguire le regole descritte in questa sezione.

5.8. Un server di inoltro non dovrebbe modificare il messaggio UPDATE tranne per quanto necessario per l'inoltro dei messaggi DNS (ad esempio, impostando il bit recursion desired appropriato per la sua configurazione).

5.9. Il server di inoltro può memorizzare nella cache l'indirizzo del master principale per evitare ripetute ricerche SOA MNAME. Tuttavia, dovrebbe essere preparato ad aggiornare questa cache se i tentativi di inoltro falliscono, poiché il master principale potrebbe essere stato spostato.

5.10. Se viene rilevato un loop di inoltro (ad esempio, se il server slave riceve indietro la propria richiesta inoltrata), il server dovrebbe restituire SERVFAIL per evitare loop di inoltro infiniti.