【Part 3/4】AWSの環境構築で学ぶトラブルシューティング【Route53】

本記事で学べること

本記事は「AWSの環境構築で学ぶトラブルシューティング」シリーズの第3回目となっています。

本シリーズは、実際に手を動かしながらWSの環境構築とその過程でトラブルが起こった場合の対処方法や問題の特定方法などを体系的に学べる内容になっています。また、トラブルシューティングのセクションでは、遭遇した問題の問題の特定方法や解決方法について解説します。

今回は、Route53を使用し、特定のインスタンスにドメインでアクセスできるようにする環境を構築します。AWSのプライベートネットワークを介した安全な通信を利用する方法を学習します。

「AWSの環境構築で学ぶトラブルシューティング」シリーズはこちら

https://envader.plus/article/259

https://envader.plus/article/260

環境構築のゴール

本記事における、環境構築のゴールを以下の図にまとめました。Webサーバーにドメインでアクセスできるようにすることがゴールです。

環境構築

現時点の環境は、以下の図のようになっており、こちらに追加する形で環境を構築します。

現時点までの環境構築に関しては、Part 1の以下の記事をご参照ください。

https://envader.plus/article/259

使用する環境の情報

以後の説明で出てくる環境の情報を以下にまとめました。

以後の説明では、networking-1-ec2-publicは1-ec2、networking-2-ec2-publicは2-ec2と簡略化して呼称します。

nginxのインストール

パブリックサブネットに配置したインスタンス（2-ec2）をWebサーバーとして構築します。Webサーバーのソフトウェアはnginxを使用します。

• nginxのインストール

  2-ec2にSSH接続し、以下のコマンドを実行します。

  $ sudo apt update
  $ sudo apt install nginx -y

  インストール後はインストールが問題なく行えているか確認しましょう。http://18.182.65.169（2-ec2のパブリックIP）にアクセスし、nginxのデフォルトのページが表示されればインストール完了です。

Route 53

今回はRoute 53を使用し、2-ec2にドメインでアクセスできるようにします。

Route53は、AWSのDNSのサービスです。Route53では、インターネットで通用するパブリックなDNSの管理や、VPC内だけで通用するプライベートなDNSの管理ができます。

パブリックなDNSの設定をする場合はドメインの購入が必要ですので、今回はVPC内だけで通用するプライベートなDNSを使用します。

• ホストゾーンの設定

  ホストゾーンとは、ドメイン名の問い合わせに対して、どういう回答をするのかという設定をまとめたものです。

  マネージメントコンソールで「Route 53」と検索し、ホストゾーンのセクションからホストゾーンの作成をクリックします。

  設定項目大枠	設定項目	入力/選択項目
  ホストゾーン設定	ドメイン名	networking-1-vpc.domain
  ホストゾーン設定	タイプ	プライベートホストゾーン
  ホストゾーンに関連付けるVPC	リージョン	東京
  ホストゾーンに関連付けるVPC	VPC ID	networking-1-vpc

  作成が完了すると、networking-1-vpc.domainというホストゾーンが作成されます。このホストゾーンはnetworking-1-vpc内で通用するDNSのホストゾーンです。

2-ec2にドメインで通信できるかの確認

2-ec2に対し、ドメインでアクセスできるようになったかどうかを確認します。プライベートホストゾーンで設定したので、ブラウザからはアクセスできません。そのため、1-ec2にSSH接続し、curlコマンドを実行します。

curlコマンドは、様々な通信プロトコルでデータの送受信を行うことができます。また、-vオプションを付けて実行すると、HTTPレスポンスの情報も取得することができます。

$ curl -v http://networking-1-vpc.domain

* Could not resolve host: networking-1-vpc.domain
* Closing connection 0
curl: (6) Could not resolve host: networking-1-vpc.domain

Could not resolve host: networking-1-vpc.domainというエラーが起こりました。

トラブルシューティング

Could not resolve host: networking-1-vpc.domainというエラーは、networking-1-vpc.domainというホストの名前解決できなかったというエラーです。現状では以下の図のように、全ての名前解決が失敗している可能性があります。

そのため、接続元の1-ec2が名前解決がどこまでできるか、ということを調べていきます。

名前解決ができるかを調べるコマンド

DNSサーバーからの情報を取得することで名前解決のテストを行えるコマンドを以下の表にまとめました。

今回は詳細な情報を得られるdigを実行して名前解決のテストを行います。

• networking-1-vpc.domainにdigを実行する

  1-ec2にSSH接続している状態で以下のコマンドを実行します。

  $ dig networking-1-vpc.domain
  
  ; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> networking-1-vpc.domain
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5582
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
  
  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 65494
  ;; QUESTION SECTION:
  ;networking-1-vpc.domain.	IN	A
  
  ;; AUTHORITY SECTION:
  networking-1-vpc.domain. 300	IN	SOA	ns-1536.awsdns-00.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
  
  ;; Query time: 0 msec
  ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
  ;; WHEN: Sat Nov 04 08:39:15 UTC 2023
  ;; MSG SIZE  rcvd: 139

  ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1の行に注目してください。ANSWERが0と返されています。これは、名前解決ができていないことを意味します。

  試しにGoogleのドメインが名前解決できるか確認します。

  $ dig google.com
  
  ; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> google.com
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26675
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
  
  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 65494
  ;; QUESTION SECTION:
  ;google.com.			IN	A
  
  ;; ANSWER SECTION:
  google.com.		163	IN	A	142.250.196.142
  
  ;; Query time: 4 msec
  ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
  ;; WHEN: Sat Nov 04 08:41:47 UTC 2023
  ;; MSG SIZE  rcvd: 55

  ANSWERが1と返され、google.comのドメインのIPアドレスが返されており、名前解決ができていることが確認できます。その他、example.comなどのメジャーなドメインの名前解決を試してみてください。

トラブルシューティングの結果

ここまでのトラブルシューティングで、以下の図のように問題のある箇所を狭めることができました。

つまり、名前解決自体は行えるが、networking-1-vpc.domainというホストだけが名前解決できないことが確認できました。

Route 53の設定を確認する

マネージメントコンソールでRoute 53 → ホストゾーンセクションのページへ移動します。ホストゾーン名networking-1-vpc.domainの設定を確認します。

まず、ホストゾーンの詳細から、関連付けられたVPCのVPCIDが、networking-1-vpcであることを確認します。

次に、レコードの確認をします。現時点で登録されているレコードが以下になります。

• レコードとは

  レコードとは、ドメイン名システム（DNS）の基本的な要素であり、インターネット上のあらゆるドメインに対して、そのドメインが何を指し示すのか、どのようにアクセスすれば良いのかを定義しています。今回触れるレコードに絞り、そのレコードのタイプを以下にまとめました。

  レコードタイプ	説明
  SOA	ドメインの権威情報を提供し、ネームサーバーの主要情報、ドメインの連絡先メールアドレス、データのリフレッシュレートなどを含みます。
  NS	そのドメインのネームサーバー情報を指定します。
  A	ドメイン名をIPv4アドレスに変換します。

  ここで重要なのがAレコードです。今回行いたいことは、2-ec2にドメインでアクセスできるようにすることです。ここまでの演習ではホストゾーンを作成しましたが、2-ec2のIPアドレスをドメインと紐づける作業をしていませんでした。

  例えるならば、ホストゾーンはアドレス帳です。アドレス帳だけ作成しても意味はありません。アドレス帳に名前と電話番号の情報を合わせて登録する必要があります。

• レコードの追加

  作成したホストゾーンにレコードを追加します。レコードの追加とは、IPアドレスとドメインを紐付ける作業です。レコードの作成をクリックします。

  設定項目	入力/選択項目
  レコード名	2-ec2-public
  値	18.182.65.169（2-ec2のパブリックIP）

  作成が完了するとAレコードとして登録されます。Aレコードは、ドメインとIPアドレス（正確にはIPv4のIPアドレス）の名前解決に使用されるレコードです。

  ※作成したレコードの反映には時間がかかる場合があります

名前解決の確認

作成したAレコードの2-ec2-public.networking-1-vpc.domainができるか確認します。1-ec2にSSH接続し、以下のコマンドを実行します。

$ dig 2-ec2-public.networking-1-vpc.domain

; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> 2-ec2-public.networking-1-vpc.domain
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60742
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;2-ec2-public.networking-1-vpc.domain. IN A

;; ANSWER SECTION:
2-ec2-public.networking-1-vpc.domain. 300 IN A	18.182.65.169

;; Query time: 3 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sun Nov 05 10:50:43 UTC 2023
;; MSG SIZE  rcvd: 81

digの結果、ANSWERが1と返されています。ANSWERセクションでは.2-ec2-public.networking-1-vpc.domainのIPアドレスは18.182.65.169となっており、正しく名前解決できているのか確認できました。

2-ec2にドメインで通信できるかの確認

2-ec2にドメインで通信できるか、curlコマンドを使用して確認します。

$ curl -v http://2-ec2-public.networking-1-vpc.domain

*   Trying 13.231.5.227:80...
* Connected to 2-ec2-public.networking-1-vpc.domain (18.182.65.169) port 80 (#0)
> GET / HTTP/1.1
> Host: 2-ec2-public.networking-1-vpc.domain
> User-Agent: curl/7.81.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx/1.18.0 (Ubuntu)
< Date: Sun, 05 Nov 2023 11:00:48 GMT
< Content-Type: text/html
< Content-Length: 612
< Last-Modified: Sat, 04 Nov 2023 06:32:28 GMT
< Connection: keep-alive
< ETag: "6545e57c-264"
< Accept-Ranges: bytes
<
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
* Connection #0 to host 2-ec2-public.networking-1-vpc.domain left intact

curlの結果、HTTPレスポンスで200 OKとnginxのデフォルトページのhtmlが返されました。問題なく2-ec2にドメインで通信できていることが確認できました。

本記事の片付け

Route 53の料金ですが、ホストゾーン、レコードともに重量課金ですが、ホストゾーンに関して、AWS公式には以下のように載っています。

作成後 12 時間以内に削除されたホストゾーンについては無料となっています

不要な料金の発生を防ぐためにも、使用予定がなければ放置せずにレコードと合わせて削除することをおすすめします。Route 53で作成したホストゾーン、レコードの削除手順は以下を参考にしてください。

• レコードの削除

  手動で作成したレコードは手動で削除する必要があります。レコード名2-ec2-public.networking-1-vpc.domainを選択し、「レコードを削除」を選択します。

• ホストゾーンの削除

  「ゾーンを削除する」を選択し、削除するホストゾーンを確認し、「削除」と入力し、削除します。

まとめ

今回はRoute 53の環境構築をしながらDNSに関して触れました。

トラブルシューティングの基本はエラーログを良く読むことです。エラーログにエラー内容が書いてあります。エラーがなぜ起こったのか、どうしたら良いのかはやはり知識や経験が必要になってきます。そのため、AWSのサービスを触れる際にはそのサービスが提供する基礎概念を理解することが重要です。

引き続き本シリーズを学習していただき、トラブルシューティングのレベルを上げていきましょう。