6.1.3. OPT Record TTL Field Use (OPT-Datensatz-TTL-Feldverwendung)
6.1.3. OPT Record TTL Field Use (OPT-Datensatz-TTL-Feldverwendung)
Der erweiterte RCODE und die Flags, die OPT im RR-Time-to-Live (TTL)-Feld speichert, sind wie folgt strukturiert:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | EXTENDED-RCODE | VERSION |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | DO| Z |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
EXTENDED-RCODE : Bildet die oberen 8 Bits des erweiterten 12-Bit-RCODE (zusammen mit den 4 in [RFC1035] definierten Bits). Beachten Sie, dass der EXTENDED-RCODE-Wert 0 anzeigt, dass ein nicht erweiterter RCODE verwendet wird (Werte 0 bis 15).
VERSION : Zeigt die Implementierungsstufe des Setters an. Vollständige Konformität mit dieser Spezifikation wird durch Version '0' angezeigt. Anfrager werden ermutigt, dies auf die niedrigste implementierte Stufe zu setzen, die eine Transaktion ausdrücken kann, um die Antworter- und Netzwerklast beim Erkennen der größten gemeinsamen Implementierungsstufe zwischen Anfrager und Antworter zu minimieren. Die Versionsnummerierungsstrategie eines Anfragers KANN idealerweise eine Laufzeitkonfigurationsoption sein. Wenn ein Antworter die VERSION-Stufe der Anfrage nicht implementiert, MUSS er mit RCODE=BADVERS antworten. Alle Antworten MÜSSEN im Format auf die VERSION-Stufe der Anfrage beschränkt sein, aber die VERSION jeder Antwort SOLLTE die höchste Implementierungsstufe des Antworters sein. Auf diese Weise lernt ein Anfrager die Implementierungsstufe eines Antworters als Nebeneffekt jeder Antwort, einschließlich Fehlerantworten und einschließlich RCODE=BADVERS.
DO : DNSSEC OK-Bit wie in [RFC3225] definiert.
Z : Von Sendern auf Null gesetzt und von Empfängern ignoriert, es sei denn, es wird in einer nachfolgenden Spezifikation geändert.