この記事にまとめた動作についてなのですが、
（確認した動作）
mDNSが動作している環境で、Hyper-Vゲストから、名前解決の一般的なコマンドを使うと、Windowsホストの直接Hyper-Vの仮想スイッチには追加していないNICのIPアドレスも取得できる。
（追記：もしかしたらこの辺りの課題になりますか？）
マルチキャスト DNS について規定している RFC 6762 では、ローカルリンクより外からのユニキャストクエリを禁止してはいませんが、そのようなパケットを受け取っても処理せずに無視することを推奨しています (セクション 5.5)。
この挙動は、技術的に保証されている動作でしょうか？
それとも、セキュリティ脆弱性として将来廃止されてしまう可能性はあるでしょうか？
よろしくお願いします。
結論から言えば、脆弱性ではなく、想定される動作の範囲と考えてよいと思います。
参照元の記事を含めると、技術要素が多くなるので、ipコマンドでは出てこないIPアドレスがdigでは見えた、という点に絞って説明します。
ipコマンドが見るのは「その端末（ゲストOSであるUbuntu自身）に設定・割当されているIPアドレス」です。
digコマンドが見るのは、自分以外への割当を含む「名前とIPアドレスの対応全体」です。
ここで、@hiro-matsumoto さんが着目している「192.168.yyy.200」は、ゲストOSには割当されておらず、ホスト側のWindowsにのみ割り当てられています。
このため、ipコマンドでは出てこず、digコマンドでは出てくるのです。
結局、使うか？使わないか？は自己判断でしょうかね。
これらをGrokに確認してもらった結果を掲載しておきます。
Windows ICS（Internet Connection Sharing）および Hyper-V Default Switch の名前解決の範囲内で起きうる、想定される挙動に近いものです。 脆弱性としてすぐ廃止される類のものではなく、「ホストが持つ複数のIPアドレスを名前解決で返す」というWindowsのマルチホーム挙動と、ICS由来のDNSプロキシ／ローカル名前解決の組み合わせで説明できます。
Hyper-V の Default Switch は内部的に ICS ベースで動作しており、ゲストに対して DHCP と簡易な名前解決（mshome.net ドメイン）を提供します。hosts.ics などにゲストやホスト関連のエントリが動的に書かれ、ゲストからは hostname.mshome.net などで解決できるのが一般的です。
通常の mshome.net クエリでは、ICS/Default Switch 側で管理されているアドレス（例: Default Switch 側や関連する内部アドレス）が返ることが多いです。
一方、.local（mDNS 由来）を絡めたクエリ（例: dig @gateway hostname.local や nslookup hostname.local hostname.mshome.net）では、Windows ホスト側が認識している「そのホスト名に紐づく複数のローカルIP」をまとめて返すケースがあります。これには Hyper-V 仮想スイッチに直接接続していない外側の NIC（例: 192.168.yyy.200）も含まれることがあります。
TTL が 0 だったり、応答が動的に生成されたように見えるのは、正式な静的DNSゾーンというより、ホストのローカル名前解決情報（マルチホームホストの全アドレス登録挙動）をプロキシ経由で返しているためです。
Windows ではマルチホームホストのコンピュータ名は、デフォルトで複数のNICのIPに紐づいて解決されることがあります（DNS登録やローカル解決の挙動）。ICS のローカルDNSリゾルバや Default Switch のプロキシがその情報をある程度引き継いで返すため、ゲストから「見えてしまう」わけです。ip a はゲスト自身のインターフェースしか見ないので当然出てきませんが、dig/nslookup は名前→IPのマッピング全体を見ます。
Qiita の Q&A 回答でも指摘されている通り、「ip コマンドは自端末の割り当てIP、dig は名前解決の対応全体」という違いで説明がつきます。mDNS 関連の既知の注意点（RFC 6762 で外部からのユニキャストクエリへの応答を推奨しないなど、JVN などで指摘されている実装の不備）はありますが、今回のケースは純粋な外部からの攻撃的クエリというより、ICS プロキシ経由の内部名前解決に近いです。
正常な範囲の動作として扱ってよいと思います。ICS 自体が「共有ネットワーク上のクライアント向けにローカル名前解決を提供する」設計であり、Hyper-V Default Switch もそれを踏襲しています。ホストの全IPが常に完璧に返る「公式機能」としてドキュメント化されているわけではありませんが、「想定外のバグで漏れている」というより、マルチホーム名前解決の副作用として起きているものです。
セキュリティ上「絶対に漏らしてはいけない情報」を意図せず公開している、という深刻な脆弱性ではありません（ゲストはすでにホストと同じネットワークセグメントに近い位置にいて、ホスト名も知っている前提です）。将来的に ICS/Default Switch の実装が変わったり、mDNS の扱いが厳格化されたりすれば挙動が変わる可能性はゼロではありませんが、「すぐにパッチで消される脆弱性」という位置づけではないでしょう。
安定性の面では、Default Switch 自体が「簡単にインターネット共有するための便利機能」であり、設定の自由度が低く、hosts.ics の更新タイミングや順序依存などの既知の癖もあります。本番や長期的に依存する用途には向いていません。
記事でも触れられている通り、Hyper-V 統合サービス（Integration Services）の KVP（Key-Value Pair） を使う方が、意図したホストゲスト間の情報共有としては適切です。ネットワーク情報の通知は一部非推奨になっているものの、代替手段が用意されており、Microsoft の公式ドキュメントでも「ホストとゲスト間で情報を共有する」仕組みとして説明されています。
ネットワーク経由の名前解決に頼るより、KVP で明示的に必要な情報（ホストの特定IPなど）を渡す方が、依存関係が・将来の変更耐性が高いです。
必要なら External スイッチや独自の NAT 構成にして、名前解決を自分でコントロールするのも手です。
まとめると、「ICS/Default Switch の名前解決として起きうる正常寄りの挙動」で、すぐに使えなくなる心配は小さいですが、公式に保証された安定APIではないので、長期的には KVP など意図した仕組みに寄せるのが無難です。興味深い発見だと思います。
ip aでは表示されないWindowsホストのNAT外側として使っているローカルIPアドレスをnslookupとdigで取得できちゃった（けどいいのかな？） - Qiita結局、使うか？使わないか？は自己判断でしょうかね。
えっと。
これが聞きたいことであれば「はい。自己判断ですね」が回答になります。
ですが、そうではなくて、「ゲストOSからホストOSの特定のNICのIPを取得したいが、もっと良い方法が無いか」が聞きたいことでしょうか。
であれば、tracerouteの結果から取るというのはどうですか？
ホスト側でICMP応答(ping応答)を許可する前提にはなりますが。
@hiro-matsumoto
Questioner
これが聞きたいことであれば「はい。自己判断ですね」が回答になります。
皆さまにお聞きしたかったのは、
「この挙動は、技術的に保証されている動作でしょうか？
それとも、セキュリティ脆弱性として将来廃止されてしまう可能性はあるでしょうか？」です。
→「公式のMS文章にでてるから大丈夫だよ」とか、そういうことが確認したかったのです。
tracerouteの結果から取るというのはどうですか？
ホスト側でICMP応答(ping応答)を許可する前提にはなりますが。
・・・それは結果が取れなかったです。。
※ちなみに現在net-toolsインストールすると tracepath らしいです。
$ ping -4 -c 1 192.168.yyy.200
PING 192.168.yyy.200 (192.168.yyy.200) 56(84) bytes of data.
64 bytes from 192.168.yyy.200: icmp_seq=1 ttl=127 time=1.04 ms
--- 192.168.yyy.200 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.039/1.039/1.039/0.000 ms
$ trace
trace-bpfcc trace-cmd tracepath
$ tracepath 192.168.yyy.200
1?: [LOCALHOST] pmtu 1500
1: host-no-namae.mshome.net 0.974ms
1: host-no-namae.mshome.net 1.405ms
2: host-no-namae 0.490ms reached
Resume: pmtu 1500 hops 2 back 2
$ tracepath -m 4 host-no-namae
1?: [LOCALHOST] pmtu 1500
1: no reply
2: no reply
3: no reply
4: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500
$ tracepath -m 4 host-no-namae.local
1?: [LOCALHOST] pmtu 1500
1: no reply
2: no reply
3: no reply
4: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500
$ tracepath -n -m 4 qiita.com
1?: [LOCALHOST] pmtu 1500
1: 172.24.nnn.1 0.317ms
1: 172.24.nnn.1 0.281ms
2: no reply
3: 192.168.x.254 1.623ms pmtu 1454
3: no reply
4: no reply
Too many hops: pmtu 1454
Resume: pmtu 1454
その状況であれば、ホストにNIC1の192.168.yyy.200の口で指定しているゲートウェイのIPに対して、
tracepath -n -m 5 <ゲートウェイのIP>
で、ゲートウェイの直前に192.168.yyy.200が返ってきませんか？
@hiro-matsumoto
Questioner
その状況であれば、ホストにNIC1の192.168.yyy.200の口で指定しているゲートウェイのIPに対して、
tracepath -n -m 5 <ゲートウェイのIP>で、ゲートウェイの直前に192.168.yyy.200が返ってきませんか？
"NIC1の192.168.yyy.200の口で指定しているゲートウェイのIP"となりますと、
この環境では「192.168.yyy.254」になりまして、これを実行しますと、
$ tracepath -n -m 5 192.168.yyy.254
1?: [LOCALHOST] pmtu 1500
1: 172.21.aaa.1 0.407ms
1: 172.21.aaa.1 0.256ms
2: 192.168.yyy.254 3.821ms reached
Resume: pmtu 1500 hops 2 back 2
こういう結果で「192.168.yyy.200」は返ってこないのです。
※そもそもで言うとゲストから「192.168.yyy.254」も分かっていないとこのコマンドも打てない訳なので、
これを手動で書いてしまったら、今回のゲストからホストのNAT側に設定しているIPアドレスを取得したい話自体が成り立ちません。
（その他）
$ tracepath -n -m 5 172.21.aaa.1
1?: [LOCALHOST] pmtu 1500
1: no reply
2: no reply
3: no reply
4: no reply
5: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500
$ tracepath -n -m 5 169.254.yyy.254
1?: [LOCALHOST] pmtu 1500
1: no reply
2: no reply
3: no reply
4: no reply
5: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500
(関連情報）
$ ip r
default via 172.21.xxx.1 dev eth1 proto dhcp src 172.21.xxx.175 metric 100
169.240.0.0/16 dev docker0 proto kernel scope link src 169.240.0.1 linkdown
169.241.0.0/16 dev br-xxxxxxxxxxxx proto kernel scope link src 169.241.0.1
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.yyy.100
172.21.xxx.0/20 dev eth1 proto kernel scope link src 172.21.aaa.175 metric 100
172.21.xxx.1 dev eth1 proto dhcp scope link src 172.21.aaa.175 metric 100
$ ip -4 a | grep -e eth0 -e eth1
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
inet 169.254.yyy.100/16 brd 169.254.255.255 scope link eth0
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
inet 172.21.aaa.175/20 metric 100 brd 172.21.aaa.255 scope global dynamic eth1
「この挙動は、技術的に保証されている動作でしょうか？
それとも、セキュリティ脆弱性として将来廃止されてしまう可能性はあるでしょうか？」です。
うーん。
セキュリティ脆弱性を理由に廃止される可能性は低いと思いますが、技術的に保証されているか、と言われると微妙です。
Hyper-Vの仮想Switch回りの仕様は、割と適当(既存のWindowsの機能の寄せ集めでなんとなく作られている)なイメージがあるので。
ただ、提示いただいた構成は、多分、社内の特定のグループで使うような、影響度の低い環境に思われますので、最悪、ダメになった時に考える、でもよい気がします。
KVPを使ってもいいでしょうし、何ならNIC1を固定IPにする、等も解決策にはなるかと思います。
回答が前後しましたが、
こういう結果で「192.168.yyy.200」は返ってこないのです。
大変失礼いたしました。
tracert/tracepathは内部側のIPしか回答してくれないのですね。
申し訳ありません。
ということで、hiro-matsumotoさんが見つけた方法かKVP辺りあたりが現実解のようです。
前述のとおり、私なら前者でとりあえず運用すると思います。