7. Problemi di Progettazione

7. Problemi di Progettazione

Questa sezione discute varie decisioni di progettazione e chiarimenti relativi al protocollo DNS UPDATE.

7.1. Questo documento colloca intenzionalmente tutta la complessità nel server. Il comportamento del richiedente è in gran parte non specificato in modo da dare ai richiedenti la massima libertà possibile.

7.2. I nomi di proprietario wildcard (cioè, nomi con un'etichetta "*") sono supportati nel protocollo UPDATE con la restrizione che il wildcarding è disabilitato (vedi sezione 1.1.3). Questo significa che i wildcard negli aggiornamenti sono trattati letteralmente e non eseguiranno espansione o corrispondenza wildcard.

7.3. Il TTL di un RRset può essere aggiornato eliminando l'RRset e poi aggiungendolo nuovamente con un nuovo TTL. Tuttavia, un CNAME non può coesistere con nessun altro RRset su un nome, quindi gli aggiornamenti che coinvolgono CNAME dovrebbero essere eseguiti con attenzione per evitare di creare configurazioni illegali.

7.4. Gli RR duplicati verranno silenziosamente ignorati. Questo significa che se un aggiornamento tenta di aggiungere un RR che esiste già nella zona con RDATA identici, l'aggiornamento avrà successo ma non avrà alcun effetto sul contenuto della zona.

7.5. Si prevede che in assenza di Secure DNS Update, un server accetterà aggiornamenti solo se provengono da un indirizzo sorgente che è stato configurato staticamente nella descrizione del server di una zona master principale. I server DHCP sarebbero probabili candidati per l'inclusione in questo elenco configurato staticamente.

7.6. Non è possibile creare una zona utilizzando questo protocollo, poiché non c'è disposizione per un server slave di essere informato di chi sono i suoi server master. Si prevede che questo protocollo sarà esteso in futuro per coprire questo caso. Pertanto, al momento, l'aggiunta di RR SOA non è supportata. Per ragioni simili, anche l'eliminazione di RR SOA non è supportata.

7.7. Il prerequisito per specificare che un nome possieda almeno un RR differisce semanticamente da QUERY, in quanto QUERY restituirebbe <NOERROR,ANCOUNT=0> piuttosto che NXDOMAIN se interrogato per un RRset su questo nome, mentre la condizione di prerequisito di UPDATE [Sezione 2.4.4] NON sarebbe soddisfatta.

7.8. È possibile che una risposta UDP vada persa in transito e che una richiesta venga riprovata a causa di una condizione di timeout. In questo caso, un UPDATE che ha avuto successo la prima volta che è stato ricevuto dal master principale potrebbe alla fine sembrare essere fallito quando la risposta a una richiesta duplicata viene finalmente ricevuta dal richiedente. (Questo perché i prerequisiti originali potrebbero non essere più soddisfatti dopo che l'aggiornamento è stato applicato.) Per questo motivo, i richiedenti che richiedono un codice di risposta accurato devono utilizzare TCP.

7.9. Poiché un richiedente che richiede un codice di risposta accurato avvierà la sua transazione UPDATE utilizzando TCP, un forwarder che riceve una richiesta via TCP deve inoltrarla utilizzando TCP.

7.10. Il rinvio degli auto-incrementi SOA SERIAL è reso possibile in modo che i numeri di serie possano essere conservati e il wraparound a 2**32 possa essere reso un evento raro. I SOA SERIAL visibili (ai client DNS) devono differire se la zona differisce. Si noti che il SOA della sezione Authority in una risposta QUERY è una forma di visibilità, ai fini di questo prerequisito.

7.11. Il SOA SERIAL di una zona non dovrebbe mai essere impostato a zero (0) a causa di problemi di interoperabilità con alcune implementazioni DNS più vecchie ma ampiamente installate. Quando si incrementa un SOA SERIAL, se il risultato dell'incremento è zero (0) (come sarà vero quando si verifica il wraparound a 2**32), è necessario incrementarlo nuovamente o impostarlo a uno (1). Vedi [RFC1982] per maggiori dettagli su questo argomento.

7.12. A causa della minimizzazione TTL necessaria quando si memorizza nella cache un RRset, si raccomanda che tutti i TTL in un RRset siano impostati allo stesso valore. Mentre il formato del messaggio DNS permette che i TTL varianti esistano nello stesso RRset, e questa varianza può esistere all'interno di una zona, tale varianza avrà risultati controintuitivi e il suo uso è scoraggiato.

7.13. La gestione del taglio di zona presenta alcuni casi limite oscuri alle operazioni di aggiunta ed eliminazione nella sezione Update. È possibile eliminare un RR NS purché non sia l'ultimo RR NS alla radice di una zona. Se si eliminano tutti gli RR da un nome, gli RR SOA e NS alla radice di una zona non sono interessati. Se si eliminano RRset, non è possibile eliminare i RRset SOA o NS in cima a una zona. Un tentativo di aggiungere un SOA sarà trattato come un'operazione di sostituzione se un SOA esiste già, o come un no-op se il SOA sarebbe nuovo.

7.14. Non è richiesta alcuna verifica semantica nel server master principale quando si aggiungono nuovi RR. Pertanto un richiedente può far sì che CNAME o NS o qualsiasi altro tipo di RR venga aggiunto anche se il loro nome target non esiste o non ha i RRset appropriati per rendere utile l'RR originale. I server master principali che implementano questo tipo di verifica dovrebbero prestare grande attenzione ad evitare dipendenze fuori zona (la cui veridicità non può essere verificata in modo autorevole) e dovrebbero implementare tutta tale verifica durante la fase di prescan.

7.15. I CNAME non-terminali o wildcard non sono ben specificati da [RFC1035] e il loro uso porterà probabilmente a risultati imprevedibili. Il loro uso è scoraggiato.

7.16. I non-terminali vuoti (nodi con figli ma senza RR propri) causeranno l'invio di risposte <NOERROR,ANCOUNT=0> in risposta a una query di qualsiasi tipo per quel nome. Non c'è disposizione per i nodi terminali vuoti - quindi se tutti gli RR di un nodo terminale vengono eliminati, il nome non è più in uso, e le query di qualsiasi tipo per quel nome risulteranno in una risposta NXDOMAIN.

7.17. In un grafo di dipendenza AXFR profondo, non è stato storicamente un errore per gli slave dipendere mutuamente l'uno dall'altro. Questa configurazione è stata utilizzata per consentire a una zona di fluire dal master principale a tutti gli slave anche se non tutti gli slave hanno connettività continua al master principale. L'uso da parte di UPDATE del grafo di dipendenza AXFR per l'inoltro proibisce questo tipo di loop di dipendenza, poiché l'inoltro UPDATE non ha rilevamento di loop analogo al pretest SOA SERIAL utilizzato da AXFR.

7.18. I nomi precedentemente esistenti che sono oscurati da un nuovo taglio di zona sono ancora considerati parte della zona genitore, ai fini dei trasferimenti di zona, anche se le query per tali nomi saranno riferite ai server della nuova sottozona. Se un taglio di zona viene rimosso, tutti i nomi della zona genitore che erano oscurati da esso diventeranno nuovamente visibili alle query. (Questa è una chiarificazione di [RFC1034].)

7.19. Se un server è autorevole per una zona e il suo figlio, allora le query per i nomi al taglio di zona tra di essi saranno risposte in modo autorevole utilizzando solo i dati dalla zona figlio. (Questa è una chiarificazione di [RFC1034].)

7.20. L'ordinamento degli aggiornamenti utilizzando l'RR SOA è problematico poiché non c'è modo di sapere quale degli RR NS di una zona rappresenta il master principale, e gli slave di zona possono essere obsoleti se i loro timer SOA.REFRESH non sono scaduti dall'ultima volta che la zona è stata modificata sul master principale. Raccomandiamo che una zona che necessita di aggiornamenti ordinati utilizzi solo server che implementano NOTIFY (vedi [RFC1996]) e IXFR (vedi [RFC1995]), e che un client che riceve un errore di prerequisito mentre tenta un aggiornamento ordinato semplicemente riprovi dopo un periodo di ritardo casuale per consentire alla zona di stabilizzarsi.