ラベルにhttps：//が含まれるDNS Aレコード

私は最近、フォームのAレコードに初めて遭遇しました。

https://www.example.com.    <TTL>   IN  A   <IP address>

私の知る限り、このレコードは意図的なものです（つまり、エラーではありません）。RFC 2181によれば、コロンとスラッシュはラベルに有効な文字であることは知っていますが、レコードの目的がわかりません。一部の認証局は、ドメイン制御の検証にこのフォームを使用していますか？このフォームはある種のエクスプロイトから保護しますか？何らかの種類のユーザーエラーまたはソフトウェアの既知の問題をトラップしますか？

domain-name-system a-record

— ビンキー
ソース

IPアドレスは、一致するwww.example.comのIPアドレスと異なりますか？これが意図的なものでエラーではないと思う理由は何ですか？

— jcaron

このAレコードの構成が間違っていないのは、これらのレコードを管理している組織が大規模なオンラインプレゼンスを持つ大企業であり、そのDNSレコードが精査されているためです。しかし、これらのAレコードはエラーであると完全に信じることができます。この問題をさらに掘り下げて（しゃれは意図していません）、記録の理由がわかったら更新を投稿します。

— Binky

誰かがFarsight DNSDBアカウントまたは同様のサービスを所有していて、「https：//」を持つ他のAレコードの完全なDNSスペースを照会したい場合、それは本当にクールです。:)

— Binky

AレコードのIPアドレスマッピングは、IPアドレスマッピングとhttps://www.example.comは異なりますwww.example.com。前者は、ARIN whoisごとに「example.com」が所有する/ 16ネットブロックのアドレス（複数のAレコード）にマッピングします。後者は、主要なCDNプロバイダーのドメイン内のCNAMEにマップします。CNAMEチェーンは、最終的にCDNプロバイダーのネットワークのIPアドレスにマッピングされます

— Binky

@Binky：それは、誤って設定されていないことを疑う正当な理由ではありません。大企業の無能は非常に一般的です。

— R ..

回答:

最も可能性の高い説明は、DNSに精通していないユーザーがDNSレコードを設定しようとし、DNSに精通している人には明白な間違いを犯したが、そうでない人には明らかではないことです。

DNSラベルは一般に任意のバイナリデータである可能性がありますが、特にセクション11の残りの部分を読む必要があります。

ただし、DNSデータを使用するさまざまなアプリケーションでは、環境で許容される特定の値に制限が課される場合があることに注意してください。たとえば、任意のバイナリラベルにMXレコードを含めることができるということは、任意のバイナリ名を電子メールアドレスのホスト部分として使用できることを意味するものではありません。DNSのクライアントは、DNSルックアップ要求のキーとして使用する値、およびDNSによって返される値に対して、状況に適した制限を課すことができます。クライアントにそのような制限がある場合、そのデータを使用する前にクライアントが準拠していることを確認するために、DNSからのデータを検証する責任があります。

とりわけ、これは、ラベルの構文がRRタイプに応じて制約される可能性があることを意味します。RFC 1123セクション2.1およびRFC 952で指定されているように、インターネットホスト名にはこのような制約構文があり、コロンとスラッシュは無効です。

— マイケル・ハンプトン
ソース

標準アドレスでは間違っていますが、帯域外通信デバイスとしてDNSを使用している可能性があります。

「通常の」チャネルではなくDNSを介してデータを渡す必要があることを想像するのは難しくありません。

— djsmiley2k-CoW
ソース

先に進んで想像してみてください。この答えは実際に何が起こっているのかを実際に言っているわけではありません-回答者はそれが論理的であると考えているだけです。

— サイブーグ

DNSを帯域外通信デバイスとして使用している可能性があります。 @ djsmiley2kこれらのAレコードを管理する組織は、実質的なセキュリティ/コンプライアンス要件を持つ企業であるため、元の投稿ではこの可能性について言及しませんでした。これらのレコードが帯域外アクセスメカニズムである可能性は非常に低く、レコードがOOBハックである場合、その影響は...恐ろしいものになります。

— ビンキー

@Blinkyは十分に公平です。この場合はほとんどありませんが、他の場合は可能性があります。

— djsmiley2k-CoW

これは確かに可能性のあることですが、DNSサイドチャネルは通常、ホスト名自体ではなく、TXTレコードのテキストを使用して行われます。さらに、「https：//」は暗号化されたテキストではなく、エラーのように見えます。

— クリギー