1. Definitions (Definitionen)

Dieses Dokument gibt absichtlich mehr Definition zu den Rollen von "Master", "Slave" und "Primary Master" Servern sowie deren Aufzählung in NS RRs und dem SOA MNAME Feld. In diesem Sinne können die folgenden Servertyp-Definitionen als Ergänzung zu [RFC1035] betrachtet werden und sollen konsistent mit [RFC1996] sein:

Slave
Ein autoritativer Server, der AXFR oder IXFR verwendet, um die Zone abzurufen und im NS RRset der Zone genannt wird.

Master
Ein autoritativer Server, der als Quelle von AXFR- oder IXFR-Daten für einen oder mehrere Slave-Server konfiguriert ist.

Primary Master
Master-Server an der Wurzel des AXFR/IXFR-Abhängigkeitsgraphen. Der Primary Master wird im SOA MNAME Feld der Zone genannt und optional durch einen NS RR. Per Definition gibt es nur einen Primary Master Server pro Zone.

Ein Domänenname identifiziert einen Knoten innerhalb der Domänennamen-Baumstruktur. Jeder Knoten hat eine (möglicherweise leere) Menge von Resource Records (RRs). Alle RRs mit demselben NAME, CLASS und TYPE werden Resource Record Set (RRset) genannt.

Der in diesem Dokument verwendete Pseudocode dient nur zu Beispielzwecken. Wenn festgestellt wird, dass er mit dem Text nicht übereinstimmt, gilt der Text als maßgeblich. Wenn der Text als mehrdeutig befunden wird, kann der Pseudocode zur Auflösung der Mehrdeutigkeit verwendet werden.

1.1 Comparison Rules (Vergleichsregeln)

1.1.1. Zwei RRs werden als gleich betrachtet, wenn ihre NAME, CLASS, TYPE, RDLENGTH und RDATA Felder gleich sind. Beachten Sie, dass das time-to-live (TTL) Feld explizit vom Vergleich ausgeschlossen ist.

1.1.2. Die Regeln für den Vergleich von Zeichenketten in Namen sind in [RFC1035 2.3.3] spezifiziert.

1.1.3. Wildcarding ist deaktiviert. Das heißt, ein Wildcard ("") in einem Update stimmt nur mit einem Wildcard ("") in der Zone überein und umgekehrt.

1.1.4. Aliasing ist deaktiviert: Ein CNAME in der Zone stimmt mit einem CNAME im Update überein und wird nicht anderweitig verfolgt. Alle UPDATE-Operationen werden auf Basis kanonischer Namen durchgeführt.

1.1.5. Die folgenden RR-Typen können nicht an ein RRset angehängt werden. Wenn die folgenden Vergleichsregeln erfüllt sind, führt ein Versuch, den neuen RR hinzuzufügen, zum Ersetzen des vorherigen RR:

SOA
Vergleiche nur NAME, CLASS und TYPE -- es ist nicht möglich, mehr als einen SOA pro Zone zu haben, selbst wenn eines der Datenfelder unterschiedlich ist.

WKS
Vergleiche nur NAME, CLASS, TYPE, ADDRESS und PROTOCOL -- nur ein WKS RR ist für dieses Tupel möglich, selbst wenn die Dienstmasken unterschiedlich sind.

CNAME
Vergleiche nur NAME, CLASS und TYPE -- es ist nicht möglich, mehr als einen CNAME RR zu haben, selbst wenn ihre Datenfelder unterschiedlich sind.

1.2 Glue RRs (Glue-RRs)

Zum Zweck der Bestimmung, ob ein im UPDATE-Protokoll verwendeter Domänenname in einer angegebenen Zone enthalten ist, ist ein Domänenname "in" einer Zone, wenn er von diesem Zonennamen besessen wird. Siehe Abschnitt 7.18 für Details.

1.3 New Assigned Numbers (Neu zugewiesene Nummern)

CLASS = NONE (254)
RCODE = YXDOMAIN (6)
RCODE = YXRRSET (7)
RCODE = NXRRSET (8)
RCODE = NOTAUTH (9)
RCODE = NOTZONE (10)
Opcode = UPDATE (5)