インターネット標準では、すべてのデバイスにリバースDNSが必要ですか？

逆引きDNSを取り巻く要件は混乱を招きます！逆引きDNSが存在しない場合、人々はすべてが壊れていると頻繁に話します。アプリケーションがリバースDNSを必要としない場合でも、必須のPTRレコード作成をサポートするためにRFCが頻繁に引用されています。

これらのRFCの一部は次のとおりです。

RFC1912：一般的なDNSの運用および構成エラー

すべてのインターネット到達可能なホストには名前が必要です。... PTRとAレコードが一致していることを確認します。すべてのIPアドレスについて、in-addr.arpaドメインに一致するPTRレコードが存在する必要があります。ホストがマルチホームの場合（複数のIPアドレス）、すべてのIPアドレスに（最初のIPアドレスだけでなく）対応するPTRレコードがあることを確認してください。一致するPTRレコードとAレコードがないと、DNSにまったく登録されていないのと同様に、インターネットサービスが失われる可能性があります。

RFC1033：ドメイン管理者操作ガイド

ホストを追加します。

 To add a new host to your zone files:

    Edit the appropriate zone file for the domain the host is in.

    Add an entry for each address of the host.

    Optionally add CNAME, HINFO, WKS, and MX records.

    Add the reverse IN-ADDR entry for each host address in the
    appropriate zone files for each network the host in on.

それにも関わらず、一部の人々は、PTRレコードの作成は DNS管理を管理する標準では必要ないと主張し続けています。実際の要件は何ですか？

短い答え

DNS運用を管理する標準では、すべてのデバイスに一致するPTRレコードが必要ですか？いや

特定のプロトコルの標準ではPTR、対応するレコードAまたはAAAAレコードと一致するレコードが必要ですか？はい。

RFCによって管理されていないアプリケーションにも同じ要件がありますか？はい。

PTR記録はCNAMEを指すことができますか？はい。ただし、CNAMEターゲットは、問題のデバイスの一意の名前でなければなりません（別のCNAMEではありません）。（RFC2181§10.2、RFC1034§3.6.2）

必須のPTRレコードの作成はベストプラクティスですか？一般的にそう信じられていますが、それはそれ自身の問題を持っています。

ロングアンサー

このQ＆Aには、よくある誤解を和らげることを目的としています。

悲劇的underquotedセクションRFC1796はここに適用されます。

RFCとしての公開がある程度の認識を提供するというのは、残念ながら広く誤解されています。それは、通常のジャーナルの出版物を超えないか、少なくともそれ以上です。実際、各RFCには、インターネット標準化プロセスとの関係に関して、情報、実験、または標準トラック（提案標準、ドラフト標準、インターネット標準）、または歴史的なステータスがあります。

RFC1912は情報です。RFC1033は明確にラベル付けされておらず、UNKNOWNの公式名称があります。つまり、非常に古いため、何の参照とも見なすべきではありません。標準を定義するものではなく、標準を公式に補強するために使用することもできません。それらは、標準を定義していることを意味する文脈で引用されるべきではありません。

Informational RFCの提案は、良いアドバイスであり、一般に受け入れられているベストプラクティスと考えてください。リバースDNSの推奨事項は一目で理解できます。これらのガイドラインに従うと、リバースDNSが必要であり、計画されていないためにアプリケーションが動作しなくなる状況に陥るリスクが低くなります。あなたは確かにDNS管理者がそれを必要とするすべてのアプリケーション/プロトコルを知ることを期待することはできず、悲しいことに同じことがそれらのレコードを要求するサービス所有者にも当てはまる傾向があります。

とはいえ、非常に優れた自動化以外では、必須のPTRレコード作成ポリシーも汚染を引き起こします。

• デバイスが廃止されると、レコードPTRが対応するA/ AAAAレコードと同期されないことが非常に一般的であり、結果としてPTR時間の経過とともに偽のデータがクリープします。このデータは、その情報を信頼できるものとして扱うことを試みる人々を誤解させるだけです。一部のアプリケーション所有者は、ファントムの問題の原因を探しているときに、それに飛び乗りたいと考えています。特にキャリアサイズのIPスペースを担当するDNS管理者にとって、IPv6の採用が一般的になるにつれて、問題は悪化し続けるだけです。
• 同じIPアドレスに対して複数のPTRレコードを持つことはほとんど役に立ちません。情報RFCのアドバイスに従うことは、必然的にこれをもたらします。参照：DNSの複数のPTRレコードが推奨されない理由

さらに悪いことに、PTRレコードがない、または不正確なPTRレコードがありますか？その標準が有効なDNSを必要とするためにプロトコルが壊れた場合、両方とも悪いものであり、後者は実際に悪い可能性があります。それ以外では、誰もがこの問題について異なる意見を持っています。それは結構です。チームと会社に最適なポリシーとツールを自由にまとめることができます。スケーリングと一貫性のある結果が得られることを確認し、リバースDNSはチームメンバーが与えなければならない時間と規律と同じくらい正確であることを忘れないでください。

しかし、PTRレコードがないと、sshdがハングします！

また、そうではありません。多くの場合、PTRレコード（NXDOMAIN）が存在しないことと、逆引きDNSが壊れていることの境界線を混同します。

の返信は、NXDOMAINフォワード確認リバースDNS（FCrDNS）を必要とするサービスと通信している場合にのみ問題を引き起こします。メールサーバー、Kerberos、OracleスキャンVIPなど

ブロークンリバースDNSはNXDOMAIN、タイムリーに応答を取得することが不可能な場合です。多くのアプリケーション（最も有名なsshd）は、アップストリームソースからの応答をタイムリーに取得する際に問題が発生し、アプリケーション内で遅延が発生すると、逆DNSルックアップをブロックします。