☰

systemd-resolvedは単一ラベルのDNSルックアップ要求をどのように処理しますか？

tag-icon • tag-icon dns systemd-networkd systemd-resolved
systemd-resolvedは単一ラベルのDNSルックアップ要求をどのように処理しますか？

私はsystemd-networkdとsystemd-resolvedを調べました。

私はいくつかの単語について混乱しています。

  • systemd-resolved.service(8)

    単一ラベル名は、LLMNRプロトコルを使用してIPマルチキャストが可能なすべてのローカルインターフェイスにルーティングされます。各インターフェイス ドメインの 1 つで終わるホスト名の検索は、一致するインターフェイスにのみルーティングされます。

  • システムネットワーク(5)

    「検索」ドメインと「パスのみ」ドメインの両方がDNSクエリルーティングに使用されます。これらのドメインで終わるホスト名（したがって、「検索ドメイン」がリストされている場合は単一のラベル名も含む）の検索は、次にルーティングされます。このインターフェイス用に設定されたDNSサーバー。

私の質問は：「検索ドメイン」で構成され、LLMNRが有効になっている多数のインターフェイスを持つホストの場合、単一ラベルのルックアップ要求はどこに行きますか？

私の混乱の詳細は次のとおりです。

  • インターフェイスが検索ドメイン「mydomain」として設定され、LLMNRが無効になっている場合、単一のラベル参照要求はこのインターフェイスにルーティングされますか？
  • インターフェイスが検索ドメイン "mydomain" で設定され、LLMNR がイネーブルになっていて "xyz" のルックアップ要求が入っている場合、LLMNR 経由の "xyz" と指定された DNS サーバ経由の "xyz.mydomain" の両方が発生しますか？

答え1

この質問は説明に時間がかかります。短く不正確な説明は次のとおりです。

単一ラベル検索リクエストはどこに行きますか？

シングルラベル？ （localhost他人を待たない）：常にLLMNRシステムに移動します。

タグが複数ありますか？ ：各インターフェイスのDNSサーバー。失敗すると（または設定されていない場合）、グローバルDNSサーバーに送信されます。

はい、一般的な順序は次のとおりです。systemd-resolved.service(8) しかし、:

パスルックアップは、各インターフェイスのドメイン名の設定によって影響を受ける可能性があります。バラよりシステムネットワーク(5)もっと学ぶ。

設定システムネットワーク(5)DNS検証のための追加リソースとして使用されます。

そして、これを知ってRFC 4795から:

LLMNRはローカルリンクでのみ機能するため、DNSを置き換えるとは見なされません。

順序（簡体）は次のとおりです。

  • ローカル、構成CPU名範囲でソートされたすべてのローカルに設定されたIPアドレス、または（設定されていない場合）IPv4アドレス127.0.0.2（ローカルループバックにある）とIPv6アドレス：：1（ローカルホスト）で解決されます。

  • ホスト名「localhost」および「localhost.localdomain」（および「.localhost」または「.localhost.localdomain」で終わるすべてのホスト名）は、IPアドレス127.0.0.1および::1で解決されます。

  • ホスト名「_gateway」は次のように解決されます。

  • /etc/hosts（前後）に定義されているマッピングが含まれています。

  • もし検索する名前にドットがありません。（ドットで区切られた名前に似ていますhome.）LLMNRプロトコルによって解析されます。

    LLMNRクエリはポート5355で送受信されます。 RFC 4795

  • 特定のドメイン拡張子（「.local」、完全な拡張子の一覧を参照）を含む複数単語（1つ以上のドット）名は、systemd-resolve --statusMulticastDNSプロトコルを介して解決されます。

  • Domains=リストと複数の単語で構成される名前解決システムネットワーク(5) インターフェイスごと一致するものがあれば、DNS サーバーのリストを表示します。それインターフェイスが使用されます。

  • 他のマルチラベル名は、設定されたDNSサーバーを持つすべてのローカルインターフェイスとグローバルに設定されたDNSサーバー（存在する場合）にルーティングされます。

#編集

あなたの質問のタイトルは次のとおりです。

systemd-resolvedは単一ラベルのDNSルックアップ要求をどのように処理しますか？

したがって、私の答えはsystemd-resolved専門的な質問に焦点を当てています。

今あなたは尋ねます：

  1. インターフェイスが検索ドメイン「mydomain」として設定され、LLMNRが無効になっている場合、単一のラベル参照要求はそのインターフェイスにルーティングされますか？

  2. インターフェイスが検索ドメイン "mydomain" で設定され、LLMNR がイネーブルになっていて "xyz" のルックアップ要求が入っている場合、LLMNR 経由の "xyz" と指定された DNS サーバ経由の "xyz.mydomain" の両方が発生しますか？

systemd-resolvedこれは排他的範囲内にないようです。

それらを分析しましょう：

  • LLMNRが無効になっていますか？どのように？尋ねてもいいですか？渡すsystemd-resolved自己無効化似たようなものsystemctl mask systemd-resolved？

systemd-resolved無効/停止した場合なしLLMNR使用していますが（Avahi、Apple Bonjour、または同様のものをインストールしない限り）、確かにこれはsystemd-resolved設定範囲外です。

この場合、次の質問を投げる必要があります。名前解決に失敗した場合はどうなりますか？ （サーバーが応答できないからです。）で構成nsswitch（文書/etc/nsswitch.conf）。 Ubuntu（Debianなど）のデフォルト設定には次の行が含まれています。

hosts:          files mdns4_minimal [NOTFOUND=return] dns myhostname

それ方法（nsswitchの言葉によると）：

  1. まずファイルを確認してください/etc/hosts。見つからない場合は続行してください。

  2. 努力するmdns4_minimal（Awashiet al。）、名前が.localで終わる場合にのみマルチキャストDNSを介して名前を解決しようとします。そのようなmDNSホストが存在するが見つからない場合、mdns4_minimalはNOTFOUNDを返します。 NOTFOUNDのデフォルトのネームサービス切り替え応答は、次にリストされているサービスを試みますが、[NOTFOUND = return]エントリはそれを上書きし、名前が解決されずに検索を停止します。 mdns4_minimalがUNAVAIL（実行中ではない）を返すと、dnsに移動します。

プロットが厚くなるみんなになりたい名前リストの最初の名前を解決してください。各人は、すべての決議を自分で完了することを提案します。

  1. dnsアイテムnsswitch 実際nss-resolveに最初に電話してくださいnss-dnsを置き換えます。

    nss-resolveは、GNU Cライブラリ（glibc）のGNUネームサービス切り替え（NSS）機能用のプラグインモジュールで、systemd-resolved（8）ローカルネットワーク名解決サービスを介してホスト名を解決できます。これは伝統的に、DNSを介してホスト名を解決するnss-dnsプラグインモジュールを置き換えます。

    これは通常、ファイル内のDOMAINS=いくつかの項目/etc/systemd/resolved.confおよび/または各インタフェースによって異なります。/etc/systemd/network上記ですでに説明しました。編集する入り口。

    sytemd-resolvedがnsswitchのdnsエントリの前にDNSサーバー自体を照会できることを理解してください。

  2. まだ見つからない場合（[notfound=return]エントリなし）、DNSサーバーが試行されます。名前が.localで終わらないと、この現象はほとんどすぐに発生し、そうであればまったく発生しません。 [NOTFOUND = return]エントリを削除すると、nsswitchはユニキャストDNSを介して未解決の.localホストを見つけようとします。これは、ほとんどの要求を決して解決できないインターネットDNSサーバーに送信するため、一般的に悪いことです。明らかに、これはかなり頻繁に発生します。

  3. myhostname最終最後の措置localhost、ホスト名、* .local、およびその他のデフォルト名のリゾルバーです。

もしsystemd-resolvedLLMNR=no一つある/etc/systemd/resolved.conf上記と同じリストにありますが、systemd-resolved設定を解析して適用することもlocalhostできますDOMAINS=（グローバルまたはインターフェイス固有）。

明らかsystemd-resolvedにはLLMNR設定があり、systemd-networkdにはリンク固有のLLMNR設定があります。 協会。

＃これはどういう意味ですか？構成が非常に具体的でないと、何が起こるかを判断するのは困難です。サービスを無効にし、何が起こるのか（あなたの設定があるコンピュータで）試してください。

#Q1

インターフェイスが検索ドメイン「mydomain」として設定され、LLMNRが無効になっている場合、単一のラベル参照要求はそのインターフェイスにルーティングされますか？

うん、もちろんです。可能。 LLMNRを無効にすると、ローカル解析のみが防止されます（他のサーバーはローカルで使用できません（例: .local）ネットワークに質問が表示されますが、名前解決者は（負の数でも）答えを見つける必要があります。可能（ない場合見つかりません=返品たとえば、mylocalhost.mylocaldomain確認が開始されると、一致するインターフェイスのDNSサーバーに確認用に接続し、検索ドメインにエントリがあり、一致するインターフェイスのmylocalhostDNSサーバーに確認用に接続します。mylocaldomain回答一般的な意味がほとんど不可能で変数が多すぎます。

#第2四半期

インターフェイスが検索ドメイン "mydomain" で設定され、LLMNR がイネーブルになっていて "xyz" のルックアップ要求が入っている場合、LLMNR 経由の "xyz" と指定された DNS サーバ経由の "xyz.mydomain" の両方が発生しますか？

いいえ。すべてが正しく設定されている場合単一のラベル名「xyz」はLLMNRでのみ解決でき、要求があってもDNSサーバーはそれを解決しようとしないでください。まあ、それは理論です。しかし、DNSシステムは〜しなければならない解決されましたcom（明らかにそうでなければ、ネットワークは今のようにダウンします）。しかし、簡単に解決できる方法があります。 Ask com.、点があり、FQDNです。いずれにせよ、NOERRORサーバーにラベルに関する情報が不足していてルートサーバーで確認を続行する必要がある場合（その場合.）、DNSサーバーは空のA（またはAAAA）で応答する必要があります。または、存在しないドメインを処理するには、NXDOMAIN（追加の解析を避けるための最良の回答）を使用してください。

これを制御する唯一の安全な方法は、ローカルDNSサーバーを保持し、解決する名前と解決しない名前を選択することです。

答え2

LLMNRとDNSを使用してこれらのすべての応答にルーティングし、受信した最初の応答を使用します。

システムの構文解析については、マンページの次のセクションを参照してください。

ルックアップが複数のインターフェイスにルーティングされる場合、最初の成功した応答が返されます。したがって、一致するすべてのインターフェイスのルックアップ領域が効果的にマージされます。すべてのインターフェイスでルックアップが失敗すると、最後に失敗した応答が返されます。

関連情報