こんにちは！松浦です。
GCPでシステムを組んでいると、「名前解決できない」「別のサーバーにつながらない」といったトラブルに出会うことがありますよね。私も最近、Cloud DNSと別プロジェクトのDNSサーバーとの通信でつまずきました。調べていくうちに、そもそもDNSの仕組みをなんとなくしか理解していないことに気づきました。
そこで今回は、DNSの基本を整理しながら、Google CloudのCloud Shellを使って名前解決の動きを実際に確かめてみました。
本記事でわかること
- DNSの役割と、名前解決にかかわる登場人物
- 名前解決がどんな順番で行われるか
- Cloud ShellでDNSの動きを確認する方法
DNSの基本
DNSとは
DNS（Domain Name System）は、www.example.com のような名前から、通信に使うIPアドレスを調べる仕組みです。この「名前からIPアドレスを調べること」を名前解決と呼びます。
電話帳をイメージすると分かりやすいです。人間は名前で覚えるほうが楽ですが、電話をかけるには電話番号が必要です。同じように、人間は名前で覚え、コンピュータはIPアドレスで通信します。その間をつないでくれるのがDNSです。
名前解決の登場人物
名前解決には3つの役割が登場します。大事なのは、「聞きに行く係」と「答えを持っている係」が別にいるという点です。
- スタブリゾルバー（DNSクライアント）
PCやサーバーの中で「この名前のIPアドレスを教えて」と依頼する - フルサービスリゾルバー（キャッシュDNSサーバー）
依頼を受けて、答えが見つかるまで代わりに調べ回る - 権威DNSサーバー
自分が担当する名前について、正解を持っていて答える
名前解決の流れ
- クライアント → リゾルバー ① www.example.comは？
- リゾルバー → ルートサーバー ② 問い合わせ → ③「.comに聞いて」
- リゾルバー → .comの権威サーバー ④ 問い合わせ → ⑤「example.comに聞いて」
- リゾルバー → example.comの権威 ⑥ 問い合わせ → ⑦「192.0.2.10です」
- リゾルバー → クライアント ⑧ 192.0.2.10です
クライアントはリゾルバーに丸投げするだけでぐるぐる再帰問い合わせが始まります。リゾルバーは、上の階層から順番に聞いて回ります。
キャッシュとTTL
リゾルバーは一度調べた結果をキャッシュとして覚えておき、同じ問い合わせにはキャッシュから答えます。覚えておいてよい時間がTTLです。「DNSの設定を変えたのにすぐ反映されない」のは、古い答えがTTLの間キャッシュに残っているからです。
実際にやってみた
IPアドレスを調べてみる
Cloud Shellだけで進めてみます。
Google Cloud コンソールの右上にある [Cloud Shell をアクティブにする] ボタンをクリックします。画面下にターミナルが開けば準備完了です。
Cloud Shellには nslookup と dig が最初から入っています。
まずは一番シンプルな nslookup で、名前からIPアドレスを調べてみます。
nslookup www.google.com結果の Server: が、Cloud Shellが問い合わせたリゾルバーです。Address: 以降が、名前解決の結果のIPアドレスです。
問い合わせ先を変えてみる
問い合わせるリゾルバーは自分で指定できます。今回はGoogle Public DNS（8.8.8.8）を指定してみます。
nslookup www.google.com 8.8.8.8Server: が 8.8.8.8 に変わりました！「どのDNSサーバーに聞いているか」を切り替えられるこの使い方は、後のシリーズでトラブルを切り分けるときにそのまま役立ちます。
digで詳しく見てみる
次は dig を使ってみます。nslookup より多くの情報が見られます。
dig www.google.com答えのレコードが表示されます。レコードの横にある数字がTTL（秒）です。何回か続けて実行すると、TTLの数字が減っていくことがあります。これは、リゾルバーのキャッシュから答えが返ってきている証拠です。
動作確認（dig +trace）
最後に、+trace を付けて名前解決の流れそのものを見てみましょう！
dig +trace www.google.com上から順に、ルートサーバー（.）、com. を担当するサーバー、google.com. を担当するサーバーへと問い合わせが進んでいくのが分かります。先ほどの図の②〜⑦の流れを、実際に目で確認することができました！
GCPではどこが担っている？
最後に、ここまでの登場人物がGCPでは何にあたるのかを軽く整理します。
- リゾルバー（インターネット向け）
Google Public DNS（8.8.8.8） - VMから見たリゾルバー
メタデータサーバー（169.254.169.254） - 権威DNSサーバー
Cloud DNS
ポイントは2つ目です。Google Cloudのドキュメントによると、VMはメタデータサーバーのIPアドレス（169.254.169.254）をネームサーバーとして使うよう設定する必要があり、Cloud DNSはVPCネットワークの名前解決の順序に従って問い合わせを処理します。 つまりGCPでは、「どのVPCから聞いたか」によって見える名前が変わることがあります。私がつまずいた別プロジェクトのDNSとの通信も、まさにこの点が関係していました。
まとめ
今回はDNSの基本を整理して、Cloud Shellで名前解決の動きを確かめてみました。
基礎を学び直したことで、トラブルのときに「どの係のところで止まっているのか」と考えられるようになり、切り分けがしやすくなると感じました。特に dig +trace は、図で理解した流れを実際に目で見られるので、とてもおすすめです！
次回は、検証の土台として「GCPでVPCとサブネットを作ってみる」をお届けします。皆さんもぜひCloud Shellで dig を叩いてみてください！
コメント