はじめに
技術書典4にて「DNSをはじめよう」が販売され、400部あったはずの紙の本の在庫がなくなり、その後まもなくしてダウンロード用のカードも溶けるようになくなるという現象が発生しました。
自分も午後に会場入りして買いに行ったら「ダウンロード版も売り切れた」と言われショックを受けるものの、ダウンロード版については追加生産をしているとの事なので、ほどなくして再度ブースを伺ったら無事に買う事ができました。
尚、今現在もBOOTHにてPDF版が販売されています。
内容については「さぁDNS！」…の前にドメイン名の取得から丁寧に書いており、ドメイン名の取得からDNS設定の流れを体感するにはちょうどいい本ではないかなと。
なお、ドメインを利用する為にはレジストラやどこかのリセラー経由で登録料を払いドメイン名を登録してもらう必要があり登録手順も様々であるなか、お名前.comからの取得を例にして説明しています。DNSはAWSのRoute53を例に説明。お名前.comとRoute53はたぶん日本ではメジャーな組み合わせじゃないかなと思う。
本を読み進めるといくつか気になる個所が出てきてtwitterにもさらっとつぶやいたものの、それではあまり人の目に触れないと考えてこのように文章としてまとめる事にしました。
内容的には本の内容を更にフォローする感じにしたつもりです。
対象読者
もちろん「DNSをはじめよう」を一通り読んだ方が対象。読んでない方は是非読んでみてほしい。なお、私が読んだのは技術書典4で販売されたもので将来、改版されたら内容が変わっているかもしれないです。各呼称はぶれると混乱すると思うのでなるべく本の記述に合わせています(例…コンテンツ/権威サーバではなくネームサーバと記述)。
本を読んでない状態で見ていただいても構いませんが、ドメインやDNSに関するある程度の知識は必要です。
免責
内容は自分の見解であり無保証です。指摘があればできる範囲で修正します。
第1章ドメインとWhois
co.jpドメインの複数所持について
本の説明の通り今は申請が通れば1組織で複数のco.jpドメインを所持する事ができるようになりました。ただこれは元締めのレジストリがOKしているだけで、レジストラが対応していない事があります。以前、お名前.comにて制限緩和申請を行おうとしたのですが不可と言われてしまい、制限緩和申請ができるレジストラにドメインを移管して対応しました。ちなみにファーストサーバのDoレジを利用しています。
尚、1組織がレジストラを変えて…例えば「レジストラAで1つ目のco.jpドメイン名、レジストラBで2つ目のco.jpドメイン名を取得すればいいのでは？」という事もできません。ばれます(僕はやってないよ！)。
結論としてはもし1組織で複数co.jpドメインを持つ必要が出てきた場合は利用しているレジストラに制限緩和申請が可能かの確認はした方がいいです。ダメだったら別のレジストリを検討しましょう。
それとお名前.comも当時はダメでしたが、今現在はもしかしたら対応しているかもしれません(オンラインで調べる限り判断はつきませんでした)。
第3章AWSのネームサーバ(Route53)を使ってみよう
NSレコードのTTLについて
ネームサーバをお名前.comからRoute53に切り替えるときにNSレコードのTTLについての説明がありますが実はこのTTLは2種類あります。試しにqiita.comのNSレコードを例にdigコマンドで名前解決してみます(digのオプションについての細かい説明は省略)。
$ dig +norec +noall +ans NS qiita.com @ns-171.awsdns-21.com.
qiita.com. 300 IN NS ns-1049.awsdns-03.org.
qiita.com. 300 IN NS ns-171.awsdns-21.com.
qiita.com. 300 IN NS ns-1956.awsdns-52.co.uk.
qiita.com. 300 IN NS ns-772.awsdns-32.net.
$ dig +norec +noall +auth NS qiita.com @e.gtld-servers.net.
qiita.com. 172800 IN NS ns-171.awsdns-21.com.
qiita.com. 172800 IN NS ns-772.awsdns-32.net.
qiita.com. 172800 IN NS ns-1049.awsdns-03.org.
qiita.com. 172800 IN NS ns-1956.awsdns-52.co.uk.
前者のdigはqiita.comのゾーンを管理しているAWSのRoute53に対して問い合わせをしています。こちらのTTLは300になっています。一方、後者のdigどこに対して問い合わせをしているのか、TTLが172800(2日)とやたらと長いです…これはqiita.comより更に上位(親)の.comドメインを管理しているネームサーバに対して問い合わせをしています。
説明の便宜上、.comドメインを管理しているネームサーバを「親ネームサーバ」、qiita.comドメインを管理しているネームサーバを「子ネームサーバ」と呼びます。
ドリル：どっちのTTL？
さてここで問題です。フルリゾルバは名前解決の内容をTTLの期間まではキャッシュしていい事になっています。この場合、フルリゾルバは親ネームサーバと子ネームサーバのどちらのTTLに従うでしょうか。
答え：フルリゾルバの実装依存
…酷い答えではありますが、この挙動はフルリゾルバの実装依存になります。体感的には子ネームサーバのTTLに従う実装が多いです。ただ親ネームサーバのTTLに従うフルリゾルバは存在します(例えばOCNが提供するフルリゾルバは親ネームサーバのTTLに従います)。
親と子ネームサーバの設定者
同じNSレコードの設定が親ネームサーバにも子ネームサーバにもありますが、それぞれの設定者は誰でしょうか。まず子ネームサーバはRoute53を使っていてここでNSレコードが設定されています。次に親ネームサーバについてはレジストラが設定しています。
本の例ではRoute53でドメインの登録をした後、Route53で表示されているNSレコードの設定をお名前.comのネームサーバ情報に登録していますね。この操作を行う事で親ネームサーバのNSレコードが変更されます。
なお、親ネームサーバにNSレコードの登録がないと子ネームサーバをたどる事(反復検索)が出来ないのでこのような仕様になっています。
ネームサーバとWeb/メールの引っ越し
今までの説明でNSレコードについては親ネームサーバと子ネームサーバにそれぞれ存在することが分かりました。
つまりネームサーバを切り替えるときは親と子、それぞれのネームサーバに設定されたNSレコードのTTLを意識する必要があります。
子ネームサーバ側のNSレコードに設定されたTTLについては利用しているDNSサービスにもよりますが、たいていTTLの値を調整する事が可能です。逆に親ネームサーバ側に設定されたNSレコードのTTL変更はできません。.comドメインであれは先程の例の通り172800(2日)、.jpドメインは86400(1日)が設定されており、gTDLごとに若干の違いがあります。
例えばネームサーバとWebサーバの引っ越しが必要になったとしましょう。事前に旧ネームサーバ内の(NSレコードの)TTLを短く設定しておき「いざ、引っ越し！」とネームサーバを新ネームサーバに切り替えた時、自分が設定したTTLの時間を過ぎても旧ネームサーバが参照され、想定より長い期間、古いWebサーバが表示される現象が発生するパターンがあります。
この原因の一つは親ネームサーバ側のTTLに従うフルリゾルバの存在です。
なお、本問題に対してどうすればいいのかというと前述の通り親ネームサーバのコントロールはできないので、対策としては「ネームサーバの引っ越しとその他のWeb/メールサービスの引っ越しは別の日にする」だけです。というかこれ以外に簡単な方法はありません。全部同時に引っ越しもできなくはないですが、たいてい事故るのでやらないほうがいいです。
第4章digをwhoisを叩いて学ぶDNS
digコマンドについて
本にも色々と使い方の説明がありますが、追加で是非覚えてほしいオプションを紹介します。
digは誰に聞いてるの
digコマンドを実行するとどこかのDNSに対して名前解決を依頼しています。さて、いったいどこのDNSに問い合わせているのかというとOSに設定されているフルリゾルバに対して問い合わせを行っています。決してdigコマンド自身がルートネームサーバから名前解決(反復検索)を行っているわけではありません(traceオプションを使った場合は別)。
この「どのDNSに対して問い合わせをするのか」を"@"オプションで指定することができます。例えば有名なgoogleが提供しているフルリゾルバである8.8.8.8に対して問い合わせをしたい場合は次のようなコマンドになります。
$ dig @8.8.8.8 qiita.com
…前略…
;; QUESTION SECTION:
;qiita.com. IN A
;; ANSWER SECTION:
qiita.com. 13 IN A 13.230.77.194
qiita.com. 13 IN A 54.64.239.23
qiita.com. 13 IN A 54.92.17.153
…後略…
digコマンドは色んな情報を吐き出して長いので一部省略してQUESTION SECTIONとANSWER SECTIONだけ載せています。
この"@"によるDNSの指定はフルリゾルバだけではなく、ネームサーバを指定しても大丈夫です(フルリゾルバもネームサーバも同じDNSですので)。
前の項目でqiita.comのNSレコードを調べているので実際にその中の一つ「ns-1049.awsdns-03.org」に対して問い合わせを行った結果が次の内容です。
$ dig @ns-1049.awsdns-03.org qiita.com
…前略…
; QUESTION SECTION:
;qiita.com. IN A
;; ANSWER SECTION:
qiita.com. 60 IN A 54.92.17.153
qiita.com. 60 IN A 54.64.239.23
qiita.com. 60 IN A 13.230.77.194
…後略…
順番はちょっと変わっていますが、いずれのdigコマンドもqiita.comの名前解決について同じIPアドレス3つを返しています。
また上記の 8.8.8.8 と ns-1049.awsdns-03.org を指定したdigコマンドを短時間に連続して実行してみるとある変化に気付くことができると思います。
何が変わっているかというと「数字」です。@で8.8.8.8を指定しているとANSWER SECTIONに書かれた数字がころころ変わります。
qiita.com. 13 IN A 13.230.77.194
上記は「13」になっていますが、digコマンドを実行するたびに変わります。逆にns-1049.awsdns-03.orgを指定していると常に「60」です。
8.8.8.8はフルリゾルバであり、ここに書かれた数字は「実際のキャッシュ保持の残り時間」で1秒経過すると数字が1つ減り0になるとそのキャッシュは使われなくなります。つまりこの数字はTTLです。
googleのフルリゾルバはたくさん存在し、それぞれが独自にキャッシュを持っていると思われるのでdigコマンドを打つたびに違うフルリゾルバが応答するため数字がバラバラですが、自分が契約するISPが提供するフルリゾルバに対して連続でdigを実行すると1秒ごとに数字が減っていくのを確認できるかもしれません(ISP提供のフルリゾルバも複数台で動いていたらgoogleのようになります)。
一方「ns-1049.awsdns-03.org」側のTTL(数字)は変わりません。これはこのDNSがネームサーバだからです。ネームサーバはフルリゾルバにこの数字を伝え、フルリゾルバはこの数字を元にキャッシュ保持期間を制御します。そのためネームサーバのTTLは通常動的に変化しません(変化する仕様をもつネームサーバもありますが)。
+norecurseオプション
フルリゾルバに対してあるドメインの名前解決を依頼した時にフルリゾルバにキャッシュがなければ、ルートネームサーバから反復検索を行い依頼されたドメインのレコードを探そうとします。この反復検索を抑制したい時に使うのが「+norecurse」オプションです。オプションで指定する際は「+norec」と略してもOKです。
(今更ですが名前解決時の反復検索や再帰検索といった動作の違いについてはここでは説明しないので興味がわいた方は是非調べてみてください)
「+norecurse」を使うと対象のフルリゾルバがキャッシュを持っているかの有無を確認でき、もしキャッシュを持っていない時も反復検索が発生しないので新たにキャッシュを持つことがありません。
尚、キャッシュがない時はdigの応答から「ANSWER SECTION」がなくなっています。ANSWERを返そうにも答えを持ってないので当たり前ではありますね。
これが何の役に立つのかというと例えばDNS関連でトラブルが発生した時です。ネームサーバの応答/フルリゾルバの応答を確認しながら調査する事になりますが、digコマンドで問い合わせをしてみるだけでフルリゾルバでは反復検索が発生し内部のキャッシュ情報が書き換わるため、正しい調査が難しくなります。
ネームサーバについては、そもそもネームサーバ自身が反復検索を許可していない事が多く+norecを指定しなくても反復検索する事はありません。
話がそれますがネームサーバが反復検索も受け付けるようになっている場合、ネームサーバ兼フルリゾルバという状態のDNSになっています。この構成は運用上、問題を起こす可能性が高く今は推奨されない構成です(別に昔は推奨されていたというわけではないのですが)。
「DNS キャッシュ 権威 同居」あたりのキーワードでgoogle検索すると色々な情報が見つかります。
話を戻しまして個人的にはdigコマンドを使う場合、+norecは常に付けるようにして必要に応じて外すような使い方がいいと考えています。
その他のオプションやdigの応答の細かい意味について
一つ一つ説明すると相当ボリュームが増えるのでここでは説明しません。
ただdigの応答には前の説明にも登場した「ANSWER SECTION」以外にもとても参考になる情報が山ほど表示されているので、DNSをもっと知るには応答内容の把握は避けて通れない道になります。
ドリル：俺自身がフルリゾルバになる事だ
フルリゾルバは自身のキャッシュに答えを持っていない時は反復検索を行って答えを探しに行きます。
digコマンドを使う事でフルリゾルバと同じ挙動を自分で再現する事ができます(+traceの利用は禁止)。
このドリル、特に答えをここに載せたりはしませんが、俺自身がフルリゾルバになる事ができればDNSの理解はより進むと思います。
DNS浸透問題
書きたいことを書いているうちに自分が当初思ったよりだいぶ長い文章になってしまいました。そして実は一番書きたかったのはこのセクションです。
「DNSの浸透」という言葉を見たとき、DNSがどのように動作することがDNSの浸透になるのか具体的なイメージをお持ちでしょうか。そしてそのイメージはDNSの動作として正しいものなのか、その言葉で関係者が共通の認識を持てるのかを考えていきます。
「DNSをはじめよう」でのDNS浸透の扱い
本の中では一般的に「DNS浸透」と言われる現象についての具体的な説明はなく「TTLによるキャッシュのコントロールができれば浸透を待つ必要はない」という表現になっています。
今回はこの浸透という表現をもっと掘り下げて説明します。
DNSの浸透とは何か
TTLの役割
まず「DNSをはじめよう」の本を読んだことでフルリゾルバが持つキャッシュはTTLでコントロールできる事が分かったと思います。このTTLは名前解決を行ったフルリゾルバに対してネームサーバからの「最大TTLの時間だけキャッシュを持っていていいよ」という依頼事項です。その後のキャッシュのコントロールはフルリゾルバにゆだねられます。
浸透という言葉の定義
次に「浸透」という言葉のイメージを考えます。朝日新聞の「コトバンク」では次のように定義されています。
１ 水などが、しみとおること。「雨水が地下に浸透する」「堤防の浸透破壊」
２ 思想・風潮・雰囲気などがしだいに広い範囲に行きわたること。「新しい生活様式が国民に浸透する」
３ ある液体または気体が、半透膜を通過して、他の液体または気体と混じり合い拡散する現象。「浸透圧」
[参考URL]https://kotobank.jp/word/浸透-82300
まとめると「ある場所に変化が発生した時にそこを中心としてその変化が広がっていく」が浸透という言葉が持つ一般的なイメージになると思います。
DNS浸透の正体
これまでの話でTTLの役割と浸透という言葉に対するイメージが共有できました。
ここで「Webサイト(サーバ)の引っ越し」をしてみましょう。登場するDNSは次の3つです。
- Webサイトのドメインを管理しているネームサーバ(以下、ネームサーバ)
- (作業)担当者が利用しているISPのフルリゾルバ(以降、ISPフルリゾルバ)
- その他世界中のフルリゾルバ(以降、世界のフルリゾルバ)
引っ越し前、現Webサイトのキャッシュを持っているのは世界のフルリゾルバの一部と担当者がWebサイトをちょくちょく見ているのでISPフルリゾルバになります。
この状態で新WebサイトのIPをネームサーバに設定、いわゆるWebサイトの引っ越し作業を行います。
ネームサーバの設定直後、まだ古いキャッシュを持っているISPフルリゾルバのせいで担当者がWebサイトを見ても旧Webサイトが表示されます。これは最大TTLで指定してた時間が経過するまでは新Webサイトは見れません。
仕方ないのでISPフルリゾルバのキャッシュが切れるまで待ちます。なお、ISPフルリゾルバがあとどれだけキャッシュを保持するか(TTLの値)は前に説明している通りdigコマンドで確認する事ができます。
ただ一点手順にミスがありましてWebサイトの引っ越し前にTTLを短くするのを忘れていてISPフルリゾルバのTTLを確認すると、どうもキャッシュが消えるまであと3時間くらいかかりそうです。
仕方ないので3時間待つしかないと思っていたら、途中で眠くなり気付いたら5時間程経過していました。
この時のISPフルリゾルバのキャッシュはTTLの時間を過ぎているのでもうキャッシュを使ってはいけません。ブラウザでWebサイトを開くと無事に新しいWebサイトが表示されました。どうやらISPフルリゾルバは新しい情報をキャッシュしたようです。
さてここで「浸透」と表現できそうな現象がどこかで発生したのかを考えます。浸透は「ある場所に変化が発生した時にそこを中心としてその変化が広がっていく」とイメージした場合、変化が発生したネームサーバを中心としてその変化が広がる必要があります。
ISPフルリゾルバは前に受け取ったデータをキャッシュとして保持し、TTLの期間が過ぎたら使わなくなるだけです。特にネームサーバから「設定変更があったからキャッシュ更新してね」と指示されるわけではありません。新しいキャッシュを保持するきっかけとなったのは寝オチをした担当者が、ネームサーバ設定変更してから5時間後にWebサイトをみるという行為です。「担当者のアクションで浸透したのでは？」と考えるかもしれませんが、担当者のアクションが必要な時点で浸透のイメージから外れているとは思いませんか。またフルリゾルバは新しい設定をキャッシュしますがまたTTLの時間経過するとそのキャッシュは使われなくなります。浸透の「広がる」というイメージからすると広がらないといけないのにいずれ消えてしまいます。
ちなみに担当者がズボラで引っ越しした後にWebサイトの確認自体をしなかったらどうでしょうか。ISPフルリゾルバに新しいWebサイトのキャッシュが入るタイミングがありません。つまり浸透どころか「何もおこりません」。
一旦はISPフルリゾルバという1つのフルリゾルバを例に説明しましたが、世界のフルリゾルバも仕様は同じですしまったく同様の事が言えます。
ネームサーバの設定を変更したからと言ってネームサーバから世界のフルリゾルバに対し「設定変更を通知する」事もありませんし、世界のリゾルバもTTLの期間を過ぎたらキャッシュを使わないようになるため、特段新しい設定が広がっているわけではありません。必要に応じて取得して一時的にキャッシュしているだけです。
上記の通りDNSの動作の観点でみると「浸透」と定義していいような現象は確認できません。
つまり「DNS浸透の正体」なんて書いはいるものの、実はDNSの動作としては存在しない得体のしれない何かを指しているのです。
DNS浸透という表現について
DNS浸透問題について色々と書いてきましたが、最後に「DNS浸透という表現を使うのはOKかNGか」についての見解です。
まず私の見解はDNS浸透という表現はNGの立場です。
理由はいくつかあります。
- 「DNS浸透」の共通認識がない
前述の「DNS浸透の正体」にてDNSの動作自体に浸透と定義していいような現象は確認できないので「DNS浸透」という表現が何を指すのかがはっきりしません。何を指すのかわからないという事は認識を共通する事もできません。
浸透という表現を使うと、受け取った人々がそれぞれが独自に定義した「浸透の動作」が意識内で作られると思います。
(逆にそれを聞き出すのも実験的な感じがして面白いかもしれません…)
- DNSを学ぶ人の妨げになる
これからDNSの勉強を始める人が「DNSの浸透」という言葉のイメージで最初に誤った認識を持ってしまう事を心配しています。
「ネームサーバの設定を変更するとその変更がだんだん浸透していくんだ」と最初に覚えてしまうと、とてもおかしな先入観になるのではと考えています。
- 失敗を有耶無耶にできる
DNSに対する作業をミスした時に「DNS浸透の問題です」という感じのふわっとした言い訳で有耶無耶にする事ができてしまいます。
ある意味いい事なのかもしれませんが、ミスはミスで正しく説明できないと、いつかDNSの動作を正しく理解している担当者に遭遇した時に多分詰みます。
また逆の立場に立ってみましょう。DNS設定変更を依頼する立場です。業者がDNSの設定変更を行っても、一向に新しいWebサイトが見えませんし、業者は「浸透を待つしかありません、仕様です」としか言ってきません。これまでの説明を読んだ皆さんからすると「え？TTLでコントロールできるでしょ？なんか騙してない？」と思いますよね。
代わりの表現について
「DNS浸透がNGならなんていえばいいのか」という話も時々聞きます。DNSの動作の観点からすると「そもそも浸透という現象がないので名前を付ける事ができない」という回答になってしまいます。
※念のため、実は浸透と表現していい現象が別の動作の所ではある…がそれを指して浸透と言う人は少ない
これだと、この話は終わってしまうので「DNSの設定を変更した時にDNS浸透という言葉を使わずにお客さんにどう説明するか」という視点で考えます。
これは実は簡単でDNSの動作をそのままお客さんに説明すればいいだけです。
「DNSはキャッシュを持つので古いキャッシュが有効な間は古い情報が表示される」
「DNSのキャッシュが消えるまでお待ちください」
少し詳しいお客さんだったらDNSをリゾルバと言ってもいいかもしれません。
もしお客さんがDNSの動作について気になって詳しい説明を求めて来たら、続けて説明してあげてください。ここで最初に「DNS浸透」なんて表現をしていたら詳しい説明の時にお客さんが混乱するかもしれませんね。
浸透問題のドリルと参考情報
一通り説明が終わったところでドリルです。
次の画像は昔のアーカイブファイルになります。実際にとあるサイトでDNSの説明に使われていました。
このgif画像はDNSの正しい動作を表しているでしょうか。答えは書かなくてももうわかると思います。
また参考情報として、JPRSでは「DNSの設定ミス」を浸透問題として扱っています。
■DNSの「浸透問題」は都市伝説――正しいサーバー引っ越し法を解説
https://internet.watch.impress.co.jp/docs/event/iw2011/494798.html
■DNS浸透の都市伝説を斬る
https://jprs.jp/tech/material/iw2011-lunch-L1-01.pdf
DNS用語も沢山でてくるのでこの記事よりももう少し基礎知識は必要になりますが、読んでいただけると理解は深まると思います。
あとがき
書いている途中で付け足したい内容が次々に出てきてだいぶ長くなってしまいました。途中まで書いて「これを真面目に説明し始めるとちょっとした本になるのでは…」と思って消したところとかあります。DNS浸透問題に関する説明もなるべくわかりやすくしてみたつもりです。
なお、途中に特に説明していない単語や説明を唐突に出しているのは一部わざとです。気になる方は各自調べてほしいと思っています。この手の知識は自発的に調べる事で理解も進みますので。それとRFCについてはあえて触れていません。気になる方は調べてみてください。一言で言うと"沼"です。余談ですがSMTPも同じく沼です。
あと好き勝手書いていますが、本文は全て現在の自分の考えです。これを読んでそのまま鵜呑みにせずに自分なりに解釈した上で知識にしてほしいです。ネットには間違った情報もたくさんあります、この文章もそんなネットの情報の一部です。お気を付けください。
最後にDNSの本を執筆された @mochikoAsTech さん、本当に執筆お疲れ様です＆ありがとうございました。ドメイン名の登録から詳しく説明する本って今までなかったなというところで、丁度足りないところを埋めてもらえた本だなと感じています。
好き勝手に色々と書いてしまいましたが、もし問題等ありましたら連絡ください。
5/4追記
「ドメインの購入」という表現をドメイン名の登録に修正しました。利用したいドメインの名称がドメイン名であり、ドメイン名は買うわけではなく登録料を支払い一定期間利用できるようになるもので、購入だと未来永劫ドメインを保有するニュアンスを含んでいるためです。
詳しい定義はJPNICのサイトをご覧ください。
■ドメイン名の登録
https://www.nic.ad.jp/ja/dom/registration.html
5/5追記
DNS浸透問題に少し追記しました。意図がうまく伝わっていない気がしたので。
また「浸透」という表現に頼ることでDNSの色々なことが見えなくなります。せっかくDNSの知識をつけるならば正しい知識をつけていきたいですよね。
浸透を使うことによる具体的な問題については次のサイトも大変参考になります。必要なDNSの前提知識も増えてくるので次へステップアップする感じで見ていただければと思います。
■「浸透」でごまかすことの弊害
http://www.e-ontap.com/dns/propagation/harmful.html
5/13追記
DNS浸透問題を修正しました。
大きな変更として「DNS浸透の本当の正体」を削除して、代わりにドリルを追加しています。