今日はDNS/ネームサーバ周りのことを書いておきたいと思います。DNSのこと、難しくてよくわからない！と思っている方が多いかもしれませんが、ウェブ関係の方はDNSは絶対に習得しておいた方がいい知識です。特にサイトの引っ越しなどをされる方、必須です。
浸透は甘え
僕も駆け出しの頃はクライアントにDNSの浸透で72時間は～（ドヤッ）と説明していましたが、1年後ぐらいにインフラエンジニアの人に教えてもらって覚醒しました。浸透は甘えです。そんなものはなかったのです、ほんとうに。時は2006年、デロリアンがあったら浸透でドヤってた自分を殴りに行きたいですね。
1個目の浸透、TTLという概念を理解せよ
TTL（Time To Live）という概念（概念なのか？）はDNSを理解する上で非常に大切です。TTLは秒単位で設定され、リソースレコード（DNSの設定項目）をTTL時間だけキャッシュして良いよという指示になります。 example.com というWebサイトのサーバのアドレスは XXX.XXX.XXX.XXX だよ！って言う情報は1度読み込むとキャッシュされます。なんでキャッシュしてるかって言うとものすごい遠く（アフリカとか）にネームサーバがあった場合、いちいち聞きに行ってたらサイトの表示にアホみたいに時間がかかるからです。1度聞いたら手近なサーバにキャッシュされます。
キャッシュとか嫌いな人が「TTLなんて短けりゃいいんでしょ？30秒とかにすりゃ良いじゃん！」と思うかも知れませんが、TTLを短くしすぎるといちいち遠く（アフリカとか）のネームサーバに問い合わせが行ってしまいサイトの表示速度が遅くなります（サイト開く前の真っ白な時間が増える）。なので平時はTTL=3600とかになってるわけです。これにより、TTL30なら1時間に120回アフリカまで行かないといけなかったのが、1時間に1回で済むようになるわけです。効率的！
一方キャッシュのデメリットは、値を変えたとしても3600秒修正が反映されないことです。DNSの仕組みではキャッシュクリアなんてできないので絶対に3600秒待たないといけません。なので、頻繁に値を変更するような場合はTTLを短縮しておく必要があります。
さて、サイトの引っ越しをするとき、ネームサーバに設定した、example.com の参照先はXXX.XXX.XXX.XXXのIPアドレスですよーって情報をYYY.YYY.YYY.YYYに変更しますよね。
お名前だとこんな画面で変更するやつですね。このVALUEを変更すると、最大TTL秒だけ反映が遅れます。これが1個目の浸透時間です。なので、TTL3600だと1時間イライラして切り替わりを待ちます。たまに初期値86400みたいなネームサーバもあるので、引っ越しを考えている人は事前確認をおすすめします。長時間のイライラを回避するためには、事前にTTLを60秒程度に短縮して切り替えを行います。こうすると理論的には最大60秒で切り替えが終了します。もちろん、3600のTTLを60にしたら、60というTTL値が反映されるのに最大3600秒は待たないとダメです。でもわかります？浸透ってなんか最大時間がわからないところにゆっくり流れ込んでいくイメージですが、DNSの場合TTLという指定時間が過ぎたらキャッシュが切れるのでフレッシュな情報に書き換わるんですよ。浸透じゃないでしょ？仕様です。だから、TTL過ぎても変更が反映されなかったら、「浸透まだかなぁ」じゃなくて、「おかしいですね、DNSの仕様上はすでに反映されているはずなんですが（ドヤッ！）」って言えるわけです。DNSの仕様語れるのカッコイイ！
これ言うと絶対「いやー、TTL無視するネームサーバなんていっぱいありますから」って言われます（実際何回か言われた）。結論から言うと、あることはあるけど少ないです。なのでレンタルサーバで運営する規模のサイトであればほぼ気にしなくて大丈夫です。いくら無視してるつってもいつかそのうち切り替わるし。
ネームサーバのリソースレコード（AレコードやCNAMEレコード）の変更だけで引っ越しが完了する場合、このTTLだけを気にしていれば引っ越しは秒で終わります。もちろん、事前にhostsの書き換えなどで引っ越し先の設定を確認しておく必要はあります。不確定な浸透時間なんてなかったですよね。TTL秒経過したら切り替わります。
DNS Checker – DNS Propagation Check & DNS Lookupってサイトがあって、ここに検索したいドメインとリソースレコード選んでポチると、世界各地のキャッシュDNSではどんな値が入ってるか確認できるんです。これめっちゃ便利ですよ。なにせ、遠くブラジルとかのDNSだって、TTL60にしてたらちゃんと値が変わりますから。あー、DNSって…頑張ってるんだな、って実感できます。是非、適当なTXTレコードを変更して浸透具合を確認してみてください！
TXTレコードって書いて思ったんですが、よくクロスサイトスクリプティングで爆破予告とかして踏み台にされて捕まったり、予告した大元が捕まったりするじゃないですか。で、まぁオーソドックスなパターンとしては5chあたりに、○日○時に○○に爆○をしかけたぞみたいなことを書くわけです。ですがこれ、ゾーンの編集権限奪われてTXTレコードに爆破予告書かれたらどうなるんだろう？って思いません？やっぱ実行犯は逮捕されるんですかね。公共の場所で誰でも見ることができるんだから逮捕されますよね。「自分のドメインのゾーン情報に身に覚えのないTXTレコードが書き込まれていたら」みたいなサポートページ作らないとダメなんでしょうか。今度法務の人に聞いてみようかな…
って考えると、TXTレコードでプロポーズとか、もういっそCAAレコードでプロポーズとかもできますよね。あなた以外から証明書発行できませんみたいな。うわー！青臭い！CAAレコードで配偶者ロックインするの青臭い！誰かやって！配偶者にdigらせて愛を確かめて！CAAレコード考えた人もこんな用途絶対想像してなかったはずです。
2個目の浸透、Whoisの変更反映時間を理解せよ
Whois情報というのをご存じでしょうか。こういうやつです。コマンドラインから whois example.com とか打てば出てくるやつです。
最近はGDPRのせいでまともな情報が掲載されていません（Whoisには最近マジで苛立ちしか感じないですがまた別の機会にします）が、ここにName Serverという項目があります。ここで、 example.com のネームサーバは ns1.dns.ne.jp だよって定義しているわけです。サイトの引っ越しの場合は、この部分の変更をしろって書いてあるレンタルサーバが非常に多くあります。さくらのレンタルサーバもそうですし（そうしなくても使えるけ…あ、誰か来たかも）、ロリポップやConoHa WINGもそうだったと思います。
Whoisには明確な反映時間が記載されていないことが多く、各社数分～72時間と幅があります。つまり、Whois情報は反映時間が明確ではないわけです。キャッシュ時間が決まってても、設定を反映するバッチ処理間隔とかも関係してるのもあると思います（ごめんなさい、どっかに書いてあったんだけど忘れてしまいました）。
反映時間が明確じゃないってことは、Whoisの情報に依存しなければいいわけです。ここで言うWhoisの情報とはネームサーバのFQDNを指しています。Whoisで指定するネームサーバが引っ越しの際は反映に時間がかかって2つに分かれちゃうわけですが、新ネームサーバ→新レンタルサーバ、旧ネームサーバ→旧レンタルサーバにそれぞれ設定されている状態でWhoisのネームサーバ情報を書き換えるから、新と旧両方にアクセスされる時間が生まれるわけです。
しかし、パターン1でご説明したとおり、ネームサーバ側の設定情報はTTLによって制御できます。つまり、新ネームサーバ→旧レンタルサーバ、旧ネームサーバ→旧レンタルサーバの設定にします。これでどっちのネームサーバにアクセスしても旧レンタルサーバを参照するようになります。まだ引っ越しは終わってませんよ。
この状態でWhoisのネームサーバを新ネームサーバへ変更します。念のため数日放置、つまり名前解決が全て新ネームサーバで行われるようになるまで待ちます。まだ引っ越し終わってませんよ。ここで、新ネームサーバ→新レンタルサーバ、旧ネームサーバ→新レンタルサーバの設定に書き換えます（旧ネームサーバは念のため）。このとき、あらかじめTTLは短めにしておきます。すると、変更所要時間が依存しているのは新ネームサーバのTTLのみになるので、引っ越しは短時間で終了し、浸透・伝播反映待ちをしなくてすみます。不確定なWhoisの反映時間に依存しない引っ越し方法ってわけです。
レンタルサーバの仕様によってできない場合がある
それさくらのレンタルサーバでできねぇだろ！と思った方もいらっしゃるでしょう。そうなんです、大変申し訳ない。さくらの場合はさくらのドメインで買ってないドメインはゾーン編集できないのです。さくら以外でもレンタルサーバの仕様によって、ゾーン情報が編集できない場合があります。なので、先に転入していただく必要があります。お前が言うなよって言われるかもしれませんが、色々事情もありまして、不便なポイントは元々ユーザーだった自分でも理解しております故ご容赦ください。
そういった事情があるので、ドメインはマニュアル☆☆した上で○の△△△の◎◎◎◎◎◎を使って、▲レコードの！＄アドレスや＜＞％＆だけをレンサバに向けて使うのが使い勝手いいんですよね（大人の事情により一部自粛）。ただ、ネームサーバはレンサバのを使わないとドメイン追加できないところもあるので（これはおそらくLet’s Encryptの認証とかで使ってる）、各社の仕様をみつつって感じかと思います。cPanel使ってるところ（mixhostとかカラフルボックスとか）だとゾーン情報は外部持ち込みドメインでも好きに触れるところが多いですね。海外系のレンサバ（SiteGroundとかBluehostとか）もゾーンは自由にいじれる場合が多いので引っ越しするのは楽ちんでした。
権威とキャッシュを理解する
DNSには権威ネームサーバ（とか権威DNSとか権威DNSサーバー）とキャッシュネームサーバ（とかフルリゾルバーとかフルサービスリゾルバーとかキャッシュDNSサーバー）があります。DNSは電話帳みたいなものなので、example.com のIPアドレスってなんですかー！って聞いたら、権威ネームサーバが、XXX.XXX.XXX.XXXですよーー！って返事してくれます。で、1度聞いたらTTL分貯めといてOK。これがDNSの根幹。聞いたら教えてくれる。教えてもらった結果は一定時間貯めておける。ところが、例えばキャッシュがない世界線だとして、 facebook.com の権威ネームサーバへ利用者みんなが問い合わせたらどうなるでしょう？死。DDoSかよ。
というわけで、一度Aさんが問い合わせて結果が帰ってきたらAさんがデフォルトで見てるキャッシュサーバ内に結果が蓄積されて、同じネームサーバを使ってるBさんがアクセスした場合、権威までいかないでキャッシュで名前解決できるわけです。facebook.comのネームサーバが死ななくてすみました。よかった。
この、キャッシュ側でデータを保持して良い時間がTTLなわけです。初回は権威が応答し、次からキャッシュが応答する、TTLが切れたら再度キャッシュ→権威に問い合わせが行き、またTTL分キャッシュするを繰り返すわけです。つまり、TTLを長くするモチベーションは、TTLが切れて権威まで問い合わせが行っちゃってサイトの読み込みが遅くなる人の数を減らせることなんですね。この、キャッシュ時間（TTL）を長くするモチベーションはものすごく重要な概念で、今度書こうと思っているCDNスキルは大事！っていう投稿でも触れる大事なポイントです。
ってわけでDNSについて、主にレンサバ引っ越しの時にフォーカスして書いてみましたが、DNSについてはmochikoAsTechさんのDNSをはじめようっていう本が非常にわかりやすいのでおすすめです。エンジニアじゃない人でも、特になんでも一人でやらなきゃいけないフリーのWeb制作者の方はマジの本気で絶対にDNSを完全に（とは言いませんがある程度）理解するとめちゃくちゃ仕事の幅というか、やれることが広がるはずだし、いままで訳がわからず待たされた時間の意味がわかるのです。これはでかい。というわけで今日はこの辺で。