.local ドメインを社内 DNS で使うべきではない理由 – mDNS と名前解決の衝突

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

結論から言えば、社内 DNS、LDAP、証明書、VPN、サーバー運用で .local を使うと、あとから泥沼になりやすいです。最初は名前解決できていても、OS、端末、VPN、アプリケーション、ネットワーク機器が変わったタイミングで挙動が割れることがあります。

この記事では、.local がなぜ普通の社内ドメインではないのか、mDNS とどう衝突するのか、代わりにどの名前空間を使うべきかを整理します。

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

RFC 6762 では、.local. で終わる名前はリンクローカルであり、その名前が発生したリンク上でだけ意味を持つものとして扱われます。さらに、.local. で終わる名前への DNS query は、mDNS の IPv4 multicast address 224.0.0.251、または IPv6 の FF02::FB へ送るものとされています。

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

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

厄介なのは、すべての環境で必ず失敗するわけではないことです。ある端末では社内 DNS を見に行き、別の端末では mDNS として扱う。あるアプリケーションでは動き、別のアプリケーションでは動かない。この揺れが .local の面倒なところです。

mDNS と通常 DNS は前提が違う

mDNS は、通常の DNS サーバーがない環境でも、同一リンク上で名前解決できるようにする仕組みです。プリンター、NAS、スマートフォン、macOS、iOS、Linux の Avahi、Windows の一部機能など、身近な機器でも使われます。

一方で、社内 DNS は組織やネットワークの名前空間を管理するための仕組みです。拠点、サーバー、証明書、LDAP、監視、バックアップ、業務アプリケーションの接続先として、安定した FQDN を提供する役割があります。

この二つを同じ名前空間で混ぜると、名前解決の責任分界が曖昧になります。.local を社内 DNS のゾーンとして使うと、mDNS のための名前と、管理者が設計した DNS 名が衝突します。

何が泥沼になるのか

.local の問題は、単に名前解決できないことではありません。環境によって動いたり動かなかったりし、原因の切り分けが難しくなることです。

DNS 名は、サーバー名、証明書、LDAP、メール、監視、バックアップ、アプリケーション設定に入り込みます。あとからドメインを変える作業は、単に DNS レコードを直すだけでは済みません。

確認するときは経路を見る

.local の問題を確認する時は、単に ping が通るかどうかだけでは足りません。どの仕組みで名前解決されたのかを見る必要があります。

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

resolvectl、getent、dig では見ている経路が異なる場合があります。dig は指定した DNS サーバーへの問い合わせ確認には便利ですが、OS の名前解決順序そのものを代表するとは限りません。

また、macOS、Windows、Linux、スマートフォン、NAS、複合機、VPN クライアントでは、名前解決の実装や優先順位が同じとは限りません。だからこそ、.local は検証環境では動いても、本番運用では厄介になりやすいのです。

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

mDNS を無効化すれば、一部の環境では回避できることがあります。しかし、それは .local を社内 DNS として使う理由にはなりません。

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

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

何を使うべきか

基本は、自分が管理している実在ドメインのサブドメインを使うことです。外部公開する必要はありません。内部 DNS でだけ解決する名前として使えばよいです。重要なのは、その名前空間を自分が管理しており、将来の衝突リスクを下げられることです。

2026 年時点では、.internal も選択肢として見かけるようになっています。ただし、Internet-Draft でも、ほとんどの場合は自分が管理するグローバル DNS 名のサブドメインを使うべきだと説明されています。.internal は、孤立したネットワークや限定された private use では検討できますが、万能な社内ドメインではありません。

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

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

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

まとめ

.local は、ぱっと見では社内用ドメインとして便利に見えます。しかし、RFC 6762 では mDNS のリンクローカルな名前空間として扱われており、通常の社内 DNS ゾーンとして使うと名前解決の挙動が環境ごとに割れやすくなります。

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

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

参考情報

関連する記事

関連記事

DNS 設計・運用メモ – DNSSEC、DoH、名前解決の限界を整理する DoH で DNS フィルタリングは無効になるのか – Chrome、Firefox、Windows の制御点 DNSSEC で名前解決できない原因が NTP だった話