Zum Hauptinhalt springen

6. Kanonische Form und Reihenfolge von Ressourceneinträgen (Canonical Form and Order of Resource Records)

Dieser Abschnitt definiert eine kanonische Form für Ressourceneinträge, eine kanonische Reihenfolge von DNS-Namen und eine kanonische Reihenfolge von Ressourceneinträgen innerhalb eines RRset. Eine kanonische Namensreihenfolge ist erforderlich, um die NSEC-Namenskette zu konstruieren. Eine kanonische RR-Form und Reihenfolge innerhalb eines RRset sind erforderlich, um RRSIG RRs zu konstruieren und zu verifizieren.

6.1. Kanonische DNS-Namensreihenfolge (Canonical DNS Name Order)​

Für die Zwecke der DNS-Sicherheit werden Besitzernamen geordnet, indem einzelne Labels als vorzeichenlose linksbündige Oktett-Strings behandelt werden. Wenn Oktett-Strings verglichen werden, sortiert das Fehlen eines Oktetts vor einem Oktett mit Nullwert, und US-ASCII-Großbuchstaben werden behandelt, als wären sie US-ASCII-Kleinbuchstaben.

Um die kanonische Reihenfolge einer Menge von DNS-Namen zu berechnen, beginnen Sie damit, die Namen nach ihren bedeutendsten (am weitesten rechts stehenden) Labels zu sortieren. Für Namen, bei denen das bedeutendste Label identisch ist, fahren Sie mit der Sortierung nach ihrem nächstbedeutendsten Label fort und so weiter.

Zum Beispiel sind die folgenden Namen in kanonischer DNS-Namensreihenfolge sortiert. Das bedeutendste Label ist "example". Auf dieser Ebene wird "example" zuerst sortiert, gefolgt von Namen, die mit "a.example" enden, dann von Namen, die mit "z.example" enden. Die Namen innerhalb jeder Ebene werden auf die gleiche Weise sortiert.

          example
          a.example
          yljkjljk.a.example
          Z.a.example
          zABC.a.EXAMPLE
          z.example
          \001.z.example
          *.z.example
          \200.z.example

6.2. Kanonische RR-Form (Canonical RR Form)​

Für die Zwecke der DNS-Sicherheit ist die kanonische Form eines RR das Wire-Format des RR, wobei:

  1. jeder Domänenname im RR vollständig expandiert (keine DNS-Namenskompression) und vollständig qualifiziert ist;

  2. alle US-ASCII-Großbuchstaben im Besitzernamen des RR durch die entsprechenden US-ASCII-Kleinbuchstaben ersetzt werden;

  3. wenn der Typ des RR NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, DNAME, A6, RRSIG oder NSEC ist, alle US-ASCII-Großbuchstaben in den DNS-Namen, die im RDATA enthalten sind, durch die entsprechenden US-ASCII-Kleinbuchstaben ersetzt werden;

  4. wenn der Besitzername des RR ein Wildcard-Name ist, ist der Besitzername in seiner ursprünglichen nicht expandierten Form, einschließlich des "*"-Labels (keine Wildcard-Substitution); und

  5. die TTL des RR auf ihren ursprünglichen Wert gesetzt wird, wie er in der ursprünglichen autoritativen Zone oder dem Original TTL-Feld des abdeckenden RRSIG RR erscheint.

6.3. Kanonische RR-Reihenfolge innerhalb eines RRset (Canonical RR Ordering Within an RRset)​

Für die Zwecke der DNS-Sicherheit werden RRs mit demselben Besitzernamen, derselben Klasse und demselben Typ sortiert, indem der RDATA-Teil der kanonischen Form jedes RR als linksbündige vorzeichenlose Oktett-Sequenz behandelt wird, in der das Fehlen eines Oktetts vor einem Null-Oktett sortiert.

[RFC2181] spezifiziert, dass ein RRset keine doppelten Einträge enthalten darf (mehrere RRs mit demselben Besitzernamen, derselben Klasse, demselben Typ und denselben RDATA). Daher MUSS eine Implementierung, die doppelte RRs beim Umwandeln des RRset in kanonische Form erkennt, dies als Protokollfehler behandeln. Wenn die Implementierung wählt, diesen Protokollfehler im Sinne des Robustheitsprinzips zu behandeln (liberal zu sein in dem, was sie akzeptiert), MUSS sie alle bis auf einen der doppelten RRs zum Zweck der Berechnung der kanonischen Form des RRset entfernen.

Navigation verwandter Kapitel:

Letztes Update am