Zum Hauptinhalt springen

6. Kanonische Form und Reihenfolge der Ressourceneinträge

Dieses Dokument definiert die kanonische Form (canonical form) und die kanonische Reihenfolge (canonical order) der Ressourceneinträge, die zum Signieren und Verifizieren von Ressourceneintragssätzen (RRset) verwendet werden. Die Verwendung einer kanonischen Form stellt sicher, dass die Signatur gültig bleibt, selbst wenn sich die Präsentationsform (presentation) der Zone ändert (z. B. wenn bei einem Zonentransfer zwischen Nameservern Domänennamen komprimiert oder die Groß-/Kleinschreibung geändert wird).

6.1. Kanonische Form​

Beim Signieren oder Verifizieren eines Ressourceneintrags MÜSSEN die den Signaturaufbau (signature input) bildenden Ressourceneinträge in kanonischer Form dargestellt werden. Die kanonische Form eines Ressourceneintrags lautet wie folgt:

  • der Eigentümername (OWNER NAME) MUSS als kanonischer Domänenname dargestellt werden (siehe Abschnitt 6.2);
  • jeder Teil des RDATA, der die Form eines Domänennamens hat, MUSS als kanonischer Domänenname dargestellt werden (siehe Abschnitt 6.2);
  • wenn der Ressourceneintragstyp RDATA-Felder definiert, die die Form eines Domänennamens haben (z. B. NS-, MX-, CNAME-, SOA-, PTR-Einträge usw.), MÜSSEN diese Domänennamen ebenfalls in kanonischer Form (unkomprimiert, Kleinbuchstaben) dargestellt werden;
  • alle Domänennamen MÜSSEN unkomprimiert sein;
  • jeder Teil eines Domänennamens, der als Zeichenkette () erscheint, MUSS in kanonischer Form dargestellt und DARF NICHT komprimiert werden;
  • für in diesem Dokument definierte DNSSEC-Typen (DNSKEY, RRSIG, DS, NSEC) MUSS das RDATA Feld für Feld in Binärform geschrieben werden, gemäß dem in den Abschnitten 2, 3, 4 und 5 vorgeschriebenen Format und der dort festgelegten Reihenfolge.

Die detaillierten Regeln lauten:

  1. für den DNSKEY-Ressourceneintrag: Die kanonische Form des RDATA ist die Verkettung, in Reihenfolge, von Flags (16 Bit), Protocol (8 Bit), Algorithm (8 Bit) und Public Key (Bytezeichenfolge in Leitungsformat);
  2. für den RRSIG-Ressourceneintrag: Die kanonische Form des RDATA ist die Verkettung, in Reihenfolge, von Type Covered, Algorithm, Labels, Original TTL, Signature Expiration, Signature Inception, Key Tag, Signer's Name (kanonischer Domänenname) und Signature;
  3. für den DS-Ressourceneintrag: Die kanonische Form des RDATA ist die Verkettung, in Reihenfolge, von Key Tag, Algorithm, Digest Type und Digest;
  4. für den NSEC-Ressourceneintrag: Die kanonische Form des RDATA ist die Verkettung, in Reihenfolge, von Next Domain Name (kanonische Form) und Type Bit Maps (gemäß Abschnitt 5.1 codiert).

6.2. Kanonische Form eines Domänennamens​

Die kanonische Form (canonical form) eines Domänennamens ist wie folgt definiert:

  • US-ASCII-Zeichen im Domänennamen MÜSSEN in Kleinbuchstaben dargestellt werden (d. h., wenn man sich für die Groß-/Kleinschreibung-unabhängige Variante entscheidet, sind Kleinbuchstaben zu verwenden). Beispielsweise MÜSSEN die Zeichen „A" bis „Z" auf „a" bis „z" abgebildet werden;
  • der Domänenname MUSS unkomprimiert sein (d. h. er darf keine Label-Komprimierungszeiger verwenden);
  • der Domänenname MUSS als vollständige, unkomprimierte Leitungsform (wire format) dargestellt werden, die mit einem leeren Label (Label der Länge Null) endet.

6.3. Kanonische Reihenfolge​

Die kanonische Ressourceneintragreihenfolge (canonical RR order) dient der Bestimmung der relativen Reihenfolge der Ressourceneinträge innerhalb eines RRset sowie der Reihenfolge der Namen und Typen in einer Zone (z. B. von den NSEC-Einträgen verwendet). Die kanonische Reihenfolge ist wie folgt definiert:

  1. Zuerst sortieren nach dem Eigentümernamen in kanonischer Form, ohne Berücksichtigung der Groß-/Kleinschreibung, unter Verwendung der kanonischen Domänennamenreihenfolge (siehe unten). Lässt sich anhand des Eigentümernamens nicht unterscheiden (d. h. die Namen sind gleich), weiter zum nächsten Schritt.

  2. Dann sortieren nach der Klasse (CLASS) des Ressourceneintrags in numerisch aufsteigender Reihenfolge (bei DNSSEC ist die Klasse in der Regel IN). Sind die Klassen gleich, weiter zum nächsten Schritt.

  3. Dann sortieren nach dem Typ (TYPE) des Ressourceneintrags in numerisch aufsteigender Reihenfolge.

  4. Dann, für Einträge innerhalb eines RRset mit demselben Eigentümernamen, derselben Klasse und demselben Typ, sortieren nach der kanonischen RDATA-Reihenfolge (canonical RDATA order) aufsteigend:

    • für Typen, deren RDATA Domänennamen enthält, werden die Domänennamen in kanonischer Form verglichen (ohne Berücksichtigung der Groß-/Kleinschreibung);
    • für SOA-Einträge werden die Felder in der Reihenfolge MNAME, RNAME, SERIAL, REFRESH, RETRY, EXPIRE, MINIMUM verglichen, wobei jedes Feld in seiner kanonischen Form verglichen wird;
    • für Typen mit mehreren Domänennamen (z. B. ein MX-Eintrag, bei dem auf eine Priorität der Zieldomänenname folgt), werden zuerst die Nicht-Domänenname-Felder verglichen, dann die Domänennamen in kanonischer Form;
    • für in diesem Dokument definierte DNSSEC-Typen wird byteweise gemäß der in Abschnitt 6.1 vorgeschriebenen binären RDATA-Reihenfolge verglichen.

Kanonische Domänennamenreihenfolge (canonical DNS name order): Zwei Domänennamen werden Label für Label verglichen, vom Ende (am weitesten rechts stehendes Label) zum Anfang, wobei jedes Label in der Reihenfolge der Bytes ohne Berücksichtigung der Groß-/Kleinschreibung verglichen wird. Beispielsweise steht der Name „a.example." vor „b.example.", und „example." steht vor „a.example.".

6.4. Behandlung von Signierung und Verifizierung​

Beim Signieren eines RRset MUSS der Signierer jeden Ressourceneintrag des RRset in der kanonischen Form und Reihenfolge der Abschnitte 6.1 bis 6.3 in den Signaturaufbau schreiben und dann den Signaturalgorithmus anwenden (siehe [RFC4035]). Der Validator MUSS den Signaturaufbau auf dieselbe Weise rekonstruieren und die Signatur verifizieren.

Abschnittsnavigation: