Loading article…
TXTレコード（テキストレコードの略）は、ドメインネームシステム（DNS）のリソースレコードの一種で、サーバー、ネットワーク、データセンター、その他の会計情報に関する人間が読める情報など、任意のテキストをホストまたはその他の名前に関連付ける機能を提供するために使用されます。[1]
また、少量の機械可読データを DNS に記録するために、より構造化された形式で使用されることもよくあります。
背景
DNSサーバーの実装がサポートしていれば、ドメインには複数のTXTレコードを関連付けることができます。[1]各レコードには、1つ以上の文字列を含めることができます。[2]従来、これらのテキストフィールドは、会社名や組織名のフルネーム、ホストのアドレスなど、さまざまな非標準化された用途に使用されていました。
TXT の使用例をいくつか示します。
- ドメイン所有権の検証[3] [4]
- 送信者ポリシーフレームワーク（SPF）の実装[5]
- 電子メールメッセージの送信者を検証するためのドメインキー識別メール（DKIM）レコード[6]
- ゼロ構成ネットワークDNSベースのサービス検出[7] [8]
- ドメインベースのメッセージ認証、レポート、適合(DMARC) ポリシー
TXT レコードを使用してさまざまな目的でデータを保存することには、問題がないわけではありません。DNS プロトコルでは、クライアントが特定のドメイン名 (例: example.com) の特定のレコード タイプ (例: TXT) をクエリする場合、そのタイプのすべてのレコードが同じ DNS メッセージで返される必要があると規定されています。これにより、大量の「不要な」情報が転送される大規模なトランザクションが発生したり、どの TXT レコードを使用するかが不明確になったりする可能性があります。この問題を回避するには、2 つの方法があります。特定の目的で TXT レコードを使用するときに使用するドメイン名プレフィックスを指定する (例: DKIM の場合は _domainkey.example.com) か、まったく新しいレコード タイプを作成する方法です。前者は DNS を変更する必要がないため「簡単」です。後者は DNS データベース モデルの設計によく適合するため、「よりクリーン」であると見なされることがあります。以前は、新しいレコード タイプの作成はIETFで複雑な手順であったため、避けられることが多かったです。プロセスがはるかに軽量で迅速なものに置き換えられたにもかかわらず、一部の人々はその抵抗感を抱き続けています。
形式
TXTレコードの構造は、RFC 1035 [2]で次のように規定されています。この仕様では、テキスト文字列の文字エンコードについては何も言及されていないことに注意してください。文字列の解釈はコンテキストに依存し、データはDNS内でバイナリとして扱われると明示的に規定されています。後の仕様 (例: RFC 6763 [8] – サービス検出に使用されるDNS) では、特定の目的のために特定のエンコードの使用が要求される場合があります。
RDATA セクションには、(TXT 長さ + TXT) が連続して複数回含まれる場合があります。データ長は、それらすべてを合わせた長さです。
非構造化テキストとして、組織は TXT 文字列を任意の方法で定義して使用できます。次に例を示します。
example.com. IN TXT 「このドメイン名はドキュメントで使用するために予約されています」
RFC 1464では、属性とその値を単一のレコードで定義するために使用できる構造化形式を定義しています。[1]次の例をご覧ください。
host.widgets.com. IN TXT "プリンター=lpr5" sam.widgets.com. IN TXT "お気に入りの飲み物=オレンジジュース"
実際には、TXTレコードを使用するサービスはこのRFCに従わず、独自のフォーマットを採用していることが多いです。[9] [10]
使用例
SPFに使用される TXT レコードの文字列:
「v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 ip6:2620:0:860::/46 a -すべて」
DMARC の使用例:
"v=DMARC1;p=なし;sp=隔離;pct=100;rua=mailto:dmarcreports@example.com;"
サイト検証に使用:
「google-site-verification=6P08Ow5E-8Q0m6vQ7FMAqAYIDprkVV8fUf_7hZ4Qvc8」
カスタム電子メール サービスに使用:
_amazonses.example.com。テキストファイル「pmBGN/7MjnfhTKUZ06Enqq1PeGUaOkw8lGhcfwefcHU="
ブランドメッセージ識別指標（BIMI）:
default._bimi TXT "v=BIMI1; l=https://example.com/image.svg; a=https://example.com/image/certificate.pem"
参照
参考文献
- ^ abc R. Rosenbaum (1993 年 5 月). ドメイン ネーム システムを使用した任意の文字列属性の保存。ネットワーク ワーキング グループ。doi : 10.17487 / RFC1464。RFC 1464 。 実験的。
- ^ ab P. Mockapetris (1987 年 11 月). ドメイン名 - 実装と仕様. ネットワークワーキンググループ. doi : 10.17487/RFC1035 . STD 13. RFC 1035. インターネット標準 13。RFC 882、883、および 973 は廃止されました。RFC 1101、1183、1348、1876、1982、1995、1996、2065、2136、2137、2181、2308、2535、2673、2845、3425、3658、4033、4034、4035、4343、5936、5966、6604、7766、8482、8490、および 8767 によって更新さ れました。
- ^ 「サイトの所有権を確認する」。2018年12月18日閲覧。
- ^ 「ドメイン検証」。Facebook 。 2018年12月18日閲覧。
- ^ S. Kitterman (2014 年 4 月)。電子メールでのドメインの使用 を承認するための送信者ポリシー フレームワーク (SPF)、バージョン 1。インターネット エンジニアリング タスク フォース。doi : 10.17487 / RFC7208。ISSN 2070-1721。RFC 7208 。 提案された標準。RFC 4408は 廃止されました。RFC 7372、RFC 8553、およびRFC 8616 によって更新されました 。
- ^ 「TXT レコードについて」。Google Apps 管理。2014年 8 月 17 日閲覧。
- ^ S. Cheshire; M. Krochmal (2013 年 2 月). マルチキャスト DNS.インターネット エンジニアリング タスク フォース. doi : 10.17487/RFC6762 . ISSN 2070-1721. RFC 6762. 提案された標準。
- ^ ab S. Cheshire; M. Krochmal (2013 年 2 月). DNS ベースのサービス検出。インターネットエンジニアリングタスク フォース。doi : 10.17487/ RFC6763。ISSN 2070-1721。RFC 6763 。 提案された標準。RFC 8553 によって更新されました。
- ^ 「DNS レコードの検証」. WebNot。 2013 年 7 月 2 日。2018 年12 月 21 日に取得。
- ^ 「Amazon SES ドメイン検証 TXT レコード」。Amazon。2018年12 月 21 日閲覧。