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つは忘れました）。これら二つはどういう意味ですか？
答え1
人々がよく間違っている混乱した名前。
側からRFC 1034、「レゾルバ」と「ネームサーバ」があります。 「パーサー」の説明完全サブシステムユーザプログラムは、特定のアーキテクチャに関係なく「ネームサーバ」にアクセスするために使用される。これは、公開されたデータに対して1つ以上の「ネームサーバー」を照会し、以下に説明する方法でこのデータを照会アプリケーションへの最終回答にリンクするサブシステムです。RFC 1034§5.3.3。 「パーサー」は包括的なクエリを実行するサブシステム解決する。
RFCは理論的にこれを可能にします。Unix中心ではない、すべてのクエリ解析メカニズムが、個々のアプリケーション内で実行される一種の共有サブシステムとして存在できるシステムです。
RFC 1034の用語では、「スタブリゾルバ」はUnixおよびLinuxの世界で一般的に使用されています。アプリケーションプロセス内で実行されるやや愚かなDNSクライアントライブラリで、同じDNS / UDPプロトコルとDNS / TCPプロトコルで実行されている外部プログラムと通信します。バックエンドトランザクションを取得してフロントエンドレスポンスを構築することで、クエリの解析を実際に実行するもう1つのプロセスです。
「Resolver」は非常に混乱する用語であり、しばしばRFCに反して使用されます。それで数年前、私はHTTPで借りた用語を使って人々にDNSを説明し始めました。プロキシサーバー、コンテンツサーバーと顧客データベースアプリケーションリンク。
- これDNSクライアントライブラリお申し込みにはほぼ常にISCのBIND DNSクライアントライブラリです。 UnixおよびLinuxシステムのほとんどのCライブラリには、BIND DNSクライアントライブラリが含まれています。ただし、他の複数のDNSクライアントライブラリが存在し、一部のアプリケーションで使用されます。
DNSクライアントライブラリは名前を修飾し、追加資料に記載されている方法で通信するDNSプロキシサーバーを見つけます。
- 初期のDNSプロキシサーバーこの特定の設定では、
systemd-resolved127.0.0.53を受け取ります。これを行う他のUnixおよびLinuxソフトウェアには、Daniel J. Bernsteinの
dnscachePowerDNS Recursor、MaraDNS Recursor（「Deadwood」）などがあります。unbounddnsmasq個人的にローカルインスタンスがあります修正済み
dnscache（受信ソケットを継承できます）127.0.0.1を受け取るすべてのコンピュータでは、BIND DNSクライアントライブラリが明示的な構成なしでプロキシDNSサーバーが配置されると予想されるデフォルトの場所でもあります。 systemd-resolved他のプロキシサーバーと通信する可能性が最も高い他のプロキシDNSサーバーと通信します。今後クエリが到達するまでチェーンに従います。解決するプロキシサーバー。- 基本的に、システム化された人が何かをリリースしたときバイナリパッケージを作成した人やローカルシステム管理者がそれを変更しない限り、確認プロキシDNSサーバーはGoogle Public DNSの一部としてGoogleが運営するサーバーになります。フォワードプロキシDNSサーバー長さは1です。
- システム管理者がGoogle以外のプロキシDNSサーバーを使用するように設定した場合、
systemd-resolvedチェーンは長くなります。このような構成の例には、LAN でローカルに検証されたプロキシ DNS サーバーを使用する、LAN エッジのルーター/ゲートウェイで実行されるプロキシ DNS サーバーを使用する、またはサードパーティのプロキシ DNS を使用する (ほぼ最高から最悪の順序まで)。 。インターネットプロキシDNSサーバー経由のサーバー。 - これプロキシDNSサーバーの確認チェーンの終わりにクエリの解析やクエリなどの重い操作を実行します。コンテンツDNSサーバーデータは必要に応じて結合され、最終応答を形成し、プロキシDNSサーバーチェーン（チェーン
systemd-resolvedの近い端を含む）に沿ってアプリケーションのDNSクライアントライブラリに返されます。
対照的に、RFC 1034の用語では、ここの「確認者」は実際にはBIND DNSクライアントライブラリであるsystemd-resolvedGoogle Public DNSを含む巨大なブラックボックスであり、RFCでは片側に「ユーザープログラム」があると定義します。コンテンツDNSサーバー（参照とデータベース情報を「直接」提供）人々はしばしばこの用語を誤用します。しかし、それはRFC 1034アーキテクチャの中立的な「パーサー」の概念を誤解して単一のUnixまたはLinuxサーバープログラムと同じであると思うので、実際にはそうではありません。 HTTP用語には巨大なブラックボックスはありません。
追加読書
- ジョナサン・ドボイン・ポラード（2000）。「コンテンツ」と「プロキシ」DNSサーバー。 よく与えられる答えです。
- ジョナサンデボインポラード（2004）。DNSクエリ解決とは何ですか？ 。よく与えられる答えです。
- ジョナサンデボインポラード（2017）。DNS名の資格とは何ですか？。よく与えられる答えです。
- ジョナサンデボインポラード（2003）。プロキシDNSサービスを受けることができる場所。よく与えられる答えです。
- ジョナサンデボインポラード（2018）。 」、および
dnscacheサービスtinydnsaxfrdns」。スナックガイド。ソフトウェア。 - https://unix.stackexchange.com/a/449092/5132
答え2
systemd-resolvedが含まれている限り、「stub-resolver」はすべてのDNS解決を実行しません（つまり、ルートDNSサーバー - > tld / gtldネームサーバー - >特権ネームサーバーに接続しません）。代わりに、名前解決のために別のリゾルバ（通常はネットワークインターフェイス設定を介して設定されます。たとえば、8.8.8.8または1.1.1.1またはISPで提供されます）に接続します。
その目的は、各プログラム/クライアントがリゾルバーを直接照会するのではなく、結果をキャッシュできるスタブリゾルバーを照会することで、フルネーム解決プロセスをスピードアップできることです。いくつかの追加の利点があります。
パーサーと多少似ているのでスタブと呼びますが、技術的にはすべての機能が欠けているのでパーサーではありません。