Zum Hauptinhalt springen

5. Ressourcen-Datensätze-Mengen

Jeder DNS-Ressourcen-Datensatz (RR) hat ein Label, eine Klasse, einen Typ und Daten. Es ist bedeutungslos, dass zwei Datensätze jemals Label, Klasse, Typ und Daten alle gleich haben - Server sollten solche Duplikate unterdrücken, wenn sie ihnen begegnen. Bei den meisten Datensatztypen ist es jedoch möglich, dass sie mit demselben Label, derselben Klasse und demselben Typ, aber mit unterschiedlichen Daten existieren. Eine solche Gruppe von Datensätzen wird hiermit als Ressourcen-Datensätze-Menge (Resource Record Set, RRSet) definiert.

5.1. Senden von RRs aus einer Ressourcen-Datensätze-Menge​

Eine Anfrage nach einem bestimmten (oder nicht bestimmten) Label, einer Klasse und einem Typ liefert stets alle Datensätze in der zugehörigen Ressourcen-Datensätze-Menge zurück - sei es ein einzelner oder mehrere RRs. Die Antwort muss als "abgeschnitten (truncated)" markiert werden, wenn die gesamte Ressourcen-Datensätze-Menge nicht in die Antwort passt.

5.2. TTLs von RRs in einer Ressourcen-Datensätze-Menge​

Ressourcen-Datensätze haben außerdem eine Lebensdauer (time to live, TTL). Es ist möglich, dass die RRs in einer Ressourcen-Datensätze-Menge unterschiedliche TTLs haben. Es wurden keine Verwendungen dafür gefunden, die nicht auf andere Weise besser erreicht werden könnten. Dies kann jedoch teilweise Antworten (nicht als "abgeschnitten" markiert) von einem Cache-Server verursachen, bei denen die TTLs für einige, aber nicht alle RRs in der Ressourcen-Datensätze-Menge abgelaufen sind.

Folglich wird die Verwendung unterschiedlicher TTLs in einer Ressourcen-Datensätze-Menge hiermit als veraltet eingestuft; die TTLs aller RRs in einer Ressourcen-Datensätze-Menge müssen gleich sein.

Empfängt ein Client eine Antwort, die RRs aus einer Ressourcen-Datensätze-Menge mit unterschiedlichen TTLs enthält, sollte er dies als Fehler behandeln. Wenn die betreffende Ressourcen-Datensätze-Menge für diese Daten aus einer nicht autoritativen Quelle stammt, sollte der Client die Ressourcen-Datensätze-Menge einfach ignorieren und, falls die Werte benötigt wurden, versuchen, sie von einer autoritativen Quelle zu beziehen. 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. Sendet eine autoritative Quelle eine derart fehlerhafte Ressourcen-Datensätze-Menge, sollte der Client die RRs für alle Zwecke so behandeln, als wären alle TTLs in der Ressourcen-Datensätze-Menge auf den Wert der niedrigsten TTL in der Ressourcen-Datensätze-Menge gesetzt worden. In keinem Fall darf ein Server eine Ressourcen-Datensätze-Menge mit nicht durchweg gleichen TTLs senden.

5.3. DNSSEC-Sonderfälle​

Zwei der durch DNS Security (DNSSEC) [RFC2065] hinzugefügten Datensatztypen erfordern besondere Aufmerksamkeit, wenn die Bildung von Ressourcen-Datensätze-Mengen betrachtet wird. Dies sind die SIG- und NXT-Einträge. Es sollte beachtet werden, dass DNS Security noch sehr neu ist und es bisher wenig Erfahrung damit gibt. Leser sollten darauf vorbereitet sein, dass die in diesem Dokument enthaltenen Informationen zu DNSSEC veralten, wenn die DNS-Security-Spezifikation reift.

5.3.1. SIG-Einträge und RRSets​

Ein SIG-Eintrag liefert Signatur- (Validierungs-) Daten für eine andere Ressourcen-Datensätze-Menge im DNS. Wo eine Zone signiert wurde, hat jede Ressourcen-Datensätze-Menge in der Zone einen zugehörigen SIG-Eintrag. Der Datentyp der Ressourcen-Datensätze-Menge ist in den Daten des SIG-RR enthalten, um anzugeben, welcher bestimmten Ressourcen-Datensätze-Menge dieser SIG-Eintrag zugeordnet ist. Würden die oben genannten Regeln angewendet, müssten, wann immer ein SIG-Eintrag zur Validierung einer Antwort in diese aufgenommen würde, auch die SIG-Einträge für alle anderen dem betreffenden Knoten zugeordneten Ressourcen-Datensätze-Mengen aufgenommen werden. In einigen Fällen könnte dies eine sehr große Anzahl von Datensätzen sein, was dadurch nicht besser wird, dass es sich um recht große RRs handelt.

Daher ist es ausdrücklich zulässig, dass der Authority-Abschnitt nur diejenigen SIG-RRs enthält, deren Feld "type covered" gleich dem Typfeld einer zurückgegebenen Antwort ist. Werden SIG-Einträge jedoch im Answer-Abschnitt zurückgegeben, als Antwort auf eine Anfrage nach SIG-Einträgen oder auf eine Anfrage nach allen einem Namen zugeordneten Datensätzen (type=ANY), muss die gesamte SIG-Ressourcen-Datensätze-Menge aufgenommen werden, wie bei jedem anderen RR-Typ.

Server, die Antworten empfangen, die SIG-Einträge im Authority-Abschnitt oder (wahrscheinlich fälschlich) als Zusatzdaten enthalten, müssen verstehen, dass die gesamte Ressourcen-Datensätze-Menge mit an Sicherheit grenzender Wahrscheinlichkeit nicht aufgenommen wurde. Daher dürfen sie diesen SIG-Eintrag nicht so cachen, dass er zurückgegeben werden könnte, falls bei diesem Server eine Anfrage nach SIG-Einträgen eingeht. RFC2065 verlangt tatsächlich, dass SIG-Anfragen nur an autoritative Server gerichtet werden, um die hier möglichen Probleme zu vermeiden, und solange es Server gibt, die die besonderen Eigenschaften von SIG-Einträgen nicht verstehen, wird dies notwendig bleiben. Jedoch sollte ein sorgfältiges Design der SIG-Eintragsverarbeitung in neuen Implementierungen es künftig erlauben, diese Einschränkung zu lockern, sodass Resolver Anfragen nach SIG-Einträgen nicht gesondert behandeln müssen.

Gelegentlich wurde gesagt, dass eine empfangene Anfrage nach einem SIG-Eintrag an einen autoritativen Server weitergeleitet werden sollte, statt aus Daten im Cache beantwortet zu werden. Dies ist nicht notwendig - ein Server, der SIG als Sonderfall für eine solche Verarbeitung kennt, sollte SIG-Einträge besser korrekt cachen und dabei ihre Eigenschaften berücksichtigen. Dann kann der Server feststellen, wann es sicher ist, aus dem Cache zu antworten und wann die Antwort nicht verfügbar ist und die Anfrage weitergeleitet werden muss.

5.3.2. NXT-RRs​

Next Resource Records (NXT) sind noch eigenartiger. In einer Zone wird es für ein bestimmtes Label immer nur einen NXT-Eintrag geben, sodass das RRSet-Problem oberflächlich betrachtet trivial ist. An einem Zonenschnitt (zone cut) jedoch werden sowohl die Elternzone als auch die Kindzone (Superzone und Subzone in der Terminologie von RFC2065) NXT-Einträge für denselben Namen haben. Diese beiden NXT-Einträge bilden keine Ressourcen-Datensätze-Menge, selbst wenn beide Zonen auf demselben Server beherbergt sind. NXT-Ressourcen-Datensätze-Mengen enthalten stets nur einen einzigen RR. Wo beide NXT-Einträge sichtbar sind, existieren zwei Ressourcen-Datensätze-Mengen. Server sind jedoch nicht verpflichtet, dies beim Empfang von NXT-Einträgen in einer Antwort als Sonderfall zu behandeln. Sie können beschließen, die Existenz zweier unterschiedlicher NXT-Ressourcen-Datensätze-Mengen zur Kenntnis zu nehmen und dies so zu behandeln wie zwei unterschiedliche Ressourcen-Datensätze-Mengen jedes anderen Typs. Das heißt, die eine cachen und die andere ignorieren. Sicherheitsbewusste Server müssen jedoch den NXT-Eintrag in der empfangenen Antwort korrekt verarbeiten.

5.4. Empfangen von Ressourcen-Datensätze-Mengen​

Server dürfen niemals RRs aus einer Antwort mit RRs in ihrem Cache zusammenführen, um eine Ressourcen-Datensätze-Menge zu bilden. Wenn eine Antwort Daten enthält, die mit Daten im Cache eines Servers eine Ressourcen-Datensätze-Menge bilden würden, muss der Server entweder die RRs in der Antwort ignorieren oder die derzeit im Cache befindliche gesamte Ressourcen-Datensätze-Menge verwerfen, je nachdem, was angemessen ist. Folglich gibt die Frage unterschiedlicher TTLs zwischen dem Cache und einer Antwort keinen Anlass zur Sorge, eine davon wird ignoriert. Das heißt, einer der Datensätze ist stets falsch, wenn die Daten aus einer Antwort von den Daten im Cache abweichen. Die Herausforderung für den Server besteht darin, festzustellen, welcher der Datensätze korrekt ist, sofern einer korrekt ist, und diesen beizubehalten, während der andere ignoriert wird. Beachten Sie, dass ein Server, der eine Antwort empfängt, die eine Ressourcen-Datensätze-Menge enthält, die mit der in seinem Cache identisch ist - mit der möglichen Ausnahme des TTL-Werts -, 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 erörtert) als die zuvor zwischengespeicherte Antwort.

5.4.1. Einstufung der Daten​

Wenn ein Server erwägt, ob er eine Ressourcen-Datensätze-Menge in einer Antwort akzeptieren oder stattdessen eine bereits in seinem Cache befindliche Ressourcen-Datensätze-Menge beibehalten soll, sollte er die relative wahrscheinliche Vertrauenswürdigkeit (trustworthiness) der verschiedenen Daten berücksichtigen. Eine autoritative Antwort aus einer Antwort sollte zwischengespeicherte Daten ersetzen, die aus Zusatzinformationen in einer früheren Antwort gewonnen wurden. Zusatzinformationen 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 aus ihrer Quelle angenommen. Die Vertrauenswürdigkeit ist, in der Reihenfolge von der höchsten zur niedrigsten:

  • Daten aus einer primären Zonendatei, mit Ausnahme von Glue-Daten,
  • Daten aus einem Zonentransfer, mit Ausnahme von Glue,
  • Die autoritativen Daten, die im Answer-Abschnitt einer autoritativen Antwort enthalten sind.
  • Daten aus dem Authority-Abschnitt einer autoritativen Antwort,
  • Glue aus einer primären Zone oder Glue aus einem Zonentransfer,
  • Daten aus dem Answer-Abschnitt einer nicht autoritativen Antwort und nicht autoritative Daten aus dem Answer-Abschnitt autoritativer Antworten,
  • Zusatzinformationen aus einer autoritativen Antwort, Daten aus dem Authority-Abschnitt einer nicht autoritativen Antwort, Zusatzinformationen aus nicht autoritativen Antworten.

Beachten Sie, dass der Answer-Abschnitt 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 Datensatz, der diesen Alias beschreibt, notwendigerweise autoritativ. Clients sollten annehmen, dass andere Datensätze aus dem Cache des Servers stammen könnten. Wo autoritative Antworten erforderlich sind, sollte der Client erneut abfragen und dabei den dem Alias zugeordneten kanonischen Namen verwenden.

Nicht authentifizierte RRs, die aus der am wenigsten vertrauenswürdigen dieser Gruppierungen empfangen und zwischengespeichert werden, das heißt Daten aus dem Zusatzdaten-Abschnitt und Daten aus dem Authority-Abschnitt einer nicht autoritativen Antwort, sollten nicht in einer Weise zwischengespeichert werden, dass sie jemals als Antworten auf eine empfangene Anfrage zurückgegeben würden. Sie können gegebenenfalls als Zusatzinformationen zurückgegeben werden. Dies zu ignorieren würde es ermöglichen, die Vertrauenswürdigkeit relativ nicht vertrauenswürdiger Daten ohne Grund oder Entschuldigung zu erhöhen.

Wenn DNS Security [RFC2065] verwendet wird und eine authentifizierte Antwort empfangen und verifiziert wurde, sind die so authentifizierten Daten als vertrauenswürdiger anzusehen als nicht authentifizierte Daten desselben Typs. Beachten Sie, dass in diesem Dokument "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 nahezu irrelevant. DNSSEC-fähige Server müssen jedoch weiterhin das AA-Bit in Antworten korrekt setzen, um den korrekten Betrieb mit Servern zu ermöglichen, die nicht sicherheitsbewusst sind (derzeit fast alle).

Beachten Sie, dass - Glue ausgenommen - 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 niemals in Konflikt geraten können. Wo Glue für denselben Namen in mehreren Zonen existiert und im Wert abweicht, sollte der Nameserver Daten aus einer primären Zonendatei gegenüber sekundären bevorzugen, darf aber ansonsten einen beliebigen einzelnen Satz solcher Daten wählen. Die Wahl derjenigen, die aus einer Quelle zu stammen scheint, die näher an der autoritativen Datenquelle liegt, kann sinnvoll sein, wo dies festgestellt werden kann. Die Bevorzugung primärer Daten gegenüber sekundären ermöglicht es, die Quelle fehlerhafter Glue-Daten leichter zu entdecken, wenn ein Problem mit solchen Daten besteht. Wo ein Server aus zwei Zonendateien erkennen kann, dass eine oder mehrere falsch konfiguriert sind, sodass Konflikte entstehen, sollte er sich weigern, die als fehlerhaft bestimmten Zonen zu laden, und geeignete Diagnosen ausgeben.

"Glue" oben umfasst jeden Datensatz in einer Zonendatei, der nicht ordnungsgemäß Teil dieser Zone ist, einschließlich Nameserver-Einträgen delegierter Unterzonen (NS-Einträge), Adresseinträgen, die diese NS-Einträge begleiten (A, AAAA usw.), und jeglicher anderer Streudaten, die auftreten mögen.

5.5. Senden von Ressourcen-Datensätze-Mengen (Wiederaufnahme)​

Eine Ressourcen-Datensätze-Menge sollte in einer DNS-Antwort nur einmal enthalten sein. Sie kann je nach Bedarf in einem der Abschnitte Answer, Authority oder Additional Information auftreten. Sie sollte jedoch nicht im selben oder in einem anderen Abschnitt wiederholt werden, außer wo dies durch eine Spezifikation ausdrücklich verlangt wird. Beispielsweise verlangt eine AXFR-Antwort, dass der SOA-Eintrag (stets eine Ressourcen-Datensätze-Menge, die einen einzigen RR enthält) sowohl der erste als auch der letzte Datensatz der Antwort ist. Wo Duplikate auf diese Weise erforderlich sind, muss die jeweils übertragene TTL dieselbe sein.