7. Designfragen

7. Designfragen

Dieser Abschnitt diskutiert verschiedene Designentscheidungen und Klarstellungen im Zusammenhang mit dem DNS UPDATE-Protokoll.

7.1. Dieses Dokument platziert absichtlich die gesamte Komplexität auf dem Server. Das Verhalten des Anforderers ist weitgehend nicht spezifiziert, um Anfordern die größtmögliche Freiheit zu geben.

7.2. Wildcard-Besitzernamen (d.h. Namen mit einem "*"-Label) werden im UPDATE-Protokoll mit der Einschränkung unterstützt, dass Wildcarding deaktiviert ist (siehe Abschnitt 1.1.3). Dies bedeutet, dass Wildcards in Updates buchstäblich behandelt werden und keine Wildcard-Expansion oder -Übereinstimmung durchführen.

7.3. Der TTL eines RRset kann aktualisiert werden, indem das RRset gelöscht und dann mit einem neuen TTL wieder hinzugefügt wird. Ein CNAME kann jedoch nicht mit einem anderen RRset an einem Namen koexistieren, daher sollten Updates mit CNAMEs sorgfältig durchgeführt werden, um das Erstellen illegaler Konfigurationen zu vermeiden.

7.4. Doppelte RRs werden stillschweigend ignoriert. Dies bedeutet, dass, wenn ein Update versucht, einen RR hinzuzufügen, der bereits in der Zone mit identischen RDATA existiert, das Update erfolgreich sein wird, aber keine Auswirkungen auf den Zoneninhalt hat.

7.5. Es wird erwartet, dass ein Server in Abwesenheit von Secure DNS Update nur Updates akzeptiert, wenn sie von einer Quelladresse stammen, die in der Beschreibung einer primären Master-Zone des Servers statisch konfiguriert wurde. DHCP-Server wären wahrscheinliche Kandidaten für die Aufnahme in diese statisch konfigurierte Liste.

7.6. Es ist nicht möglich, eine Zone mit diesem Protokoll zu erstellen, da es keine Möglichkeit gibt, einem Slave-Server mitzuteilen, wer seine Master-Server sind. Es wird erwartet, dass dieses Protokoll in Zukunft erweitert wird, um diesen Fall abzudecken. Daher wird zu diesem Zeitpunkt das Hinzufügen von SOA RRs nicht unterstützt. Aus ähnlichen Gründen wird auch das Löschen von SOA RRs nicht unterstützt.

7.7. Die Voraussetzung zum Spezifizieren, dass ein Name mindestens einen RR besitzt, unterscheidet sich semantisch von QUERY, da QUERY <NOERROR,ANCOUNT=0> statt NXDOMAIN zurückgeben würde, wenn nach einem RRset an diesem Namen abgefragt wird, während die Voraussetzungsbedingung von UPDATE [Abschnitt 2.4.4] NICHT erfüllt wäre.

7.8. Es ist möglich, dass eine UDP-Antwort während der Übertragung verloren geht und eine Anfrage aufgrund einer Timeout-Bedingung wiederholt wird. In diesem Fall könnte ein UPDATE, das beim ersten Empfang durch den primären Master erfolgreich war, letztendlich als fehlgeschlagen erscheinen, wenn die Antwort auf eine doppelte Anfrage schließlich vom Anforderer empfangen wird. (Dies liegt daran, dass die ursprünglichen Voraussetzungen möglicherweise nicht mehr erfüllt sind, nachdem das Update angewendet wurde.) Aus diesem Grund müssen Anforderer, die einen genauen Antwortcode benötigen, TCP verwenden.

7.9. Da ein Anforderer, der einen genauen Antwortcode benötigt, seine UPDATE-Transaktion mit TCP initiiert, muss ein Weiterleiter, der eine Anfrage über TCP erhält, diese mit TCP weiterleiten.

7.10. Die Verschiebung von SOA SERIAL-Auto-Inkrementierungen wird möglich gemacht, damit Seriennummern gespart werden können und das Überlaufen bei 2**32 zu einem seltenen Ereignis gemacht werden kann. Sichtbare (für DNS-Clients) SOA SERIALs müssen sich unterscheiden, wenn sich die Zone unterscheidet. Beachten Sie, dass das Authority Section SOA in einer QUERY-Antwort eine Form der Sichtbarkeit ist, für die Zwecke dieser Voraussetzung.

7.11. Das SOA SERIAL einer Zone sollte niemals auf null (0) gesetzt werden, aufgrund von Interoperabilitätsproblemen mit einigen älteren, aber weit verbreiteten Implementierungen von DNS. Beim Inkrementieren eines SOA SERIAL, wenn das Ergebnis des Inkrements null (0) ist (wie es beim Überlauf von 2**32 der Fall sein wird), ist es notwendig, es erneut zu inkrementieren oder auf eins (1) zu setzen. Siehe [RFC1982] für weitere Details zu diesem Thema.

7.12. Aufgrund der TTL-Minimierung, die beim Zwischenspeichern eines RRset erforderlich ist, wird empfohlen, dass alle TTLs in einem RRset auf denselben Wert gesetzt werden. Während das DNS-Nachrichtenformat erlaubt, dass variante TTLs im selben RRset existieren, und diese Varianz innerhalb einer Zone existieren kann, wird eine solche Varianz kontraintuitive Ergebnisse haben, und ihre Verwendung wird entmutigt.

7.13. Die Verwaltung von Zonenschnitten stellt einige obskure Eckfälle für die Hinzufügungs- und Löschoperationen im Update-Abschnitt dar. Es ist möglich, einen NS RR zu löschen, solange es nicht der letzte NS RR an der Wurzel einer Zone ist. Beim Löschen aller RRs von einem Namen bleiben SOA- und NS-RRs an der Wurzel einer Zone unberührt. Beim Löschen von RRsets ist es nicht möglich, SOA- oder NS-RRsets an der Spitze einer Zone zu löschen. Ein Versuch, ein SOA hinzuzufügen, wird als Ersetzungsoperation behandelt, wenn bereits ein SOA existiert, oder als No-Op, wenn das SOA neu wäre.

7.14. Im primären Master-Server ist keine semantische Überprüfung beim Hinzufügen neuer RRs erforderlich. Daher kann ein Anforderer veranlassen, dass CNAME- oder NS- oder andere Arten von RRs hinzugefügt werden, auch wenn ihr Zielname nicht existiert oder nicht die richtigen RRsets hat, um den ursprünglichen RR nützlich zu machen. Primäre Master-Server, die diese Art der Überprüfung implementieren, sollten große Sorgfalt darauf verwenden, zonenexterne Abhängigkeiten (deren Richtigkeit nicht autoritativ überprüft werden kann) zu vermeiden und sollten alle solchen Überprüfungen während der Vorscan-Phase implementieren.

7.15. Nichtterminal- oder Wildcard-CNAMEs sind von [RFC1035] nicht gut spezifiziert, und ihre Verwendung wird wahrscheinlich zu unvorhersehbaren Ergebnissen führen. Ihre Verwendung wird entmutigt.

7.16. Leere Nichtterminals (Knoten mit Kindern, aber ohne eigene RRs) veranlassen, dass <NOERROR,ANCOUNT=0>-Antworten als Antwort auf eine Abfrage eines beliebigen Typs für diesen Namen gesendet werden. Es gibt keine Bestimmung für leere Terminalknoten - wenn also alle RRs eines Terminalknotens gelöscht werden, ist der Name nicht mehr in Gebrauch, und Abfragen eines beliebigen Typs für diesen Namen führen zu einer NXDOMAIN-Antwort.

7.17. In einem tiefen AXFR-Abhängigkeitsgraphen war es historisch kein Fehler, dass Slaves gegenseitig voneinander abhängig sind. Diese Konfiguration wurde verwendet, um es einer Zone zu ermöglichen, vom primären Master zu allen Slaves zu fließen, auch wenn nicht alle Slaves kontinuierliche Konnektivität zum primären Master haben. Die Verwendung des AXFR-Abhängigkeitsgraphen durch UPDATE für die Weiterleitung verbietet diese Art von Abhängigkeitsschleife, da die UPDATE-Weiterleitung keine Schleifenerkennung analog zum SOA SERIAL-Vortest hat, der von AXFR verwendet wird.

7.18. Zuvor existierende Namen, die durch einen neuen Zonenschnitt verdeckt werden, werden für die Zwecke von Zonentransfers immer noch als Teil der übergeordneten Zone betrachtet, obwohl Abfragen für solche Namen an die Server der neuen Subzone verwiesen werden. Wenn ein Zonenschnitt entfernt wird, werden alle übergeordneten Zonennamen, die durch ihn verdeckt wurden, wieder für Abfragen sichtbar. (Dies ist eine Klarstellung von [RFC1034].)

7.19. Wenn ein Server für eine Zone und ihr Kind autoritativ ist, werden Abfragen für Namen am Zonenschnitt zwischen ihnen autoritativ beantwortet, wobei nur Daten aus der Kindzone verwendet werden. (Dies ist eine Klarstellung von [RFC1034].)

7.20. Die Aktualisierungsreihenfolge unter Verwendung des SOA RR ist problematisch, da es keine Möglichkeit gibt zu wissen, welches der NS RRs einer Zone den primären Master darstellt, und die Zonenslaves möglicherweise veraltet sind, wenn ihre SOA.REFRESH-Timer seit dem letzten Mal, als die Zone auf dem primären Master geändert wurde, nicht abgelaufen sind. Wir empfehlen, dass eine Zone, die geordnete Updates benötigt, nur Server verwendet, die NOTIFY (siehe [RFC1996]) und IXFR (siehe [RFC1995]) implementieren, und dass ein Client, der einen Voraussetzungsfehler beim Versuch eines geordneten Updates erhält, einfach nach einer zufälligen Verzögerungsperiode wiederholt, um der Zone Zeit zum Ausgleichen zu geben.