VMware Fusion 8のDNSプロキシ, AAAAクエリに対する不正な応答 (たぶん Workstation, Player 12も)

3行のまとめ

1. EDNS0ありで、IPv4 onlyホスト(Aのみ)のAAAAクエリを出すと、CNAMEの無限ループの不正な応答だけが返る
2. EDNS0なしで、IPv4 onlyホスト(Aのみ)のAAAAクエリを出すと、CNAMEの無限ループの不正な応答と、A応答の２つの応答が返る
3. AAAAがついているレコード (www.google.com, ipv6.google.com など) は問題ない応答を返す

はじめに

NATの配下にVMを配置してホストOSのIPアドレスで外部通信する仕組みを、仮想マシン各社(VMware Fusion/Workstation, VirtualBox, Parallels, ほかいろいろ)が提供している。通常DNSプロキシもセットで提供される。

少なくとも先の３社はIPv6 NATにも対応していて、内部VMからのAAAAクエリの処理を適切に処理してくれるとを期待するが、VMware FusionのDNSプロキシについてはAAAAクエリに対しておかしな応答を返してくる(なお、この記事はDNSプロキシに関するものでIPv6 NATに関するものではない)。

AAAAクエリへの応答をチェック

環境: VMware Fusion 8.5.3
ネットワークアダプタ: NAT
VMはNATの下に配置してVMware NATが提供するDHCPv4でアドレス、DNS情報を付与する。NAT配下のVM上でOSのリゾルバは使わずに dig でクエリを作って直接ひく。

ケース1: IPv4/IPv6対応デュアルなホスト

特に問題ない (デフォルトで+edns=0されていてEDNS0あり)

dig www.google.com. AAAA
 .
 .
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; MBZ: 0x0005, udp: 4096
;; QUESTION SECTION:
;www.google.com.		IN	AAAA

;; ANSWER SECTION:
www.google.com.		5	IN	AAAA	2404:6800:4004:815::2004

ケース2: IPv6 onlyのホスト

これも特に問題ない

# dig ipv6.google.com AAAA
  .
  .
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; MBZ: 0x0005, udp: 4096
;; QUESTION SECTION:
;ipv6.google.com.		IN	AAAA

;; ANSWER SECTION:
ipv6.google.com.	5	IN	CNAME	ipv6.l.google.com.
ipv6.l.google.com.	5	IN	AAAA	2404:6800:4004:815::200e

ケース3: IPv4 onlyのホスト

AAAAクエリに対しては、EDNS0に対応していないならFORMERR、EDNS0に対応しているならNOERRORかつAAAAレコードなしが返ってくることを期待するのだが

# dig github.com AAAA
;; Warning: Message parser reports malformed message packet.

; <<>> DiG 9.10.4-P4 <<>> +edns github.com AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20528
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: Message has 16 extra bytes at end

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; MBZ: 0x0005, udp: 4096
;; QUESTION SECTION:
;github.com.                    IN      AAAA

;; ANSWER SECTION:
github.com.             5       IN      CNAME   github.com.

まず、Warningメッセージに応答が壊れていると表示されるうえに、アンサーセクションの数は２つあると解釈しているが、解釈できているのは無限ループCNAMEのみ。

次は、EDNS0なしでクエリしてみると、フォーマットエラーは解消され、アンサーセクションにはA応答と、無限ループのCNAME応答が入ったものが返ってくる。

# dig +noedns github.com AAAA

; <<>> DiG 9.10.4-P4 <<>> +noedns github.com AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64051
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;github.com.                    IN      AAAA

;; ANSWER SECTION:
github.com.             5       IN      CNAME   github.com.
github.com.             5       IN      A       192.30.253.113

アプリケーション (名前解決API) への影響

そもそも

　　IPv4 only ホストのAAAAレコードなんて、結果が壊れてても害はないのでは？

と思うだろうし、実際、多くのデスクトップ向けVMware製品のユーザがNAT配下のVMから、不自由なくIPv4インターネットへアクセスできている。しかし好ましい実装ではないし、条件が整うと動かなくなるアプリケーションが存在する。

もう少し具体的に書くと、名前解決APIがAAAAをひくような要求すると、APIが失敗で終わる実装がある。アプリケーションから見ると、IPv6, IPv4接続の以前に、その前段の名前解決が止まってしまう。動作イメージはこんな具合

C:\>git clone git://github.com/abc/defg.git
Cloning into 'defg'...
fatal: Unable to look up github.com (port 9418) (Non-recoverable failure in name resolution)

上記のような問題が発生する詳細な条件は、ゲストOSのリゾルバ実装とIPv6アドレスの有無により状況が様々に異なるので、workadoundとともに別の記事にする。

参考資料

workaroundではないが、まずはコレを抑える。

[1] RFC4074, "Common Misbehavior Against DNS Queries for IPv6 Addresses"