mDNSの概要とローカル環境での位置づけ
mDNSは、小規模なローカルネットワーク内において、専用のDNSサーバーを介さずにホスト名とIPアドレスの解決を行うプロトコルです。UDPの 5353 番ポートを利用し、同一セグメント内の全機器に対してマルチキャストで問い合わせを行うことで、.local ドメインを使った名前解決を実現します。AppleのBonjourや各種スマート家電、Chromecastなどで広く利用されており、ネットワークに接続するだけで自動的に機器同士を認識できる手軽さが大きな特徴です。ユーザーが個人で利用する環境においては、ローカルDNSサーバーと併用されることも多く、IPアドレスを意識させない仕組みとして重宝されています。
配布するアプリにmDNS機能を組み込む価値
自分が開発して外部に配布するセルフホストのWebアプリに対して、このmDNS機能を直接組み込むべきかどうかは悩ましい問題です。アプリ側がmDNSに対応していれば、インストーラーを実行して起動した直後から、分かりやすいホスト名でアクセスできるようになり、動的にIPアドレスが変更される環境でも接続を維持しやすくなるというメリットがあります。
しかし、実際に導入を検討すると、いくつかの無視できないハードルが立ちはだかります。まず、mDNSは同一サブネット内でしか機能しないため、VPN経由のアクセスやルーターのプライバシーセパレーター機能によって名前解決ができなくなるトラブルが発生しやすくなります。開発者側としては、こうした環境起因のトラブルに対するサポート負荷を考慮しなければなりません。
非標準ポートという根本的な課題
何より大きな問題は、セルフホストアプリの性質上、ポート番号の明記が避けられないという点にあります。Webアプリを安全かつ正常に動作させるためには、OSの管理者権限やポート競合のリスクを避けるため、標準ポートである 80 や 443 を使うべきではありません。
そのため、非標準ポート（例: 3000 や 8080 など）を利用せざるを得ず、仮にmDNSによって appname.local という名前解決が成功したとしても、実際にアクセスするURLは [http://appname.local:3000](http://appname.local:3000) のような中途半端な形にならざるを得ません。ポート番号の入力を省略できないのであれば、利便性の向上幅は非常に限定的であり、実装コストやマルチキャストに伴う環境依存のトラブルリスクをわざわざ背負うメリットは薄いと言えます。
結論としての設計判断
セルフホストのWebアプリにmDNSを組み込むアプローチは、一見するとユーザービリティを高める有効な手段に見えますが、ポート番号の制約を考慮すると中途半端な実装になりがちです。環境によって動作が不安定になるリスクや実装・サポートの手間を総合的に勘案すると、無理にアプリ側へmDNSを組み込むのではなく、初期設定時に適切なIPアドレスとポート番号を明確に提示する設計にする方が、結果として堅実でトラブルの少ない選択肢になります。
