1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

技術検証:自宅のDNSサーバーからAWS上の外向けDNSサーバー経由で、GoogleパブリックDNSにフォワードしてみた

Last updated at Posted at 2025-01-10

はじめに

今回は、過去の技術検証をもとに、自宅のDNSサーバーからAWS上に構築した外向けDNSサーバーを経由し、最終的にGoogleのパブリックDNSにフォワードして名前解決を行ってみます。

外向けDNSを活用したフォワード設定を改めて試してみたいという思いから、少し複雑な技術検証に挑戦しています。

この記事は、個人レベルの検証をもとに作成しています。そのため、内容が実運用環境に適さない場合がありますことをご了承ください。

この内容が、どなたかの技術的な参考になれば幸いです。

書こうと思ったきっかけ

普段、インターネットにアクセスする際には、自宅のDNSサーバーを経由し、GoogleのパブリックDNS(例: 8.8.8.8)にフォワードする設定を使用しています。

前回の記事で、自分専用の外向けDNSサーバーを構築したので、今回はそのDNSサーバーを使ってさらにフォワード設定を追加し、検証を行ってみたいと思いました。

もともと、自宅のDNSサーバーと外向けDNSサーバーを組み合わせた技術検証をしてみたいという目標があったため、今回はWiresharkなどのツールも活用し、ネットワークの観点から体系的に整理しながら進めていきます。

前提: 過去の技術検証の続きです

正直なところ、ここまで技術検証が拡大するとは想定していませんでした。

しかし、気になることは何でも試してみたいという私の知的好奇心が抑えきれず、どんどん検証内容が広がってしまっています(笑)。

直近の記事では、Terraformを使ったWindowsサーバーの構築、リモートデスクトップ接続の設定方法、さらにActive DirectoryとDNSサーバーの構築手順をご紹介しました。

また、前回の記事では、外向けDNSサーバーに簡単なAレコードを追加し、名前解決が正常に行えるかを検証しました。

名前解決とDNSフォワーダについて

名前解決とは、インターネットやネットワーク上でホスト名(例: www.yahoo.co.jp)を対応するIPアドレスに変換するプロセスです。

スクリーンショット 2024-11-23 17.05.17.png
引用画像:https://www.value-domain.com/media/a-record/

このプロセスが正常に動作することで、Webサイトの閲覧やネットワークサービスの利用が可能になります。

DNSを利用した名前解決については、以下の記事も参考にしてみてください!

DNSフォワーダとは?

DNSフォワーダは、自分のDNSサーバーで名前解決ができない場合、外部のDNSサーバーに問い合わせを行う仕組みです。

image.png
引用画像:https://atmarkit.itmedia.co.jp/ait/articles/1706/23/news042.html

他のサイトでも詳しく説明されていますので、さらに詳しく知りたい方はこちらをご参照ください。
参考サイトhttps://wa3.i-3-i.info/word12573.html
参考サイトhttps://jprs.jp/glossary/index.php?ID=0198

今回は、主にDNSフォワードの仕組みに焦点を当てた技術検証を行っています。その点をご理解いただければ幸いです。

実際にやってみた

ここでは、自宅にDNSサーバーがあり、さらに外向けに公開している自分専用のDNSサーバーがあることを前提に進めています。

自宅のDNSサーバーの設定変更

私の環境では、Googleの「8.8.8.8(優先)」と「8.8.4.4(代替)」のパブリックDNSをフォワーダー先に設定しています。

設定変更前

image.png

今回の検証では、GoogleのパブリックDNS設定を削除し、前回構築した外向けDNSサーバーのパブリックIPアドレスをフォワーダー先として設定します。

設定変更後

Screenshot 2025-01-10 at 9.49.10.png

AWS上の外向けDNSサーバーの設定変更

AWS上にTerraformを使って構築したDNSサーバーについては、フォワード先をGoogleの「8.8.8.8(優先)」に設定を変更しました。

Screenshot 2025-01-10 at 9.56.37.png

【※ここまでの設定のまとめ】

  • 自宅のDNSサーバーで名前解決ができない場合:
    → AWS上に構築した外向けDNSサーバーにフォワードされる。

  • AWSの外向けDNSサーバーでも名前解決ができない場合:
    → 最終的にGoogleのパブリックDNSサーバーにフォワードされる。

DNSフォワードされているか確認してみた

ローカル端末のMacBookでの確認

フォワード設定の確認は少し複雑でしたが、まずはMacBookのクライアント端末で、nslookupコマンドのインタラクティブモードを使って検証しました。

以下の手順で、内部DNSサーバーを指定して名前解決を行い、フォワードの動作を確認します。これにより、すべての名前解決リクエストが 192.168.1.7 に送信されます。

➜  ~ nslookup                  
> server 192.168.1.7
Default server: 192.168.1.7
Address: 192.168.1.7#53
> www.yahoo.co.jp
Server:		192.168.1.7
Address:	192.168.1.7#53

Non-authoritative answer:
www.yahoo.co.jp	canonical name = edge12.g.yimg.jp.
Name:	edge12.g.yimg.jp
Address: 183.79.249.252
> 

Non-authoritative answer(権威のない応答)

この応答は、192.168.1.7 自体が権威DNSサーバーではなく、他のDNSサーバーから取得した情報をキャッシュして返していることを示しています。

フォワーダ設定の確認

192.168.1.7 は、設定されたフォワーダを使用して上位のDNSサーバー(例えばISPやGoogleのDNS)に問い合わせている形跡が確認できました。この結果から、フォワード設定が正常に動作していることがわかります。

自宅のDNSサーバーからの確認

以下のコマンド tracert www.yahoo.co.jp は、ローカルホストから www.yahoo.co.jp(最終的には edge12.g.yimg.jp)までの通信経路(ルート)を調査した結果です。

C:\Users\Administrator>tracert www.yahoo.co.jp

edge12.g.yimg.jp [183.79.249.252] へのルートをトレースしています
経由するホップ数は最大 30 です:

  1    <1 ms    <1 ms    <1 ms  10.0.4.2
  2     2 ms     1 ms     2 ms  192.168.1.1
  3     4 ms     4 ms     4 ms  fp93c0ab01.hygk102.ap.nuro.jp [xxx.xxx.xxx.xxx]
  4     5 ms     5 ms     5 ms  152.165.186.14
  5     6 ms     6 ms     6 ms  120.74.58.161
  6     6 ms     6 ms     7 ms  219.98.232.222
  7     6 ms     6 ms     6 ms  103.246.232.162
  8     6 ms     6 ms     6 ms  183.79.224.214
  9     7 ms     6 ms     6 ms  183.79.249.252

トレースを完了しました。

DNSの名前解決結果

www.yahoo.co.jp は、DNS によって edge12.g.yimg.jp に名前解決されています。

最終的な到達先

実際の通信は、最終的に 183.79.249.252 という IP アドレスに到達しています。

Wiresharkを使用した解析

詳細を確認するために、Wiresharkを用いてネットワーク解析を実施しました。

Screenshot 2025-01-10 at 10.33.54.png

解析の結果、期待通りAWS上に構築した外向けDNSサーバーにDNSフォワードが行われていることが確認できました。

この結果は、ネットワークの設定が適切に機能しており、DNSフォワードのプロセスが正常に動作していることを示しています。

AWS上に構築した外向けDNSサーバーの確認

最後に、AWS上に構築した外向けDNSサーバーがYahoo!のサイトにアクセスした際、GoogleのDNSサーバーへ想定通りフォワードされているか確認します。

この確認は、仮想ネットワークインターフェースを使用しているため、Wiresharkでは解析できません。そのため、別の方法を用いて解析を行います。

この部分の解析は難易度が高いです。私自身も初めて取り組んだ際は全く理解できませんでしたが、「こういう方法もあるんだ...」という視点で参考にしていただければ幸いです。

管理者としてコマンドプロンプトを起動し、以下のコマンドでトレースを開始・停止します。

netsh trace start capture=yes
netsh trace stop

しばらく時間がかかりますが、ネットワーク解析結果がファイルとして生成されます。

Screenshot 2025-01-10 at 10.50.40.png

生成されたファイルはそのままでは使用できないため、Wiresharkで解析するために適切な形式に変換する必要があります。

Screenshot 2025-01-10 at 10.52.30.png

変換には、Microsoftが提供する専用ツールを使用します。ツールは以下のリンクからダウンロードできます。

変換作業には少し手間がかかりますが、ツールをローカル環境にダウンロードして実行することで、Wiresharkで利用可能な形式に変換できます。

Screenshot 2025-01-10 at 10.56.58.png

変換後のファイルを使用して、Windows 11でWiresharkアプリケーションを開き、キャプチャデータをロードします。

Screenshot 2025-01-10 at 10.58.04.png

ファイルを開くと、ネットワークパケット単位での詳細な解析が可能です。ここではDNSに関する通信をフィルタリングして解析しました。

Screenshot 2025-01-10 at 11.15.41.png

解析の結果、Yahoo!のサイトにアクセスする際、AWS上に構築した外向けDNSサーバーでは名前解決が行えず、リクエストがGoogleの優先DNSサーバーにフォワードされていることを確認しました。

この動作は想定通りであり、検証は大成功になります!!

まとめ

ここまでお読みいただきありがとうございました。今回、自分の頭の中で考えた検証内容を最後までやり切れたことは、とても良い経験になったと思います。

改めて、ネットワークについて学び直す貴重な機会となりましたが、やはりネットワークが最も難しく、技術の「鬼門」だと感じています。

今回の技術検証が少しでも参考になり、どなたかの技術の支えになれば幸いです!

おまけ:まとめるのが大変だった

今回の検証内容は、頭の中での机上検討が済んでいたため、ある程度想定した通りに進めることができました。

特に大変だったのは、Wiresharkを使って細かくネットワークを解析する作業でしたが、すべて想定通りの結果を得られたので満足しています。

また、検証結果をどのようにブログとして記録するかについても迷いましたが、それぞれの観点から確認を行い、エビデンスとして整理できたことで、とても達成感を感じています!

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?