話を戻して、一般のご家庭ではsmb共有フォルダへの名前解決はどうしてるか、実態はこんな順かなぁ。

①IPアドレス直打ち
ていうか名前解決を諦めるパターン。クライアントがWindowsだと、更新日時書き換え問題などが起きうる。

②NBT（NetBIOS over TCP/IP）
クライアントWindows側で、今はデフォルト無効化されたSMB v1を有効化する必要があるが、逆にSMB v2以上非対応の古いNAS等だと、NBTは必ず使える筈なので、今でも結構使われているんじゃないか？

③LLMNR
ご家庭用のWindows対応を謳うNASだと最近はこれが主流か？NBTとLLMNRのどっちが有効化されるかは、SMBがv1か、v2/3かで自動的に変わるんじゃないかと思う。理屈的には名前解決をNBT、通信をSMB v3という組み合わせも成立はするけど。手持ちのLANDISKはv3有効化するとLLMNRで名前解決してるようだ。

④mDNS
mDNSだとクライアントはWindowsに限定されないし、こっちが主流かなぁ。ご家庭用のNASが全部mDNS対応してるのかはよくわからない。

⑤DNS
これは逸般の誤家庭か。.localドメインに所属したNASだとAndroid端末からアクセスできないなどの問題あり。

よく調べたら、LANDISKはSMB v3でもNBTが使われてた。
まあ、LLMNRをWindows以外でわざわざ実装することも無いか。それするくらいならmDNS対応するよな。

LANDISKは、私が勘違いしてなければ、NBTとmDNSを喋るようだ。

余談だが、Windows端末から、対象機器がmDNS対応かどうかを確認する方法って何が正解なんですかね。

まず、nslookupはmDNS非対応だからNG。

pingやResolve-DnsNameは対応してるけど、クエリに"hoge"と入れるとNBTとLLMNRには"hoge"がそのまま渡り、mDNSには"hoge.local"が渡る。

クエリに"hoge.local"と入れるとNBTとmDNSには"hoge.local"がそのまま渡り、LLMNRには"hoge"が渡る。という仕様らしい。

これだとmDNSに対応してるか、してないかを判別する方法が無いように思う。

"hoge.local"というブロードキャストが飛んでることと、対象機器から応答があることを、パケットキャプチャして確かめるしかなくないです？

そもそもなんでこんな話してるんだっけ。そうだ、NASからのコピーで更新日時が書き換わる問題は、IPアドレス直打ちではなくホスト名で回避できるのではないか、という仮説から始まったのだった。

この仮説を実証するのは簡単で、IPアドレス直打ちで現象が再現するかの確認をすればいい。…のだけど、これやるとIPアドレス直打ちとホスト指定で別の資格情報を使ってアクセスすることになって、smbの制限で接続が切られちゃうんよね。こうなると復旧がめんどい。

https://x.com/kaoriya/status/1853952138285895896
あ、検証されてる方が居た。よかった。

Windowsの名前解決仕様を確認するのがめんどかったので、久しぶりにChatGPTを開いたのだが、相変わらずとんでもない大嘘をつかれたし、知らないことを聞くのはマジでやめよう。（n敗）