DNSレコードタイプのリスト

すべてのアクティブなDNSレコードタイプのグラフィカルな概要

このDNSレコードタイプのリストは、ドメインネームシステム（DNS）のゾーンファイルで許可されるリソースレコード（RR）の概要です。疑似RRも含まれています。

リソースレコード

タイプタイプID（10進数）RFCの定義説明関数
あ		1RFC 1035 [1]住所記録32 ビットのIPv4アドレスを返します。これは、ホスト名をホストの IP アドレスにマッピングするために最もよく使用されますが、 DNSBL、RFC 1101 でのサブネット マスクの保存などにも使用されます。
AAAAA		28RFC 3596 [2]IPv6アドレスレコード128 ビットのIPv6アドレスを返します。これは、ホスト名をホストの IP アドレスにマッピングするために最もよく使用されます。
AFSDB		18RFC 1183AFSデータベースレコードAFSセルのデータベースサーバのロケーション。このレコードは、AFSクライアントがローカルドメイン外のAFSセルにアクセスするためによく使用されます。このレコードのサブタイプは、廃止されたDCE/DFSファイルシステムで使用されます。
APL		42RFC 3123アドレスプレフィックスリストさまざまなアドレス ファミリのアドレス範囲のリスト (例: CIDR形式) を指定します。実験的。
CAA		257RFC  6844認証局の認可DNS証明機関の認可、ホスト/ドメインに対して受け入れ可能なCAを制限する
CDNSKEY		60RFC 7344親に転送するためのDNSKEYレコードの子コピー
CDS		59RFC 7344子供のDSDSレコードの子コピー（親に転送用）
CERT		37RFC 4398証明書記録PKIX、SPKI、PGPなどを保存します。
CNAME		5RFC 1035 [1]正典名記録ある名前から別の名前へのエイリアス: DNS ルックアップは、新しい名前でルックアップを再試行して続行されます。
CSYNC		62RFC 7477子から親への同期子DNSゾーンと親DNSゾーン間の同期メカニズムを指定します。典型的な例としては、親ゾーンと子ゾーンで同じNSレコードを宣言することが挙げられます。
DHCID		49RFC 4701DHCP識別子DHCPのFQDNオプションと組み合わせて使用​​する
DLV		32769RFC 4431DNSSECルックアサイド検証レコードDNS委任チェーンの外部にDNSSECトラストアンカーを公開するためのものです。DSレコードと同じ形式を使用します。これらのレコードの使用方法については、RFC 5074で説明されています。
DNAME		39RFC 6672委任名レコード名前とそのすべてのサブネームのエイリアスです。CNAMEレコードは正確な名前のみのエイリアスですが、CNAMEレコードはCNAMEレコードとは異なります。DNSルックアップは新しい名前で再試行することで継続されます。
DNSキー		48RFC 4034DNSキーレコードDNSSECで使用されるキーレコード。KEYレコードと同じ形式を使用します。
DS		43RFC 4034委任署名者委任されたゾーンのDNSSEC署名鍵を識別するために使用されるレコード
EUI48108RFC 7043MACアドレス（EUI-48）48 ビットの IEEE 拡張一意識別子。
EUI64109RFC 7043MACアドレス（EUI-64）64 ビットの IEEE 拡張一意識別子。
ヒント		13RFC 8482、RFC 1035プレースホルダレコード、またはホスト情報ANYクエリへの応答時に使用されるように再利用されました。元々は「ホスト情報」として定義され、ホストのオペレーティングシステムとハードウェアに関する情報を提供することを目的としていました。RFC 8482では、明示的なHINFOクエリにおけるこの従来の意味は廃止されていませんが、ほとんど使用されないものとされています。
ヒップ		55RFC 8005ホストアイデンティティプロトコルIP アドレスのエンドポイント識別子とロケータの役割を分離する方法。
HTTPS		65RFC 9460HTTPSバインディングSVCBレコードの特殊なタイプ。HTTPS経由の安全な接続を確立するために必要な接続情報を提供します。通常、この情報はホストへの接続時に取得およびネゴシエートされます。ホストとネゴシエートするのではなく、DNSサーバーから情報を取得することで、より安全な接続（Encrypted Client Helloの使用など）が実現され、ホストへの接続が最初に確立された際のレイテンシが低減されます。
IPSECKEY		45RFC 4025IPsecキーIPsecで使用できるキーレコード
鍵		25RFC 2535 [3]およびRFC 2930 [4]重要な記録SIG(0) (RFC 2931) および TKEY (RFC 2930) のみで使用される。[5] RFC 3445 ではアプリケーションキーとしての使用が廃止され、DNSSEC のみでの使用に限定された。 [6] RFC 3755 では DNSSEC 内での代替として DNSKEY が指定されている。[7 ] RFC 4025 では IPsec で使用するための代替として IPSECKEY が指定されている。[8]
KX		36RFC 2230鍵交換記録一部の暗号化システム（DNSSECを除く）において、関連付けられたドメイン名の鍵管理エージェントを識別するために使用されます。これはDNSセキュリティとは全く関係ありません。IETFの標準化過程ではなく、情報提供ステータスです。これまで限定的に導入されてきましたが、現在も使用されています。
場所29RFC 1876位置記録ドメイン名に関連付けられた地理的な場所を指定します
MX15RFC 1035 [1]およびRFC 7505メール交換記録ドメインのメールを受け入れるメール交換サーバーのリスト
ナプター35RFC 3403命名権限ポインタドメイン名を正規表現ベースで書き換えることができ、それをURIとして使用したり、さらにドメイン名を検索したりすることができます。
NS		2RFC 1035 [1]ネームサーバーレコード指定された権威ネームサーバーを使用するようにDNSゾーンを委任します
NSEC		47RFC 4034次のセキュアレコードDNSSECの一部で、名前が存在しないことを証明するために使用されます。（廃止された）NXTレコードと同じ形式を使用します。
NSEC3		50RFC 5155次のセキュアレコードバージョン3ゾーンウォーキングを許可せずに名前の非存在を証明できるDNSSECの拡張機能
NSEC3PARAM		51RFC 5155NSEC3パラメータNSEC3で使用するパラメータレコード
OPENPGPKEY61RFC 7929OpenPGP公開鍵レコードOPENPGPKEY DNS リソース レコードを使用して、特定の電子メール アドレスの OpenPGP 公開キーを DNS に公開および検索するためのDNS ベースの名前付きエンティティの認証( DANE) 方式。
PTR		12RFC 1035 [1]PTRリソースレコード [de]正規名へのポインタ。CNAMEとは異なり、DNS処理は停止し、名前のみが返されます。最も一般的な用途は逆DNSルックアップの実装ですが、 DNS-SDなどの用途もあります。
RP		17RFC 1183責任者ドメインの責任者に関する情報。通常は、@ を . に置き換えたメールアドレスです。
RRSIG		46RFC 4034DNSSEC署名DNSSEC で保護されたレコードセットの署名。SIG レコードと同じ形式を使用します。
SIG		24RFC 2535サインSIG(0) (RFC 2931) および TKEY (RFC 2930) で使用される署名レコード。[7] RFC 3755 では、DNSSEC 内で使用する SIG の代替として RRSIG が指定されました。[7]
スミメア53RFC 8162 [9]S/MIME証明書協会[10]送信者認証のために、S/MIME 証明書をドメイン名に関連付けます。
SOA6RFC 1035 [1]およびRFC 2308 [11]権限レコードの開始プライマリ ネーム サーバー、ドメイン管理者の電子メール、ドメイン シリアル番号、ゾーンの更新に関連するいくつかのタイマーなど、 DNS ゾーンに関する権限のある情報を指定します。
SRV33RFC 2782サービスロケーターMX などのプロトコル固有のレコードを作成する代わりに、新しいプロトコルに使用される一般化されたサービス ロケーション レコード。
SSHFP		44RFC 4255SSH公開鍵フィンガープリントSSH公開ホスト鍵のフィンガープリントをDNSに公開するためのリソースレコード。ホストの信頼性検証に役立ちます。RFC 6594では、ECC SSH鍵とSHA-256ハッシュが定義されています。詳細はIANA SSHFP RRパラメータレジストリを参照してください。
SVCB		64RFC 9460サービスバインディングこのリソースレコードは、クライアントがホストに接続する際に役立つメタデータやその他の情報を提供します。HTTPSレコードは、HTTPS接続を確立する際に役立つ特殊なSVCBレコードです。より汎用的なSVCBレコードは、サポートされているプロトコル、代替エンドポイント、CNAMEレコードではサポートされていない一部のエイリアスタイプなど、その他の情報も提供できます。
TA		32768—DNSSEC信頼機関署名付きDNSルートを使用しないDNSSEC導入提案の一部です。詳細はIANAデータベースとWeiler仕様を参照してください。DSレコードと同じ形式を使用します。
Tキー		249RFC 2930トランザクションキーレコードTSIGで使用される鍵素材を提供する方法。鍵素材は、付随するKEY RRの公開鍵で暗号化されます。[12]
TLSA		52RFC 6698TLSA証明書協会DANEのレコード。RFC 6698 では、「TLSA DNS リソース レコードは、TLS サーバー証明書または公開キーをレコードが見つかったドメイン名に関連付けるために使用され、これによって「TLSA 証明書の関連付け」が形成されます」と定義されています。
TSIG		250RFC 2845トランザクション署名動的更新が承認されたクライアントからのものであることを認証するために、またはDNSSECと同様に、応答が承認された再帰ネームサーバ[13]からのものであることを認証するために使用できます。
TXT		16RFC 1035 [1]テキスト記録元々はDNSレコード内の任意の人間が読めるテキストのためのものでした。しかし、1990年代初頭以降、このレコードはRFC 1464、日和見暗号化、送信者ポリシーフレームワーク、DKIM、DMARC、DNS-SDなど で規定されているような機械可読データを格納することが多くなりました。
URI		256RFC 7553統一資源識別子ホスト名から URI へのマッピングを公開するために使用できます。
ゾーンMD		63RFC 8976DNSゾーンのメッセージダイジェスト保存中の DNS ゾーン データに対して暗号化メッセージ ダイジェストを提供します。

その他のタイプと疑似RR

他の種類のレコードは、単に特定の種類の情報を提供するもの（例えば、HINFOレコードはホストが使用するコンピュータ/OSの種類の説明を提供します）や、実験的な機能で使用されるデータを返すものがあります。「type」フィールドは、プロトコル内で様々な操作にも使用されます。

タイプタイプID。RFCの定義説明関数
*255RFC 1035 [1]キャッシュされたすべてのレコードネームサーバーが認識しているすべてのタイプのレコードを返します。ネームサーバーに名前に関する情報がない場合、リクエストはそのまま転送されます。返されるレコードは完全ではない場合があります。例えば、名前にAとMXの両方があるが、ネームサーバーにAレコードしかキャッシュされていない場合、Aレコードのみが返されます。通常はANYと呼ばれます（例：dig、Windows nslookup、Wireshark）。2019年にRFC8482 [14]標準化過程の公開により、Cloudflare [ 15]を含む多くのDNSプロバイダーは、レコードを列挙する代わりに、「ANY」クエリに対して最小限の応答のみを提供するようになりました。
AXFR252RFC 1035 [1]権威ゾーン転送プライマリ ネーム サーバーからセカンダリ ネーム サーバーにゾーン ファイル全体を転送します。
IXFR		251RFC 1996増分ゾーン転送指定されたゾーンのゾーン転送を要求しますが、以前のシリアル番号との差分のみを対象とします。権限サーバーが設定上の問題または必要な差分の不足により要求を処理できない場合、この要求は無視され、完全な（AXFR）応答が送信されます。
オプト		41RFC 6891オプションこれは、EDNS をサポートするために必要な疑似レコードタイプです。
別名 /

ANAME / apex CNAME / CNAME フラット化 / トップレベルリダイレクト

-ドラフト-ietf-dnsop-aname-04DNAMEに類似したエイリアスANAME、ALIAS、apex CNAME、CNAME flattening、あるいはトップレベルリダイレクトレコードは、疑似レコードタイプであり、一般的に使用されていますが、RFC標準化されていないレコードタイプです。実装は様々です。特にベアドメイン名や、他のレコードと共存する必要がある場合に、CNAMEの代替として機能します。これにより、DNSソフトウェアベンダーは、ANAMEレコードの宛先に類似したAレコードとAAAAレコードを合成的に生成します。宛先が変更されると、これらの合成AレコードとAAAAレコードも自動的に変更されます。実際に使用されるメカニズムは、多くの場合、独自のものと見なされます。

廃止されたレコードタイプ

進歩により、当初定義されたレコードタイプの一部は廃止されました。IANAにリストされているレコードの中には、様々な理由から用途が限られているものがあります。リストに廃止とマークされているもの、あまり知られていないサービス用のもの、古いバージョンのサービス用のもの、そして「適切ではない」という特別な注意書きが付いているものもあります。

タイプタイプID
（10進数）		RFCの定義廃止された説明
医学博士3RFC 883RFC 973メール宛先（MD）レコードとメール転送（MF）レコード。MAILAは実際のレコードタイプではなく、MFレコードまたはMDレコードを返すクエリタイプです。RFC 973では、これらのレコードはMXレコードに置き換えられました。
MF4
マイラ254
MB7RFC 883正式に廃止されたわけではありません。採用される可能性は低いです (RFC 2505)。MB、MG、MR、およびMINFOは、加入者メーリングリストを公開するためのレコードです。MAILBは、これらのレコードのいずれかを返すクエリコードです。MBとMGは、SMTPのVRFYコマンドとEXPNコマンドを置き換えることを意図していました。MRは、「551 User Not Local」SMTPエラーを置き換えることを目的としていました。その後、RFC 2505でVRFYとEXPNの両方を無効にすることが推奨され、MBとMGは不要になりました。RFC 1035では、これらは実験的な機能に分類されました。
MG8
氏9
ミンフォ14
メールB253
ウィークス11RFC 883、RFC 1035RFC 1123 では「信頼できない」と宣言されています (詳細は RFC 1127 を参照)。ホストがサポートする既知のサービスを記述するレコード。実際には使用されていません。現在推奨されている慣習では、IPアドレスでサービスがサポートされているかどうかを確認するには、そのIPアドレスへの接続を試みることが推奨されています。SMTPはMX処理においてWKSレコードを使用することさえ禁止されています。[16]
注意32RFC 1002間違い (RFC 1002 より)。番号は現在 NIMLOC と SRV に割り当てられています。
NBSTAT33
ヌル10RFC 883RFC 1035RFC 1035 により廃止されました。RFC 883 では、このレコードを使用する「完了クエリ」（オペコード 2 およびおそらく 3）が定義されていました。RFC 1035 では後に、オペコード 2 が「ステータス」に再割り当てされ、オペコード 3 が予約されました。
A638RFC 2874RFC 6563初期の IPv6 の一部として定義されましたが、RFC 3363 によって実験的なものに格下げされ、その後 RFC 6563 によって歴史的に格下げされました。
NXT30RFC 2065RFC 3755DNSSEC（RFC 2065）の最初のバージョンの一部。NXTはDNSSECのアップデート（RFC 3755）によって廃止されました。同時に、KEYとSIGの適用範囲もDNSSECでの使用が含まれないように制限されました。
鍵25
SIG24
ヒント13RFC 883RFC 8482では廃止されていません。現在、CloudflareがANYタイプのクエリに応答するために使用されています。[17]ホストCPUの種類とオペレーティングシステムに関する情報を提供することを目的としたレコードです。これにより、プロトコルは類似のピアと通信する際に処理を最適化できるようになります。
RP17RFC 1183RP は、SOA レコードで使用されるものとは異なる、特定のホスト、サブネット、またはその他のドメイン レベル ラベルの異なる連絡先ポイントに関する、人間が判読できる特定の情報に使用される場合があります。
X2519現在、注目すべきアプリケーションでは使用されていない
ISDN20現在、注目すべきアプリケーションでは使用されていない
RT21現在、注目すべきアプリケーションでは使用されていない
NSAP22RFC 1706現在、注目すべきアプリケーションでは使用されていない
NSAP-PTR23現在、注目すべきアプリケーションでは使用されていない
PX26RFC 2163現在、注目すべきアプリケーションでは使用されていない
EID31—Nimrod DNSインターネットドラフトで定義されましたが、RFCには採用されませんでした。現在、主要なアプリケーションでは使用されていません。
ニムロック32—
アトマ34—ATMフォーラム委員会によって定義されました。[18]
APL42RFC 3123さまざまなアドレス ファミリのアドレス範囲のリスト (例: CIDR形式) を指定します。実験的。
シンク40—キッチンシンクインターネットドラフトによって定義されたが、RFCステータスにはならなかった
GPOS27RFC 1712LOC記録のより限定的な初期バージョン
UINFO100—IANAが予約しており、RFCで文書化されておらず[1]、90年代初頭にBINDからサポートが削除されました。
ユーザID101—
性同一性障害102—
非特定103—
SPF99RFC 4408RFC 7208SPFデータをTXTレコードに保存する代わりに、同じ形式で送信ポリシーフレームワークプロトコルの一部として規定されました。広範囲にわたるサポート不足のため、RFC 7208で廃止されました。 [19] [20]
情報56—ゾーンのステータス情報を提供するために使用される。2008年にIETFドラフト「ゾーンステータス（ZS）DNSリソースレコード」に提案されたが、採用されずに失効した。[21]
RKEY57—NAPTRレコードの暗号化に使用される。2008年にIETF草案「RKEY DNSリソースレコード」に提案されたが、採用されずに失効した。[22]
タリンク58—DNSSEC Trust Anchor History Serviceインターネットドラフトで定義されたが、RFCステータスにはならなかった。
NID104RFC 6742注目すべきアプリケーションでは使用されていないため、「実験的」とマークされています
L32105
L64106
LP107
死亡259—DOA over DNSインターネットドラフトで定義されたが、RFCステータスにはならなかった

参考文献

  1. ^ abcdefghi Paul Mockapetris (1987年11月). 「RFC 1035: ドメイン名 – 実装と仕様」. IETF (インターネット技術タスクフォース) ネットワークワーキンググループ. p. 12.
  2. ^ 「RFC 3596: IPバージョン6をサポートするためのDNS拡張」インターネット協会、2003年10月。2021年4月14日時点のオリジナルよりアーカイブ。
  3. ^ RFC 2535、§3
  4. ^ RFC 3445, §1. 「KEY RRはRFC 2930で定義されています...」
  5. ^ RFC 2931, §2.4. 「一方、SIG(0)は公開鍵認証を使用し、公開鍵はKEY RRとしてDNSに保存され、秘密鍵は署名者側に保存されます。」
  6. ^ RFC 3445, §1. 「DNSSECはKEY RRに唯一許容されるサブタイプとなる...」
  7. ^ abc RFC 3755, §3. 「DNSKEYはKEYの代替となり、RFC3445に従い、これらのキーがアプリケーション用ではないことを示すニーモニックが付与されます。RRSIG（Resource Record SIGnature）はSIGの代替となり、NSEC（Next SECure）はNXTの代替となります。これらの新しいキータイプは、SIG(0) RFC2931とTKEY RFC2930を除き、古いキータイプを完全に置き換えます。」
  8. ^ RFC 4025、要約。「このレコードは、RFC 3445で廃止されたKEYリソースレコードのサブタイプ#4の機能を置き換えます。」
  9. ^ Hoffman, P.; Schlyter, J. (2017年5月). 「RFC 8162 – S/MIMEにおけるドメイン名と証明書の関連付けのためのセキュアDNSの使用」.インターネット技術タスクフォース. doi :10.17487/RFC8162 . 2018年10月17日閲覧。
  10. ^ 「ドメインネームシステム（DNS）パラメータ」。インターネット割り当て番号局。2018年9月。 2018年10月17日閲覧。
  11. ^ SOA レコードの最小フィールドは、RFC 2308 で NXDOMAIN 応答の TTL に再定義されています。
  12. ^ RFC 2930、§6。「...鍵素材は、付随するKEY RR RFC 2535の公開鍵で暗号化されたTKEY RRの鍵データフィールド内で送信されます。」
  13. ^ RFC 2845、要約
  14. ^ J. Abley、Afilias、O. Gudmundsson、M. Majkowski、Cloudflare Inc.、E. Hunt、ISC（2019年1月）。「RFC 8482: QTYPE=ANYを持つDNSクエリへの最小サイズの応答の提供」IETFデータトラッカー。インターネット技術タスクフォース。 {{cite news}}: CS1 maint: 複数の名前: 著者リスト (リンク)
  15. ^ 「その後の出来事：ANYの廃止」Cloudflare . 2019年3月16日. 2021年9月19日閲覧。
  16. ^ RFC 1123 セクション 2.2、5.2.12、6.1.3.6
  17. ^ 「その後の出来事：ANYの廃止」Cloudflare、2016年4月13日。 2019年3月9日閲覧。
  18. ^ 「ATMネームシステム V2.0」（PDF） 。ATMフォーラム技術委員会。2000年7月。 2019年3月14日時点のオリジナル（PDF）からアーカイブ。 2019年3月14日閲覧。
  19. ^ Kucherawy, M. (2012年7月). 「RRTYPE問題の背景」. Sender Policy Framework (SPF) と Sender ID Experiments の解決. IETF . sec. A. doi : 10.17487/RFC6686 . RFC 6686. 2013年8月31日閲覧.
  20. ^ Kitterman, S. (2014年4月). 「SPF DNSレコードタイプ」. 電子メールにおけるドメイン使用の承認のための送信者ポリシーフレームワーク（SPF）バージョン1. IETF . sec. 3.1. doi : 10.17487/RFC7208 . RFC 7208. 2014年4月26日閲覧.
  21. ^ Reid, Jim (2008年7月4日). 「draft-reid-dnsext-zs-01 – ゾーンステータス（ZS）DNSリソースレコード」. IETFデータトラッカー. IETF . 2019年3月9日閲覧。
  22. ^ Reid, Jim; Schlyter, Jakob; Timms, Ben (2008年7月4日). 「draft-reid-dnsext-rkey-00 – The RKEY DNS Resource Record」. IETF Datatracker . IETF . 2019年3月9日閲覧。

さらに読む

  • 「ドメインネームシステム（DNS）パラメータ」 。 2018年8月14日閲覧。
  • 「DNSの基本 – G Suite管理者ヘルプ」 。 2018年11月8日閲覧。
「https://en.wikipedia.org/w/index.php?title=List_of_DNS_record_types&oldid=1323397924#PTR」から取得