4. Comportamento del Richiedente
4. Comportamento del Richiedente
Questa sezione descrive il comportamento di un richiedente, cioè un agente che effettua richieste UPDATE.
4.1. Un richiedente invia una richiesta UPDATE a un name server autorevole noto per la zona che viene aggiornata. Questo server può essere un server principale o slave per la zona. Se il server è uno slave, la richiesta verrà inoltrata al principale. Il richiedente può provare più server prima di trovarne uno che sia autorevole e possa eseguire l'aggiornamento.
4.2. Se il server risponde con un codice di risposta NOTAUTH o NOTIMP, il richiedente dovrebbe provare un server diverso.
4.3. Se il codice di risposta è SERVFAIL, il richiedente dovrebbe riprovare l'aggiornamento, forse dopo un certo ritardo. Tuttavia, in assenza di un algoritmo di retry più specifico specificato da un protocollo di scoperta del servizio DNS, il richiedente non dovrebbe riprovare indefinitamente.
4.4. Se il codice di risposta è YXRRSET o NXRRSET, questo significa che il prerequisito non è stato soddisfatto. Il richiedente può riprovare con un prerequisito modificato o può abortire l'aggiornamento.
4.5. Se il codice di risposta è NOERROR, l'aggiornamento è stato accettato dal master principale. Tuttavia, questo non garantisce che tutti gli slave abbiano ricevuto l'aggiornamento.
4.6. Un richiedente può includere un RR SOA nell'aggiornamento per impostare o modificare i parametri SOA. Se devono essere inviati più messaggi UPDATE per la stessa zona in sequenza, e se il SOA SERIAL è gestito dal richiedente, allora il richiedente dovrebbe controllare il SOA SERIAL attuale della zona (forse esaminando la risposta a un UPDATE precedente) prima di inviare aggiornamenti successivi. Questo evita gare tra i messaggi UPDATE del richiedente e i trasferimenti di zona slave.
4.7. UDP è preferito per le richieste UPDATE che si adattano a un singolo datagramma, poiché questo impone meno carico sul server e meno ritardo per il richiedente. Tuttavia, i richiedenti dovrebbero essere preparati a riprovare la richiesta utilizzando TCP se la richiesta UDP scade, poiché alcuni firewall e filtri di pacchetti bloccano la porta UDP 53. I richiedenti che richiedono un codice di risposta accurato devono utilizzare TCP, poiché una risposta UDP può andare persa in transito.
4.8. Mentre è possibile includere più aggiornamenti in un singolo messaggio UPDATE, farlo non è raccomandato a meno che gli aggiornamenti non siano fortemente correlati. Il motivo è che se un qualsiasi aggiornamento nel messaggio non riesce a soddisfare i suoi prerequisiti o incontra un errore durante l'elaborazione, l'intero messaggio UPDATE verrà rifiutato. Pertanto, i richiedenti dovrebbero generalmente inviare messaggi UPDATE separati per aggiornamenti non correlati.