2. Update-Nachrichtenformat

Das DNS-Nachrichtenformat ist durch [RFC1035 4.1] definiert. Einige Erweiterungen sind erforderlich (z.B. sind unter UPDATE mehr Fehlercodes möglich als unter QUERY) und einige Felder müssen überladen werden (siehe Beschreibung der CLASS-Felder unten).

Das Gesamtformat einer UPDATE-Nachricht ist gemäß [ibid]:

+---------------------+
|        Header       |
+---------------------+
|         Zone        | gibt die zu aktualisierende Zone an
+---------------------+
|     Prerequisite    | RRs oder RRsets, die (nicht) vorhanden sein müssen
+---------------------+
|        Update       | RRs oder RRsets, die hinzugefügt oder gelöscht werden sollen
+---------------------+
|   Additional Data   | zusätzliche Daten
+---------------------+

Der Header-Abschnitt gibt an, dass diese Nachricht ein UPDATE ist, und beschreibt die Größe der anderen Abschnitte. Der Zone-Abschnitt benennt die Zone, die durch diese Nachricht aktualisiert werden soll. Der Prerequisite-Abschnitt gibt die Anfangsinvarianten (im Hinblick auf den Zoneninhalt) an, die für dieses Update erforderlich sind. Der Update-Abschnitt enthält die vorzunehmenden Änderungen, und der Additional Data-Abschnitt enthält Daten, die zum Abschluss notwendig sein können, aber nicht Teil dieses Updates sind.

2.1 Transportprobleme

Eine Update-Transaktion kann in einem UDP-Datagramm übertragen werden, wenn die Anfrage passt, oder in einer TCP-Verbindung (nach Ermessen des Anforderers). Wenn TCP verwendet wird, ist die Nachricht in dem in [RFC1035 4.2.2] beschriebenen Format.

2.2 Nachrichten-Header

Der Header des DNS-Nachrichtenformats ist durch [RFC 1035 4.1] definiert. Nicht alle Opcodes definieren dieselben Flag-Bits, obwohl praktisch die meisten der für QUERY definierten Bits (in [ibid]) von den anderen Opcodes identisch definiert werden. UPDATE verwendet nur ein Flag-Bit (QR).

Das DNS-Nachrichtenformat gibt Datensatzzählungen für seine vier Abschnitte an (Question, Answer, Authority und Additional). UPDATE verwendet dieselben Felder und dieselben Abschnittsformate, aber die Benennung und Verwendung dieser Abschnitte unterscheidet sich wie im folgenden modifizierten Header nach [RFC1035 4.1.1] gezeigt:

                                  1  1  1  1  1  1
    0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                      ID                       |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |QR|   Opcode  |          Z         |   RCODE   |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                    ZOCOUNT                    |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                    PRCOUNT                    |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                    UPCOUNT                    |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                    ADCOUNT                    |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Diese Felder werden wie folgt verwendet:

ID
Eine 16-Bit-Kennung, die von der Entität zugewiesen wird, die eine beliebige Art von Anfrage generiert. Diese Kennung wird in die entsprechende Antwort kopiert und kann vom Anforderer verwendet werden, um Antworten mit ausstehenden Anfragen abzugleichen, oder vom Server, um doppelte Anfragen von einem Anforderer zu erkennen.

QR
Ein Ein-Bit-Feld, das angibt, ob diese Nachricht eine Anfrage (0) oder eine Antwort (1) ist.

Opcode
Ein Vier-Bit-Feld, das die Art der Anfrage in dieser Nachricht angibt. Dieser Wert wird vom Urheber einer Anfrage gesetzt und in die Antwort kopiert. Der Opcode-Wert, der eine UPDATE-Nachricht identifiziert, ist fünf (5).

Z
Für zukünftige Verwendung reserviert. Sollte in allen Anfragen und Antworten null (0) sein. Ein Z-Feld ungleich null sollte von Implementierungen dieser Spezifikation ignoriert werden.

RCODE
Antwortcode - dieses Vier-Bit-Feld ist in Anfragen undefiniert und in Antworten gesetzt. Die Werte und Bedeutungen dieses Feldes innerhalb von Antworten sind wie folgt:

Mnemonik	Wert	Beschreibung
NOERROR	0	Keine Fehlerbedingung.
FORMERR	1	Der Nameserver konnte die Anfrage aufgrund eines Formatfehlers nicht interpretieren.
SERVFAIL	2	Der Nameserver stieß bei der Verarbeitung dieser Anfrage auf einen internen Fehler, z.B. einen Betriebssystemfehler oder ein Weiterleitungs-Timeout.
NXDOMAIN	3	Ein Name, der existieren sollte, existiert nicht.
NOTIMP	4	Der Nameserver unterstützt den angegebenen Opcode nicht.
REFUSED	5	Der Nameserver verweigert die Durchführung der angegebenen Operation aus Richtlinien- oder Sicherheitsgründen.
YXDOMAIN	6	Ein Name, der nicht existieren sollte, existiert.
YXRRSET	7	Ein RRset, das nicht existieren sollte, existiert.
NXRRSET	8	Ein RRset, das existieren sollte, existiert nicht.
NOTAUTH	9	Der Server ist nicht autoritativ für die im Zone-Abschnitt genannte Zone.
NOTZONE	10	Ein im Prerequisite- oder Update-Abschnitt verwendeter Name liegt nicht innerhalb der vom Zone-Abschnitt bezeichneten Zone.

ZOCOUNT
Die Anzahl der RRs im Zone-Abschnitt.

PRCOUNT
Die Anzahl der RRs im Prerequisite-Abschnitt.

UPCOUNT
Die Anzahl der RRs im Update-Abschnitt.

ADCOUNT
Die Anzahl der RRs im Additional Data-Abschnitt.

2.3 Zone-Abschnitt

Der Zone-Abschnitt hat dasselbe Format wie in [RFC1035 4.1.2] angegeben, wobei die Felder wie folgt neu definiert sind:

                                  1  1  1  1  1  1
    0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                                               |
  /                     ZNAME                     /
  /                                               /
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                     ZTYPE                     |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                     ZCLASS                    |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

UPDATE verwendet diesen Abschnitt, um die Zone der zu aktualisierenden Datensätze anzugeben. Alle zu aktualisierenden Datensätze müssen sich in derselben Zone befinden, daher darf der Zone-Abschnitt genau einen Datensatz enthalten. ZNAME ist der Zonenname, ZTYPE muss SOA sein und ZCLASS ist die Klasse der Zone.

2.4 Prerequisite-Abschnitt

Dieser Abschnitt enthält eine Reihe von RRset-Voraussetzungen, die zu dem Zeitpunkt erfüllt sein müssen, zu dem das UPDATE-Paket vom primären Master-Server empfangen wird. Das Format dieses Abschnitts entspricht [RFC1035 4.1.3]. Es gibt fünf mögliche Semantiksets, die hier ausgedrückt werden können, zusammengefasst wie folgt und dann unten erklärt.

RRset existiert (wertunabhängig). Mindestens ein RR mit einem angegebenen NAME und TYPE (in der durch den Zone-Abschnitt angegebenen Zone und Klasse) muss existieren.
RRset existiert (wertabhängig). Ein Satz von RRs mit einem angegebenen NAME und TYPE existiert und hat dieselben Mitglieder mit denselben RDATAs wie das hier in diesem Abschnitt angegebene RRset.
RRset existiert nicht. Keine RRs mit einem angegebenen NAME und TYPE (in der durch den Zone-Abschnitt bezeichneten Zone und Klasse) dürfen existieren.
Name wird verwendet. Mindestens ein RR mit einem angegebenen NAME (in der durch den Zone-Abschnitt angegebenen Zone und Klasse) muss existieren. Beachten Sie, dass diese Voraussetzung NICHT durch leere Nicht-Terminals erfüllt wird.
Name wird nicht verwendet. Kein RR eines beliebigen Typs ist im Besitz eines angegebenen NAME. Beachten Sie, dass diese Voraussetzung durch leere Nicht-Terminals erfüllt wird.

Die Syntax davon ist wie folgt:

2.4.1 - RRset existiert (wertunabhängig)

Mindestens ein RR mit einem angegebenen NAME und TYPE (in der durch den Zone-Abschnitt angegebenen Zone und Klasse) muss existieren.

Für diese Voraussetzung fügt ein Anforderer dem Abschnitt einen einzelnen RR hinzu, dessen NAME und TYPE gleich dem des Zonen-RRset sind, dessen Existenz erforderlich ist. RDLENGTH ist null und RDATA ist daher leer. CLASS muss als ANY angegeben werden, um diese Bedingung von der eines tatsächlichen RR zu unterscheiden, dessen RDLENGTH natürlicherweise null (0) ist (z.B. NULL). TTL wird als null (0) angegeben.

2.4.2 - RRset existiert (wertabhängig)

Ein Satz von RRs mit einem angegebenen NAME und TYPE existiert und hat dieselben Mitglieder mit denselben RDATAs wie das hier in diesem Abschnitt angegebene RRset. Während die RRset-Reihenfolge undefiniert und daher für diesen Vergleich nicht signifikant ist, müssen die Mengen in ihrem Umfang identisch sein.

Für diese Voraussetzung fügt ein Anforderer dem Abschnitt ein vollständiges RRset hinzu, dessen Vorhandensein erforderlich ist. NAME und TYPE sind die des bezeichneten RRset. CLASS ist die der Zone. TTL muss als null (0) angegeben werden und wird beim Vergleich von RRsets auf Identität ignoriert.

2.4.3 - RRset existiert nicht

Keine RRs mit einem angegebenen NAME und TYPE (in der durch den Zone-Abschnitt bezeichneten Zone und Klasse) dürfen existieren.

Für diese Voraussetzung fügt ein Anforderer dem Abschnitt einen einzelnen RR hinzu, dessen NAME und TYPE gleich dem des RRset sind, dessen Nichtexistenz erforderlich ist. Die RDLENGTH dieses Datensatzes ist null (0), und das RDATA-Feld ist daher leer. CLASS muss als NONE angegeben werden, um diese Bedingung von einem gültigen RR zu unterscheiden, dessen RDLENGTH natürlicherweise null (0) ist (z.B. der NULL RR). TTL muss als null (0) angegeben werden.

2.4.4 - Name wird verwendet

Name wird verwendet. Mindestens ein RR mit einem angegebenen NAME (in der durch den Zone-Abschnitt angegebenen Zone und Klasse) muss existieren. Beachten Sie, dass diese Voraussetzung NICHT durch leere Nicht-Terminals erfüllt wird.

Für diese Voraussetzung fügt ein Anforderer dem Abschnitt einen einzelnen RR hinzu, dessen NAME gleich dem des Namens ist, dessen Besitz eines RR erforderlich ist. RDLENGTH ist null und RDATA ist daher leer. CLASS muss als ANY angegeben werden, um diese Bedingung von der eines tatsächlichen RR zu unterscheiden, dessen RDLENGTH natürlicherweise null (0) ist (z.B. NULL). TYPE muss als ANY angegeben werden, um diesen Fall von einem RRset-Existenztest zu unterscheiden. TTL wird als null (0) angegeben.

2.4.5 - Name wird nicht verwendet

Name wird nicht verwendet. Kein RR eines beliebigen Typs ist im Besitz eines angegebenen NAME. Beachten Sie, dass diese Voraussetzung durch leere Nicht-Terminals erfüllt wird.

Für diese Voraussetzung fügt ein Anforderer dem Abschnitt einen einzelnen RR hinzu, dessen NAME gleich dem des Namens ist, dessen Nichtbesitz von RRs erforderlich ist. RDLENGTH ist null und RDATA ist daher leer. CLASS muss als NONE angegeben werden. TYPE muss als ANY angegeben werden. TTL muss als null (0) angegeben werden.

2.5 Update-Abschnitt

Dieser Abschnitt enthält RRs, die zur Zone hinzugefügt oder aus ihr gelöscht werden sollen. Das Format dieses Abschnitts entspricht [RFC1035 4.1.3]. Es gibt vier mögliche Semantiksets, die unten zusammengefasst sind und mit Details folgen.

RRs zu einem RRset hinzufügen.
Ein RRset löschen.
Alle RRsets von einem Namen löschen.
Ein RR aus einem RRset löschen.

Die Syntax davon ist wie folgt:

2.5.1 - Zu einem RRset hinzufügen

RRs werden dem Update-Abschnitt hinzugefügt, deren NAME, TYPE, TTL, RDLENGTH und RDATA die hinzugefügten sind, und CLASS ist dieselbe wie die Zonenklasse. Alle doppelten RRs werden vom primären Master stillschweigend ignoriert.

2.5.2 - Ein RRset löschen

Ein RR wird dem Update-Abschnitt hinzugefügt, dessen NAME und TYPE die des zu löschenden RRset sind. TTL muss als null (0) angegeben werden und wird vom primären Master nicht verwendet. CLASS muss als ANY angegeben werden. RDLENGTH muss null (0) sein und RDATA muss daher leer sein. Wenn ein solches RRset nicht existiert, wird dieser Update RR vom primären Master stillschweigend ignoriert.

2.5.3 - Alle RRsets von einem Namen löschen

Ein RR wird dem Update-Abschnitt hinzugefügt, dessen NAME der des von RRsets zu bereinigenden Namens ist. TYPE muss als ANY angegeben werden. TTL muss als null (0) angegeben werden und wird vom primären Master nicht verwendet. CLASS muss als ANY angegeben werden. RDLENGTH muss null (0) sein und RDATA muss daher leer sein. Wenn keine solchen RRsets existieren, wird dieser Update RR vom primären Master stillschweigend ignoriert.

2.5.4 - Ein RR aus einem RRset löschen

Zu löschende RRs werden dem Update-Abschnitt hinzugefügt. NAME, TYPE, RDLENGTH und RDATA müssen mit dem zu löschenden RR übereinstimmen. TTL muss als null (0) angegeben werden und wird vom primären Master ignoriert. CLASS muss als NONE angegeben werden, um dies von einer RR-Hinzufügung zu unterscheiden. Wenn keine solchen RRs existieren, wird dieser Update RR vom primären Master stillschweigend ignoriert.

2.6 Additional Data-Abschnitt

Dieser Abschnitt enthält RRs, die mit dem Update selbst oder mit neuen RRs zusammenhängen, die durch das Update hinzugefügt werden. Beispielsweise sollten Out-of-Zone-Glue (A RRs, auf die von neuen NS RRs verwiesen wird) hier präsentiert werden. Der Server kann Out-of-Zone-Glue nach Ermessen des Server-Implementierers verwenden oder ignorieren. Das Format dieses Abschnitts entspricht [RFC1035 4.1.3].