【初心者向け】無料ドメインを使ってAmazon Route 53で実装しながら理解するDNS

freenomの無料ドメインとAWSのDNSマネージドサービスであるAmazon Route 53を使って実装しながらDNSの概要を理解していきます。図でDNSの名前解決の流れを追っていき,最後にコマンドの出力を確認します。
2020.05.15

はじめに

皆さんこんにちは。石橋です。今回は、DNS(Domain Name System)の概要をAmazon Route 53(以下Route 53)により無料ドメインを使用して実装して理解していきたいと思います。

想定読者

  • DNSについてよく知らない人
  • Route 53についてよく知らない人

出来るようになること

  • DNSの概要を理解すること
  • ドメインとIPアドレスを紐付ける設定をRoute 53で行うこと

DNSとは

インターネットに接続されている機器には、それぞれ固有のIPアドレスが割り当ててあります。 そして通信したい相手のグローバルIPアドレスが分かれば、インターネットを通して通信することができます。 例えば、ブラウザにグローバルIPアドレスを入力するとwebページを表示することができます。

しかし、アプリケーションを利用するために通信相手を直接指定したい時や、様々な接続先を管理したい時は、このような数字の羅列で扱うのは辛くなります。 そこ"classmethod.jp"というような文字列(ドメイン)でIPアドレスを管理するとわかりやすくなります。 このドメインを管理するのが、DNS(Domain Name System)です。 DNSにより、文字列(ドメイン)とIPアドレスを対応させるDNS名前解決をすることにより、"classmethod.jp"などのような文字列(ドメイン)でIPアドレスを特定して通信することができます。

DNSでトラフィックがアプリケーションに届くまで

DNSで実際にクライアントから対象となるホストに接続にするために、DNSがどのように名前解決するのかを見ていきます。

DNS とはより引用

上の図では、End user が www.example.com というドメインで 192.0.2.44 というIPアドレスの Web server にアクセスしています。 このクエリ(DNSへの問い合わせ)がDNSによりどのように名前解決されるのかを、図の番号にしたがってみていきます。

1. ユーザーがウェブブラウザを開き、アドレスバーに www.example.com を入力して、Enter キーを押す。

2. www.exmaple.comのリクエストがDNS resolverにルーティングされる。

  • 図でDNS resolverと記載されているものは、フルサービスリゾルバ再帰リゾルバなどと呼ばれ、3,4,5の手順を見ると分かるように、複数のネームサーバーに対して問い合わせ(クエリ)を行なっています。
    • リゾルバとは DNSに問い合わせを行うホストやソフトウェア のことです。そして、リゾルバは最低でも1つ以上のネームサーバーのIPアドレスを知っている必要があります。
    • フルサービスリゾルバは名前解決のために他のサーバーにクエリを送信するサーバーです。クエリを実行して最終結果を返すため、再帰リゾルバなどとも呼ばれています。

3. DNS resolver から www.example.com のリクエストがDNS root name server に転送され .com のTLD(トップレベルドメイン)を参照せよというレスポンスが返る。

  • DNSは階層構造になっています。
    • それぞれのネームサーバーは下の階層のネームサーバーのIPアドレスを知っており、頂点にあるルートDNS(図のDNS root name server)からネームサーバーが木構造のように結ばれています。
  • ドメイン名は組織やホストを識別するための階層的名前です。
    • 図では、階層構造の上から"com"が企業や商用を表すトップレベルドメイン、"example"が組織や個人が独自に名前を設定できるセカンドレベルの独自ドメイン、"www"が独自ドメインを分割するために任意で設定するサブドメインに当たります。
  • www.example.comというドメインでリクエストをされたルートDNSから、DNS resolverに対してDNS root name serverの下の階層である.comドメインを管理するネームサーバー(Name server for .com TLD)の情報が返ってきている様子を表しています。

4. DNS resolver から.com ドメインTLD ネームサーバーに再びリクエストが転送される。

  • DNS resolverが、www.example.comのリクエストを.comドメインを管理するネームサーバーに転送して、Route 53 name serverを参照せよというレスポンスが返ってきている様子を表しています。

5. DNS resolver が、Route 53 name serverを選択し、www.example.com のリクエストを転送する。

6. Route 53 name serverは、example.com ホストゾーンで www.example.com レコードを検索し、関連付けられた値を取得して、IP アドレスをDNS resolverに返す。

  • ゾーンとはネームサーバーが管理する階層のことです。
    • example.com ホストゾーンとは、example.comのネームサーバー(ここではRoute 53 name server)が管理する階層で、〇〇.exmaple.comはこれに属します。
  • レコードとはゾーンの詳細なデータの単位です。
    • ネームサーバーによって管理されており、ホスト名とIPアドレスを対応させるAレコードや、ドメインとネームサーバーを対応させるNSレコードなどがあります。
  • www.example.comのリクエストをされたRoute 53 name server が、example.com ホストゾーン内でwww.example.comのAレコードを参照して、 Web server のIP アドレス 192.0.2.44 をDNS resolverに返しています。

7. DNS resolverが取得したウェブサーバーのIPアドレスをEnd userに返す。

  • ユーザーが必要とする IP アドレスをDNS resolverが、ウェブブラウザに返しています。
  • DNS resolverでは、指定された期間、example.com の IP アドレスがキャッシュ (保存) されるため、次に誰かが example.com を参照すると、より迅速に応答できます。
    • このキャッシュをどれくらいの時間保持するかをTime to Live (TTL)といいます。

8. ウェブブラウザは、DNS リゾルバーから取得した IP アドレスに www.example.com のリクエストを送信する。

  • これは Amazon EC2 インスタンスで実行されているウェブサーバーや、ウェブサイトのエンドポイントとして設定されている Amazon S3 バケットなどのユーザーのコンテンツがある場所です。

9. 192.0.2.44 にあるウェブサーバーやその他のリソースからウェブブラウザに www.example.com のウェブページが返され、ウェブブラウザでそのページが表示される。

  • 図ではモナ・リザの写真が返されています。

以上のような形で、DNSがドメイン名から名前解決をしています。 ドメインからIPアドレスを検索する例を見てきましたが、DNSはホスト名からIPアドレスを参照する情報(Aレコード)だけではなく、さまざまな情報を管理しています。 たとえば、Aレコードとは逆に、IPアドレスからホスト名を検索するときの情報がPTRレコードや、メールアドレスとそのメールを受信するメールサーバーのホスト名が登録されれいるMXレコードなどです。 このように、インターネットにおける通信をサポートする情報を保持していることからDNSはインターネットに広がる分散データベースと考えることができます。

実装

DNSの概要をある程度把握できたかと思います。それでは実際に、ユーザー対してドメインでウェブページを返す実装をしていきます。

動作環境

  • Amazon linux 2 AMI(HVM), SSD Volume Type

作業

1.無料ドメインの取得とRoute 53 Hosted Zoneの設定

今回の検証用ドメインは、freenomを利用して取得します。 具体的な取得方法は以下の記事のfreenom作業(1),AWS作業(1), freenom作業(2)を参考にしていただければと思います。

今回私はcm-ishibashi.tkを取得し、同名のHosted Zoneを設定しました。

2.EC2インスタンスの作成とDNSレコード登録

今回以下のようにEC2インスタンスをwebサーバーとして、Route 53でドメイン登録します。

2-1. EC2インスタンスの作成とwebサーバーのインストール

今回は検証のため、詳細な設定をせずにデフォルトVPCにEC2インスタンスを建てました。

  • 起動設定
    • AMI : Amazon linux 2 AMI(HVM), SSD Volume Type
    • インスタンスタイプ : t2.micro
    • VPC : デフォルト
    • セキュリティグループ
    • SSH の「マイIP」からの接続を許可
    • HTTP の「任意の場所」からの接続を許可

起動したEC2インスタンスにwebサーバーをインストールします。グローバルIPv4アドレスにアクセスした時に何か表示されればどのような設定でも大丈夫です。私は以下のように設定しました。

# ssh接続してEC2内で操作
sudo yum update -y
sudo yum install -y httpd
sudo systemctl enable httpd
sudo usermod -a -G apache ec2-user
exit
# もう一度EC2にssh接続
sudo chown -R ec2-user:apache /var/www/
echo "<h1>hello from EC2</h1>" >> /var/www/html/index.html
sudo systemctl start httpd

ここまでできたら一度ブラウザでグローバルIPアドレスにアクセスして、EC2インスタンスの/var/www/html/index.htmlに記載した内容が表示されることを確認しましょう。

表示できていれば、IPアドレスでwebサーバーにアクセスできる仕組みは出来ています。以下はこれをドメインを使ってアクセスする方法を実装します。

2-2. Route 53でAレコードの登録

Route 53のコンソールで作成したホストゾーンで以下のようにAレコードを登録します。

  • レコードセットの作成をクリック
    • 名前:サブドメインを記入します。今回はサブドメインを使用しないので、記入しなくも構いません。
    • タイプ:A IPv4アドレス
    • エイリアス:今回はEC2のグローバルIPを直打ちするので「いいえ」とします。
    • TTL:クエリの結果がキャッシュとして残る時間を指定できます。検証なので、1分にしておきます。
    • ルーティングポリシー:今回はシンプルを指定します。
  • レコードセットの保存をクリック

私の設定では以下のようになっています。

登録したAレコード以外のレコードセットを軽く見てみます。 - NSレコード - 前述のようにドメインとネームサーバーを対応させるレコードで、Route 53のホストゾーンの作成時、デフォルトで4つ払い出されます。 - 手順通りに行っていれば取得した.tk ドメインのネームサーバーに、これらを登録していると思います。これによりリクエストがRoute 53に来るようになります。 - SOAレコード - ゾーンの管理のための情報や設定などを記述するためのレコードです。

動作確認

ブラウザからドメイン(私の場合はcm-ishibashi.tk)でアクセスでアクセスできることを確認します。

ローカルのターミナルからdigコマンドで確認します。

$ dig cm-ishibashi.tk +trace

; <<>> DiG 9.10.6 <<>> +trace cm-ishibashi.tk
;; global options: +cmd

## ブロック1
. 504591 IN NS f.root-servers.net.
. 504591 IN NS g.root-servers.net.
. 504591 IN NS h.root-servers.net.
. 504591 IN NS i.root-servers.net.
. 504591 IN NS j.root-servers.net.
. 504591 IN NS k.root-servers.net.
. 504591 IN NS l.root-servers.net.
. 504591 IN NS m.root-servers.net.
. 504591 IN NS a.root-servers.net.
. 504591 IN NS b.root-servers.net.
. 504591 IN NS c.root-servers.net.
. 504591 IN NS d.root-servers.net.
. 504591 IN NS e.root-servers.net.
;; Received 811 bytes from 192.168.0.1#53(192.168.0.1) in 14 ms

## ブロック2
tk. 172800 IN NS a.ns.tk.
tk. 172800 IN NS b.ns.tk.
tk. 172800 IN NS c.ns.tk.
tk. 172800 IN NS d.ns.tk.
tk. 86400 IN NSEC tkmaxx. NS RRSIG NSEC
tk. 86400 IN RRSIG NSEC 8 1 86400 20200527170000 20200514160000 48903 . upwWq03lF/w2YDtIjlEHMa5C0jVZDARUkx2cvY1XPCGLnnlTo9XYlh3f BO94/LU5LWPcOnQm8jO8PcfbT44tLiuoQZfE+oZ84NCvHVNr6CoqTA6d 4BH6MebYGuX2JB1tUqfUmOZsSU/y59Bsg6AZvnzhDleYvcB4bK+itZT4 Bg9KxUflEyGfOtfUc3TmF7e/R6NyPiwNRtA3vcI3lsoTfhlBQwJoHvcd BSbJ5aZ+iPP+OYigAQW8asbfDeCd8zA1En426gkwuys0soqlA0xc0X87 PgNs+ok85kBpQWCnAEHwagtBTk2hnd2hS1YPrtt3gHRAMK9RJMOM6e4a piytyA==
;; Received 602 bytes from 192.5.5.241#53(f.root-servers.net) in 6 ms

## ブロック3
cm-ishibashi.tk. 300 IN NS ns-923.awsdns-51.net.
cm-ishibashi.tk. 300 IN NS ns-1600.awsdns-08.co.uk.
cm-ishibashi.tk. 300 IN NS ns-1035.awsdns-01.org.
cm-ishibashi.tk. 300 IN NS ns-197.awsdns-24.com.
;; Received 184 bytes from 194.0.41.1#53(d.ns.tk) in 8 ms

## ブロック4
cm-ishibashi.tk. 300 IN A 18.217.39.95
cm-ishibashi.tk. 172800 IN NS ns-1035.awsdns-01.org.
cm-ishibashi.tk. 172800 IN NS ns-1600.awsdns-08.co.uk.
cm-ishibashi.tk. 172800 IN NS ns-197.awsdns-24.com.
cm-ishibashi.tk. 172800 IN NS ns-923.awsdns-51.net.
;; Received 200 bytes from 205.251.192.197#53(ns-197.awsdns-24.com) in 108 ms

dig コマンドにtraceオプションをつけ実行すると、DNSが再起的に名前解決している様子が確認できます。それでは結果を見ていきます。 実行結果の";;"の区切りづつ上から順に「ブロックN」という文言を入れました。

ブロック1:DNS リゾルバからルートネームサーバーの情報を取得

  • ルートネームサーバーが13個並んでおり、a~mの名前がついているのが分かります。
    • 木構造のrootにあたりますが実際には一つではなく、耐障害性を高めるために複数に分散されています。
    • DNSに対する問い合わせがない時は、2番目3番目のサーバーというように順番にネームサーバーに問い合わせが行われます。
  • プライベートipの192.168.0.1の53番でDNSサーバーを扱い、データを受け取ったことが分かります。
    • これは私の場合利用しているルーターのプライベートIPです。

ブロック2:ルートネームサーバに対して、.tkドメインを管理するネームサーバーの情報を問い合わせ

  • リクエストに対して、ブロック1のF.root-server.netから返答がきたことが分かります。

ブロック3:.tkを管理するネームサーバーに対して、cm-ishibashi.tkを管理するするネームサーバーの情報の問い合わせ

  • 問い合わせに対して、ブロック2のd.ns.tkから返答が来たことが分かります。
  • ここで取得した4つのNSレコードはRoute 53のホストゾーンから払い出されたものです。

ブロック4 :Route 53のネームサーバーのAレコードから接続先のIPアドレスの取得

  • 問い合わせに対して、ブロック3のns-197.awsdns-24.com(Route 53のネームサーバー)から返答が来たことが分かります。
  • Aレコードで、EC2のグローバルIPアドレスが参照できていることが分かります。

以上のようにコマンドを実行して実際に名前解決している仕組みを見てみると、DNSの再帰問い合わせの様子がよく分かります。

まとめ

今回DNSの概要を見てから実際に実装して確認していきました。自分は最初にRoute 53のコンソールを使用したときは、知らない単語が多く、どのように使えばよいのか理解できませんでした。

Route 53の知識というよりも、DNSに関する知識が足りていなかったからです。

AWSのコンソールやドキュメントは、ITインフラの知識を有していることを前提として作られていることが多く、初学者の内は理解できないのはITインフラの基礎的な知識が足りないことに起因するのか、それともAWS特有の知識が足りないことに起因するのかを考える必要があると経験を通して実感しています。

この記事が少しでも誰かの参考になれば幸いです。

注意事項

  • 2020年5月15日の環境で検証を行なっております。サービスやguiの仕様が変更されている場合がありますので、ご注意ください。
  • 無駄な料金を発生させない為に、検証後は構築したリソースをすぐにクリーンアップすることをお勧めします。
  • 今回作成したEC2インスタンスには、EIPをアタッチしておらず、EC2インスタンスを停止・再開後にグローバルIPアドレスが変わり、ドメインが機能しなくなります
    • それを避けたい場合は、EIPをアタッチして、Route 53にAレコードを登録するようにしてください。

参考

DNS とは

インターネット10分講座:DNS

ドメイン名のしくみ

マスタリングTCP/IP 入門編(第6版)

AWS再入門2018 Amazon Route 53(DNS)編