2.4 リソースレコード つまり社長が A 部門というゾーンを A 部長に委任していたように、ルートネームサー バに任せることを委任と呼びます。 このように自身が任されているゾーンを分割して、その一部のゾーンを他のネームサー リソースレコードには次 ( 表 2. I) のように A レコードや MX レコードといった種類 は 03 一〇〇〇〇一〇〇〇〇」といったリソースレコードがあるのです。 うゾーンの中には「 B さんの携帯番号は 090 一〇〇〇〇一〇〇〇〇」や「 B さんの自宅番号 の C さんは B さんというゾーンを管理してます。そして C さんが管理する B さんとい 先ほどの会社の例で言うと、 A 部長は A 部門というゾーンを管理していて、マネージャ ドを書くことができます。 「 staging. startdns. fun とそれに紐づく IP アドレス」のようにたくさんのリソースレコー とそれに紐づく IP アドレス」や「 www.startdns.fun とそれに紐づく IP アドレス」、 をリソースレコードと呼びます。たとえ tistartdns. fun のゾーンの中には「 startdns. fun そしてこのゾーンの中にある「ドメインと IP アドレスの紐づけ」ひとつひとつのこと 帳が管理している範囲を前述のとおりゾーンと呼びます。 「 example.com の電話帳」のようにドメインごとに分かれています。この一冊一冊の電話 ネームサーバのお腹の中にある電話帳は管理しやすいように 「 startdns. fun の電話帳」 2.4 リソースレコード り、任されたゾーンをさらに分割して他のネームサーバに委任したりできます。 ているネームサーバは、そのドメインについて権威を持つので、サフ。ドメインを作った バは . fun というゾーンを a. nic. fun に委任していた、ということです。ゾーンを委任され リソースレコードのタイプ値の意味 を表 2.1 リソースレコードの種類 があり、それぞれ書き方も決められています。 A レコード CNAME SOA TXT (SPF) MX レコード NS レコード ドメインに紐づく IP アドレス ( 例 : ウェブサーバ ) ドメインのゾーンを管理するネームサーバ ドメインに紐づくメール受信サーバ このドメインのメール送信元サーバ ドメインのゾーンの管理情報 このドメインの別名でリソースレコードの参照先 それぞれのリソースレコードをどういうときに使うのか ? については第 3 章「 AWS の ネームサーバ (Route53) を使ってみよう」や第 4 章「 dig と whois を叩いて学ぶ DNS 」 で具体例を見て、手を動かしながら確認していきましよう。 67

第 4 章 dig と whOis を叩いて学ぶ DNS レコードは名前解決に使われることなく無視されてしまうのか、あるいは使われるのか動 作が全く保証されません。 このような理由から Route53 をはじめとするネームサーバのサービスでは、 CNAME レコードを設定した場合は他のリソースレコードが設定できないようになっています。 また「ありとあらゆるレコード」には CNAME レコードも含まれるため、次のように CNAME レコードを複数設定することもできません。 campaign. example . CO 爪 . campaign ・ example . com. IN IN CNAME CNAME cdnl . example ・ jp ・ cdn2. example ・ jp ・ ZONE APEX は CNAME を使えない 122 * 31 startdns . fun. IN CNAME cdn. example ・ jp ・ す。 * 33 Route53 の Alias の他に CloudFIare の CNAME Flattening など類似のサービスはいくっかありま ' 32 Elastic Load Balancing の略。 AWS のサービスの 1 つでいわゆるロード . バランサーのことです。 Domain や NakedDomain 、ホスト名なしドメインなどと呼ばれることもあります。 レジストラやリセラで買ったいちばん短い表記のドメインのことを ZONE APEX と呼びます。 Apex startdns. fun や example. jp のように www や stg といったサブドメインを含まないドメインのこと。 ができるのです。 * 33 Route53 の AIias レコードという独自拡張を使うと ZONE APEX でも CDN を使うこと や ELB * 32 を使いたいと思っても ZONE APEX では使用できなかったのですが、なんと には NS レコードと SOA レコードが必ず存在する」という 2 つの制限から、たとえ CDN 前述の「 CNAME レコードは他のリソースレコードと共存できない」「 ZONEAPEX Route53 の AIias レコードなら ZONE APEX でも設定可能 SOA レコードと NS レコードが自動生成されていたのを覚えていますか ? ) です。 ( お名前.com で自分のドメインを買った後、 Route53 でホストゾーンを作成したら および「このドメインの管理情報はこれだよ」という SOA レコードが必ず存在するから ZONE APEX には「このドメインはこのネームサーバを使うよ」という NS レコード、 なぜならば CNAME レコードが他のリソースレコードと共存できないのに対して、 と思っても、次のような CNAME レコードは設定できないのです。 ZONE APEX*31 では CNAME を設定することができません。筆者が CDN を使いたい 前述の℃ NAME レコードは他のリソースレコードと共存できない」という理由から、

第 5 章トラブルシューティング 解答 C. 変更後の IP アドレス ( 203.0.113.222 ) が間違っていることが原因 答え 正解は A です。 TTL は Time ToL ⅳ e の略でキャッシュ保持時間のことです。 TTL に書いてある秒数が過ぎるまで、フルリゾルバにはこのリソースレコードがキャッシュと して残ります。 example. net の変更前の A レコードは TTL が 604800 秒、つまり 7 日間になっている ため、 C さんが A レコードを書き換えてからも最大 7 日間はフルリゾルバに古い IP アド レスがキャッシュされており、そのフルリゾルバを使っているユーザには古いサイトが表 示されてしまうのです。 人や端末によって異なるフルリゾルバを使っているため、 C さんのスマホでは新しいサ イトが見られますが、クライアントのパソコンではまだ古いサイトが表示されてしまう、 といった現象が起こります。古いウェブサーバでリダイレクトの設定をすればいいんじゃ ない ? と思われるかもしれませんが、古いウエプサーバに来たアクセスを example. net にリダイレクトしたところでまた古いウエプサーバにリクエストが飛んでくるだけですの で、何の意味もないどころか無限リダイレクトでブラウザがエラーになってしまいます。 キャッシュが消えるまでの時間を逆算して考えると、そもそも C さんはリニューアル 日である 5 月 1 日の 8 日以上前に example. net の A レコードの TTL を 300 程度まで短 くしておいて、当日 IP アドレスを書き換えたらすぐに反映されるようにしておくべきで どうしてもキャッシュを今すぐ消したい ! という場合、もし C 社の情シスが自社のフ ルリゾルバを管理しているのであれば「フルリゾルバのキャッシュをクリアして ! 」と頼 めばキャッシュがなくなって、ネームサーバへ改めてリソースレコードを問い合わせに 行ってくれますが、それでリニューアル後のサイトが表示されるようになるのは C 社内 だけの話です。世界中にあるフルリゾルバすべてに対してキャッシュクリアをお願いして まわるわけにはいかないので、クライアントも C 社もキャッシュが消えるまで大人しく 7 日待っしかありません。 事前に TTL を確認した上で短くしておくことで、無駄に「浸透」を待たなくて済みま すし、 TTL を過ぎても新サイトに切り替わらなければ何か他に問題があるのでは ? と気 づくことができます。サイトリニューアル時は変更対象のリソースレコードの TTL を事 130

4.4dig を叩いてリソ 解答 ースレコードを確認してみよう 正解は A です。ただし B も CNAME レコードとその A レコードが返ってくるので、 B も正解で構いません。 CNAME レコードは CDN 、 29 を使うときによく利用されます。 $ dig kidokid. bornelund. co. JP cname + short b0 て nelund ー ELB ー 1960389134. ap-northeast-l. elb. amazonaws . com. CDN を使う場合だけでなく、 1 台のウェフ。サーバに大量のサイトが相乗りしているよ うな場合も CNAME レコードを使うと便利です。たとえばウエプサーバにサイト A 、サ イト B 、サイト C ・ ・と計 100 サイトが相乗りしていてそれそれ A レコードを設定し ていた場合、ウエプサーバを引っ越すとなったら 100 件の A レコードを書き換えなけれ ばなりません。ですが、 A レコードを設定しているのはサイト A のみで、それ以外のサ イトは CNAME でサイト A のドメインを指定するという方法にしておけば、サーバ引っ 越しに際して書き換えなければならないのはサイト A の A レコードのみです。 4.4.12 CNAME と他のリソースレコードは共存できない 一見便利な CNAME レコードですが使用する際は注意点があります。それは 「 CNAME レコードを設定したら、他のリソースレコードは設定できない」という ことです。 たとえば次のような CNAME レコードと MX レコードは共存ができません * 30 campaign ・ example. com. campaign ・ example ・ com. IN IN CNAME MX cdn. example ・ jp ・ mail .example.com/ campaign.example.com の CNAME レコードで cdn. example. jp を設定すると、 A レ コードだけでなく MX レコードも TXT レコードも NS レコードも、ありとあらゆる リソースレコードが cdn. example. jp を参照しに行ってしまいます。そのため 2 行目で campaign.example.com の MX レコードで mail.example.com を設定しても、その MX 、 29 Contents DeIivery Network の略。アクセスしてきたエンドユーザに最も近いサーバからサイトのコン テンツを効率的に配信できる仕組みのこと。 CDN を使うとエンドユーザからのアクセスが分散されるた め、 TVCM や LINE 砲で一気にアクセスが殺到してもサイトが落ちたり重くなったりしないで済みま す。 、 3 ( ) A CNAME record is not allowed to coexist with any other data. http : //www. ietf.org/rf c/ rfC1912. txt 121

第 3 章 AWS のネームサーバ (Route53) を使ってみよう AmazonVPC 」にしてしまうと AWS 内での名前解決しか出来なくなり、外から聞かれ ても何も答えてくれなくなってしまいますので、必ず「 PubIicHosted Zone 」にしておい てください。入力完了したら℃ reate 」を押します。 項目 = 表 3.1 ホストゾーン作成時の設定 入力するもの Domain Name お名前.com で買った自分のドメイン Comment Type 何も入力しない Public Hosted Zone これで Route53 というネームサーバの中に自分のドメインのゾーンが出来て、 の中にドメインのネームサーバを示す NS レコードと管理情報を示す SOA レコードとい ソーン うリソースレコードも出来ました。 ( 図 3.22 ) 飛′、 4M00 ( 00 い ←の 0 図 3.22 ・フィートハック 0 日本第 朝 0 0 リソースクループ いをを代をを物員 NS C 0 0 ・引まは物 自分のドメインのゾーンとその中のリソースレコードが出来た 3.3.2 自分のドメインのネームサーバが何か確認 てみましよう。 ではこれで自分のドメインのネームサーバが Route53 になったのか、ちょっと確認し 84 https : //www. cman ・ jp/network/support/nslookup. html * 7 【 DNS サー . バ接続確認】」、 7 というべージを開きます。 ブラウザの別タブで「 dig 」を検索 ( 図 3.23 ) して、一番上の「 nslookup(dig) テスト

3 C H A P T E R AWS のネームサーバ ( R 。 e53 ) を 69 自分のドメインのゾーンやリソースレコードを作ってみましよう。 この章では AWS の Route53 ( ルートフィフティースリー ) という DNS サービスで 第 2 章「 DNS の仕組み」では DNS の仕組みを学びました。 第 1 章「ドメインと Whois 」で自分のドメインを買って、 使ってみよう

5.6 < トラブル > AWS で突然ドメイン名が引けなくなった ネームサーバが死んでしまったときのために TTL を長くしておいたつもりでも、 AWS まです ) 秒にして返す * 8 ようです。 ( 逆にリソースレコードの TTL が 60 秒より短い場合はそのま 139 https : //dev. classmethod. jp/c10ud/aws/dig¯route53-begginer/ * 8 要です。 では他の環境より早くキャッシュが切れて異なる挙動になると思われますので、注意が必

4.4dig を叩いてリソ 解答 ースレコードを確認してみよう 答え 正解は A です。次のように dig コマンドを叩くと「 awsdns 」という文字を含むネーム サーバ名が返ってくるので、ネームサー . バが AWS の Route53 であることが分かります。 $ dig herbgarden-sf . com ns + short Ⅱ s ー 390. awsdns-48. co 用 . ns ー 1487. awsdns—57. org. Ⅱ s ー 1984. awsd Ⅱ s ー 56. co . Ⅱ k . れSー692. awsdns—22. net . ゾーンの中のリソースレコードを確認するには AWS のマネジメントコンソールにログ インする必要がありますが、 A 、 VS アカウント名やパスワードまではさすがに dig では分 からないので、そこはなんとか過去資料から探してください。また Route53 にはホスト ゾーンの工クスポート機能がないので、リソースレコードを 1 つ 1 つコピーベーストする か CLI * 22 を駆使して取得する必要があります。 4.4.7 SPF レコード (TXT レコード ) A さんが B さんに手紙を書くとき、封筒の差出人欄に℃さんより」と書けば簡単に 送信元を騙ることができます。メールもそれと同じで、送信元のメールアドレスを詐称し て送信することは容易です。迷惑メールの多くはこのように送信元を詐称しているなりす ましメールです。 このとき送り主が本物なのか、あるいは自分の持ち物でないドメインで送信元を詐 称して勝手にメールを送っている「なりすましメール」なのかを確認する手段として、 SPF*23 レコードというものがあります。 SPF レコードは次の dig コマンドで確認でき 115 * 23 Sender Policy Framework の略。 コマンドラインからも操作できます。 * 22 コマンドラインインターフェイスの略。 AWS はプラウザでぼちぼち操作するだけでなく、 CLI を用いて $ dig ドメイン名 txt + short

第 4 章 dig と whOis を叩いて学ぶ DNS 生 4.9 PTR レコード A レコードは前述のとおりドメインから IP アドレスを正引きできるレコードです。対 して IP アドレスからドメインを逆引きできるレコードのことを PTR レコード * 26 と呼び $ dig —x IP アドレス + short きません。この IP に対して PTR レコードを設定できるのは、 IP アドレスの持ち主であ 203.0.113.222 だったとして、この IP の PTR レコードを Route53 で設定することはで ですが、たとえばさくらインターネットの VPS で借りたサーバの IP アドレスが で設定ができます。 用しているので、 startdns. fun の A レコードや MX レコード、 SPF レコードは Route53 ます。筆者は startdns. fun というドメインを持っており、ネームサーバは Route53 を使 と、 PTR レコードのような IP アドレスのリソースレコードは設定依頼をする先が異なり なお A レコードや MX レコードや SPF レコードといったドメインのリソースレコード PTR レコードは次の dig コマンドで確認できます。 きができること」という条件も満たさないと迷惑メールと判断することがあります。 ドに登録されていること」だけでなく「メール送信元の IP アドレスからドメインの逆引 メールを受信するメールサーバによっては「メール送信元の IP アドレスが SPF レコー 152. 195.38.205 CS1018. wpc. omicroncdn. net . $ dig aibO ・ sony ・ jp a + short んな風にドメインと IP アドレスが返ってくることがあります。 ときどきドメインから IP アドレスを引こうとして dig で A レコードを調べたのに 4.4-10 CNAME レコード るさくらインターネットの管理画面からとなります。 118 https : //aibo. sony ・ jp/ * 27 * 26 poinTeR record の略 然関係のなさそうなドメインが出てくるのでしよう ? 十 short オプションを外して、この なぜ aibo のサイト、 27 の A レコードを調べると CS1018. wpc. omicroncdn. net という全

第 3 章 AWS のネ ームサー バ (Route53) を使ってみよう 、 0 n 引似 ) ku 似 d テスヨ DNS サーバ X ←ー ) 0 CMAN ( り第い第 NnetworKS usp マネーンメント勲視サービス ーハ : ・プー呱メッ〒支ノ〔いチュい・ク エヌネットワークス Q 、 ハー監視 / ネットワーク監視サービス Ⅲ浦対応学 ! 導、まて 3 分 無料サーパー監襯サービス サーパメンテ支彦 ルアドし・ス確調 にドメイン / 棧 に寸い ~ トチェンク S S チ 1 ッ : ′ [ 爪 S チェッ ? ー N らチェ : ・ク HT 丁チェック い日本語ドメイン変 もアドしフー覧 当用語集 ロ監視は作、・ . …ュアル 害・メンテ去ンス 当社他リイト」山を 0 R コード作成 田 ns okup ( dig ) テスト【 DNS サーバ接続確認】 自動設定 : 第から指現在丐げア こ指定のホスト名の DNS 問い合わせ (r 。 ku 既 d ) を行い結果を表示ます . ロ ョブンヨン ( 仕意 ) d を電十一ドをする NS : 正式なネームリーバ ーイ : : 物物、ヨ = 0 塰」また一 ; 第 ) 2 1 6 3 0 1 」 startdns. fun ホスト名 ( FODN ) を指定してくたさい D N s サーバを指定する場合 ( 任意 ) 毋料「 ~ 利用いたたドまづな「をな れ slook p 実行 洋を・制約事項」を確認下い d 実行 図 3.37 再び自分のドメインのネームサーバを調べる 「 dig 実行」を押したら、ちょっと下にスクロールして確認結果の ANSWER SECTION というところを見てください。次のように表示されていればネームサーバはちゃんと Route53 へ切り替わっています。 ANSWER SECTION : startdns . fun . 3600 IN startdns.fun . 3600 IN startdns . fun. 3600 IN startdns . fun . 3600 IN NS NS NS NS Ⅱ s ー 1072. awsdns-06. org. Ⅱ s ー 1605. awsdns—08. co . uk. nSー177. awsdns-22. com. ns ー 943. awsdns-53. net . よく DNS の変更は「浸透に時間がかかる」と言われますが、これは TTL に指定され 96 りますし、事前に TTL を短くしておくことで反映にかかる時間を短くすることもできま しておけば、最大でどれだけ待てば新しいリソースレコードの情報に切り替わるのか分か 理屈さえ分かれば「浸透」はただ闇雲に待っ必要はありません。変更前の TTL を把握 だ古いサイトが表示される、といった現象が起こります。 たときに、 Web 制作会社の A 社は新しいサイトが見られるがクライアントの B 社ではま フルリゾルバを使っているため、たとえばサイトリニューアルで A レコードを書き換え め、新しいリソースレコードの情報が反映されない、ということです。人によって異なる た時間が過ぎるまではフルリゾルバに古いリソースレコードのキャッシュが残っているた