Linux DNSの設定
最終検証日：
翻訳: 竹洞 陽一郎
LinuxでDNSを設定する方法は、驚くほど多く存在します。
Tailscaleは、すでに存在しているLinuxのDNS設定がどのようなものであっても、それと相互運用しようと試みます。
しかし残念ながら、その中にはホストのDNS設定を協調的に管理することに必ずしも向いていないものもあります。
よくある問題
NetworkManager + systemd-resolved
NetworkManagerとsystemd-resolvedを併用している場合（多くのディストリビューションで一般的な構成です）、/etc/resolv.confが/run/systemd/resolve/stub-resolv.confへのシンボリックリンクになっていることを確認してください。
これがデフォルトの状態であるはずです。
そうなっていない場合は、以下を実行します。
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
NetworkManagerは、このシンボリックリンクが存在することを検出すると、デフォルトの動作としてsystemd-resolvedを使用し、resolv.confファイルを自らの管理下に置かなくなります。
修正後、すべてのサービスを再起動します。
sudo systemctl restart systemd-resolved sudo systemctl restart NetworkManager sudo systemctl restart tailscaled
DHCPクライアントdhclientによる/etc/resolv.confの上書き
DNS管理システムが何もインストールされていない環境では、dhclientのようなDHCPクライアントも、tailscaledのようなプログラムも、/etc/resolv.confファイルを自ら書き換える以外の選択肢がありません。
その結果、両者が互いに書き換えを繰り返して競合することがあります。
（例えば、DHCPのリース更新時にresolv.confが書き換えられ、MagicDNSの機能が失われるといった事象です）
考えられる回避策は、resolvconfまたはsystemd-resolvedを使用することです。
他のプログラムがresolv.confを更新した際にTailscaleがそれを検知して自身の設定を再度追加できるようにする対応は、Issue 2334で追跡されています。
Amazon LinuxでのDNSの問題
Amazon Linuxでは、無限の転送ループによってTailscaleのDNSが機能しなくなることがあります。
Tailscaleが/etc/resolv.confをバックアップして自身のDNSサーバ（100.100.100.100）で置き換えると、systemd-resolvedがそのアドレスをバックアップファイルに追加します。
その後、Tailscaleが上流のDNSサーバを特定するためにバックアップを再読み込みすると、クエリを自分自身に転送してしまい、ループが発生してDNS解決が機能しなくなります。
この問題は、特にAmazon Linux 2023で発生することが知られています。
この問題の回避策は、Amazonのカスタム設定をマスクし、/etc/resolv.confをスタブリゾルバに向けることで、systemd-resolvedをAmazonのレガシーモードからスタブリゾルバモードに再構成することです。
mkdir -p /etc/systemd/resolved.conf.d ln -sf /dev/null /etc/systemd/resolved.conf.d/resolved-disable-stub-listener.conf ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf