7. SOA RRs

Drei kleinere Probleme bezüglich des Start of Zone of Authority (SOA) Ressourceneintrags bedürfen einiger Klärung.

7.1. Placement of SOA RRs in authoritative answers (Platzierung von SOA RRs in autoritativen Antworten)

RFC1034 zeigt in Abschnitt 3.7 an, dass der Autoritätsabschnitt einer autoritativen Antwort den SOA-Eintrag für die Zone enthalten kann, aus der die Antwort stammt. Bei der Diskussion von negativem Caching bezieht sich RFC1034 Abschnitt 4.3.4 auf diese Technik, erwähnt aber den zusätzlichen Abschnitt der Antwort. Ersteres ist korrekt, wie es durch das in Abschnitt 6.2.5 von RFC1034 gezeigte Beispiel angedeutet wird. SOA-Einträge sollten, falls hinzugefügt, im Autoritätsabschnitt platziert werden.

7.2. TTLs on SOA RRs (TTLs auf SOA RRs)

Es kann beobachtet werden, dass in Abschnitt 3.2.1 von RFC1035, der das Format eines Ressourceneintrags definiert, die Definition des TTL-Felds eine nebensächliche Zeile enthält, die besagt, dass die TTL eines SOA-Eintrags immer als Null gesendet werden sollte, um Caching zu verhindern. Dies wird nirgendwo anders erwähnt und wurde im Allgemeinen nicht implementiert. Implementierungen sollten nicht davon ausgehen, dass SOA-Einträge eine TTL von Null haben werden, noch sind sie verpflichtet, SOA-Einträge mit einer TTL von Null zu senden.

7.3. The SOA.MNAME field (Das SOA.MNAME-Feld)

Es ist in den Spezifikationen ziemlich klar, scheint aber weitgehend ignoriert worden zu sein, dass das MNAME-Feld des SOA-Eintrags den Namen des primären (Master-)Servers für die durch den SOA identifizierte Zone enthalten sollte. Es sollte nicht den Namen der Zone selbst enthalten. Diese Information wäre nutzlos, da man, um sie zu entdecken, mit dem Domänennamen des SOA-Eintrags beginnen muss — das ist der Name der Zone.

---