前回までのMeraki MXにおけるFQDNでのFirewallルールの設定においてiPhoneを使ってPacket Captureを行いながら検証を行いました。
そのPacket Captureを眺めているととても興味深い内容となりましたのでまとめておきます。
iPhoneのDNSサーバをMXにしてPacket Capture
これは、FQDNテストの第一回目での構成です。
iPhoneにてDHCPで取得するDNSサーバをMXのIPアドレスとし、MXは上流のDNSサーバとしてGoogle DNSである8.8.8.8及び8.8.4.4に転送する設定を行なっています。
この状況で本ブログサイトを閲覧しそれをPacketCaptureしてみます。
iPhoneから見たDNSサーバはMeraki MXとなりますのでIPアドレスは192.168.2.1となっていますが、DNSクエリでcandm-network.hatenadiary.jpで問い合わせを行い、レスポンスとして54.199.90.60と35.75.255.9が帰ってきています。
その後、54.199.90.60とHTTPSを使っての通信が開始されています。
その後の詳細は割愛します。
ここまでは一般的によく見るHTTPSの通信フローです。
iPhoneのDNSサーバを8.8.8.8に設定してPacket Capture
次にDNSサーバを8.8.8.8に設定して同様の試験を行います。
Safariのキャッシュをクリアし、さらにiPhoneを再起動して同様の試験を行ってみます。
WiresharkにてDNSでフィルタをかけて表示してみます。
なんとほとんどのDNSクエリが確認出来ませんでした。
次にIPアドレス8.8.8.8でフィルタを行ってみます。
なんと、Port#443を使ってTLS通信を行っていました。
これはDNS over HTTPS(DoH)による名前解決であることがわかります。
とうとうDNSまで暗号化されてしまう時代でPacket Captureを取ってのトラブルシュートが難しくなっている状況です。
DNSでのやり取りは暗号化されているにせよ、先に確認した54.199.60.90と通信しているはずなのでフィルタをかけて確認してみます。
見事、該当サーバとHTTPSの通信が行えていることが確認出来ました。
この検証で確認できる限りiPhone(iOS16.5)はDNSサーバがDNS over HTTPSで通信できる場合には積極的に暗号化を行い名前解決を行うということが確認出来ました。
Appleのプライベートリレーって？
ここからは、余談となるのですがAppleはプライベートリレーと呼ばれる機能をiCloud有料ユーザに対して提供しています。
これはユーザのIPアドレスをサーバ側には伝えずトラッキングされないようにする仕組みです。
難しいことはさておきこの機能を有効にしパケットキャプチャを取得して確認してみます。
8.8.8.8でフィルタを行いましたが何ら引っかかることはありませんでした。
Captureを追ってみると17.248.167.102とUDP(QUIC)を使って通信が開始されていることが確認出来ます。
この17.248.167.102をwhoisで調べてみるとApple社が所有しているIPアドレスであることが確認出来ます。
この試験によりiOSから送信されるパケットはDNSサーバで名前解決されたIPアドレスを使って通信を開始するのではなく、DNSによる名前解決も実通信もApple社のDataCenterを介して行われるようになるということになります。
一点補足しておくと、一切のDNS通信を行わない訳ではなく、Apple社のサーバ名に対する名前解決は従来のDNSを使って行われます。
上のキャプチャでは取得期間内にそのDNSクエリは拾えなかったということですね。
まとめ
上記試験結果をもとにiOSにおけるDNSの仕組みについてググってみたのですがそれを裏付けるような情報を得られることは出来ませんでした。
この記事を書くきっかけとなったMeraki MXのFQDNでのルール設定に関してもDNS over HTTPSの通信が行われてしまうと全く動作しなくなるということになり得ます。
ネットワークインフラにてトラフィックの可視化をすることも難しくなってくることも近い将来やってくるのでしょう。
