- 概要
- 何故に依頼が発生したのか
- ケース1.お客様管轄のドメイン名で名前解決してAWS環境へ接続させたい場合
- ケース2.お客様管轄のドメイン名で利用するAWSリソースにて検証が必要となった場合
- まとめ
- 関連エントリー
概要
当エントリーでは、AWSインフラ構築担当者からDNSレコードの登録依頼を 受けた側の視点 で
実施すべき対応とそれが何故に必要なのかについて、概要に触れながらパターン別でご紹介します。
※当エントリーでは便宜上、ドメイン管理組織(会社)のシステム担当を お客様 と呼称します
※既存ドメインは Amazon Route 53 以外で管理されている前提で記載します
何故に依頼が発生したのか
そもそもこのDNSのレコードの登録を依頼されるのはどういう時なのか？というと、AWSインフラ構築担当者と、DNSのドメイン管理者が異なる場合 に発生します。
よくあるケースとして大きく2つあります。
ケース1.お客様管轄のドメイン名で名前解決してAWS環境へ接続させたい場合 ケース2.お客様管轄のドメイン名で利用するAWSリソースにて検証が必要となった場合
両方で共通しているのは お客様管轄のドメイン名 であるという点です。
ここでいう管轄=当該ドメインを所有/管理している と理解ください。
利用したいドメイン (例: example.com ) の管理者が、自分自身であれば登録対応をすれば良いだけの話ですが、 他者の場合は当該ドメイン管理者に登録依頼を中継する必要があります。
もし、ドメイン管理部門が不明な場合、まずは社内で確認すると良いでしょう。
一般的に 社内システム全般を管理している組織 (情報システム部 等)であれば、どの組織やら担当者が管理しているか程度は把握されている事がほとんどです。
更にもし、社内全体に確認し回っても管理者が不明であった場合はその利用したいドメインは、そもそもあなたの会社のものではない可能性があります。 JPRSのWHOIS で確認をオススメします。
あわせて、新規ドメインを取得する方向も検討してください。
当blog末尾の関連エントリー参照
よくある業務連携フロー
AWSインフラ構築においてDNSレコード登録が発生するケースではざっくり以下のような業務連携が必要となります。(既存ドメインで名前解決させたい場合の例)
大規模な組織だと独自フォーマットの申請書の提出を求められたり、何営業日以内に対応しますといった形となっている場合もあるかと思います。
後述する検証のケースなどでは、有効期限があったりもしますので、スムーズに連携出来るよう準備しておくと手戻りが少なくて良いでしょう。
続いて各ケースを見ていきます。
ケース1.お客様管轄のドメイン名で名前解決してAWS環境へ接続させたい場合
仮にお客様管轄の会社ドメインが example.com だとして、Amazon EC2でWebサーバーを構築後、そのサーバーに対して www.example.com でアクセスさせたい場合などがこちらのケースに該当します。
この場合、ドメイン管理者にてexample.com というゾーンの中に www.example.com でアクセス可能とする為、 www というサブドメインを付与して接続先を指定するような形でレコード登録をする必要があります。
サブドメイン文字列(www)はお客様のほうで自由に決定頂く内容となります。一般的に、社内システムであれば利用者が直感的に何のサーバーなのかを理解出来る短い文字列が良いでしょう。
当然ですが、その example.com というゾーンに対して変更を加えられるような権限はドメイン管理者以外の例えばAWSインフラ構築を委託している別業者にはありません。(セキュリティ上、無くて然るべきとお考えください)
その為、当blogエントリーの主旨である DNSレコード登録依頼が発生し、業務連携が必要となっている訳です。
続けて、ケース1の中でよくある対応パターンと実際のレコードサンプルについて見ていきます。
よくある名前解決のためのレコード登録パターン
以下の通りです。
順に説明していきます。
(1-1) Elastic Load Balancing のCNAMEレコードの登録 (1-2) Amazon CloudFront のCNAMEレコード登録 (1-3) EIPのAレコード登録
(1-1) Elastic Load Balancing のCNAMEレコードの登録
執筆時点で Elastic Load Balancing (以後ELB)には4種類があり、ALB,NLB,GLB, 旧世代のCLBがありますが 今回は一般的なWebサーバーの構成でよく利用されるALBを前提にサンプルをご紹介します。
Application Load Balance ことALBは、名前どおり HTTP/HTTPSのプロトコルをサポートするアプリケーションロードバランサーとなりEC2インスタンスとかの前段とかでTLSのオフロード(暗号化/復号 処理の肩代わり)をしつつ複数のEC2インスタンスのグループに対して処理を分散したりする役目を持ちます。
仮にEC2インスタンスが一台だったとしても、セキュリティ確保やメンテナンスの観点から前段にALBが設置されるケースは多くあります。 (ALBはAWS WAFと連携できたりもします)
EC2インスタンス(Webサーバー)の前段にALBが設定されている構成の場合、ユーザーはWebサーバーに対してアクセスする際は、ALBの エンドポイント とも呼ばれる DNS名 に対してアクセスする形となります。
実際に、東京リージョン(ap-northeast-1)に tamura-blog-alb という名称でALBを作成した場合は、以下の様なDNS名が割当られます。 (XXX=ご利用のAWSアカウント番号)
tamura-blog-alb-XXXXXXXX.ap-northeast-1.elb.amazonaws.com
以下イメージとなり、朱書きのDNSレコードの登録を実施頂く必要があります。(amazonaws.comでの名前解決は割愛)
補足:AWS側の名前解決は省略
登録するDNSレコード
www.example.com としてアクセスした際に ALB経由でWebサーバーに接続させたいという場合、 exmple.com ゾーンに対して以下レコードのような追加します。
| Name | Type | Value |
|---|---|---|
| www | CNAME | tamura-blog-alb-XXXXXXXX.ap-northeast-1.elb.amazonaws.com |
Name に指定する www についてはサブドメインとも呼ばれ、基本そのゾーン内で重複せず禁則文字列とかに抵触しなければ システム管理者の方で自由に決定し設定ください。
(参考) ALBにはIPアドレスは払い出されません
オンプレミスの場合、ネットワーク機器単位に静的なIPアドレスが付与されているものであるといった考え方もあり、稀に「ALBのIPアドレス情報を教えてください」という要望を受ける場合があります。
ALBに対して固定のIPアドレスは付与されず、内部では負荷状況により自動的にスケールアウト/インしている都合もあり変動するものとなります。 従って、IPアドレスは払い出されず先述したエンドポイントというDNS名が作成時に払い出されそのエンドポイントにアクセスするものであるとご理解ください。(このエンドポイントは対象ALBを削除しない限りは不変です)
仮に現時点で利用しているものを参考までに把握したいとかであれば エンドポイントに対して dig コマンドで確認頂けます。
(1-2) Amazon CloudFront のCNAMEレコード登録
世界中(インターネット上)にキャッシュサーバーを分散配置し、アクセス元のクライアントに対して 最も近い経路のキャッシュサーバーからコンテンツ配信する事でクライアントに対しては高速に、大元のコンテンツサーバー(オリジンと呼びます)はキャッシュの恩恵を受けて負荷を大幅に減らせるような仕組みがContent Delivery Network(CDN)であり、AWSが提供しているCDN サービスが Amazon CloudFront です。
設置パターンも色々とありますが、上で紹介したELBの更に前段に入る構成パターンが多いので、今回は例としてご紹介します。
Amazon CloudFrontは、Destribution という単位で構築され、こちらもALB同様にエンドポイントに対してアクセスさせるといったイメージになります。
Destributionには、以下の様なDNS名が割当られます。 (XXX=乱数)
XXXXXXXXXXXX.cloudfront.net
ユーザー(Cleint)としてはその Destribution のエンドポイントに対してアクセスするだけで最適なエッジ(地理的に近い等)にアクセスされる形となります。
以下イメージとなり、朱書きのDNSレコードの登録を実施頂く必要があります。
登録するDNSレコード
www.example.com を Amazon Cloud Front経由でアクセスさせたいという場合、exmple.com ゾーンに対して以下レコードのような追加します。
| Name | Type | Value |
|---|---|---|
| www | CNAME | XXXXXXXXXXXX.cloudfront.net |
(1-3) EIPのAレコード登録
EIP(Elastic IPアドレス)とは、AWSで取得可能な 固定Public IP(v4)アドレス となります。
主にEC2インスタンスなどに関連付けて利用されます。
(正確にはEC2インスタンスにアタッチされるENIという仮想NICのようなものに関連付けされます)
(参考) 固定Public IPアドレスが必要なAWSのマネージドサービス(例えばNAT Gatway)でも裏で利用されていたりもします
以下イメージとなり、朱書きのDNSレコードの登録を実施頂く必要があります。
登録するDNSレコード
IPアドレス 203.0.113.10 のWebサーバーに www.example.com としてアクセスさせたいという場合、以下のようなコードを登録します。
| Name | Type | Value |
|---|---|---|
| www | A | 203.0.113.10 |
ケース2.お客様管轄のドメイン名で利用するAWSリソースにて検証が必要となった場合
次に検証系の内容です。
当該ドメインと関連するAWSリソースを 利用可能とする為 にドメイン検証を行う内容となります。
作業の特性上、AWS環境の構築期間中の どこかのタイミング で「このDNSレコードの登録をお願いします」といった依頼が発生する場合があります。
AWSインフラ構築担当者も極力相手方に手間がかからないよう、依頼事項は纏めたい筈ですがそうも行かないケースがあるという事です。
もし、AWSインフラ構築担当とシステム担当とドメイン管理者がすべて異なるような場合は、これらの事情を把握したうえで、速やかにレコード登録の連携出来るよう準備しておくとスムーズで良いでしょう。 (良いプロジェクトとなる事でしょう)
よくあるDNS検証のレコード登録パターン
以下の通りです。
順に説明していきます。
(2-1) TLS証明書の発行時の検証 (2-2) Amazon SES でのEメール送信ドメインの検証
(2-1) TLS証明書の発行時の認証
HTTPSでアクセスさせる為には、TLS証明書が必要となります。 ざっくり、通信の暗号化 と その接続先のサーバーが本物であるという事の認証 で利用されます。
AWSの場合は、AWS Certificate Manager (ACM)というサービスにて証明書の発行や管理が可能となります。 その中でも無料のパブリック証明書を発行するケースが多いので、今回は例として記載します。
ACMを利用するメリットとして、自動更新される無料の証明書を手軽に発行し、利用出来るという点があります。
TLS証明書の更新作業は、本番環境で実際にやった事がある実担当の方ならご理解頂けると思いますが「やらないで済むならやりたくない作業」であると思います。
当内容は昔から更新を忘れたり、オペミスしたりとシステムトラブル原因の一つでした。
本番用途の環境であれば、これから記載する DNS検証 を行いつつ証明書の 自動更新を有効化 しておきたいものです。
検証について、厳密にいうとEメール検証のような対応も可能ですが 自動更新といったACMを利用するメリットを活かしつつ手間が少ない DNS 検証が推奨されています。
Q.DNS 検証の利点は何ですか? より抜粋
CNAME レコードの設定後、DNS 検証レコードがある限り、ACM は自動的に使用中の (AWS リソースに関連付けられている) 証明書を更新します。更新は完全に自動化されており、何も触る必要はありません。
AWSインフラ構築担当(TLS証明書の発行実施者)とドメイン管理者が異なる場合には、発行したTLS証明書を利用可能とするためのDNS検証用レコード登録で作業連携が必要となります。
以下イメージとなり、朱書きのDNSレコードの登録を実施頂く必要があります。
登録するDNSレコード
AWS指定のCNAMEレコード (XXX は 乱数)
| Name | Type | Value |
|---|---|---|
| _XXXXXXXXX.www.example.com | CNAME | _XXXXXXX.XXXXXXX.acm-validations.aws. |
(参考) ACMの証明書発行画面
こちらのCNAMEレコードを当該ゾーンに登録頂いたら 検証状態が 検証保留中 -> 成功 と代わり利用可能となります。
発行したTLS証明書は、 (重要) DNS 検証レコードがある限り自動更新が可能となる ので当該レコードについては、利用廃止する時まで操作(変更やら削除を)しないよう注意して運用ください。
(2-2) Amazon SES でのEメール送信ドメインの検証
Amazon Simple Email Service (Amazon SES)は、AWSの提供するフルマネージドのEメールサービスとなります。
(過去にはEメール送信専用のサービスでしたが、機能拡張され特定リージョンのみEメール受信機能も有しています)
利用を開始する際、Amazon SES経由でのEメール送信をドメイン全体から送信を許可するか、それとも特定Eメールアドレスのみ許可するかを指定出来ます。
具体的に mail.example.com をドメインパートとしたEメールアドレス全てからの配送を許可するか (*@mail.example.comを許可するようなざっくりイメージ)
hoge@mail.example.com といった特定Eメールアドレスからのみ配送を許可するかを選択できる形となります。
前者のドメイン全体を許可する場合は、ドメインの検証が必要となり具体的にAmazon SESより指定された以下 TXTレコードの認証を行う必要があります。 (後者の場合は、当該EメールアドレスでのユーザーによるEメール受信認証となります)
以下イメージとなり、朱書きのDNSレコードの登録を実施頂く必要があります。
登録するドメインDNSレコード (検証用)
Amazon SESにて example.com ドメインの登録を行う際に検証用途で登録が必要となるTXTレコード
| Name | Type | Value |
|---|---|---|
| _amazonses.mail.example.com | TXT | XXXXXXXXXXXXXXXXXXXXX |
(参考) Amazon SESでドメイン登録を行った際の画面キャプチャ
このレコードを登録してくださいといった情報が CSVもダウンロード可能なので、CSVを添付する形で作業依頼がされる場合もあるかもしれません。 (受信利用がない場合は、MXは不要です)
登録が推奨されるDNSレコード (DKIM用)
迷惑メール扱いされない為にもDKIMといったEメールの改ざん検知を目的とした認証技術を活用する事が好ましく、AWSとか関係なくどの環境でも DKIM関連の設定は推奨されます。
exmple.com ゾーンに対して以下の AWS指定レコードを当該ゾーンに追加します。(Amazon SESのドメイン管理画面で確認可能) XXX,YYY,ZZZは乱数のようなイメージとなります。
| Name | Type | Value |
|---|---|---|
| XXXXXXXXX._domainkey.mail.example.com | CNAME | XXXXXXX.dkim.amazonses.com |
| YYYYYYYYY._domainkey.mail.example.com | CNAME | YYYYYYY.dkim.amazonses.com |
| ZZZZZZZZZ._domainkey.mail.example.com | CNAME | ZZZZZZ.dkim.amazonses.com |
(参考) Amazon SES のドメイン管理画面(DKIM項目)
ドメイン認証時にも取得出来ますが、登録後でも当画面項目から取得&確認が可能です。
(参考) カスタムメールFROM を利用する構成の場合
Amazon SESのデフォルトでは、MAIL FROM ドメイン(envelope from)として amazonses.com が利用されます。
それを自ドメインに変更したい場合は、上の図にも記載の通り、カスタム MAIL FROMドメイン を設定する必要があり、その構成の場合のみ追加で更に Bouncedメールや苦情を受け取る為のMXレコードと、Amazon SESが当該ドメインから送信許可されている事の認証で利用されるSPFレコードが必要となり、更にDMARCのレコード登録が推奨されます。
| Name | Type | Value |
|---|---|---|
| subdomain.example.com | MX | 10 feedback-smtp.ap-northeast-1.amazonses.com |
| subdomain.example.com | TXT | v=spf1 include:amazonses.com ~all |
| _dmarc.example.com | TXT | v=DMARC1;p=quarantine;pct=25;rua=dmarcreports@example.com |
このようにEメール関連は登録対象がどうしても多くなりがちですが、用途を把握しシステム利用を廃止する時まで操作(変更やら削除を)しないよう注意して運用ください。
まとめ
DNSレコードの登録を依頼される側の視点で、よくある対応パターンについて紹介してきました。
今回紹介出来ていない対応パターンもあるでしょうし、今後、新たなパターンも生まれてくる事でしょうが、基本は A , CNAME , TXT といったレコード の登録ケースがほとんどで、考え方としては流用が効くものになるかと思われます。
※Amazon Route 53の場合のみ上の内容に加えAlias付き Aレコードの考慮が必要です
一番大切なのは、DNSレコードの登録手順やら業務連携の手法ではなく、
ドメイン管理者として、 登録依頼されたレコードが何故必要なのか？ と そのレコードにはどのような意味があるのか？ を理解したうえで、レコード登録/運用頂く事であると私(執筆者)は考えています。当エントリーが、その理解の手助けとなれば幸いです。
各パターンの細かい技術内容やら仕様についてはAWS公式のドキュメントを合わせてご確認ください。
