第 4 章 dig と whOis を叩いて学ぶ DNS $ dig ドメイン名 ns + short 4.4.6 問題 【ドリル】他社へのサイト移管時にネームサーバの所在が不明 あなたは Web 制作会社 A 社でボタニカルシャンプーのサイト (https : / / herbgarden-sf . com/) の運用を担当しているエンジニアです。 ( 図 4.4 ) ートフガーデン特新半新モ : ターキャン X ← - ) 侖 ①命 h : 物円わ g 誕 den - 、f.com ・ 0 合 0 人気家用オ - カ = ックシマンプー【きく一”ハープカー子 子供の頃のような髪のツハリ・コシを取り戻すために 図 4.4 ボタニカルシャンプーのサイト このたびクライアントの意向でサイトの運用を A 社からライバルの B 社へ移管するこ とになりました。クライアント経由で B 社から「 DNS も弊社管理のネームサーバに移管 するので現状のゾーン情報をください」と言われたのですが、インフラに関する資料がな くてネームサーバがどこにあるのか分かりません。このドメインのネームサーバはどこに あるのでしようか ? A. AWS の Route53 B. Microsoft の Azure DNS C. IDCF クラウド DNS 114

第 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

5.3 サイト移管の AtoZ ています。 EC2 上でリニューアル後のサイトが完成してテストも完了したら、 5 月 1 日に B 社が Route53 で example. net の A レコードの値を 203.0.113.111 から 203.0.113.222 に書き 換えてやればサイト移管は完了です。 このようにドメインの管理→ネームサーバ→ウェフ。サーバの順で移管することで、移管 元の A 社の負担が少なくなり、移管先である B 社が主体となって移管作業を進められる ようになります。逆の順番 ( ウェフ。サーバ→ネームサーバ→ドメインの管理 ) で移管を進 めようとすると、 5 月 1 日の A レコード書き換えも B 社から A 社に頼まなければならな いし、お名前.com のネームサーバにあるリソースレコードの情報もいちいち A 社が B 社 に渡してあげないといけません。 【ドリル】リニューアル後のサイトが人によって表示されない 5.3.1 問題 ドメインの管理やネームサーバの変更は 4 月上旬に済ませたし、 EC2 上で動いている 新サイトもテストはばっちりです。 5 月 1 日のサイトリニューアル当日、 B 社の C さんは Route53 で example. net の A レコードの値を 203.0.113.111 から 203.0.113.222 に書き 換えた後、手元のスマホでサイトを開いてリニューアル後のページが正しく表示されるこ とを確認してからクライアントに「リリース完了」の電話をしました。ですが電話の向こ うのクライアントは「え、古いサイトが表示されるんですけど・ ・ ? 」と困惑気味です。 慌ててパソコンのプラウザでサイトを見ると、確かにリニ ーアル前の古いサイトが表 示されました。別のオフィスにいるデザイナーにチャットで「ちょっとサイト見てくれな い ? 古いやつが出てる ? 」と聞いたところ「こっちではちゃんと新しいサイトが表示さ れてますよ ? 」と返事が来ました。 先ほど C さんが書き換えたリソースレコードは以下のようになっていました。 変更前 example. net . 変更後 example. net . 604800 300 IN IN A A 203.0.113. 111 203.0.113.222 人や端末によって古いサイトが表示されたり、 れたりする現象の原因は次のどれでしようか ? リニューアル後の新しいサイトが表示さ ・ A. 変更前の TTL ( 604800 ) が長いことが原因 ・ B. 変更後の TTL ( 300 ) が短いことが原因 129

1 .9 Whois とは 答え 解答 正解は A です。 A 社のウエプサイトですので基本的には A 社 ( クライアント ) の情報 を記載すべきです。 Whois 情報は誰でも見られるため、広告代理店の B 社や Web 制作 会社の C 社が請け負っていることを公にしてはいけないような守秘義務のあるケースで うつかり Whois が B 社や C 社になっていると、見る人が見れば「 A 社のサイトは B 社 や C 社が関わっているんだ」と分かってしまいます。 * 21 一方で Whois 情報は前述のとおりトラブルがあったときの連絡先として公開されてい るものなので、実際何かトラブルがあればそこに連絡が来ます。先ほどの 2 週間無視した らドメイン利用停止になる「ドメイン情報認証」のメールも、 Whois のメールアドレス宛 に送られてきます。また SSL 証明書を購人するときにも Whois の連絡先に対して「この ドメインの SSL 証明書を発行していいですか ? 」という確認メールが届きます。あるい はドメインの管理を B 社から別の広告代理店 D 社へ移管するようなときにも「 D 社に移 管していいですか ? 」という確認メールが届きます。 クライアントである A 社にそうした技術的な問い合わせや連絡が来ても困ってしま ・という場合は社名や担当者名などは A 社にしておいて、メールアドレスだけは A 53 //nlab. itmedia. co. jp/n1/artic1es/1411/24/news015. html サイトも、 Whois から NPO 法人が関わっていることが明らかになって炎上していました。 http : * 21 2014 年に NPO 法人が小学 4 年生になりすまして作った「 # どうして解散するんですか ? 」という privacy protection service by onamae.com 」と出るので個人情報を晒さなくて済みます。 Whois 情報公開代行を使えば、 Whois の所有者の欄には自分の名前の代わりに「 Whois るサービスで、一般的にはプロキシサービスやプライバシーサービスと呼ばれています。 これは Whois 上で表示される組織名や連絡先を代理でお名前.com の情報にしてくれ ど出てきた「 Whois 情報公開代行」というサービスです。 バシーを守るため個人情報を Whois に載せたくない」という人のためにあるのが、先ほ を買ったとき自宅の住所や名前を Whois に載せるのは抵抗があります。そこで「プライ 仕事の場合は前述のように Whois に正しい情報を登録すべきですが、個人でドメイン 1 .9.6 プライバシーを守るための Whois 情報公開代行 が得策でしよう。 社に作ってもらったメーリングリスト ( メンバーに B 社や C 社が入っている ) にするの

1 .9 Whois とは 」 PRS WH 〇でドメインの所有者情報を見てみよう ドメインは大文字小文字の区別をしない . 4 2 4 / 1 .9.2 1 .9.3 1 .9.4 1 .9.5 1 .9.6 Wh 。 is の項目はレジストリごとに微妙に違う Wh 。 is を正確に登録しなければいけない理由 < トラブル > ドメイン情報認証メールを無視して全サイトが停止 【ドリル】 Whois に登録すべきなのはクライアントの情報 ? 4 / プライバシーを守るための Wh 。 is 情報公開代行 1 . IO . co. ip は国内企業しか買えないドメイン 1 .10.1 【ドリル】 . co. ip ドメインは 2 つ買える ? 1 . 1 1 ドメインの有効期限が切れるとどうなるのか ? 1 . 1 1 . 1 < トラカレ > ドロップキャッチされたイオンシネマ 1 . 1 1 . 2 【ドリル】ドメインを手放してよい条件は ? 1 . 1 2 ドメインを買ったらサイトが見られるか ? 当 6 5 9 CHAPTER2 2.1 2.2 2.3 2.4 DNS とは 2.1 .2 フルリゾルバ 2.1 . 1 ネームサーバ 7 .62 お名前.com のページが表示されるまで リソースレコード ゾーンと委任

1 .8 実際にお名前.com でドメインを買ってみよう 1 .82 くトラブル > ドメイン自動更新の落とし穴 前述のとおりドメインは 1 年ごとに更新されます。対してクレジットカードは基本的に 有効期限が 5 年です。 たとえばとある広告代理店 A 社でクライアント B 社の新製品サイト用にドメインを 買ったとします。本来であればきちんと経理を通して請求書払いで購人すべきですが、 サービスインまで日もなかったためディレクターの C さんが「後で経費精算すればいい や」と考えて自分の個人クレジットカードで買い、 Web 制作会社 D 社とウエプサーバを 運用している E 社へ「ドメインは買っといたからこれを使って」と伝えました。 ディレクター C さんがドメインを買った 2 年後に転職して会社を去り、そこからさら に 3 年後に C さんのクレジットカードの有効期限が来ました。お名前.com からは再三に 渡って「与信に失敗して決済できなかったよ ! クレジットカード情報を新しくして ! 更 新しないと期限切れちゃうよ ! 」というメール * 14 が届きますが、宛て先は辞めてしまっ た C さんのメールアドレスなので A 社の人は誰も気づきません。 そしてある日ドメインの期限が切れて、突然 B 社の新製品サイトが見られなくなり、お 問い合わせメールも届かなくなって一体何が起きた ? ! と大騒ぎになります。 「サーバが落ちたのか ? 」「いいや落ちていない ! 」「調べたらドメインの期限切れらし いぞ、早く更新しなければ ! 」「誰だ ? 誰がドメインを更新してたんだ ! 」「クライアン トの B 社か ? 委託先の D 社か ? 」「いいや、ドメインだしサーバを面倒みてる E 社じゃ ないのか ? 」「それともうちか ? 」と A 社の中はてんやわんやです。 後任ディレクターの F さんが過去のメールをひっくり返して調べた結果、ようやく「ド メインは 3 年前に辞めた C さんが買っていたらしい」と分かりましたが、 F さんは直接 C さんに面識がありません。まして退職直後ならまだしも C さんが A 社を辞めてから既 に 3 年が経過していたため連絡を取るまでがまた大変です。 C さんの連絡先を知ってい る人を探し回って F さんはなんとか C さんを捕まえましたが、 C さんも既にお名前.com ・失効直後だったらまだ買い戻せたドメイン のアカウントやパスワードを忘れており・ は、そうこうしているうちに日にちが経過してまた市場へ売りに出されてしまい、全く関 係のない業者に買われてしまいました。後日、大枚をはたいてなんとかドメインを譲って もらったものの、このトラブルを通してクライアント B 社から広告代理店 A 社への心象 はすっかり悪くなってしまいました いかがでしたか ? 想像しただけで怖いですよね。こんなトラブルを起こさないために * 13 重ねて書いておきますがこのトラブルはフィクションです。登場する A 社や C さんなどの人物・団体・ 名称等は架空であり、実在のものとは関係ありません。 ドメインの期限が切れる 15 日前に自動史新をしようと試み、与信に失敗して「 [ お名前.com ] ドメイン自 動更新与信失敗」という件名のメールが届きます。 * 13 * 14 41

4.4dig を叩いてリソ ースレコードを確認してみよう 4.4.8 【ドリル】どうしてメールが迷惑メール扱いされるの ? 問題 あなたは Web 制作会社 A 社のフロントエンドエンジニアです。小規模なクライアント B 社からの依頼でキャンペーンサイト (http://campaign ・ example. com/) を構築した のですが、後から「問い合わせフォームが欲しい」という追加要望が出てきました。 予算もあまりないためフォームは実装せず、問い合わせのページだけは簡単にフォー ムが作れる外部の ASP サービスを使うことにしました。工ンドユーザがフォームから問 い合わせを行うと、その ASP サービスが B 社とエンドユーザの両方に「問い合わせを 受け付けました」というメールを送ってくれます。このとき送信元のメールアドレスは 「 info@example.com 」です。 ところが B 社の担当者から「問い合わせ受付メールが迷惑メール扱いされて迷惑メー ルボックスに人ってしまう。工ンドユーザの方でも同じ現象が起きているようだ」という クレームが入りました。原因を調査するにはどの dig コマンドを叩くべきでしようか ? A. dig example.com spf 十 short B. dig campaign.example.com txt 十 short C. dig example.com txt 十 short 答え 解答 正解は C です。送ったメールが迷惑メール扱いされてしまうときは「 dig ドメイン名 txt 十 short 」で SPF レコードを確認しましよう。 SPF レコードには、そのドメインでの メール送信を許可されているサーバのリストが書かれています。 今回、問い合わせ受付メールが迷惑メール扱いされてしまったのは、 SPF レコードに メールを送っているサーバの IP アドレスを追加し忘れたことが原因と思われます。 ASP サービスにメール送信元の IP アドレスを確認して、 SPF レコードに追記しましよう。 117

第 1 章ドメインと Whois が表示されればあとは特に何もしなくて大丈夫です。 メールアドレスの有効性認証フォーム Authentication Form Of the VaIidity Of the e-mail address メールアトレスの有効性を確認させていたたきました。 お申込み時のこ登録情報においはありませんか ? ご登録情報に不備がございますと、以下のようなケースが懸念されます , 今一度こ登録報をこ確認ください。 各情報の確・修正等はご利用のドメイン管理会へご相談くださいますようお囀いいたしま丁。 ・各種こ内がてきす、結妛として大切なドメインの失効を招く可能性があります。 トメイン紛争などに発展したに、所有恆の正当な主張ができない場合かあります。 ・ ICANN ( ※ ) のホリシーのよりドメインのこ利用に期限が生しる場合があります。 ※ ICANN : インターネット上て使用されるドメイン名や IP アドレスといったアトレス資源の割当管理を行う 米国の非常利団体て、トメイン登録業務を行うレジストラ ( 登録業者 ) を公綣する限を持っています。 図 1 .40 メールアドレスの有効性認証フォーム 繰り返しになりますが、この URL を踏まないまま 2 週間が経っとドメインは利用停 止になります。しかも今回買った ( あるいは Whois 情報を更新した ) ドメインだけでな く、 Whois に同じメールアドレスを登録している全てのドメインが同時に利用停止とな りますので注意が必要です。お名前.com でドメインを買ったらこの 2 つを忘れずに行い ましよう。 ・ Whois 情報をきちんと登録する ドメイン情報認証のメールで URL を踏んで正確性確認を行う 1 .9.5 問題 【ドリル】 Whois に登録すべきなのはクライアントの情報 ? とある化粧品メーカー A 社のウエプサイトで使うドメインを、広告代理店の B 社が代 わりに買って、さらにサイトの制作や運用は A 社から Web 制作会社の C 社に委託した 52 C. 実際にサイトの管理を任されているのは C 社だから C 社を登録すべき ・ B. A 社から任されてドメインを買ったのは B 社だから B 社を登録すべき ・ A. A 社のウエプサイトなんだから A 社を登録すべき 場合、 Whois 情報には A 社・ B 社・ C 社のどれを登録すべきでしようか ?

2.1 DNS とは public DNS*2 や CIoudflare の 1.1.1.1 * 3 のようにだれでも無料で使えるオープンリゾル バというものがあります。 2013 年 8 月に OCN * 4 のフルリゾルバが死んで OCN ューザが インターネットに接続できなくなる、 5 障害が発生しました。そのとき「 DNS サーバの設 定を 8.8.8.8 にすれば直るよ」という情報が Twitter で出回りました ( 図 2.1) 。 ネットに繋がらない (OCN) 方へ。ローカル @p 愴 n01431 フォローする ) 4 仮縫 八を『 8.8.8.8 』に設定するとつながるよ。 工リア接続のプロ八ティを開、優先 DNS サー ネサトワーう 朝コーカルエッア場のプ 0 バティ トつ一ク設の第 を = ~ いれ第を氈代ト [ 0 第 [ を - ′い : 物い地 23 : 40 - 2013 年 8 月 23 日 ル 0 瞽讐ま哥ご皛讐 ・ -4 ・イ : 市ーネトフ 0 トユ、バーラルいわ 、イ : ′タ - ネト 10 トコルバージわい : に第 4 外、 ) ドネ , トつ一り第フ日 ) にンター第第 な新パト 1 ケゾよ、一ラ 材ロⅸーネ , トワ・・ク解クライアント この物を工まの項目を第、は第 インターネ , トアうせ ) みし メディアすす第 を代新一 インターネットプコトコルハーシ強ン 4 き ( 0 月外、滝 ) プロバティ ・まの ( サーットのアトレスを、 O 0 をサ - バ - ・の P ドレ 1 を・、 : 第青第を はのをアドレ 1 をメ引 ・アトしスを自をを書すを 0 ) 優第にサーバヨ 代賛 0 サーバ - イ ーー材物 . : 設定を強マい 8 2 , 956 件のリツィート 1 , 296 件のいいね 0 のなま↓ *4NTT コミュニケーションズが運営する日本最大級のインターネットサービスプロバイダ。 https://l . 1 . 1 . l/ja-jp/ * 3 https : //developers. google ・ com/speed/public-dns/ * 2 これは使用するフルリゾルバを故障中の OCN のものから GoogIe PubIic DNS に変更 、図 2.1 DNS サーバを 8.8.8.8 にするとつながるというツィート 63 なったりゲームやアプリなどのサービスが使えなくなったりした、ということです。 * 5 ドメインから IP を引く名前解決ができないことでウエプサーバの IP が分からず、サイトが見られなく

第 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 レコードを書き換え め、新しいリソースレコードの情報が反映されない、ということです。人によって異なる た時間が過ぎるまではフルリゾルバに古いリソースレコードのキャッシュが残っているた