5. Resource Record Sets (Ressourcen-Datensatzsätze)
Jeder DNS-Ressourceneintrag (Resource Record, RR) hat ein Label, eine Klasse, einen Typ und Daten. Es ist sinnlos, dass zwei Einträge Label, Klasse, Typ und Daten alle gleich haben – Server sollten solche Duplikate unterdrücken, wenn sie auftreten. Es ist jedoch für die meisten Eintragstypen möglich, dass sie mit demselben Label, derselben Klasse und demselben Typ existieren, aber mit unterschiedlichen Daten. Eine solche Gruppe von Einträgen wird hiermit als Ressourcen-Datensatzsatz (Resource Record Set, RRSet) definiert.
5.1. Sending RRs from an RRSet (Senden von RRs aus einem RRSet)
Eine Abfrage nach einem bestimmten (oder nicht bestimmten) Label, Klasse und Typ wird immer alle Einträge im zugehörigen RRSet zurückgeben – ob es sich um einen oder mehrere RRs handelt. Die Antwort muss als „abgeschnitten" (truncated) markiert werden, wenn das gesamte RRSet nicht in die Antwort passt.
5.2. TTLs of RRs in an RRSet (TTLs von RRs in einem RRSet)
Ressourceneinträge haben auch eine Lebensdauer (Time to Live, TTL). Es ist möglich, dass die RRs in einem RRSet unterschiedliche TTLs haben. Es wurden keine Verwendungen dafür gefunden, die nicht besser auf andere Weise erreicht werden können. Dies kann jedoch zu teilweisen Antworten (nicht als „abgeschnitten" markiert) von einem Caching-Server führen, bei denen die TTLs für einige, aber nicht alle RRs im RRSet abgelaufen sind.
Folglich ist die Verwendung unterschiedlicher TTLs in einem RRSet hiermit veraltet, die TTLs aller RRs in einem RRSet müssen gleich sein.
Sollte ein Client eine Antwort erhalten, die RRs aus einem RRSet mit unterschiedlichen TTLs enthält, sollte er dies als Fehler behandeln. Wenn das betreffende RRSet von einer nicht autoritativen Quelle für diese Daten stammt, sollte der Client das RRSet einfach ignorieren und, wenn die Werte erforderlich waren, versuchen, sie von einer autoritativen Quelle zu erwerben. Clients, die so konfiguriert sind, dass sie alle Anfragen an einen oder mehrere bestimmte Server senden, sollten diese Server für diesen Zweck als autoritativ behandeln. Sollte eine autoritative Quelle ein solches fehlerhaftes RRSet senden, sollte der Client die RRs für alle Zwecke so behandeln, als ob alle TTLs im RRSet auf den Wert des niedrigsten TTL im RRSet gesetzt worden wären. In keinem Fall darf ein Server ein RRSet mit nicht identischen TTLs senden.
5.3. DNSSEC Special Cases (DNSSEC-Sonderfälle)
Zwei der durch DNS-Sicherheit (DNSSEC) [RFC2065] hinzugefügten Eintragstypen erfordern besondere Aufmerksamkeit bei der Betrachtung der Bildung von Ressourcen-Datensatzsätzen. Dies sind die SIG- und NXT-Einträge. Es sollte beachtet werden, dass DNS-Sicherheit noch sehr neu ist und es bisher wenig Erfahrung damit gibt. Leser sollten darauf vorbereitet sein, dass die in diesem Dokument enthaltenen DNSSEC-bezogenen Informationen veraltet werden, wenn die DNS-Sicherheitsspezifikation reift.
5.3.1. SIG records and RRSets (SIG-Einträge und RRSets)
Ein SIG-Eintrag stellt Signatur-(Validierungs-)Daten für ein anderes RRSet im DNS bereit. Wenn eine Zone signiert wurde, wird jedes RRSet in der Zone einen zugehörigen SIG-Eintrag haben. Der Datentyp des RRSet ist in den Daten des SIG RR enthalten, um anzuzeigen, mit welchem bestimmten RRSet dieser SIG-Eintrag verbunden ist. Würden die obigen Regeln angewendet, müssten immer dann, wenn ein SIG-Eintrag mit einer Antwort zur Validierung dieser Antwort enthalten ist, auch die SIG-Einträge für alle anderen RRSets, die mit dem entsprechenden Knoten verbunden sind, enthalten sein. In einigen Fällen könnte dies eine sehr große Anzahl von Einträgen sein, was nicht dadurch geholfen wird, dass sie recht große RRs sind.
Daher ist es ausdrücklich erlaubt, dass der Autoritätsabschnitt nur diejenigen SIG RRs enthält, deren Feld „abgedeckter Typ" (type covered) gleich dem Typfeld einer zurückgegebenen Antwort ist. Wenn jedoch SIG-Einträge im Antwortabschnitt zurückgegeben werden, als Antwort auf eine Abfrage nach SIG-Einträgen oder eine Abfrage nach allen mit einem Namen verbundenen Einträgen (type=ANY), muss das gesamte SIG RRSet enthalten sein, wie bei jedem anderen RR-Typ.
Server, die Antworten mit SIG-Einträgen im Autoritätsabschnitt oder (wahrscheinlich fälschlicherweise) als zusätzliche Daten empfangen, müssen verstehen, dass das gesamte RRSet mit ziemlicher Sicherheit nicht enthalten wurde. Daher dürfen sie diesen SIG-Eintrag nicht auf eine Weise zwischenspeichern, die es erlauben würde, dass er zurückgegeben wird, wenn eine Abfrage nach SIG-Einträgen an diesem Server empfangen wird. RFC2065 verlangt tatsächlich, dass SIG-Abfragen nur an autoritative Server gerichtet werden, um die Probleme zu vermeiden, die hier verursacht werden könnten, und solange Server existieren, die die besonderen Eigenschaften von SIG-Einträgen nicht verstehen, wird dies notwendig bleiben. Eine sorgfältige Gestaltung der SIG-Eintragsverarbeitung in neuen Implementierungen sollte jedoch erlauben, diese Einschränkung in Zukunft zu lockern, sodass Resolver SIG-Eintragsabfragen nicht speziell behandeln müssen.
5.3.2. NXT RRs (NXT-Ressourceneinträge)
Next Resource Records (NXT) sind noch spezieller. Es wird in einer Zone für ein bestimmtes Label immer nur einen NXT-Eintrag geben, daher ist das RRSet-Problem oberflächlich betrachtet trivial. An einem Zonenschnitt haben jedoch sowohl die Elternzone als auch die Kindzone (Superzone und Subzone in RFC2065-Terminologie) NXT-Einträge für denselben Namen. Diese beiden NXT-Einträge bilden kein RRSet, selbst wenn beide Zonen auf demselben Server untergebracht sind. NXT RRSets enthalten immer nur einen einzelnen RR. Wo beide NXT-Einträge sichtbar sind, existieren zwei RRSets. Server sind jedoch nicht verpflichtet, dies beim Empfang von NXT-Einträgen in einer Antwort als Sonderfall zu behandeln. Sie können wählen, die Existenz von zwei verschiedenen NXT RRSets zu bemerken und sie so zu behandeln, wie sie zwei verschiedene RRSets eines anderen Typs behandeln würden. Das heißt, eines zwischenspeichern und das andere ignorieren. Sicherheitsbewusste Server müssen den NXT-Eintrag in der empfangenen Antwort korrekt verarbeiten.
5.4. Receiving RRSets (Empfangen von RRSets)
Server dürfen niemals RRs aus einer Antwort mit RRs in ihrem Cache zusammenführen, um ein RRSet zu bilden. Wenn eine Antwort Daten enthält, die ein RRSet mit Daten im Cache eines Servers bilden würden, muss der Server entweder die RRs in der Antwort ignorieren oder das gesamte RRSet, das sich derzeit im Cache befindet, verwerfen, je nachdem, was angemessen ist. Folglich verursacht das Problem variierender TTLs zwischen Cache und Antwort keine Bedenken, eines wird ignoriert. Das heißt, einer der Datensätze ist immer inkorrekt, wenn die Daten aus einer Antwort von den Daten im Cache abweichen. Die Herausforderung für den Server besteht darin, zu bestimmen, welcher der Datensätze korrekt ist, falls überhaupt, und diesen beizubehalten, während der andere ignoriert wird. Beachten Sie, dass wenn ein Server eine Antwort erhält, die ein RRSet enthält, das mit dem in seinem Cache identisch ist, mit der möglichen Ausnahme des TTL-Werts, er optional die TTL in seinem Cache mit der TTL der empfangenen Antwort aktualisieren kann. Er sollte dies tun, wenn die empfangene Antwort als autoritativer angesehen würde (wie im nächsten Abschnitt besprochen) als die zuvor zwischengespeicherte Antwort.
5.4.1. Ranking data (Rangfolge der Daten)
Bei der Überlegung, ob ein RRSet in einer Antwort akzeptiert oder ein bereits im Cache befindliches RRSet beibehalten werden soll, sollte ein Server die relative wahrscheinliche Vertrauenswürdigkeit der verschiedenen Daten berücksichtigen. Eine autoritative Antwort aus einer Antwort sollte zwischengespeicherte Daten ersetzen, die aus zusätzlichen Informationen in einer früheren Antwort stammen. Zusätzliche Informationen aus einer Antwort werden jedoch ignoriert, wenn der Cache Daten aus einer autoritativen Antwort oder einer Zonendatei enthält.
Die Genauigkeit der verfügbaren Daten wird von ihrer Quelle angenommen. Die Vertrauenswürdigkeit sollte in der Reihenfolge von der höchsten zur niedrigsten sein:
- Daten aus einer primären Zonendatei, außer Glue-Daten
- Daten aus einem Zonentransfer, außer Glue
- Die autoritativen Daten, die im Antwortabschnitt einer autoritativen Antwort enthalten sind
- Daten aus dem Autoritätsabschnitt einer autoritativen Antwort
- Glue aus einer primären Zone oder Glue aus einem Zonentransfer
- Daten aus dem Antwortabschnitt einer nicht autoritativen Antwort und nicht autoritative Daten aus dem Antwortabschnitt autoritativer Antworten
- Zusätzliche Informationen aus einer autoritativen Antwort
- Daten aus dem Autoritätsabschnitt einer nicht autoritativen Antwort
- Zusätzliche Informationen aus nicht autoritativen Antworten
Beachten Sie, dass der Antwortabschnitt einer autoritativen Antwort normalerweise nur autoritative Daten enthält. Wenn der gesuchte Name jedoch ein Alias ist (siehe Abschnitt 10.1.1), ist nur der Eintrag, der diesen Alias beschreibt, notwendigerweise autoritativ. Clients sollten davon ausgehen, dass andere Einträge möglicherweise aus dem Cache des Servers stammen. Wenn autoritative Antworten erforderlich sind, sollte der Client erneut abfragen, unter Verwendung des mit dem Alias verbundenen kanonischen Namens.
Nicht authentifizierte RRs, die aus der am wenigsten vertrauenswürdigen dieser Gruppierungen empfangen und zwischengespeichert werden, das heißt Daten aus dem Abschnitt für zusätzliche Daten und Daten aus dem Autoritätsabschnitt einer nicht autoritativen Antwort, sollten nicht auf eine Weise zwischengespeichert werden, die es erlauben würde, dass sie als Antworten auf eine empfangene Abfrage zurückgegeben werden. Sie können als zusätzliche Informationen zurückgegeben werden, wo dies angemessen ist. Dies zu ignorieren würde erlauben, dass die Vertrauenswürdigkeit relativ unzuverlässiger Daten ohne Grund oder Entschuldigung erhöht wird.
Wenn DNS-Sicherheit [RFC2065] verwendet wird und eine authentifizierte Antwort empfangen und verifiziert wurde, sollen die so authentifizierten Daten als vertrauenswürdiger angesehen werden als nicht authentifizierte Daten desselben Typs. Beachten Sie, dass in diesem gesamten Dokument „autoritativ" (authoritative) eine Antwort mit gesetztem AA-Bit bedeutet. DNSSEC verwendet vertrauenswürdige Ketten von SIG- und KEY-Einträgen, um die Authentizität von Daten zu bestimmen, das AA-Bit ist fast irrelevant. DNSSEC-bewusste Server müssen jedoch das AA-Bit in Antworten weiterhin korrekt setzen, um den korrekten Betrieb mit Servern zu ermöglichen, die nicht sicherheitsbewusst sind (derzeit fast alle).
Beachten Sie, dass außer Glue-Daten, es unmöglich ist, dass Daten aus zwei korrekt konfigurierten primären Zonendateien, zwei korrekt konfigurierten sekundären Zonen (Daten aus Zonentransfers) oder Daten aus korrekt konfigurierten primären und sekundären Zonen jemals in Konflikt geraten. Wo Glue für denselben Namen in mehreren Zonen existiert und sich im Wert unterscheidet, sollte der Nameserver Daten aus einer primären Zonendatei bevorzugt vor sekundären wählen, kann aber andernfalls jeden einzelnen Satz solcher Daten wählen. Die Wahl dessen, was von einer Quelle näher an der autoritativen Datenquelle zu stammen scheint, könnte sinnvoll sein, wo dies bestimmt werden kann. Die Wahl primärer Daten über sekundäre ermöglicht es, die Quelle falscher Glue-Daten leichter zu entdecken, wenn ein Problem mit solchen Daten besteht. Wenn ein Server aus zwei Zonendateien erkennen kann, dass eine oder mehrere falsch konfiguriert sind, um Konflikte zu erzeugen, sollte er das Laden der als fehlerhaft bestimmten Zonen verweigern und geeignete Diagnosen ausgeben.
„Glue" oben umfasst jeden Eintrag in einer Zonendatei, der nicht ordnungsgemäß Teil dieser Zone ist, einschließlich Nameserver-Einträgen delegierter Subzonen (NS-Einträge), Adresseinträgen, die diese NS-Einträge begleiten (A, AAAA usw.), und allen anderen verstreuten Daten, die möglicherweise erscheinen.
5.5. Sending RRSets (reprise) (Senden von RRSets (Wiederholung))
Ein Ressourcen-Datensatzsatz sollte in jeder DNS-Antwort nur einmal enthalten sein. Er kann in einem der Abschnitte Antwort, Autorität oder Zusätzliche Informationen erscheinen, wie erforderlich. Er sollte jedoch nicht im selben oder einem anderen Abschnitt wiederholt werden, außer wenn dies durch eine Spezifikation ausdrücklich erforderlich ist. Zum Beispiel erfordert eine AXFR-Antwort, dass der SOA-Eintrag (immer ein RRSet, das einen einzelnen RR enthält) sowohl der erste als auch der letzte Eintrag der Antwort ist. Wo Duplikate auf diese Weise erforderlich sind, muss die in jedem Fall übertragene TTL dieselbe sein.