6.1.3. OPT Record TTL Field Use (OPT レコード TTL フィールドの使用)
6.1.3. OPT Record TTL Field Use (OPT レコード TTL フィールドの使用)
OPT が RR 生存時間 (TTL) フィールドに格納する拡張 RCODE とフラグは, 次のように構造化されています:
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | EXTENDED-RCODE | VERSION |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | DO| Z |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
EXTENDED-RCODE : 拡張 12 ビット RCODE の上位 8 ビットを形成します ([RFC1035] で定義された 4 ビットとともに)。EXTENDED-RCODE 値 0 は, 非拡張 RCODE が使用されていることを示します (値 0 から 15)。
VERSION : 設定者の実装レベルを示します。この仕様への完全な準拠はバージョン '0' で示されます。リクエスタは, トランザクションを表現できる最低の実装レベルに設定することが推奨されます。これにより, リクエスタとレスポンダ間の最大共通実装レベルを発見するレスポンダとネットワーク負荷が最小限に抑えられます。リクエスタのバージョン番号戦略は, 理想的には実行時構成オプションであってもかまいません。 レスポンダがリクエストの VERSION レベルを実装していない場合, RCODE=BADVERS で応答しなければなりません。すべての応答は, リクエストの VERSION レベルに形式が制限されなければなりませんが, 各応答の VERSION はレスポンダの最高実装レベルであるべきです。このようにして, リクエスタは, エラー応答や RCODE=BADVERS を含むすべての応答の副作用として, レスポンダの実装レベルを学習します。
DO : [RFC3225] で定義されている DNSSEC OK ビット。
Z : 送信者によってゼロに設定され, 後続の仕様で変更されない限り受信者によって無視されます。