メインコンテンツまでスキップ

3. ドメイン名前空間とリソースレコード (DOMAIN NAME SPACE and RESOURCE RECORDS)

3.1. 名前空間の仕様と用語 (Name space specifications and terminology)​

ドメイン名前空間はツリー構造です。ツリー上の各ノードとリーフは、リソースセット（空の場合もあります）に対応します。ドメインシステムは、内部ノードとリーフの使用を区別せず、このメモでは「ノード (node)」という用語を両方を指すために使用します。

各ノードにはラベル (label) があり、その長さは0～63オクテットです。兄弟ノードは同じラベルを持つことはできませんが、兄弟でないノードには同じラベルを使用できます。1つのラベルが予約されており、それはルートに使用されるヌル（つまり、長さゼロ）ラベルです。

ノードのドメイン名は、ノードからツリーのルートへのパス上のラベルのリストです。慣例により、ドメイン名を構成するラベルは、最も具体的（最下位、ルートから最も遠い）から最も一般的（最上位、ルートに最も近い）へ、左から右に印刷または読み取られます。

内部表現 (Internal representation)​

内部的には、ドメイン名を操作するプログラムは、各ラベルが長さオクテットとそれに続くオクテット文字列であるラベルのシーケンスとして表現する必要があります。すべてのドメイン名はルートで終わり、ルートはラベルとしてヌル文字列を持っているため、これらの内部表現では長さバイトゼロを使用してドメイン名を終了できます。

大文字小文字の区別 (Case sensitivity)​

慣例により、ドメイン名は任意の大文字小文字で保存できますが、現在のすべてのドメイン機能のドメイン名比較は、ASCII文字セットと上位ゼロビットを仮定して、大文字小文字を区別しない方法で行われます。これは、ラベル "A" を持つノードまたはラベル "a" を持つノードを自由に作成できますが、兄弟として両方を作成することはできないことを意味します。"a" または "A" のいずれかを使用して参照できます。ドメイン名またはラベルを受け取ったときは、その大文字小文字を保持する必要があります。この選択の根拠は、いつか新しいサービスのために完全なバイナリドメイン名を追加する必要があるかもしれないということです。既存のサービスは変更されません。

絶対名と相対名 (Absolute and relative names)​

ユーザーがドメイン名を入力する必要がある場合、各ラベルの長さは省略され、ラベルはドット (".") で区切られます。完全なドメイン名はルートラベルで終わるため、これにより、ドットで終わる印刷形式になります。このプロパティを使用して、次のものを区別します:

  • 絶対名 (Absolute names): 完全なドメイン名を表す文字列（しばしば「絶対」と呼ばれます）。たとえば、"poneria.ISI.EDU."

  • 相対名 (Relative names): 不完全なドメイン名の開始ラベルを表し、ローカルドメインの知識を使用してローカルソフトウェアによって完成される必要がある文字列（しばしば「相対」と呼ばれます）。たとえば、ISI.EDUドメインで使用される "poneria"。

相対名は、既知の起点に対して、または検索リストとして使用されるドメインのリストに対して取得されます。相対名は主にユーザーインターフェイスに表示され、その解釈は実装によって異なります。マスターファイルでは、単一の起点ドメイン名に対して相対的です。最も一般的な解釈では、ルート "." を単一の起点として、または検索リストのメンバーの1つとして使用するため、複数ラベルの相対名は、入力を節約するために末尾のドットが省略されたものであることがよくあります。

長さの制限 (Length limitations)​

実装を簡素化するために、ドメイン名を表すオクテットの総数（つまり、すべてのラベルオクテットとラベル長の合計）は255に制限されています。

ドメインとサブドメインの関係 (Domain and subdomain relationships)​

ドメインはドメイン名によって識別され、ドメインを指定するドメイン名の位置またはそれより下のドメイン名前空間の部分で構成されます。ドメインが別のドメインに含まれている場合、そのドメインは別のドメインのサブドメインです。この関係は、サブドメインの名前が含まれるドメインの名前で終わるかどうかを確認することでテストできます。たとえば、A.B.C.DはB.C.D、C.D、D、および " " のサブドメインです。

3.2. 使用に関する管理ガイドライン (Administrative guidelines on use)​

ポリシーの問題として、DNSの技術仕様は特定のツリー構造やラベル選択のルールを義務付けていません。その目標は、任意のアプリケーションを構築するために使用できるように、できるだけ汎用的であることです。特に、システムは、名前空間がネットワーク境界、名前サーバーなどの線に沿って編成される必要がないように設計されました。この理由は、名前空間が暗黙のセマンティクスを持つべきではないということではなく、暗黙のセマンティクスの選択は手元の問題に使用するために開かれたままにすべきであり、ツリーの異なる部分が異なる暗黙のセマンティクスを持つことができるということです。たとえば、IN-ADDR.ARPAドメインは、その役割がネットワークまたはホスト番号から名前への変換であるため、ネットワークとホストアドレスによって編成および配布されます。NetBIOSドメイン [RFC-1001, RFC-1002] は、そのアプリケーションに適しているため、フラットです。

ただし、ホスト、メールボックスなどに使用される名前空間の「通常」の部分に適用されるガイドラインがいくつかあり、名前空間をより均一にし、成長を提供し、ソフトウェアが古いホストテーブルから変換されるときの問題を最小限に抑えます。ツリーの最上位レベルに関する政治的決定はRFC-920に由来しました。最上位レベルの現在のポリシーは [RFC-1032] で議論されています。MILNET変換の問題は [RFC-1031] でカバーされています。

最終的に複数のゾーンに分割される下位ドメインは、最終的な分解が名前変更なしで実行できるように、ドメインの上部で分岐を提供する必要があります。特殊文字、先頭の数字などを使用するノードラベルは、より制限的な選択に依存する古いソフトウェアを壊す可能性があります。

3.3. 使用に関する技術ガイドライン (Technical guidelines on use)​

DNSを使用して何らかのオブジェクトの命名情報を保持する前に、2つのニーズを満たす必要があります:

  • オブジェクト名とドメイン名の間のマッピングの規則。これは、オブジェクトに関する情報へのアクセス方法を記述します。

  • オブジェクトを記述するためのRRタイプとデータフォーマット。

これらのルールは非常に単純な場合もあれば、かなり複雑な場合もあります。多くの場合、設計者は既存のフォーマットを考慮し、既存の使用法との上位互換性を計画する必要があります。複数のマッピングまたはマッピングのレベルが必要になる場合があります。

ホスト名マッピング (Host name mapping)​

ホストの場合、マッピングは、ドメイン名の通常のテキスト表現のサブセットであるホスト名の既存の構文と、ホストアドレスなどを記述するためのRRフォーマットに依存します。アドレスからホスト名への信頼できる逆マッピングが必要なため、IN-ADDR.ARPAドメインへのアドレスの特別なマッピングも定義されています。

メールボックスマッピング (Mailbox mapping)​

メールボックスの場合、マッピングはわずかに複雑です。通常のメールアドレス <local-part>@<mail-domain> は、<local-part> を（含まれるドットに関係なく）単一のラベルに変換し、<mail-domain> をドメイン名の通常のテキストフォーマットを使用してドメイン名に変換し（ドットはラベルの区切りを示します）、2つを連結して単一のドメイン名を形成することにより、ドメイン名にマッピングされます。したがって、メールボックス[email protected]は、ドメイン名としてHOSTMASTER.SRI-NIC.ARPAで表されます。この設計の背後にある理由を理解するには、メール交換のスキーム [RFC-974] も考慮する必要があります。

典型的なユーザーはこれらのルールを定義することに関心がありませんが、それらは通常、古い使用法との上位互換性への欲求、異なるオブジェクト定義間の相互作用、およびルールを定義するときに新しい機能を追加する避けられない衝動の間の多数の妥協の結果であることを理解する必要があります。DNSを使用して何らかのオブジェクトをサポートする方法は、DNSに固有の制限よりもしばしばより重要です。

3.4. 名前空間の例 (Example name space)​

次の図は、現在のドメイン名前空間の一部を示しており、このRFCの多くの例で使用されています。ツリーは実際の名前空間の非常に小さなサブセットであることに注意してください。

                               |
                               |
         +---------------------+------------------+
         |                     |                  |
        MIL                   EDU                ARPA
         |                     |                  |
         |                     |                  |
   +-----+-----+               |     +------+-----+-----+
   |     |     |               |     |      |           |
  BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC
                               |
   +--------+------------------+---------------+--------+
   |        |                  |               |        |
  UCI      MIT                 |              UDEL     YALE
            |                 ISI
            |                  |
        +---+---+              |
        |       |              |
       LCS  ACHILLES  +--+-----+-----+--------+
        |             |  |     |     |        |
        XX            A  C   VAXA  VENERA Mockapetris

この例では、ルートドメインには3つの直接のサブドメインがあります: MIL、EDU、およびARPA。LCS.MIT.EDUドメインには、XX.LCS.MIT.EDUという名前の1つの直接のサブドメインがあります。すべてのリーフもドメインです。

3.5. 推奨される名前構文 (Preferred name syntax)​

DNS仕様は、ドメイン名を構築するためのルールをできるだけ汎用的にしようとしています。アイデアは、既存のオブジェクトの名前を最小限の変更でドメイン名として表現できるようにすることです。ただし、オブジェクトのドメイン名を割り当てるときは、慎重なユーザーは、ドメインシステムのルールと、これらのルールが公開されているか既存のプログラムによって暗示されているかにかかわらず、オブジェクトの既存のルールの両方を満たす名前を選択します。

たとえば、メールドメインに名前を付けるときは、ユーザーはこのメモのルールとRFC-822のルールの両方を満たす必要があります。新しいホスト名を作成するときは、HOSTS.TXTの古いルールに従う必要があります。これにより、古いソフトウェアがドメイン名を使用するように変換されるときの問題が回避されます。

次の構文は、ドメイン名を使用する多くのアプリケーション（メール、TELNETなど）で問題を少なくします。

<domain> ::= <subdomain> | " "

<subdomain> ::= <label> | <subdomain> "." <label>

<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]

<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>

<let-dig-hyp> ::= <let-dig> | "-"

<let-dig> ::= <letter> | <digit>

<letter> ::= 大文字のA～Zと小文字のa～zの52個のアルファベット文字のいずれか

<digit> ::= 0～9の10個の数字のいずれか

ドメイン名では大文字と小文字の両方が許可されていますが、大文字小文字に重要性は付与されていません。つまり、スペルが同じで大文字小文字が異なる2つの名前は、同一として扱われます。

ラベルはARPANETホスト名のルールに従う必要があります。文字で始まり、文字または数字で終わり、内部文字として文字、数字、およびハイフンのみを持つ必要があります。長さにもいくつかの制限があります。ラベルは63文字以下である必要があります。

たとえば、次の文字列はインターネット内のホストを識別します:

A.ISI.EDU  XX.LCS.MIT.EDU  SRI-NIC.ARPA

3.6. リソースレコード (Resource Records)​

ドメイン名はノードを識別します。各ノードには、空の場合もあるリソース情報のセットがあります。特定の名前に関連付けられたリソース情報のセットは、個別のリソースレコード (RRs) で構成されます。セット内のRRの順序は重要ではなく、名前サーバー、リゾルバー、またはDNSの他の部分によって保持される必要はありません。

特定のRRについて話すとき、次のものがあると想定します:

owner (所有者)​

RRが見つかるドメイン名。

type (タイプ)​

このリソースレコード内のリソースのタイプを指定するエンコードされた16ビット値。タイプは抽象リソースを参照します。

このメモでは次のタイプを使用します:

  • A: ホストアドレス
  • CNAME: エイリアスの正規名を識別
  • HINFO: ホストが使用するCPUとOSを識別
  • MX: ドメインのメール交換を識別。詳細は [RFC-974] を参照。
  • NS: ドメインの権威名前サーバー
  • PTR: ドメイン名前空間の別の部分へのポインター
  • SOA: 権威ゾーンの開始を識別

class (クラス)​

プロトコルファミリーまたはプロトコルのインスタンスを識別するエンコードされた16ビット値。

このメモでは次のクラスを使用します:

  • IN: インターネットシステム
  • CH: Chaosシステム

TTL​

RRの生存時間 (time to live)。このフィールドは秒単位の32ビット整数であり、主にリゾルバーがRRをキャッシュするときに使用されます。TTLは、RRが破棄される前にキャッシュできる期間を記述します。

RDATA​

リソースを記述する、タイプおよび場合によってはクラス依存のデータ:

  • A: INクラスの場合、32ビットIPアドレス。CHクラスの場合、ドメイン名の後に16ビット8進Chaosアドレスが続きます。
  • CNAME: ドメイン名。
  • MX: 16ビットの優先値（低いほうが良い）の後に、所有者ドメインのメール交換として機能するホスト名が続きます。
  • NS: ホスト名。
  • PTR: ドメイン名。
  • SOA: いくつかのフィールド。

RR構造の考慮事項 (RR structure considerations)​

所有者名は、RRの不可欠な部分を形成するのではなく、暗黙的であることがよくあります。たとえば、多くの名前サーバーは、名前空間のツリーまたはハッシュ構造を内部的に形成し、ノードからRRをチェーンします。残りのRR部分は、すべてのRRで一貫している固定ヘッダー（タイプ、クラス、TTL）と、記述されているリソースのニーズに適合する可変部分（RDATA）です。

TTLフィールドの意味は、RRをキャッシュに保持できる期間の時間制限です。この制限は、ゾーン内の権威データには適用されません。これもタイムアウトしますが、ゾーンの更新ポリシーによってです。TTLは、データが由来するゾーンの管理者によって割り当てられます。短いTTLを使用してキャッシュを最小限に抑えることができ、ゼロのTTLはキャッシュを禁止しますが、インターネットパフォーマンスの現実は、これらの時間が典型的なホストの場合日の単位であるべきであることを示唆しています。変更が予想される場合、変更中の不整合を最小限に抑えるために変更前にTTLを削減し、変更後に以前の値に戻すことができます。

RRのRDATAセクションのデータは、バイナリ文字列とドメイン名の組み合わせとして運ばれます。ドメイン名は、DNS内の他のデータへの「ポインター」としてよく使用されます。

3.6.1. RRのテキスト表現 (Textual expression of RRs)​

RRは、DNSプロトコルのパケット内でバイナリ形式で表現され、名前サーバーまたはリゾルバーに格納されるときは通常、高度にエンコードされた形式で表現されます。このメモでは、RRの内容を示すために、マスターファイルで使用されるものと同様のスタイルを採用しています。このフォーマットでは、ほとんどのRRは1行に表示されますが、括弧を使用して継続行が可能です。

行の先頭にはRRの所有者が与えられます。行が空白で始まる場合、所有者は前のRRと同じであると想定されます。読みやすさのために空白行が含まれることがよくあります。

所有者に続いて、RRのTTL、タイプ、およびクラスをリストします。クラスとタイプは上記で定義されたニーモニックを使用し、TTLはタイプフィールドの前の整数です。解析のあいまいさを避けるために、タイプとクラスのニーモニックは互いに素であり、TTLは整数であり、タイプニーモニックは常に最後です。INクラスとTTL値は、明確さのために例から省略されることがよくあります。

RRのリソースデータまたはRDATAセクションは、データの典型的な表現の知識を使用して与えられます。

たとえば、メッセージで運ばれるRRを次のように示すことができます:

ISI.EDU.        MX      10 VENERA.ISI.EDU.
                MX      10 VAXA.ISI.EDU.
VENERA.ISI.EDU. A       128.9.0.32
                A       10.1.0.52
VAXA.ISI.EDU.   A       10.2.0.27
                A       128.9.0.33

MX RRには、16ビット番号とその後にドメイン名で構成されるRDATAセクションがあります。アドレスRRは、32ビットインターネットアドレスを含むために標準IPアドレスフォーマットを使用します。

この例は、3つのドメイン名のそれぞれに2つのRRがある6つのRRを示しています。

同様に、次のように表示される場合があります:

XX.LCS.MIT.EDU. IN      A       10.0.0.44
                CH      A       MIT.EDU. 2420

この例は、XX.LCS.MIT.EDUの2つのアドレスを示しており、それぞれ異なるクラスです。

3.6.2. エイリアスと正規名 (Aliases and canonical names)​

既存のシステムでは、ホストやその他のリソースに、同じリソースを識別する複数の名前があることがよくあります。たとえば、名前C.ISI.EDUとUSC-ISIC.ARPAは両方とも同じホストを識別します。同様に、メールボックスの場合、多くの組織は実際には同じメールボックスに送られる多くの名前を提供しています。たとえば、[email protected]、[email protected]、および[email protected]はすべて同じメールボックスに送られます（ただし、その背後のメカニズムはやや複雑です）。

これらのシステムのほとんどには、同等の名前のセットの1つが正規または主要な名前であり、他のすべてがエイリアスであるという概念があります。

CNAMEレコード (CNAME records)​

ドメインシステムは、正規名 (CNAME) RRを使用してこのような機能を提供します。CNAME RRは、その所有者名をエイリアスとして識別し、RRのRDATAセクションに対応する正規名を指定します。CNAMERRがノードに存在する場合、他のデータは存在すべきではありません。これにより、正規名とそのエイリアスのデータが異なることがないことが保証されます。このルールはまた、キャッシュされたCNAMEを他のRRタイプの権威サーバーをチェックせずに使用できることを保証します。

CNAME RRは、DNSソフトウェアで特別なアクションを引き起こします。名前サーバーがドメイン名に関連付けられたリソースセット内で目的のRRを見つけられない場合、リソースセットが一致するクラスのCNAMEレコードで構成されているかどうかを確認します。そうである場合、名前サーバーはレスポンスにCNAMEレコードを含め、CNAMEレコードのデータフィールドで指定されたドメイン名でクエリを再開します。このルールの1つの例外は、CNAMEタイプに一致するクエリは再開されないことです。

たとえば、名前サーバーがUSC-ISIC.ARPAのクエリを処理していて、タイプAの情報を要求し、次のリソースレコードを持っていたとします:

USC-ISIC.ARPA   IN      CNAME   C.ISI.EDU

C.ISI.EDU       IN      A       10.0.0.52

これらのRRの両方がタイプAクエリへの応答で返されますが、タイプCNAMEまたは * クエリはCNAMEのみを返す必要があります。

別の名前を指すRR内のドメイン名は、常にエイリアスではなく主要な名前を指す必要があります。これにより、情報へのアクセスにおける余分な間接参照が回避されます。たとえば、上記のホストのアドレスから名前へのRRは次のようになります:

52.0.0.10.IN-ADDR.ARPA  IN      PTR     C.ISI.EDU

USC-ISIC.ARPAを指すのではなく。もちろん、堅牢性の原則により、ドメインソフトウェアはCNAMEチェーンまたはループが提示されたときに失敗してはいけません。CNAMEチェーンは追跡され、CNAMEループはエラーとして通知される必要があります。

3.7. クエリ (Queries)​

クエリは、応答を引き出すために名前サーバーに送信される可能性のあるメッセージです。インターネットでは、クエリはUDPデータグラムまたはTCP接続で運ばれます。名前サーバーによる応答は、クエリで提起された質問に答えるか、要求者を別の名前サーバーのセットに参照するか、何らかのエラー状態を通知します。

一般的に、ユーザーはクエリを直接生成せず、代わりにリゾルバーにリクエストを行い、リゾルバーは名前サーバーに1つ以上のクエリを送信し、結果として生じる可能性のあるエラー状態と参照を処理します。もちろん、クエリで尋ねることができる可能性のある質問は、リゾルバーが提供できるサービスの種類を形作ります。

メッセージフォーマット (Message format)​

DNSクエリと応答は、標準のメッセージフォーマットで運ばれます。メッセージフォーマットには、常に存在する多数の固定フィールドを含むヘッダーと、クエリパラメータとRRを運ぶ4つのセクションがあります。

ヘッダーの最も重要なフィールドは、異なるクエリを分離するオペコード (opcode) と呼ばれる4ビットフィールドです。可能な16の値のうち、1つ（標準クエリ）は公式プロトコルの一部であり、2つ（逆クエリとステータスクエリ）はオプションであり、1つ（完了）は廃止され、残りは未割り当てです。

4つのセクションは次のとおりです:

  • Question (質問): クエリ名と他のクエリパラメータを運びます。
  • Answer (回答): クエリに直接答えるRRを運びます。
  • Authority (権威): 他の権威サーバーを記述するRRを運びます。オプションで、回答セクションの権威データのSOA RRを運ぶことができます。
  • Additional (追加): 他のセクションのRRを使用する際に役立つ可能性のあるRRを運びます。

これらのセクションの内容は、ヘッダーオペコードによって異なりますが、フォーマットは異なりません。

3.7.1. 標準クエリ (Standard queries)​

標準クエリは、ターゲットドメイン名 (QNAME)、クエリタイプ (QTYPE)、およびクエリクラス (QCLASS) を指定し、一致するRRを要求します。このタイプのクエリはDNSクエリの大多数を占めるため、特に指定しない限り、「クエリ」という用語を使用して標準クエリを意味します。QTYPEおよびQCLASSフィールドはそれぞれ16ビット長であり、定義されたタイプとクラスのスーパーセットです。

QTYPEフィールドには次のものが含まれる場合があります:

  • <任意のタイプ>: そのタイプのみに一致します（例: A、PTR）。
  • AXFR: 特別なゾーン転送QTYPE。
  • MAILB: すべてのメールボックス関連RRに一致します（例: MBおよびMG）。
  • *: すべてのRRタイプに一致します。

QCLASSフィールドには次のものが含まれる場合があります:

  • <任意のクラス>: そのクラスのみに一致します（例: IN、CH）。
  • *: すべてのRRクラスに一致します。

クエリドメイン名、QTYPE、およびQCLASSを使用して、名前サーバーは一致するRRを検索します。関連するレコードに加えて、名前サーバーは、目的の情報を持つ名前サーバーを指すRRまたは関連するRRを解釈する際に役立つと予想されるRRを返す場合があります。たとえば、要求された情報を持たない名前サーバーは、それを持つ名前サーバーを知っている場合があります。関連するRRでドメイン名を返す名前サーバーは、そのドメイン名をアドレスにバインドするRRも返す場合があります。

クエリと応答の例 (Example query and response)​

たとえば、[email protected]にメールを送信しようとするメーラーは、リゾルバーにISI.EDUに関するメール情報を要求し、QNAME=ISI.EDU、QTYPE=MX、QCLASS=INのクエリが発生します。応答の回答セクションは次のようになります:

ISI.EDU.        MX      10 VENERA.ISI.EDU.
                MX      10 VAXA.ISI.EDU.

追加セクションは次のようになる場合があります:

VAXA.ISI.EDU.   A       10.2.0.27
                A       128.9.0.33
VENERA.ISI.EDU. A       10.1.0.52
                A       128.9.0.32

これは、サーバーが、要求者がメール交換情報を必要とする場合、おそらくその後すぐにメール交換のアドレスが必要になると想定しているためです。

QCLASS=* 構文は、権威に関して特別な解釈が必要であることに注意してください。特定の名前サーバーはドメインシステムで利用可能なすべてのクラスを知らない可能性があるため、すべてのクラスに対して権威があるかどうかを知ることはできません。したがって、QCLASS=* クエリへの応答は決して権威的ではありません。

3.7.2. 逆クエリ (Inverse queries) (オプション)​

名前サーバーは、特定のリソースをそのリソースを持つドメイン名またはドメイン名にマッピングする逆クエリもサポートする場合があります。たとえば、標準クエリがドメイン名をSOA RRにマッピングする場合、対応する逆クエリはSOA RRをドメイン名にマッピングする場合があります。

このサービスの実装は名前サーバーではオプションですが、すべての名前サーバーは少なくとも逆クエリメッセージを理解し、未実装エラー応答を返すことができる必要があります。

ドメインシステムはホストアドレスやその他のリソースタイプではなくドメイン名によって編成されているため、ドメインシステムは逆クエリの完全性または一意性を保証できません。逆クエリは主にデバッグとデータベースメンテナンス活動に役立ちます。

逆クエリは適切なTTLを返さない場合があり、識別されたRRがセットの1つである場合（たとえば、複数のアドレスを持つホストの1つのアドレス）を示しません。したがって、逆クエリで返されたRRは決してキャッシュされるべきではありません。

逆クエリは、ホストアドレスをホスト名にマッピングするための許容可能な方法ではありません。代わりにIN-ADDR.ARPAドメインを使用してください。

逆クエリの詳細な議論は [RFC-1035] に含まれています。

3.8. ステータスクエリ (Status queries) (実験的)​

定義される予定です。

3.9. 完了クエリ (Completion queries) (廃止)​

RFC 882およびRFC 883で説明されているオプションの完了サービスは削除されました。再設計されたサービスが将来利用可能になる可能性があり、またはオペコードが他の使用のために再利用される可能性があります。

に最終更新