※ 2025 年 3 月 10 日現在の情報をもとに作成しています
1. はじめに
Windows OS には DNS の動作確認やトラブルシューティングをするために nslookup コマンドが用意されています。本記事では、Cisco Secure Client Umbrella Module が有効になっている PC で nslookup のサーバー指定を使用する際の挙動について紹介します。
2. nslookup について
nslookup コマンドに対して、引数としてドメイン名のみを指定した場合、OS に設定されている DNS サーバー宛ての DNS リクエストが生成されます。
例として、Cisco Secure Client Umbrella Module がインストールされている PC (内部の DNS サーバーを設定) で、Umbrella のデバッグ用ドメイン (debug.opendns.com) の DNS リクエストを生成した場合、以下のような結果になります。
> ipconfig /all (一部抜粋)
DNS サーバー. . . . . . . . . . . . .: 192.168.0.2 <= 内部の DNS サーバー
> nslookup -type=txt debug.opendns.com (一部抜粋)
サーバー: UnKnown
Address: 192.168.0.2
権限のない回答:
debug.opendns.com text =
"device 0101c6dca4043d44"
debug.opendns.com text =
"originid 646121968"
nslookup の出力結果の「サーバー」が内部の DNS サーバー (192.168.0.2) となっていることから、この DNS リクエストが内部の DNS サーバー宛てとして作られたことが分かります。
ただし、PC には Cisco Secure Client Umbrella Module がインストールされているため、Umbrella Module がこの DNS リクエストを奪い取り、除外確認や暗号化、付加情報の埋め込みを行ってから、Umbrella の DNS サーバー (208.67.222.222/208.67.220.220) に転送します。
その証拠として、出力結果の中からデバイス ID (0101c6dca4043d44) が確認できます。デバイス ID は、Umbrella Module によって DNS リクエストの中に埋め込まれたもので、出力結果の中にも記録されます。
また、出力結果の中にある Origin ID (646121968) は、Umbrella の DNS サーバーが通信から識別したアイデンティティを示しており、この通信に対して何らかの DNS ポリシーが適用された (つまり Umbrella で保護された) ことがわかります。
なお、この Cisco Secure Client が DNS リクエストを奪い取る仕組みは、以下の流れによって行われます。
- PC 上を流れるローカル DNS サーバー宛ての DNS リクエストを監視し、あればループバック (127.0.0.1) に転送する
- ループバックされた DNS リクエストを Umbrella Module が受け取る
ちなみに、netstat コマンドで、ループバックされた DNS リクエスト (TCP/UDP 53) が Umbrella Module のプロセス (dnscryptproxy.exe) に送られるルーティング設定を確認できます。
> netstat -nab (一部抜粋)
アクティブな接続
プロトコル ローカル アドレス 外部アドレス 状態
TCP 127.0.0.1:53 0.0.0.0:0 LISTENING
[dnscryptproxy.exe]
UDP 127.0.0.1:53 *:*
[dnscryptproxy.exe]
※ Cisco Secure Client の前身である Umbrella Roaming Client では、このループバックを DNS 設定上で明示的に行っていました
3. nslookup のサーバー指定について
nslookup コマンドのドメイン名の指定の後に、DNS サーバーの IP アドレスを指定すると、そのサーバー宛てに DNS リクエストが送られるようになります。
例えば、前項と同じ環境にて、Umbrella の DNS サーバーを指定した場合、どうなるでしょうか。一見すると、同じ動作になるように思えます。
> nslookup -type=txt debug.opendns.com 208.67.222.222 (一部抜粋)
サーバー: dns.sse.cisco.com
Address: 208.67.222.222
権限のない回答:
debug.opendns.com text =
"originid 0"
nslookup の出力結果の「サーバー」が Umbrella の DNS サーバーとなっていることから、このリクエストが Umbrella の DNS サーバー宛てとして作られたことが分かります。
ただし、 Umbrella の DNS サーバー宛ての DNS リクエストはループバックの対象とはならないため、Umbrella Module によって一切の処理が行われることなく Umbrella の DNS サーバーへ送られます。
その証拠として、Umbrella Module が埋め込むはずのデバイス ID が出力結果の中にありません。
また、originid も 0 (アイデンティティはなし) となっており、この通信に対していずれの DNS ポリシーも適用されなかった (つまり Umbrella で保護されなかった) ことがわかります。
次に、内部の DNS サーバーを指定してみます。
> nslookup -type=txt debug.opendns.com 192.168.0.2 (一部抜粋)
サーバー: UnKnown
Address: 192.168.0.2
権限のない回答:
debug.opendns.com text =
"device 0101c6dca4043d44"
debug.opendns.com text =
"originid 646121968"
この場合、ループバックの対象となることから、前項の例と同様に、Umbrella で保護されたことになります。
ループバックそのものを指定した場合も、結果は同じになります。
> nslookup -type=txt debug.opendns.com 127.0.0.1 (一部抜粋)
サーバー: localhost
Address: 127.0.0.1
権限のない回答:
debug.opendns.com text =
"device 0101c6dca4043d44"
debug.opendns.com text =
"originid 646121968"
最後に、比較のため Umbrella 以外の DNS サーバー (この例では Google DNS) を指定してみます。
> nslookup -type=txt debug.opendns.com 8.8.8.8 (一部抜粋)
サーバー: dns.google
Address: 8.8.8.8
opendns.com
primary name server = auth1.opendns.com
responsible mail addr = noc.opendns.com
serial = 1741583086
refresh = 16384 (4 hours 33 mins 4 secs)
retry = 2048 (34 mins 8 secs)
expire = 1048576 (12 days 3 hours 16 mins 16 secs)
default TTL = 2560 (42 mins 40 secs)
宛先が内部の DNS サーバーではないため、ループバックの対象とはならず、Google DNS にそのまま送られます。そして、Google DNS はUmbrella のデバッグ用ドメインを解釈できないため、結果として、SOA 以外の情報が返ってきません。
