「Systemd-resolved」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
 
(2人の利用者による、間の3版が非表示)
1行目: 1行目:
 
{{Lowercase title}}
  
{{Lowercase title}}
−
[[Category:Domain Name System]]
 +
[[Category:ドメインネームシステム]]
−
[[Category:マルチキャスト DNS]]
  
 
[[en:Systemd-resolved]]
  
[[en:Systemd-resolved]]
 
[[de:Systemd/systemd-resolved]]
  
[[de:Systemd/systemd-resolved]]
68行目: 67行目:
 
{{Note|
  
{{Note|
 
* {{man|5|resolved.conf}} の {{ic|1=Domains=~.}} オプションがないと、リンク単位の設定で {{ic|1=Domains=~.}} を設定している DNS サーバがあれば、''systemd-resolved'' はそれを使う可能性があります。
  
* {{man|5|resolved.conf}} の {{ic|1=Domains=~.}} オプションがないと、リンク単位の設定で {{ic|1=Domains=~.}} を設定している DNS サーバがあれば、''systemd-resolved'' はそれを使う可能性があります。
−
* このオプションは、リンクごとの設定で指定されたより詳細な検索ドメインに一致するドメイン名の検索には影響しません。リンク単位の設定について詳しくは [[systemd-networkd#network files]] を参照してください。
 +
* このオプションは、リンクごとの設定で指定されたより詳細な検索ドメインに一致するドメイン名の検索には影響しません。リンク単位の設定について詳しくは [[systemd-networkd#network ファイル]] を参照してください。
 
}}
  
}}
   
184行目: 183行目:
 
LLMNR と[[ファイアウォール]]を使う場合、UDP と TCP のポート {{ic|5355}} を開いてください。
  
LLMNR と[[ファイアウォール]]を使う場合、UDP と TCP のポート {{ic|5355}} を開いてください。
   
−
== 検索 ==
 +
== ルックアップ ==
   
 
DNS レコードや mDNS あるいは LLMNR ホストを問い合わせるには ''resolvectl'' ユーティリティを使います。
  
DNS レコードや mDNS あるいは LLMNR ホストを問い合わせるには ''resolvectl'' ユーティリティを使います。
197行目: 196行目:
 
-- Data is authenticated: no
  
-- Data is authenticated: no
 
}}
  
}}
−  
−
{{man|1|resolvectl|EXAMPLES}} には他の例が存在します。
  
   
 
== トラブルシューティング ==
  
== トラブルシューティング ==

2024年8月15日 (木) 13:40時点における最新版

関連記事

systemd-resolved は D-Bus インターフェイスと resolve NSS サービス (nss-resolve(8))、127.0.0.53 のローカル DNS スタブリスナによるネットワーク名前解決をローカルアプリケーションに提供する systemd サービスです。使用方法については systemd-resolved(8) を見てください。

インストール

systemd-resolved はデフォルトでインストールされる systemd パッケージの一部です。

設定

systemd-resolved は Domain Name System (DNS) (DNSSEC と DNS over TLS を含む) と Multicast DNS (mDNS) そして Link-Local Multicast Name Resolution (LLMNR) のリゾルバサービスを提供します。

リゾルバは /etc/systemd/resolved.conf を編集するか、あるいは /etc/systemd/resolved.conf.d/ 中のドロップイン .conf ファイルで設定できます。resolved.conf(5) を参照してください。

systemd-resolved を使うには systemd-resolved.service を起動・有効化してください。

ヒント: systemd#特定のサービスの問題を診断に書かれているようにして systemd-resolved のデバッグ情報を有効にすることで、挙動を理解することができます。

DNS

glibc の getaddrinfo(3) (または同等のもの)に依存するソフトウェアは、デフォルトで nss-resolve(8) が使用可能な場合、/etc/nsswitch.conf を使用するように設定されているため、そのまま使用できます。

ウェブブラウザ や GnuPG など、/etc/resolv.conf を直接読み取るソフトウェアにドメイン名前解決を提供するために、systemd-resolved にはファイルを処理するための 4 つの異なるモード( スタブ、スタティック、アップリンク そしてフォーリン )があります。それらは、systemd-resolved(8) § /ETC/RESOLV.CONF で説明されています。ここでは推奨モード、すなわち、/run/systemd/resolve/stub-resolv.conf を使用するスタブモードにのみ注目します。

/run/systemd/resolve/stub-resolv.conf には唯一の DNS サーバとしてのローカルスタブ 127.0.0.53 と検索ドメインのリストが含まれています。これは、systemd-resolved で管理された設定をすべてのクライアントに伝達する推奨の操作モードです。これを使用するには、/etc/resolv.conf をそのシンボリックリンクに置き換えます。 

# ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
ノート:
  • /etc/resolv.conf を正しく設定しないと、DNS の解決に支障をきたすことになります。
  • このファイルは外部のシステムからバインドマウントされるので、arch-chroot の中では /etc/resolv.conf シンボリックリンクを作成することはできません。代わりに、chroot の外からシンボリックリンクを作成します。例: 
    # ln -sf /run/systemd/resolve/stub-resolv.conf /mnt/etc/resolv.conf

DNS サーバーの設定

ヒント: systemd-resolved によって DNS が使われているかチェックするには、resolvectl status を実行します
自動

systemd-resolved は /etc/resolv.conf によってネットワークマネージャでは自動的に使用されます。systemd-resolved は /etc/resolv.conf シンボリックリンクで認識されるため特に設定は必要ありません。systemd-networkd や NetworkManager がその場合に該当します。

ただし DHCP や VPN クライアントが resolvconf プログラムを使用して名前サーバーや検索ドメインを設定する場合 (resolvconf を使用するソフトウェアの一覧については openresolv#使用プログラムを見てください)、/usr/bin/resolvconf シンボリックリンクを作るために追加パッケージ systemd-resolvconf が必要です。

ノート:
  • systemd-resolved の resolvconf インターフェイスには制限がありクライアントによっては動作しない可能性があります。詳しくは resolvectl(1) § COMPATIBILITY WITH RESOLVCONF(8) を参照。
  • systemd-resolvconf は systemd-resolved.service が実行されている場合のみ機能します。systemd-resolved を使用していない場合は、systemd-resolvconf パッケージがアンインストールされている事を確認してください。そうでない場合、/usr/bin/resolvconf バイナリを期待するネットワークソフトウェアで問題が発生します。
手動

スタブモードとスタティックモードでは、カスタム DNS サーバを resolved.conf(5) ファイルで設定できます。 

/etc/systemd/resolved.conf.d/dns_servers.conf
[Resolve]
DNS=192.168.35.1 fd7b:d0bd:7a6e::1
Domains=~.
ノート:
  • resolved.conf(5) の Domains=~. オプションがないと、リンク単位の設定で Domains=~. を設定している DNS サーバがあれば、systemd-resolved はそれを使う可能性があります。
  • このオプションは、リンクごとの設定で指定されたより詳細な検索ドメインに一致するドメイン名の検索には影響しません。リンク単位の設定について詳しくは systemd-networkd#network ファイル を参照してください。
フォールバック

systemd-resolved がネットワークマネージャから DNS サーバーアドレスを受信できず手動でも DNS サーバーが設定されていない場合、DNS 解決が常に機能するように systemd-resolved はフォールバック DNS アドレスにフォールバックします。

ノート: フォールバック DNS は次の順番で使われます: Cloudflare, Quad9 (フィルタリングや DNSSEC なし), Google。サーバーがどこに定義されているかどうかは systemd の PKGBUILD を見てください。

resolved.conf(5) で FallbackDNS= を設定することでフォールバックのアドレスは変更できます。例: 

/etc/systemd/resolved.conf.d/fallback_dns.conf
[Resolve]
FallbackDNS=127.0.0.1 ::1

フォールバック DNS 機能を無効化したい場合は特にアドレスを指定せずに FallbackDNS オプションを設定してください: 

/etc/systemd/resolved.conf.d/fallback_dns.conf
[Resolve]
FallbackDNS=

DNSSEC

DNSSEC の検証は resolved.conf(5) の DNSSEC= 設定を変更することで有効にできます。

  • DNSSEC=allow-downgrade を設定すると、上流の DNS サーバが DNSSEC をサポートしている場合のみ DNSSEC を検証します。
  • 以下のように、DNSSEC=true を設定すると、常に DNSSEC を検証し、DNSSEC をサポートしていないネームサーバでの DNS 解決ができなくなります。
/etc/systemd/resolved.conf.d/dnssec.conf
[Resolve]
DNSSEC=true
ノート:
  • DNS サーバーが DNSSEC をサポートしておらずデフォルトの allow-downgrade モードでは問題が発生するとき (例: systemd issue 10579)、DNSSEC=false を設定することで systemd-resolved の DNSSEC サポートを明示的に無効化できます。
  • systemd-resolved は何度か検証に失敗すると、DNSSEC を無効にすることがあります。もし DNSSEC オプションが true に設定されていると、DNS 解決が完全に停止します。systemd issue 9867 を参照してください。

不正な署名のドメインを問い合わせて DNSSEC 検証をテスト: 

$ resolvectl query sigfail.verteiltesysteme.net
sigfail.verteiltesysteme.net: resolve call failed: DNSSEC validation failed: invalid

正しい署名を使っているドメインをテスト: 

$ resolvectl query sigok.verteiltesysteme.net
sigok.verteiltesysteme.net: 134.91.78.139

-- Information acquired via protocol DNS in 266.3ms.
-- Data is authenticated: yes

DNS over TLS

DNS over TLS はデフォルトでは無効になっています。有効にするには resolved.conf(5) の [Resolve] セクションの DNSOverTLS= 設定を変更してください。DNS プロバイダのサーバ証明書の検証を有効にするには、DNS= の設定にそのホスト名をip_address#hostname の形式で含めます。例えば: 

/etc/systemd/resolved.conf.d/dns_over_tls.conf
[Resolve]
DNSOverTLS=yes
ノート: 使用する DNS サーバーが DNS over TLS をサポートしていない場合、DNS リクエストが全て失敗するようになります。

DNS over TLS は常にポート 853 を使用し、ポート 53 を使用しないので、ngrep は DNS over TLS が機能しているかどうかをテストするために使用することができます。コマンド ngrep port 53 はホスト名が DNS over TLS で解決されたときに何も出力せず、ngrep port 853 は暗号化された出力になるはずです。

DNS over TLS のクエリをより詳細にパケット検査するには Wireshark を使うことができます。

mDNS

systemd-resolved は マルチキャスト DNS リゾルバ・レスポンダとして使えます。

リゾルバは "hostname.local" 命名規則によるホストネーム解決を提供します。

mDNS は systemd-resolved の全体設定 (resolved.conf(5) の MulticastDNS=) とネットワークマネージャの接続毎の設定の両方が有効になっている場合にのみ使われます。デフォルトで systemd-resolved は mDNS レスポンダを有効にしますが systemd-networkd と NetworkManager はどちらも接続毎の設定で有効にしません:

  • systemd-networkd の場合、[Network] セクションに MulticastDNS= 設定があります。systemd.network(5) を見てください。
  • NetworkManager の場合、設定は [connection] セクションの mdns= です。利用可能な値: 0 - 無効, 1 - リゾルバのみ, 2 - リゾルバとレスポンダ [1]。
ノート: If Avahi をインストールしている場合、systemd-resolved と衝突しないようにするため avahi-daemon.service と avahi-daemon.socket は無効化してください。
ヒント: NetworkManager の接続設定は /etc/NetworkManager/conf.d/ に設定ファイルを作成して [connection] セクションで connection.mdns= を設定することで設定できます。例えば以下の設定で全ての接続で mDNS リゾルバが有効になります: 
/etc/NetworkManager/conf.d/mdns.conf
[connection]
connection.mdns=1

NetworkManager.conf(5) を見てください。

mDNS とファイアウォールを使う場合は、UDP ポート 5353 が開いていることを確認してください。

LLMNR

Link-Local Multicast Name Resolution は Microsoft によって作られたホストネーム解決プロトコルです。

LLMNR は systemd-resolved の全体設定 (resolved.conf(5) の LLMNR=) とネットワークマネージャの接続毎の設定の両方が有効になっている場合にのみ使われます。デフォルトで systemd-resolved は LLMNR レスポンダを有効にし、systemd-networkd と NetworkManager は接続の設定も有効にします。

  • systemd-networkd の場合、設定は [Network] セクションの LLMNR= です。systemd.network(5) を見てください。
  • NetworkManager の場合、[connection] セクションの llmnr= が設定です。nm-settings(5) を見てください。利用可能な値: 0 - 無効化, 1 - リゾルバのみ, 2 - リゾルバとレスポンダ。
ヒント: NetworkManager の接続設定は /etc/NetworkManager/conf.d/ に設定ファイルを作成して [connection] セクションで connection.llmnr= を設定することで設定できます。例えば以下の設定で全ての接続で LLMNR が無効になります: 
/etc/NetworkManager/conf.d/llmnr.conf
[connection]
connection.llmnr=0

NetworkManager.conf(5) を参照。

LLMNR とファイアウォールを使う場合、UDP と TCP のポート 5355 を開いてください。

ルックアップ

DNS レコードや mDNS あるいは LLMNR ホストを問い合わせるには resolvectl ユーティリティを使います。

例えば DNS レコードを確認するには: 

$ resolvectl query archlinux.org
archlinux.org: 2a01:4f8:172:1d86::1
               138.201.81.199

-- Information acquired via protocol DNS in 48.4ms.
-- Data is authenticated: no

トラブルシューティング

​system-resolved がローカルドメインを検索しない

systemd-resolved は、 UseDomains = yes または Domains=[domain-list] が存在する場合でも、ホスト名のみが指定されているとローカルドメインを検索しない場合があります。適切な systemd-networkdの .network ファイルにあり、そのファイルは resolv.conf によって search[domain-list] を生成します。 networkctl status または resolvectl status を実行して、検索ドメインが実際に取得されているかどうかを確認できます。

考えられる回避策:

  • LLMNR を無効にすると、「systemd-resolved」がすぐに DNS サフィックスの追加を続行できるようになります。
  • /etc/nsswitch.conf の hosts データベースをトリミングします (たとえば、resolve service の [!UNAVAIL=return] オプションを削除します)
  • 完全修飾ドメイン名の使用に切り替えます。
  • ホスト名を解決するには /etc/hosts を使用します。
  • systemdの resolve を使用する代わりに、 glibc の dns を使用するようにフォールバックします。

systemd-resolved がサフィックスがないホスト名を解決できない

完全修飾ドメイン名ではないシステム解決ホスト名を解決するには、 R olveUnicastSingleLabel=yes を /etc/systemd/resolved.conf に追加します。

警告: これにより、ユーザーの制御下にないグローバル DNS サーバーに単一ラベル名が転送されます。この動作は標準に準拠しておらず、プライバシーとセキュリティのリスクを引き起こす可能性があります。詳細については、 resolved.conf(5) を参照してください。

これは、 LLMR が無効化 (LLMR=no) されている場合にのみ発生するようです。

systemd-networkd を使用している場合、DHCP サーバーまたは IPv6 ルーター通知によって提供されるドメインを検索ドメインとして使用できます。デフォルトでは無効になっており、インターフェイスの .network ファイルに追加して有効にします。 

[DHCPv4]
UseDomains=true

[IPv6AcceptRA]
UseDomains=yes

各インターフェイスの systemd-resolved の内容を確認するには、次のコマンドを使用します。 

$ resolvectl domain

参照

「https://wiki.archlinux.jp/index.php?title=Systemd-resolved&oldid=38478」から取得