DNSクライアントはDNSメッセージの圧縮（ポインタがラベル名ではなく他のポインタを指すことがある）について心配する必要がありますか？そうすることは明らかですが、私が言及しているRFCではこれについて言及していません。
DNS rfc1035から：
圧縮方式を使用すると、メッセージのドメイン名を次のように表現できます。
0オクテットで終わるタグシーケンス
ポインタ
ポインタで終わる一連のタグ
DNSクライアントはサーバー応答でこれらの動作を予想できますか？
答え1
はい、できます。
関連する DNS 標準でこれを許可しないエントリが見つからなかったため、それを取得したらデコードできる必要があります。メッセージ圧縮の定義RFC 1035 4.1.4説明する：
この方法では、ドメイン名全体またはドメイン名の末尾にあるタグのリストが、同じ名前の以前の出現を指すポインタに置き換えられます。
これには、このケースが文字通りのタグリストであることを提案するものはありません。 「ネイキッドポインタ」は、「ポインタで終わるタグのリスト」の特別なケースに過ぎず、それをデコードするのに追加の複雑さは必要ありません。
ポインタを生成する理由はなく、コーディングを複雑にするため、ポインタへのポインタは実際にはまれです。しかし、仕様に関する限り、完全に有効なようです。
答え2
いいえ（理論的には可能ですが、実際には何でも起こります）
驚くべきことに、その答えは別のRFCにあると思います。
RFC 2929：DNS（ドメインネームシステム）IANAに関する考慮事項
セクション3.3では、次のように言います。
現在のタグには、データタグと圧縮タグの2種類があります。圧縮タグは、
NAMEの行エンコーディングを短縮するためのRRまたはDNSメッセージの他の場所にあるデータタグへのポインタです。
特に、圧縮タグがデータタグへのポインタであることに注意してください。圧縮タグが他の圧縮タグへのポインタになる可能性があるとは言わないので、仕様にポインタケースがないと思います。
コメントで説明したように、仕様にはこの状況が禁止されているとは記載されていませんが、禁止される可能性がある他のすべての項目はリストされていません。彼らは何が許され、他のすべてが許されてはならないかを教えてくれます。したがって、私は「仕様で明示的に禁止されていないので許可されています」という主張とそれから導出された結論を使用して@TooTeaの答えに同意しません。
これに基づいてDNS仕様に準拠すると主張するには、ポインタが他のポインタを指してはいけませんが、同時に未知の受信メッセージを処理する必要がある場合は、次のリスクから自分自身を保護する必要があるという結論に達しました。そのようなイベントは、他のイベント（転送ポインタなど）に影響を与え、受け入れるか拒否するかを決定します。
フォステルの法則によれば、受け入れるほうが良いと思うかもしれませんが、この情報に適応しようとするよりも置いておく方が良いと思います。その理由は次のとおりです。
- 上記のように、このような状況は仕様に記載されていないため、「発生してはならない」ということです。
- 私はこれが野生ではまれであると予想しています（しかし、私は次のポイントのために何の証拠も持っていません）。
- これが発生した場合、送信者の圧縮アルゴリズムが悪いという意味になる可能性があるため、この欠陥のあるソフトウェアを補償しようとする必要はありません。
XがYを指し、YがZを指している場合、XがZを指すようにしておくのはどうでしょうか？ 「中間」ポインタがある場合、アドインは提供されないため、存在する理由はありません（バグと無効な実装を除く）。