web-dev-qa-db-ja.com

グルーレコードは、再帰リゾルバによってキャッシュされますか？

グルーレコードからの信頼できるネームサーバーのIPアドレスは、再帰リゾルバによってキャッシュされますか？
トップレベルドメインのネームサーバーには、ドメイン名の委任と共に接着剤が含まれています。
では、再帰リゾルバはこの「A」/「AAAA」レコード（グルーレコード）をキャッシュしますか？キャッシュが適用されるのは、応答が「権限のある」ネームサーバーから送信された場合のみですが、TLDネームサーバーはさらに委任し、権限があるとは見なされません。
または
権限のあるネームサーバーは、独自のIPアドレスをAレコードとして（ドメインのAレコードとともに）提供しますか？これは、再帰リゾルバーによってキャッシュされるものですか？

domain-name-systemsubdomaindns-zonedomain-namedns-hosting
1
Abhishek Palakkal Kaliyath

通常、グルーレコードは信頼できる回答としては与えられません。フラグ（aaの有無を確認すると、気づくかもしれません）（= /// =）Authoritative Answer ; RFC 1035、4.1.1 ）例次のクエリのうち：

  • 親に対する権限：

    Dig com NS @f.gtld-servers.net
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27

  • コントロールの削除。両方とも、追加セクションにグルーレコードを提供します。

    Dig google.com NS @f.gtld-servers.net
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9

Dig ns1.google.com A @f.gtld-servers.net
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9

  • 信頼できるサーバーからの信頼できる応答：

    Dig google.com NS @ns1.google.com
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 9

Dig ns1.google.com A @ns1.google.com
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

RFC 1034、5.3. の基本的なアルゴリズムは、ほとんどの応答データをキャッシュします;失敗と他の奇妙な内容（d）のみが無視されます（強調は私のものです）：

  • a。応答が質問に答えるか、名前エラーが含まれている場合は、データをキャッシュし、それをクライアントに返します。

  • b。応答に他のサーバーへのより適切な委任が含まれている場合、委任情報をキャッシュし、ステップ2に進みます。

  • c。応答がCNAMEを示し、それ自体が回答ではない場合、CNAMEをキャッシュします、SNAMEをCNAME RRの正規名に変更して、ステップ1。

  • d。応答がサーバー障害またはその他の奇妙なコンテンツを示している場合は、サーバーをSLISTから削除して、ステップ3に戻ります。

RFCはまた、一部の実装では、キャッシュされたデータを無視して権限のあるサーバーに問い合わせるようにリゾルバーに強制するオプションがある可能性があることにも言及しています。実際に何が起こるかは実装に依存します。 Kudelski Security Researchの DNSがインターネットを殺す方法 によれば、

意図しない誤った応答を引き起こす可能性のあるバグのほかに、キャッシュポイズニング（ Dan Kaminskyの2008 DNS脆弱性 および DNSキャッシュポイズニングへのヒッチハイカーガイド を参照）を考慮する必要があります。多くのDNSキャッシュ実装は、グルーレコードを通常のレコードとしてキャッシュするため、DNSサーバーが悪意のある応答を提供し、その結果、キャッシュに誤ったエントリが含まれる可能性があります。

例えば：

evil.com.       IN NS ns.company.com.
ns.company.com. IN A 6.6.6.6

正当なサーバーが言う間

company.com.    IN NS ns.company.com.
ns.company.com. IN A 1.2.3.4

したがって、誤ったIPアドレスは、レコードの存続期間中、キャッシュに入れられます。この問題を回避するために、ほとんどのキャッシングリゾルバー実装では、アウトオブバイリウィックNSレコードのオプションの接着レコードを信頼せず無視するため、上記の例ではns.company.com. IN A 6.6.6.6を無視します。 DNS管理者への注意：バイリウィック内のレコードのみを保持することをお勧めします。

回答が信頼できるものであるかどうかは、それ自体がレコードをキャッシュする必要があるかどうかを示すものではありません。

  • 上位のネームサーバーは、同じ信頼できるネームサーバー構造の一部です。したがって、彼らはサブドメインの制御を委任する、つまり最終的には信頼できる人に応答できる人を制御できるので、彼らは信頼され、信頼できるはずです。通常、グルーレコードはゾーン自体のレコードと一致する必要があり、その他はすべてIANAごとの構成エラーになります 信頼できるネームサーバーの技術要件 ：

    接着剤と信頼できるデータ間の整合性

    グルーとしてIPアドレスがリストされているネームサーバーの場合、IPアドレスはそのホストの信頼できるAおよびAAAAレコードと一致する必要があります。

    委任とゾーン間の整合性

    権限のあるネームサーバーによって提供されるNSレコードのセットは、親ゾーンの委任用に提案されたものと一致する必要があります。

  • すべての再帰サーバーがルートネームサーバーから名前の解決を開始するわけではありませんが、より複雑な再帰インフラストラクチャもあります。リゾルバーには、forwarders、つまり権威ネームサーバーの代わりに要求する他の再帰ネームサーバーを含めることができます。これらの応答は信頼できるものではありませんが、常にキャッシュされます。

  • DNSキャッシュポイズニングシナリオでは、加害者は信頼できるネームサーバーではありませんが、信頼できるソースサーバーであるかフォワーダーであるかに関係なく、信頼できるソースからのなりすましです。 DNSはUDPを使用するため、応答のなりすましがより簡単になります。これに対するいくつかの解決策があります：

    • 最大UDP応答サイズ。応答がそれよりも大きい場合、つまり単一のUDPパケットよりも大きい場合、DNSはTCPを使用します。追加のセクションがあるため、接着剤レコードを含む応答は簡単にその境界を越えます。 TCP接続は、MitMの位置を必要とするため、なりすましは簡単ではありません。

    • DNSSEC検証。スプーフィングされた応答では、レコードのDNSSECシグニチャーを一致させることができないため、それらはキャッシュされません。

    • 暗号化DNS。 DNS over TLS（ RFC 7858 ）とDNS over HTTPS（ RFC 8484 ）の2つの標準があります。

2
Esa Jokinen