以前に、Active Directoryで「.local」はもうダメって話題を記事にしたのですが、この主な理由としてmDNSの予約語に.localが使われるから、ということでした。
興味が出て、ちょっと調べてみたので、さわりだけご報告します。
mDNS(multicast DNS、マルチキャストDNS)
以前はmacOS界隈でBonjour（ボンジュール）と呼ばれていた仕組みで、同一セグメント内なら手間不要で名前解決が可能になるという仕組みです。Bonjour懐かしいな…、スゴイ昔にFileMaker Serverの仕事をしていた時に使って以来その単語を耳にしました。
mDNSは小規模なDNSを代替する機能となりますので、LAN内の名前解決専用にDNSサーバを設置していた場合、mDNSを使うことでDNSサーバの運用が不要になるケースもあるそうです。
DNSではドメインのFQDN（ホスト名＋ドメイン名）をフルネームとして指定しますが、mDNSでは「ホスト名＋.local」をFQDNとして使用することになります。
※mDNSではドメイン部分を「.local」固定で名前解決を試行することになります。
※この.local固定のせいでActive Directory黎明期に作られたADドメイン.localが影響を受けて使えなくなっている（使わない方がよい、と言われている）状況。
このActive Directoryで.localドメインをクリーンアップした成果としてのmDNS、小規模なLAN環境ではかなり活用したいケースもありそうです。
活用のポイント
やはり、IPをDHCPサーバ（あるいはルータ、特にブロードバンドルータでのDHCP機能を使っているような小規模環境）で動的に割り当てているLANではIPアドレスは変動することになります。
しかしホスト名（コンピュータ名）はIPアドレスと違って変動せず一意の名前が割り当てられています。
そこで、LAN内ではコンピュータ名でブロードキャストで名前解決されてアクセスするケースが一般的なのですが、ブロードキャストはルータを超えることができず、別のセグメントへは何らかの（hostsやlmhostsのような静的な）方法を用いてアクセスする必要が出てきます。
LAN内のコンピュータみんなでmDNS対応してしまえば、ローカルにDNSサーバの設置なく、コンピュータ名だけ把握しておけば安定したアクセスができる、DNSサーバ設置の主な動機になるこのポイントが特別なサーバコンピュータ設置なしで実現できるのは結構メリットありそうと思いました。
基本：通信別にみると…
これまでの名前解決はブロードキャスト
DNSでの名前解決はユニキャスト
mDNSではマルチキャスト
で名前解決を実行します。
■ブロードキャストは…
ネットワーク内の全てにデータを送信する通信。一般的に（私の理解では）同一ネットワークセグメント（ネットワークアドレスが同一のコンピュータ＆通信機器）に対して一斉に通信を実施する通信方式です。
■ユニキャストとは…
ただ一つのアドレスに対して実行する通信。一対一での通信を実施する（人間が）通信をイメージするときの一般的なイメージ。
メールソフトでメールサーバと通信し電子メールのやり取りをするとか、ブラウザでWebサーバにアクセスしてコンテンツを閲覧するとか。
■マルチキャストとは…
ある特定の宛先を指定して、狙った複数の対象に実行する通信。マルチキャストアドレスという特殊なIPアドレスを使用して特定多数に通信を実行する通信。
マルチキャストはOSのイメージ配信で使った記憶があります。すっごい昔のソフトウェアでLAN内にイメージ配信を実行し、OSイメージを展開していました。
このとき、ソフトウェアの力で（ユーザは意識することなく）マルチキャストの通信が実行されており、イメージ配信を待ち受けているPCでのみOSが展開されて（待ち受けてないPCはなにも処理が実行されない）いました。
mDNSがマルチキャストでの通信です。
名前解決したいPCではmDNSのクエリをマルチキャストを送信し、mDNSに応答する機器がレスポンスを返す、このmDNSに応答する機器がこれまではユニキャストのDNSサーバだったのが、mDNSに応答する機器に置き換わることで、小規模LAN内での名前解決が実現する、という概要。
とはいえ、まだ勉強中なので、わかりやすく説明できない感が自分の中で大きい状況。
■詳しいページ：
https://qiita.com/maccadoo/items/48ace84f8aca030a12f1
■MSのサポートページ（1607で動作させる場合必要な設定）
https://blogs.technet.microsoft.com/jpntsblog/2018/04/28/既定の受信の規則-mdns-udp-受信-が機能しない問題/
■RaspberryPiをmDNS対応したページ
https://qiita.com/takish/items/1a640576caa2d0dfefc4
これらのページが分かりやすかったので、参考にさせていただきました。ありがとうございます。
重要な「Resolve-DnsName」コマンドレット
名前解決の確認はPowerShellを起動してコマンドレット「Resolve-DnsName」を使って動作を確認します。
例：コンピュータ名「ThinkCT02」「ThinkCT01」「ThinkPad01」「ThinkPad02」のPCを「Resolve-DnsName」で検索してみた例。（名前やIPは架空のものです。）
--------------------------------------------------------------
PS C:\> Resolve-DnsName ThinkCT02
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
ThinkCT02 A 30 Answer 192.168.1.3
PS C:\> Resolve-DnsName ThinkCT01
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
ThinkCT01 AAAA 1200 Question ::1
ThinkCT01 A 1200 Question 192.168.50.22
ThinkCT01 A 1200 Question 192.168.1.32
PS C:\Windows\system32> Resolve-DnsName ThinkPad01
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
ThinkPad01 A 1200 Question 192.168.1.20
PS C:\> Resolve-DnsName ThinkPad02
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
ThinkPad02 A 1200 Question 192.168.1.105
--------------------------------------------------------------
正常に終了したコマンド結果
存在しないホスト名（名前解決できないホスト名）は以下のようになります。
例：存在しないコンピュータ名「ThinkPad11」を検索してみると。
--------------------------------------------------------------
PS C:\> Resolve-DnsName ThinkPad11
Resolve-DnsName : ThinkPad11 : ファイル名、ディレクトリ名、またはボリューム ラベルの構文が間違っています。
発生場所 行:1 文字:1
+ Resolve-DnsName ThinkPad11
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ResourceUnavailable: (ThinkPad11:String) [Resolve-DnsName], Win32Exception
+ FullyQualifiedErrorId : ERROR_INVALID_NAME,Microsoft.DnsClient.Commands.ResolveDnsName
--------------------------------------------------------------
当然ですが、エラーになっちゃいます。存在しないから。
Resolve-DnsNameコマンドレットを使ってみると、DNSサーバへの名前解決応答もカバーしてくれることに気づきます。
例：既存のDNSサーバが応答を返す「FileServer.treedown.net」が「192.168.1.7」の場合、DNSサーバ経由で応答してきたときの画面出力
--------------------------------------------------------------
PS C:\> Resolve-DnsName FileServer.treedown.net
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
FileServer.treedown.net A 0 Answer 192.168.1.7
Name : treedown.net
QueryType : SOA
TTL : 0
Section : Authority
NameAdministrator : hostmaster.treedown.net
SerialNumber : 103
TimeToZoneRefresh : 900
TimeToZoneFailureRetry : 600
TimeToExpiration : 86400
DefaultTTL : 0
--------------------------------------------------------------
いま、自分の使っているクライアントOSから名前解決を要求するにあたり、使える手段全てで名前解決を試行してくれるようなので、使い方によってはResolve-DnsNameコマンドレットを使ったほうが動作確認にはメリットが大きそう。
でも、だからといって従来使ってきたnslookupコマンドが不要になるかというと、DNSへの名前解決を確認することに限定した試行をする際にはやはりnslookupで（DNSの名前解決に限定して）確認したほうが、余計な勘違いをしないで済むのでいいだろう、と考えることができます。
※要するに、DNSでの名前解決を確認したいのに、他の名前解決方法も含めた名前解決ができてしまうResolve-DnsNameコマンドだと、「あれ？できるのに、コッチはできない？」といった錯誤が起きるかもしれない、という意味で、純粋にDNSの動作を確認する意味では伝統のnslookupを使った方がいいかなと思いました。
※使いよう、ってことですね。
