ホスト名でのアクセス、あるいはネットワークドライブ割り当てしてれば大丈夫なのかもしれないね。
IPアドレス直打ちでNASにアクセスして、知らないコンピュータからコピーしたファイルで信頼性が不明だから、Zone IDを付与し、ファイルの更新日時が変更される、という仕様は、まあまあ妥当である気もする。
https://x.com/mutaguchi/status/1308143508977405952
>一般のご家庭でAndroidからNASとかの共有フォルダにsmbでアクセスするとき、名前解決をどうやってるのかはよく分からない。IPアドレス直指定なのですかね?
結局これだ。みんなIPアドレス直指定なんじゃないか、やっぱり。
https://x.com/mutaguchi/status/1522523794883063808
そういえば、Androidから.localなドメイン内マシンにアクセスできない問題どうなったかな、と思って調べたら、
https://zenn.dev/seiichihorie/articles/20240917-android-mdns
https://support.google.com/pixelphone/thread/139593141/local-dns-resolution-suddenly-stopped-working
引き続きどうもなってなかった。
これは、mDNSと競合する、.localなドメイン名を付ける方が悪い、で片づけてもいい話ではあるんだが、そうは言っても.localドメインは現実に存在してるんだし、Androidの名前解決の実装の方で融通を効かせてくれてもいいんじゃないか?というのはある。
話を戻して、一般のご家庭では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端末からアクセスできないなどの問題あり。
余談だが、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"というブロードキャストが飛んでることと、対象機器から応答があることを、パケットキャプチャして確かめるしかなくないです?
https://x.com/kaoriya/status/1853952138285895896
あ、検証されてる方が居た。よかった。
というかもともとWindowsからNASやファイルサーバーにアクセスするとき、IPアドレスでアクセスすると、認証情報が保持されないとか無かったっけ。とにかく理由は忘れたけど、IPアドレス直打ちはトラブルの元だという記憶だけは昔からあるので、常にホスト名でアクセスしてるなぁ。