web-dev-qa-db-ja.com

DNSサーバー、リゾルバー、スタブリゾルバーとは何ですか？

https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html#Description は言う

さらに、systemd-resolvedは、ローカルループバックインターフェースのIPアドレス127.0.0.53にローカルDNSスタブリスナーを提供します。ローカルAPIをバイパスしてDNS要求を直接発行するプログラムは、systemd-resolvedに接続するために、このスタブに送られます。

`/ etc/resolv.conf`の形式をどのように理解すればよいですか？ は言う

dNSサーバーとリゾルバー（「スタブリゾルバー」）は異なる場合があります。DNS要求を127.0.0.53に渡し、ルーターに実際のDNSを渡すことができます（たとえば、ローカルホストは処理できますが、完全なDNSのリモートホストの要求を渡すことができます） ）。

DNSサーバー、リゾルバー、スタブリゾルバーとは何ですか？

2種類のDNSサーバー（1つは「リゾルバー」と呼ばれ、もう1つは忘れた）についても耳にしました。 2つの種類はどういう意味ですか？

dnsterminologysystemd-resolved
3
Tim

人々がよく間違える、紛らわしい名前。

RFC 1034 の用語には、「リゾルバ」と「ネームサーバー」があります。 「リゾルバー」はサブシステム全体を記述します。特定のアーキテクチャーに関係なく、ユーザープログラムが「ネームサーバー」にアクセスするために使用します。 RFC 1034§5.3. で説明されている方法で、1つまたは複数の「ネームサーバー」がパブリッシュするデータについてクエリし、それらのデータからクエリアプリケーションの最終的な回答をまとめるのはサブシステムです。 。 「リゾルバー」は、クエリを行うoverallサブシステムresolutionです。

RFCは理論的にはnix中心になることを意図していないので、すべてのクエリ解決メカニズムが潜在的に個々のアプリケーションプログラム内で実行される共有サブシステムの形式であるシステムを許可します。

RFC 1034の用語​​では、「スタブリゾルバ」は、UnixおよびLinuxの世界で一般的に採用されているものです。アプリケーションプロセスで実行されているかなりダムのDNSクライアントライブラリが、実行中の外部プログラムと同じDNS/UDPおよびDNS/TCPプロトコルと通信します。別のプロセスとして、これは実際に、バックエンドトランザクションを作成し、それらからフロントエンドレスポンスを構築することにより、クエリ解決の面倒な作業を行います。

「リゾルバー」は、このような混乱を招く用語であり、RFCとは対照的に頻繁に使用されます。その数年前、HTTPから借用した用語を使用して人々にDNSを説明しました：プロキシサーバー、コンテンツサーバー、およびクライアントライブラリアプリケーションにリンクされます。

  • アプリケーションのDNSクライアントライブラリはalmostであり、常にISCのBIND DNSクライアントライブラリになります。 UnixおよびLinuxシステムのほとんどのCライブラリには、BIND DNSクライアントライブラリが組み込まれています。ただし、他にもいくつかのDNSクライアントライブラリが存在し、少数のアプリケーションが代わりにそれらを使用しています。

    DNSクライアントライブラリは、名前の修飾を行い、さらに読む際に説明されている方法で、どのDNSプロキシサーバーと通信するかを調べます。

  • 最初のDNSプロキシサーバーは、この特定のセットアップでは、systemd-resolvedが127.0.0.53でリッスンしています。

    この役割を実行する他のUnixおよびLinuxソフトウェアには、Daniel J. Bernsteinのdnscache、unbound、dnsmasq、PowerDNS Recursor、MaraDNS Recursor（ "Deadwood"）などがあります。前方へ。

    私は個人的に、127.0.0.1でリッスンしているすべてのマシンに 変更されたdnscache （リスニングソケットを継承できる）のローカルインスタンスを持っています。これは、BIND DNSクライアントライブラリのデフォルトの場所でもあります。明示的な構成がない場合、プロキシDNSサーバーが存在することを期待します。

  • systemd-resolvedは他のプロキシDNSサーバーと通信しますが、さらに他のプロキシサーバーと通信する可能性がありますforwardingクエリがresolvingプロキシサーバーに到達するまでチェーンに沿ってクエリ。
    • デフォルトでは、 systemdのユーザーが物を出荷するため であり、バイナリパッケージを作成した人またはローカルシステム管理者が変更しない限り、解決プロキシDNSサーバーは、GoogleがGoogle Publicの一部として実行するサーバーになりますDNS、および転送プロキシDNSサーバー長さ1のチェーンが存在します。
    • システム管理者がGoogleの代わりに他のプロキシDNSサーバーを使用するようにsystemd-resolvedを設定している場合、チェーンは長くなります。そのような構成の例としては、LAN上のローカル解決プロキシDNSサーバーの使用、LANのエッジにあるルーター/ゲートウェイで実行されているプロキシDNSサーバーの使用、またはLANの使用などがあります。インターネット全体に公開されているサードパーティのプロキシDNSサーバー。
  • 解決するプロキシDNSサーバーチェーンの遠端にあるクエリ解決の大まかな作業を行い、必要に応じて、世界中のコンテンツDNSサーバーをクエリして、データを結合します。最終的な回答を形成し、プロキシDNSサーバーのチェーンに沿って、そのチェーンの近端にあるsystemd-resolvedを含めて、アプリケーションのDNSクライアントライブラリに返します。

対照的に、RFC 1034用語では、ここでの「リゾルバー」は実際には、BIND DNSクライアントライブラリ、systemd-resolved、およびGoogle Public DNSを含む巨大なブラックボックスです。 "一方の側にコンテンツDNSサーバー（紹介とデータベース情報を「直接」提供）をもう一方の側に。 RFC 1034アーキテクチャーに依存しない「リゾルバー」の概念が1つの単一のUnixまたはLinuxサーバープログラムと同じであると誤解しているために、この用語を誤用することがよくあります。 HTTP用語には、大きなブラックボックスはありません。

参考文献

7
JdeBP