Systemd-resolved

関連記事

• systemd-networkd
• ドメイン名前解決
• Avahi

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, 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

警告: 2023年6月時点で、systemd-resolved における DNSSEC サポートは実験的かつ不完全と見なされています。[1] そのため、systemd はデフォルトで 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

無効な署名を持つドメインにクエリを送信して、DNSSEC 検証をテストします:

$ resolvectl query badsig.go.dnscheck.tools

badsig.go.dnscheck.tools: resolve call failed: DNSSEC validation failed: invalid

次に、有効な署名でドメインをテストします:

$ resolvectl query go.dnscheck.tools

go.dnscheck.tools: 2604:a880:400:d0::256e:b001 -- link: enp2s0
                   142.93.10.179               -- link: enp2s0

-- Information acquired via protocol DNS in 122.2ms.
-- Data is authenticated: yes; Data was acquired via local or encrypted transport: no
-- Data from: network

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]
DNS=9.9.9.9#dns.quad9.net
DNSOverTLS=yes

ノート:

• DNSOverTLS=yes を設定する場合、使用する DNS サーバーが DNS over TLS をサポートしている必要があります。そうでなければ、すべての DNS リクエストが失敗します。
• 代替として、DNSOverTLS=opportunistic を設定することで、サーバーが DNS over TLS をサポートしている場合のみ使用することもできます。この場合、使用する DNS サーバーが DNS over TLS をサポートしていない場合は、systemd-resolved が通常の暗号化されていない DNS にフォールバックします。

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

Wireshark を使用すると、DNS over TLS クエリの詳細なパケット解析が可能です。

追加のリスニングインターフェース

"systemd-resolved" はデフォルトでループバックインターフェースを介してローカルアプリケーションの DNS リクエストに応答します。デフォルトのインターフェース以外にも DNS リクエストに応答させたい場合は、各追加インターフェースに対して resolved.conf(5) 内でオプション DNSStubListenerExtra を設定します。例えば以下のようにします:

/etc/systemd/resolved.conf.d/additional-listening-interfaces.conf

[Resolve]
DNSStubListenerExtra=192.168.10.10
DNSStubListenerExtra=2001:db8:0:f102::10
DNSStubListenerExtra=192.168.10.11:9953

ヒント: これは、DNS サーバーとして機能する ルーター に systemd-forsolved を使用する場合に便利です。

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 - リゾルバとレスポンダ [2]。

ノート: 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 がサフィックスがないホスト名を解決できない

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

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

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

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

[Network]
UseDomains=true

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

$ resolvectl domain

参照

• A name resolution issue with systemd-resolved we found in the wild By Francisco Ros
• その他の例については resolvectl(1) § EXAMPLES を参照してください。