.local ドメインを使うと泥沼になる理由

.local ドメインは、社内 DNS や検証環境の名前として使えそうに見えます。しかし、長期的な運用を考えると避けた方がよい名前です。理由は、.local が通常の DNS 名前空間ではなく、mDNS と強く結びついた特別な名前として扱われるからです。

この記事は、以前書いた短いメモを再整理したものです。結論は変わりません。社内 DNS、LDAP、証明書、VPN、サーバー運用で .local を使うと、あとから泥沼になりやすいです。

.local は普通の社内ドメインではない

.local は、mDNS で使われる名前として広く扱われています。mDNS は、通常の DNS サーバーへ問い合わせるのではなく、同一リンク上のマルチキャストで名前解決を行います。

RFC 6762 では、Multicast DNS は通常の Unicast DNS サーバーがない環境でも、ローカルリンク内で DNS のような名前解決を行う仕組みとして説明されています。この仕組みでは、.local がローカル用途の名前として扱われます。

224.0.0.251:5353  # IPv4 mDNS
ff02::fb:5353    # IPv6 mDNS

つまり、server01.local のような名前を社内 DNS に登録していても、OS やアプリケーションによっては「これは mDNS で解決する名前だ」と判断され、通常の DNS サーバーへ問い合わせない場合があります。

何が泥沼になるのか

.local の厄介さは、常に失敗することではありません。環境によって動いたり動かなかったりすることです。

状況	起きること
Linux では解決できるが macOS ではできない	macOS 側が mDNS として扱い、社内 DNS を見に行かない場合がある。
サーバーでは解決できるがアプライアンスではできない	mDNS の無効化や名前解決順序の変更ができない機器がある。
hosts に書くと解決できる	DNS を経由しないため一時的には回避できるが、根本解決ではない。
VPN 越しに解決できない	mDNS は基本的にローカルリンク前提であり、ルーティングされたネットワークと相性が悪い。
証明書や LDAP で困る	FQDN として安定して使いたい名前が、OS の名前解決仕様に左右される。

このような問題は、一度システムが運用に入るとかなり面倒です。DNS 名は、サーバー名、証明書、LDAP、メール、監視、バックアップ、アプリケーション設定に入り込みます。あとからドメインを変える作業は、IP アドレスを変える以上に広範囲へ影響することがあります。

Ubuntu と systemd-resolved の例

Ubuntu では、名前解決に systemd-resolved が使われる構成があります。この場合、mDNS や LLMNR、DNS の扱いは resolved の設定やリンクごとの状態に影響されます。

.local を通常 DNS のゾーンとして使っていると、期待した DNS サーバーへ問い合わせず、mDNS 側の名前として扱われる可能性があります。どうしても一時的に解決したい場合は /etc/hosts に書けば解決できることがありますが、それは DNS 設計として正しい状態ではありません。

resolvectl status
resolvectl query server01.local
getent hosts server01.local

確認するときは、単に ping が通るかではなく、どの仕組みで名前解決されたのかを見る必要があります。resolvectl、getent、dig では見ている経路が異なる場合があります。

mDNS を無効化すればよいのか

mDNS を無効化すれば回避できる場合もあります。しかし、それは .local を社内ドメインとして使う理由にはなりません。

理由は単純で、すべてのクライアント、サーバー、アプライアンス、スマートフォン、VPN 接続端末で同じように mDNS を制御できるとは限らないからです。自分が管理している Linux サーバーでは無効化できても、macOS、iOS、複合機、NAS、ネットワーク機器、業務アプリケーションでは挙動を変えられない場合があります。

名前解決の設計は、個別端末の回避設定に頼るべきではありません。最初から衝突しない名前空間を選ぶ方が安全です。

何を使うべきか

プライベートネットワークであっても、基本的には自分が管理している実在ドメインのサブドメインを使うのが安全です。

候補	考え方
`internal.example.com`	自分が管理する実ドメインのサブドメイン。最も扱いやすい。
`home.example.com`	自宅環境や検証環境でも、所有ドメイン配下に置く。
`lab.example.com`	検証環境を本番と分けたい場合に使いやすい。
`.local`	mDNS と衝突するため、社内 DNS の名前空間としては避ける。

実在ドメインのサブドメインを使っても、内部 DNS でだけ解決する構成にできます。外部へ公開する必要はありません。重要なのは、名前空間として衝突しないことです。

すでに .local を使っている場合

すでに .local を使っている場合、いきなり全変更するのは現実的ではありません。まず影響範囲を把握します。

確認対象	確認内容
DNS ゾーン	`.local` 配下にどのレコードがあるか。
証明書	SAN や CN に `.local` が入っていないか。
LDAP / AD	ベース DN、サーバー名、クライアント設定に入っていないか。
監視・バックアップ	ホスト名や URL として使われていないか。
アプリケーション設定	接続先 FQDN として埋め込まれていないか。

移行するなら、まず新しいドメインを決め、DNS に新旧両方の名前を並行登録し、証明書とアプリケーション設定を順番に移します。最後に .local への依存を消していくのが現実的です。

参考

RFC 6762 – Multicast DNS

RFC 6761 – Special-Use Domain Names

まとめ

.local は、ぱっと見では社内用ドメインとして便利に見えます。しかし、mDNS と衝突するため、長期運用では名前解決の挙動が環境ごとに割れやすくなります。

DNS はシステムの根に近い設計です。一度運用に入ると、証明書、認証、監視、バックアップ、アプリケーション設定へ広がります。だからこそ、最初から .local を避け、自分が管理する実ドメインのサブドメインを使う方が安全です。

使えているから問題ない、ではなく、あとから変えにくいから最初に避ける。.local はその典型だと思います。