③Route 53・Certificate Manager

• 0. コマンド準備
• 1. 解説動画
• 2. 概要
• DNS (Domain Name System)
• SSLサーバ証明書 (SSL Server Certificate)
• リソース一覧
• 公式URL
• 3. 解説手順
• 4. CFnテンプレート
• Route 53
• AWS Certificate Manager (ACM)
• 5. 予習
• 6. FAQ（随時追加）
• 7. コラム（随時追加）
• ルートサーバ
• 各組織のDNSサーバ

ドメイン名を購入して（もしくはルビコンから借りて）AWSでDNSサーバ (Route 53) を構築し、SSL証明書 (Certificate) を発行しましょう！

0. コマンド準備

教材の中で dig コマンドを実行して頂きます。

• Macの方はそのままターミナルで使えると思います。
• Windowsの方は下記赤枠からAWS CloudShellを起動して sudo yum -y install bind-utils を入力してインストールしてください。ただし操作のたびに必要になるのでご注意ください。

• 後で学習するEC2の回で、EC2にSession Managerでログインする方法が分かるようになると、そちらでは1回インストールすると繰り返しは不要です。Windowsの方はどちらかで操作ください。

1. 解説動画

※Route 53を「ルート ごじゅうさん」と呼んでいましたが、「ルート フィフティースリー」の方が良さそうなので、今後は呼び直します。「EC2 イーシーツー」「S3 エススリー」は英語読みなので、Route 53も同様にいたします。ただ私もそうでしたが、現場では「ごじゅうさん」と呼ぶ人の方が多い気がするので、周りに合わせてください！

※動画の画質が悪い場合は、歯車から720p (1080p) 以上の画質を選択ください

※複数のシステムを作成できるように、S3ファイル名のパスを route53.yml → [SystemName]/route53.yml に変更させてください。まだ動画に反映されておりませんので、ご了承ください🙇‍♂️

※複数のシステムを作成できるように、S3ファイル名のパスを certificatemanager.yml → [SystemName]/certificatemanager.yml に変更させてください。まだ動画に反映されておりませんので、ご了承ください🙇‍♂️

※パスを変更するには、[Create folder]というボタンから [SystemName] というフォルダを作成し、その中に certificatemanager.yml をアップロードすればOKです。

2. 概要

DNS (Domain Name System)

日頃使っているドメインとその名前解決について、深掘りしていきたいと思います。

JPドメインの登録管理と.JPのDNSの運用をしているのが、JPRS（株式会社日本レジストリサービス）です。JPRS用語辞典 が分かりやすいので、そこから図を引用させて頂きます。

JPRSが「DNSがよくわかる教科書」を出版していますので、DNSの仕組みを理解されたい方はぜひ手に取ってみてください。下記のような用語を勉強でき、DNSの仕様を網羅していますのでオススメします！.JPドメインを長年運用されてきたJPRSの記載なので信用も置けます。

委任・レジストリとレジストラ・正引きと逆引き・キャッシュとネガティブキャッシュ・digコマンドの結果・フォワーダー・パブリックDNS・digコマンドの結果・DNSチェックサイト・DNSに対する攻撃・DNSSEC・権威サーバーの引越・DNS over HTTPS

DNSがよくわかる教科書

Amazonで株式会社日本レジストリサービス(JPRS) 渡邉結衣、佐藤新太、藤原和典, 森下泰宏のDNSがよくわかる教科書。アマゾンならポイント還元本が多数。株式会社日本レジストリサービス(JPRS) 渡邉結衣、佐藤新太、藤原和典, 森下泰宏作品ほか、お急ぎ便対象商品は当日お届けも可能。またDNSがよくわかる教科書もアマゾン配送商品なら通常配送無料。

www.amazon.co.jp

同じくJPRSが公開している「1時間で学び直すDNSの仕組みのキホン」も非常に分かりやすいので、必ずご覧ください！

【ドメインの構造】

JPRS用語辞典 = https://jprs.jp/glossary/ この jprs.jp の名前解決を例に考えてみましょう。

日頃 jprs.jp と表記されるドメイン名ですが、末尾に . を付けると jprs.jp. となり、これはFQDN (Fully Qualified Domain Name; 完全修飾ドメイン名) と呼ばれます。末尾の . の後ろに目には見えないルート (root=根元) が存在するイメージです。

FQDNは根元から順番に ルートドメイン「.」→ jpドメイン「jp.」→ jprs.jpドメイン「jprs.jp.」と逆ツリー構造になっています。ちなみにjpドメインなどルートの直下にあるドメインをトップレベルドメイン (TLD) と呼びます。最近はかなり増えましたので、どんなものがあるか調べてみると面白いです。

別の見方として、逆ツリー構造を真上から見て（根元から見下ろして？ 見上げて？）「範囲」のイメージで図示すると次のようになりますね。

【ゾーン と 権威DNSサーバー】

ゾーンとは上の青丸一つ一つと考えて頂ければ、まずはOKです。 DNSにおける管理の単位で、ルートドメインから順に委任されることによって誕生します。 委任されたゾーンは、委任先の「権威DNSサーバー」によって管理されます。

AWS Route 53ではまずHosted Zoneを作りますが、これがまさにゾーンです。

ルビコンの場合はawsmaster.jp用のHosted Zoneを作ります（この時、1つのドメイン＝1つのゾーンです）。もし検証用に別のstg.awsmaster.jp用のHosted Zoneを作った場合は、下の図のように1つのドメインの中に2つのゾーンがあることになります。

ゾーンにはIPv4アドレスのAレコードやIPv6アドレスのAAAA（読み方：クワッドエー）レコードなどを追加します。

【権威DNSサーバーは何個あるか？】

1. ルートドメイン → ルートゾーン → ルートサーバー x 13 (JPRS用語辞典｜ルートサーバー（root servers）, https://root-servers.org/)
2. jpドメイン → jpゾーン → JP DNS x 8 (JPRS用語辞典｜JP DNS（ジェーピーディーエヌエス）)
3. jprs.jpドメイン → jprs.jpドメインのゾーン → jprs.jpドメインの権威DNSサーバー x 4

【名前解決の流れ と キャッシュDNSサーバー】

クライアントは「キャッシュDNSサーバー」に名前解決を依頼すると、キャッシュDNSサーバーがルートサーバーから順に「権威DNSサーバー」に問い合わせを行って、最後に結果をクライアントに返してくれます。

【名前解決のコマンド実例】

理屈の話はどうしても分かりづらいと思いますので、実際にやってみましょう！

## 【自分がクライアントとして、IPv4アドレス（Aレコード）を問い合わせる】
## OSに設定されているキャッシュDNSサーバーに、jprs.jpのIPv4アドレスを問い合わせ
dig jprs.jp.

## 【自分がクライアントとして、IPv4アドレス（Aレコード）を問い合わせる】
## 公開キャッシュDNSサーバー(1.1.1.1)に、jprs.jpのIPv4アドレスを問い合わせ
dig jprs.jp. @1.1.1.1

## 【自分がクライアントとして、IPv6アドレス（AAAAレコード）を問い合わせる】
## AAAAレコードを指定して、jprs.jpのIPv6アドレスを問い合わせ
dig jprs.jp. AAAA

2番目のコマンドにあった1.1.1.1ですが、ルビコンのオススメです。CDNサービスのCloudflareが運営する高速・安全・無料のDNSサービス 1.1.1.1 - インターネット最速､プライバシー優先DNSリゾルバ です。ご参考まで。

## 【自分がキャッシュDNSサーバーになったつもりで、IPv6アドレス（AAAAレコード）を問い合わせる】
## ①ルートサーバーに問い合わせたら、答えはもらえなかったけど、jpドメインの権威DNSサーバーを教えてもらえた
dig +norecurse jprs.jp. AAAA @m.root-servers.net

## ②jpドメインの権威DNSサーバーに問い合わせたら、答えはもらえなかったけど、jprs.jpドメインの権威DNSサーバーを教えてもらえた
dig +norecurse jprs.jp. AAAA @a.dns.jp

## ③jprs.jpドメインの権威DNSサーバーに問い合わせたら、jprs.jpのIPv6アドレスを教えてもらえた（ゴールイン！）
dig +norecurse jprs.jp. AAAA @ns1.jprs.jp

SSLサーバ証明書 (SSL Server Certificate)

【HTTPS通信の流れ】

SSLサーバー証明書を使って、HTTP通信の暗号化（HTTPS通信）が行われますが、全体の流れとしては次のようになります。

【共通鍵暗号方式 と 公開鍵暗号方式】

• 共通鍵暗号方式 暗号化と復号に同一の鍵を使用する暗号方式です。代表的なアルゴリズムにAESがあります。暗号化通信の開始に先立って通信当事者同士が鍵を共有しておく必要があります。また暗号化通信ごとに固有の鍵ペアが必要になります。
• 公開鍵暗号方式 暗号化と復号に異なる鍵を使用する暗号方式です。代表的なアルゴリズムにRSAや楕円曲線暗号があります。公開鍵と呼ばれる暗号化鍵は誰もが使用できるように公開しておき、秘密鍵と呼ばれる復号鍵は受信者が厳重に管理します。

【証明書チェーン】

その中でも「③証明書を確認」は次のような流れで、ブラウザがSSLサーバー証明書を検証しています。

【証明書とチェーンの確認】

ブラウザで下記のようにSSLサーバー証明書のチェーンを確認できます。

左図のように証明書を確認し、右図のように証明書チェーンを確認できます。 （図はWindowsの場合ですが、Macでも同じように確認できます）

リソース一覧

公式URL

Route 53 Hosted Zone

• Docs: Amazon Route 53 とは - Amazon Route 53
• CFn: Amazon Route 53 リソースタイプのリファレンス - AWS CloudFormation
• CLI: route53 — AWS CLI v2 Command Reference

AWS Certificate Manager (ACM)

• Docs: AWS Certificate Manager とは - AWS Certificate Manager
• CFn: AWS Certificate Manager リソースタイプのリファレンス - AWS CloudFormation
• CLI: acm — AWS CLI v2 Command Reference

3. 解説手順

1. ドメイン登録サービス、例えば（一番有名な）お名前.com や（個人的にオススメな）Value Domainでドメインを購入する。年間1000円など有料なので、もし ○○.awsmaster.jp で良ければ、ルビコンが受講期間中は無料で貸し出します。ご希望の際はお知らせください ※ドメインを購入する場合は、初年度と2年目以降の料金がかなり異なる場合がある（例えば初年度は60円で、2年目以降は2,586円など）ので、ご注意ください。
2. 東京リージョン(ap-northeast-1)のCFnでRoute 53 HostedZone（ホストゾーン）、CAAレコードを作成する
3. ドメイン登録サービス（前述）で、Route 53ホストゾーンのネームサーバを変更する ※反映までに1, 2時間かかることもあるのでご注意ください （お名前.comの場合）ネームサーバーの変更｜お名前.com Navi ガイド （Value Domainの場合）バリュードメインのネームサーバーの変更 ※「.jp」ドメインなどのccTLD（国別トップレベルドメイン）を除き、下記のような「ドメイン情報認証のお願い」が届いた場合は、必ず認証してください！ バリュードメインであれば下記のように親会社である onamae.com からメールが届いているはずです。認証していないと後でドメインが使えなくなりますので、ご注意ください

4. dig コマンドで結果を確認する。CFnテンプレートで指定した[DomainName]を使ってテストしてください ※コマンドの実行環境については 0. コマンド準備 に記載しています dig [ご自身のドメイン名]. ns dig [ご自身のドメイン名]. caa
5. 東京リージョン(ap-northeast-1)とバージニア北部リージョン(us-east-1)のCFnでCertificate（SSL証明書）を作成する ※動作確認はELBやCloudFrontで実施予定 ※初めて証明書を作成する際に「ドメイン認証」が必要です。具体的にはCFnでスタックを作成中に、Certificate Managerの画面でボタンを押して、Route 53にCNAMEレコードを追加して頂く必要があります。詳しくはYouTubeの動画を参照ください。この「ドメイン認証」は初回だけでOKです。

4. CFnテンプレート

Route 53

awsmaster.jp の HostedZone と CAAレコード（RecordSet）を作成します。

【注意】[SystemName]=awsmaster と [DomainName]= awsmaster.jp をお好きなシステム名とドメイン名に置換してください。システム名は変えなくてもOKですが、ドメイン名は実際に使っていきますのでご自身が購入されたものか、ルビコンから借りたものにしてください。

※システム名 [SystemName] はお好きな名前に変えて頂いてもかまいませんが、英小文字a～zのみを使って、極端に長すぎないように注意してください。数字や記号（ハイフンやアンダースコアなど）は使わないでください。誤動作する可能性があります。AWSの中ではAthenaやParameter Storeなどの例外を除き、ハイフン区切りの英小文字（ケバブケースと呼びます）を名前に使うことが多いです。

※システム名 [SystemName] は今後全てのCFnスタック名でも、テンプレート内でも、毎回同じでお願いします！ 途中で1文字でも変わってしまうとエラーで動きません。またハイフン区切りのケバブケースでは大文字も使わず、CFnスタック名も毎回記載の通りでお願いします。

CFn Stack Name: [SystemName]-prod-route53　←必ずこの命名規則に従ってください S3 File Name: [SystemName]/route53.yml

---
### [Change System Name] awsmaster
### [Change Domain Name] awsmaster.jp
AWSTemplateFormatVersion: "2010-09-09"
Description: Create Route 53 Hosted Zone

Parameters:
  SystemName:
    Description: System Name
    Type: String
    Default: awsmaster ### [Change System Name]
  DomainName:
    Description: Domain name
    Type: String
    Default: awsmaster.jp ### [Change Domain Name]
  Environment:
    Description: Environment
    Type: String
    Default: prod
    AllowedValues:
      - prod
      - stg
      - dev

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups:
      - Label:
          default: "Environment Configuration"
        Parameters:
          - SystemName
          - DomainName
          - Environment

Conditions:
  isProd: !Equals [ !Ref Environment, prod ]

Resources:
  ## Route 53: Hosted Zone
  HostedZone:
    Type: AWS::Route53::HostedZone
    Properties:
      Name: !If [ isProd, !Ref DomainName, !Sub "${Environment}.${DomainName}" ]
      HostedZoneConfig:
        Comment: !Sub ${SystemName}-${Environment}-hostedzone
      HostedZoneTags:
        - Key: Name
          Value: !Sub ${SystemName}-${Environment}-hostedzone

  ## Route 53: Record Set (CAA)
  RecordSetCaa:
    Condition: isProd
    Type: AWS::Route53::RecordSet
    Properties:
      HostedZoneId: !Ref HostedZone
      Name: !Ref DomainName
      Type: CAA
      ResourceRecords:
        - '0 issue "amazon.com"'
      TTL: 3600

Outputs:
  ## Route 53: Hosted Zone
  HostedZone:
    Value: !Ref HostedZone
    Export:
      Name: !Sub ${AWS::StackName}-HostedZone

  HostedZoneDomainName:
    Value: !If [ isProd, !Ref DomainName, !Sub "${Environment}.${DomainName}" ]
    Export:
      Name: !Sub ${AWS::StackName}-HostedZoneDomainName

  HostedZoneNameServer1:
    Value: !Select [ 0, !GetAtt HostedZone.NameServers ]
    Export:
      Name: !Sub ${AWS::StackName}-HostedZoneNameServer1

  HostedZoneNameServer2:
    Value: !Select [ 1, !GetAtt HostedZone.NameServers ]
    Export:
      Name: !Sub ${AWS::StackName}-HostedZoneNameServer2

  HostedZoneNameServer3:
    Value: !Select [ 2, !GetAtt HostedZone.NameServers ]
    Export:
      Name: !Sub ${AWS::StackName}-HostedZoneNameServer3

  HostedZoneNameServer4:
    Value: !Select [ 3, !GetAtt HostedZone.NameServers ]
    Export:
      Name: !Sub ${AWS::StackName}-HostedZoneNameServer4

  ## Route 53: Record Set (CAA)
  RecordSetCaa:
    Condition: isProd
    Value: !Ref RecordSetCaa
    Export:
      Name: !Sub ${AWS::StackName}-RecordSetCaa

【変更履歴】

• 2021-08-28：（CFnで作ったものか手で作ったものか区別しやすいように）CommentとTagの追加
• 2023-04-14：コメント文を全般的に修正

AWS Certificate Manager (ACM)

Certificate（証明書）を作成します（置換箇所は前述Route 53と同様です）

【重要】動画で解説しました通り

• ELBで使うために、東京リージョン (ap-northeast-1)
• CloudFrontで使うために、バージニア北部リージョン (us-east-1)

で全く同じものを 2回作ってください。

【注意】初めて証明書を作成する際に「ドメイン認証」が必要です。具体的にはCloudFormationでスタックを作成中に、Certificate Managerの画面でボタンを押して、Route 53にCNAMEレコードを追加して頂く必要があります。詳しくはYouTubeの動画を参照ください。この「ドメイン認証」は初回だけでOKです。 ※認証結果はすぐにCertificate ManagerやCFnの画面で確認できませんので、ご注意ください。

CFn Stack Name: [SystemName]-prod-certificatemanager　←必ずこの命名規則に従ってください S3 File Name: [SystemName]/certificatemanager.yml

---
### [Change System Name] awsmaster
### [Change Domain Name] awsmaster.jp
## CloudFront certificate needs to be created in the us-east-1 region.
## ELB certificate needs to be created in the ap-northeast-1 region.
AWSTemplateFormatVersion: "2010-09-09"
Description: Create Certificate

Parameters:
  SystemName:
    Description: System name
    Type: String
    Default: awsmaster ### [Change System Name]
  DomainName:
    Description: Domain name
    Type: String
    Default: awsmaster.jp ### [Change Domain Name]
  Environment:
    Description: Environment
    Type: String
    Default: prod
    AllowedValues:
      - prod
      - stg
      - dev

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups:
      - Label:
          default: "Environment Configuration"
        Parameters:
          - SystemName
          - DomainName
          - Environment

Conditions:
  isProd: !Equals [ !Ref Environment, prod ]

Resources:
  ## Certificate Manager: Certificate
  Certificate:
    Type: AWS::CertificateManager::Certificate
    Properties:
      DomainName: !If [ isProd, !Ref DomainName, !Sub "${Environment}.${DomainName}" ]
      SubjectAlternativeNames:
        - !If [ isProd, !Sub "*.${DomainName}", !Sub "*.${Environment}.${DomainName}" ]
      Tags:
        - Key: Name
          Value: !Sub ${SystemName}-${Environment}-certificate-${AWS::Region}
      ValidationMethod: DNS

Outputs:
  ## Certificate Manager: Certificate
  Certificate:
    Value: !Ref Certificate
    Export:
      Name: !Sub ${AWS::StackName}-Certificate

  CertificateDomainName:
    Value: !If [ isProd, !Ref DomainName, !Sub "${Environment}.${DomainName}" ]
    Export:
      Name: !Sub ${AWS::StackName}-CertificateDomainName

  CertificateSubjectAlternativeName1:
    Value: !If [ isProd, !Sub "*.${DomainName}", !Sub "*.${Environment}.${DomainName}" ]
    Export:
      Name: !Sub ${AWS::StackName}-CertificateSubjectAlternativeName1

【変更履歴】

• 2023-04-14：コメント文を全般的に修正

5. 予習

1. CFnでRoute 53とCertificate Managerのリソースを作成してください ※CFnでエラーになった場合は、EventsタブのスクリーンショットをSlackでください （AWSの画面が変わっている場合は同じ設定項目を探してください）
2. CFnで作成したリソースを手でも作ってください。作成中に分からなかった設定項目については調べたり、質問のためにメモしておいてください ※解説手順3,4は不要です。CFnで作った方を有効のまま残しておいてください ※命名はSystemNameの箇所をCFnと別名にしてください。awsmasterとawsmaster2のように
3. 【宿題】下記の項目について調べて、次回のZoomで説明してください
1. Route 53とACMの料金体系
2. [DNS] 権威DNSサーバーとキャッシュDNSサーバーの違い。AWSには両方あるか？
3. [DNS] 下記のdigコマンドを実行してください ※[ご自身のドメイン名]にはCFnテンプレートで指定した[DomainName]を入れます ※コマンドの実行環境については 0. コマンド準備 に記載しています
1. dig [ご自身のドメイン名]. caa
2. dig [ご自身のドメイン名]. caa +norec @m.root-servers.net
3. dig [ご自身のドメイン名]. caa +norec @*** ※***の部分は上記コマンドの結果「AUTHORITY SECTION」に表示されているDNSサーバー（「NS」の右に書かれているドメイン）の1つを指定してください
4. 「ANSWER SECTION」が表示されるまで、上記コマンドを繰り返してください
Copy

例えば、私の場合は次のようにコマンドを実行していくことになります

dig awsmaster.jp. caa
dig awsmaster.jp. caa +norec @m.root-servers.net
dig awsmaster.jp. caa +norec @a.dns.jp
dig awsmaster.jp. caa +norec @ns-388.awsdns-48.com

4番目のコマンドでANSWER SECTIONが表示されて終了です

4. [DNS] 上記で実行した各コマンドの意味。それぞれ何をしているのか？
5. [DNS] SOA、NS、CAA、A、AAAA、CNAME、MX、TXT、PTRの各レコードの用途
6. [DNS] レコードのTTLの意味
7. [証明書] DV、OV、EVの違い。今回のACMはどれに当たるか？
8. [証明書] 今回のACMでも使われている、SAN（Subject Alternative Name）の意味
4. 【応用課題】余裕のある方は実際に挑戦して頂くと勉強になると思います！ ※時間の都合でZoomで解説はしませんので、答え合わせをされたい方はSlackでDMください
1. [DNS] 日本の組織が運営するルートサーバーはMの1個だけだが、実際に日本国内に置かれているルートサーバーは何個あるか？ https://root-servers.org/ を参照ください
2. [DNS] キャッシュDNSサーバーは名前解決の際、 dig +norecurse jprs.jp. AAAA @m.root-servers.net でまずルートサーバーから問い合わせると書きました。しかし実際は m.root-servers.net → 202.12.27.33 の名前解決が先にできていないと dig +norecurse jprs.jp. AAAA @202.12.27.33 の問い合わせができません。このルートサーバーの名前解決はどうやっているでしょうか？ ―― この問題文の意味を理解することから難しいので、再度分かりやすく書きます ―― 冒頭で次のように書きました。 > クライアントは「キャッシュDNSサーバー」に名前解決を依頼すると、キャッシュDNSサーバーが ルートサーバーから順に「権威DNSサーバー」に問い合わせを行って、最後に結果をクライアントに返してくれます。 例えば jprs.jp のIPv6アドレスを知りたい（＝名前解決したい）場合、キャッシュDNSサーバーは 「1番目：ルートサーバー（例えば m.root-servers.net）に jprs.jp. のAAAAレコードを問い合わせる＝dig +norecurse jprs.jp. AAAA @m.root-servers.net」 ことから始めます。 ただちょっと待ってください。m.root-servers.net のIPアドレスはどうやって調べるのですか？ インターネットでは宛先のIPアドレスが分からないと通信はできません。ならば 「0番目：ルートサーバー（例えば m.root-servers.net）に m.root-servers.net のAレコード(IPv4) か AAAAレコード(IPv6) を問い合わせる」 が答えでしょうか？ いやいや無理です。先ほども書きましたように m.root-servers.net のIPアドレスが分からないと m.root-servers.net とは通信（ここではDNS名前解決）ができないのです。 繰り返しになりますが、一体どうすれば一番最初に m.root-servers.net の名前解決（＝IPアドレスを調べる）ができるでしょうか？ という問題です。
3. [DNS] キャッシュDNSサーバーで、キャッシュのTTLが問い合わせのたびに短くなることをdigコマンドで確認してください。どのようなコマンドを使いましたか？ TTLは短くなりましたか？

6. FAQ（随時追加）

「3. 解説手順」の「ドメイン登録サービス（前述）で、Route 53ホストゾーンのネームサーバを変更する」の手順が漏れていませんか？　再度ご確認ください。ちなみにdig [ご自身のドメイン名]. caaコマンドを実行して「ANSWER SECTION」がない場合は手順が漏れていると分かります。

ドメイン購入後、下記のようなメールが届きますので、必ずURLをクリックして有効性を認証してください。もし有効期限が切れた場合は、バリュードメインまでお問合せください。

From: <verification-noreply@onamae.com>　※value-domain.comではないのでご注意 Subject: 【重要】[バリュードメイン] ドメイン 情報認証のお願い （中略） ────────────────────────────────── ■メールアドレスの有効性認証■ ────────────────────────────────── 本メールはICANNのWhois情報正確性確認方針に基づき、レジストラより ドメイン名の登録者（Registrant）にご登録いただいているメールアドレスへ 送信しております。 ドメイン登録者情報のメールアドレスとして情報が正しい場合は、期日までに 以下URLへアクセスしてください。 対応期日：20**年**月**日 **:** https://www.onamae.com/domain/verification?authId=(以下略) ドメイン情報認証のお手続きが期限内に行われない場合、該当ドメイン を利用したホームページの閲覧や、メールの送受信ができなくなります ので、必ずお手続きをお願いいたします。 ※メールアドレス以外にも、Whois情報が不正確なドメインは、登録抹消や 　 使用停止の対象となることがございますのでご注意ください。 ※各種情報の確認・修正等はご利用のドメイン管理会社へご相談くださいます 　ようお願いいたします。

余談ですが「ICANNとは何か？」「Whoisとは何か？」も調べてみると勉強になると思います。

これは仕様なので仕方ありません。CFnで作成したRoute 53ホストゾーンのドメイン（私で言えば awsmaster.jp ）と、手で作成したドメインが同じ場合、解説手順3（ドメイン登録サービスにRoute 53ホストゾーンのネームサーバを変更する）を実行したホストゾーンの方が実際に使われ、もう片方はダミーとして存在するだけで、実際には使われないためです。※宿題2に記載の通り、手で作成した方は解説手順3,4を実行しないようにお願いします。

もちろんCFnで作成したホストゾーンと、手で作成したホストゾーンのドメインを分けて、両方とも解説手順3を実施し、Certificate Managerもそれぞれドメインを分けた場合は両方にCNAMEレコードが追加されます。

今後もCFnで作成するリソースはきちんと動くものを積み上げ式で作って頂きます。一方で手で作成するリソースはあくまで手順の確認や勉強が目的で、ダミー（＝本物そっくりのニセモノ）と思って頂いた方が良いです。なので手作成の方は勉強が終わったら消して頂いてかまいません。

（手でも同じ設定で作って欲しいとお願いしている立場からすると）皮肉なことに、手作成のリソースはCFn作成のリソースと完全に同じ設定にしてしまうと、上記のようにバッティング（＝競合）して動かないケースが出てきます。動かすための配慮は意外と難易度が高いので、手作成の方は動かすことよりも、設定項目やその選択肢を理解することの方を優先して頂ければと思います。

RFC(Request for Comments) というのがインターネットに関する技術仕様を世界共通で決めた文書です（詳しくは RFCってなに? - JPNIC を参照ください）要はインターネットの公式ドキュメントですね。

DNSについて書かれたRFC2181の8章(https://datatracker.ietf.org/doc/html/rfc2181#section-8)から抜粋します。

It is hereby specified that a TTL value is an unsigned number, with a minimum value of 0, and a maximum value of 2147483647. That is, a maximum of 2^31 - 1.

JPRSが公開している日本語訳(https://jprs.jp/tech/material/rfc/RFC2181-ja.txt)からも抜粋します。

ここで、TTL値は、最小値0、最大値2147483647の符号なし整数であると規定する。最大値は2^31-1となる。

ちなみにAWSを使っていて私が見たことある最小値は1秒で、最大値は172800秒（2日間）です。

このようなインターネットで使われる技術の基本ルールはRFCに書かれていると覚えておくと、いざという時にすぐググれると思います。ご参考まで。

ご認識の通り、Route 53でもドメインを取得できます。ただデメリットだらけで、メリットがほとんどないのでオススメしていません。

【デメリット】

1. 日本の会社に比べて高額です。米ドル価格なので、円安になると日本円換算で金額が上がります。1年目の割引キャンペーンもありません
2. 以前は取得できるドメインの種類が少なくて、それもデメリットでした。最近は Amazon Route 53 に登録できる最上位ドメイン の通り増えましたが、今でも.co.jpや.or.jpなどの属性型JPドメインを取得できません。※法人を設立した場合は.co.jpドメインがオススメです！
3. .jpドメイン（汎用JPドメイン）の場合、ドメインロック（指定事業者変更ロック）を有効にできません。 ※第三者による移管申請を防ぐためにも、ドメインロックは有効にしておくことをオススメします！
4. （隠れたデメリットとして）AWSアカウントを解約する際にドメインを他のAWSアカウントや他の会社に移管する必要があります。移管は結構面倒なので、最初から他で取得しておいた方が手間いらずで楽です
5. あまり必要ないですが、技術的なサポートが受けられません。必要な場合は有償のサポートプランを契約しなければなりません

【メリット】

1. 請求をAWSに一本化できます

7. コラム（随時追加）

ルートサーバ

13個の名前がついているルートサーバ（ルートDNSサーバ）全てが止まれば、インターネットは終わります。世界中でWebやメールが使えなくなります。

昔（2002年に）は攻撃を受けて9個まで同時に止まったことがあります（詳しくは ルートサーバーに大規模DoS攻撃も、大きな混乱なし | WIRED.jp 参照）今は数百台のサーバに分散されているので、止まることはありえませんが。

ちなみに13個は政府機関、大学、民間企業など敢えて違う種類の組織が運用し、そのうち10個がアメリカの組織です。残り3個のうち1個、Mルートサーバが日本にあるのは、村井純先生のおかげです（詳しくは WIDEプロジェクトの25年　日本とインターネットのこれまでとこれから 参照）1984年から日本のインターネットの基礎を作った人物です。

各組織のDNSサーバ

同様にして、各組織で運用されているDNSサーバも色んなサーバのうち、最も重要なサーバです。なぜなら設定をミスると、一瞬にしてそのドメイン全てに接続できなくなってしまうからです。

そのため、オンプレの時代は組織の中でも信頼された1人・2人くらいしか触らせなかったのがDNSです。触りたくても気軽にいじることができなかったDNS。

今はクラウドの時代で、誰でも気軽に触れるようになりました。幸せなことです。ただ触るときは細心の注意を払ってください。

これらが背景にあるので、私の教材ではDNSの概要説明にやたらと熱が入っています。

以上、お疲れさまでした！