サイトオープン直前！紙一重のタイミングでDNS Aレコード設定

サイト開設のどれくらい前に DNS Aレコードを設定すべきか

とある大規模アクセスのある Webサイトが、オープンの数秒前ギリギリになって Aレコードを設定しているのを目撃した、
というお話。

あくまでも外からの観測による考察なので、もし実際に試す場合は諸条件に注意したほうが良いと思う。 (少し更新した)

TL;DR

ティザーサイト repusmyt.com のカウントダウン

日本で有名なとあるバンドが 2016年1月8日、十何年ぶりの再結成を発表した。 発表の20日ほど前から、謎のカウントダウンを行うティザーサイト http://repusmyt.com/ が準備されていた（現在はバンドのwebページにリダイレクトされる）。このサイトで巧妙なマウスドラッグをすると、バンドの再結成をほのめかす謎めいた画像がいろいろ現れるようになっており、ファンの間で話題を呼んだ。 カウントが 0 になった時何が起こるのか？ 気になる。様々な噂が飛び交った。 渋谷の東急のビル壁面にでかでかと広告が出ていたらしい。

https://twitter.com/sato_cie/status/684693321185280004

リバースエンジニアリング：現れた新サイトURL

そこで http://repusmyt.com/ の JavaScript をリバースエンジニアリングしてみた。 負荷対策のためか、このサイトは一枚の index.html と CSS と 数枚の画像、 JavaScript のみで構成されており、サーバーサイドには何ら動的な仕組みがなかった。

JavaScript は minify されていたので適当な beautifier にかけたところ、 カウントダウン終了後に http://theyellowmonkey.jp/ という URLに遷移することがわかった（1日前にページ遷移を含む JavaScript に更新されたようだった。また、ソースに URL が露出するのを防ぐため、URL の文字列は並べ替えられていた）。

引けないホスト名

しかし 1月7日時点では、 http://theyellowmonkey.jp/ にはアクセスできなかった。 ホスト名 theyellowmonkey.jp を解決できない。

より正確にいえば、 ドメイン theyellowmonkey.jp は確かに存在したが、そこには SOA レコード以外のレコードがなかった。DNSコンテンツサーバーからは大体こんな感じの応答が返っていた （これは当時取得したわけではなく適当に加工したものだが）:

$ dig -t a theyellowmonkey.jp @ns-659.awsdns-18.net.
; <<>> DiG 9.8.3-P1 <<>> -t soa theyellowmonkey.jp @ns-659.awsdns-18.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37903
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;theyellowmonkey.jp.		IN	SOA

;; ANSWER SECTION:
theyellowmonkey.jp.	900	IN	SOA	ns-659.awsdns-18.net. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 140 msec
;; SERVER: 205.251.194.147#53(205.251.194.147)
;; WHEN: Thu Jan  7 08:00:08 2016
;; MSG SIZE  rcvd: 123

DNS浸透いうな問題

家族がファンだったので、どうなるのか興味深く眺めていた。 はたして、1月8日 0時0分には、 ちゃんと実在するページへリダイレクトされるのか？

よく、 DNS の設定変更をすると「浸透」までに時間がかかる、と言われる。 これは全く誤りであるとされる。

参考： Geekなぺーじ:なぜ「DNSの浸透」は問題視されるのか (6)
参考： 浸透いうな!

ここでも解説されているように、浸透しないと言われるケースのうちの一つは構成ミスによるものだが、他にも、存在しないドメイン名を事前に引いてしまった場合がある。

存在しないドメインを引くと、ネガティブキャッシュの仕組みが働き、しばらくの間はその名前を引いてもコンテンツサーバーへの問い合わせが行われなくなってしまう。 そうなるとキャッシュをクリアするかTTLの時間が経過するまでは、そのホスト名を引いても問い合わせが行われない（上記の dig によれば 900秒=15分 (高橋様より: ご指摘ありがとうございます)）。

しかし今回の場合は、ドメインは存在するが、Aレコードが存在しないというケースだ。 ドメインは存在するのでネガティブキャッシュの対象にはならない…、ような気がする。 また、そもそも私の DNS キャッシュが theyellowmonkey.jp を引けなくなっても、他の人のキャッシュには関係ない。

追記： A レコードが存在しない場合、上のSOA の設定のとおり 900秒 ネガティブキャッシュが効いていたと思われる。

サイト開設直前の Aレコード追加

結局、0時0分の直前に Aレコードが追加され、私と家族が見守るなか ブラウザはうまく http://theyellowmonkey.jp/ に遷移し、更に http://theyellowmonkeysuper.jp/ にリダイレクトされた。 バンド再結成、ツアー決定だそうだ。 やったね！

現在ではこんな応答が返ってくる。確かに Aレコードや NSレコードが追加されている：

$ dig -t a theyellowmonkey.jp @ns-659.awsdns-18.net.

; <<>> DiG 9.8.3-P1 <<>> -t a theyellowmonkey.jp @ns-659.awsdns-18.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58423
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;theyellowmonkey.jp.		IN	A

;; ANSWER SECTION:
theyellowmonkey.jp.	60	IN	A	54.65.36.171
theyellowmonkey.jp.	60	IN	A	54.238.172.35

;; AUTHORITY SECTION:
theyellowmonkey.jp.	172800	IN	NS	ns-1027.awsdns-00.org.
theyellowmonkey.jp.	172800	IN	NS	ns-1884.awsdns-43.co.uk.
theyellowmonkey.jp.	172800	IN	NS	ns-458.awsdns-57.com.
theyellowmonkey.jp.	172800	IN	NS	ns-659.awsdns-18.net.

;; Query time: 65 msec
;; SERVER: 205.251.194.147#53(205.251.194.147)
;; WHEN: Fri Jan  8 22:14:50 2016
;; MSG SIZE  rcvd: 208

うまく遷移できなかった人達

ところで Twitter を検索すると、 DNS エラーでうまくページ遷移できなかった人々もちらほら見られた（アクセス負荷が高いせいで閲覧できない人も多かったようだが）。 この人たちには 浸透しなかった は、ネガティブキャッシュの影響を受けたのだろうか？

これは単に、PC の時計が少し早めに設定されていたため、 Aレコードの設定前に カウントが 0に達してしまい、ページ遷移できなかったのではないかと想像している。多分…

余談： AWS Route53 の SOA シリアル

現在、 theyellowmonkey.jp の SOA を引くと、相変わらず、以前と同じ

theyellowmonkey.jp.	900	IN	SOA	ns-659.awsdns-18.net. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

が返ってくる。 BIND 等で DNS を運用した経験からすると、これは奇妙だ。 DNS のレコードを追加した場合は、シリアル （ここでは 1） がインクリメントされなければ、セカンダリサーバーに変更が反映されないのでは？　上で書いたように、現在は 3台のスレーブのネームサーバーで運用しているように見える。

これは、このドメインが利用している DNSサービス AWS Route53 の仕様によるもので、シリアルが更新されなくても変更がスレーブに反映される仕組みがあるため、シリアルを更新する必要がなかったようだ。

このことを回答する AWS 担当者と、 Route53 はシリアルを自動的に更新すべきであると主張する人物の議論が以下にあった。

https://forums.aws.amazon.com/message.jspa?messageID=221157 (要 AWS アカウント？)

結論など

ドメインさえ準備されていれば、 Webサイトのオープン直前に Aレコードを設定しても問題ないようだ。 ただ、今回は次のような特殊な条件があったことを留意しておきたい。

• AWS Route53 を利用していたため、マスターとスレーブの DNS サーバーを同時に更新できる (でないと スレーブを見に行った人が困る)。
• ドメイン名はほとんどの利用者に知られておらず、サイトオープンと同時に 利用者に通知された。
  • （前もってドメイン名が知られていた場合、不適切に設定された DNS サーバーを利用しているユーザーが解決できなかった可能性がある。）

(追記) ~~「浸透しない」~~ネガティブキャッシュのせいで(?)名前解決できなかったケース

一部のユーザーは (恐らく) 0時0分後のアクセスで実際に DNS エラーで閲覧できないと言っている。

DNSエラーでhttps://t.co/etsIwwZCWlにアクセスできないんですけど

— ゅぅゃ (@you_yah) January 7, 2016

https://t.co/qjaphTykJM DNSエラー返ってくるようだけど…（すでに何があるかは把握済）

— たにみやん (@tanimiyan) January 7, 2016

うちも見られない https://t.co/ZgtCrzPEXr 閲覧にDNSの知識が必要なサイト:-)

— Eijiro Sumii (@esumii) January 7, 2016

https://t.co/tAv1MZrkRC じゃなくて https://t.co/cD9CPOdulD そりゃあ繋がらないわｗリンクが違うんだものｗ

— 老猫ニナコちゃん@Xロス (@oldcatchan) January 7, 2016

これは、

* 事前に theyellowmonkey.jp のドメイン名を知った人々が名前を引いた (そして失敗した)

• その ISP が提供する DNS キャッシュサーバーが theyellowmonkey.jp を不適切にキャッシュしていた
• たまたま、別々のファンが同じ ISP を利用していた

という条件が重なったためであると思われる。（時系列的に、ドメイン名を最初に漏洩したのが私だったのを考えると、私が漏らしさえしなければ完全にうまくいっていた可能性もあるし、ローカルの時計を進めてページ遷移してしまった人も居たかもしれない。）

（以上）