web-dev-qa-db-ja.com

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

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

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

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

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

RFC10 ：DOMAIN ADMINISTRATORS OPERATIONS GUIDE

ホストの追加。

 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管理を規定する標準では必要とされないと主張する人々もいます。実際の要件は何ですか？

domain-name-systemreverse-dnsfcrdns
25
Andrew B

短い答え

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

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

RFCに準拠していない一部のアプリケーションに同じ要件がありますか？はい。

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

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

長い答え

このQ＆Aは、よくある誤解を和らげるのを助ける目的で提供されています。

RFC1796 の悲劇的に引用符で囲まれたセクションがここに適用されます。

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

RFC1912は情報提供です。 RFC1033は明確にラベル付けされておらず、公式に [〜＃〜] unknown [〜＃〜] と指定されています。これは、古すぎて 何かの参照と見なすべきではありません 。それらは標準を定義しておらず、標準を公式に補強するために使用することもできません。 それらは標準を定義していることを意味する文脈では決して引用されるべきではありません。

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

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

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

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

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

また、真実ではありません。 PTRレコードがないこと（NXDOMAIN）とbroken逆引きDNSの間の境界線を混乱させることがよくあります。

NXDOMAINの応答は、前方確認済み逆引きDNS（FCrDNS）を必要とするサービスと通信している場合にのみ問題を引き起こします。メールサーバー、Kerberos、OracleスキャンVIPなど.

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

35
Andrew B