Route53でのサブドメイン移行で「DNSの浸透」神話の裏側を理解した話

現在絶賛リモートワーク(テレワーク)中、ご飯をついつい忘れがちなので、会社のSlackにある「お昼ご飯を報告するチャンネル」に参加してみました。

▲ みんな美味しそうな生活をしている事を知ってしまい、ダメージが大きい

ファストフードのポテト比較のブログが書けそうな、AWS事業本部のShirotaです。最近はバーガーキングのポテトが一番好きです。

Route53上でAレコードの切り替えを検証していた

さて、本題に入る前に今回行おうとした事をシナリオめいた問題仕立てで説明したいと思います。

現在、Route53からオンプレにある本番環境とAWS上にある移行先予定の開発環境に名前解決を行なっています。

▲ 簡単にまとめてみました

開発が完了次第、AWS上にある開発環境を本番環境に移行する予定です。

▲ こう名前解決するようにしたい

さぁ、作業内容をまとめてみて下さい。

……という事で、早速こういったシナリオを解き進めてみたいと思います。

やった事

現在、Route53に登録されているレコードを確認します。

名前	タイプ	値	TTL(秒)
www.hogehoge.com	A	XXX.XXX.XXX.XXX	300
dev.hogehoge.com	A	ALIAS dualstack.hogehoge-alb-XXXXXXXXX.ap-northeast-1.elb.amazonaws.com.	60(ALBの設定に準拠)

dev.hogehoge.com を www.hogehoge.com に書き換えて終わり！……と言いたいところですが、 www.hogehoge.com は既にAレコードかつ、ALIASで無いオンプレミスのレコードが登録されている為に重複する設定が入れられません。
以下のようにしてCNAMEで逃す方法も考えたのですが、結局はdev.hogehoge.comをwww.hogehoge.comに書き換えようとするとAレコード(ALIAS)とCNAMEで重複する為無理でした。

名前	タイプ	値	TTL(秒)
www.hogehoge.com	CNAME	www2.hogehoge.com	300
www2.hogehoge.com	A	XXX.XXX.XXX.XXX	300
dev.hogehoge.com	A	ALIAS dualstack.hogehoge-alb-XXXXXXXXX.ap-northeast-1.elb.amazonaws.com.	60(ALBの設定に準拠)

ダウンタイムの発生は回避し辛いと思い、なるべくダウンタイムを減らす方針で考えてみます。

▲ まずはTTLをいじる

まずは現行のwww.hogehoge.comのレコードのTTLをデフォルトの300秒から60秒に短縮します。
ちょっと短縮した理由としては、「www.hogehoge.com」を完全移行するまでのキャッシュを残しつつ、移行が済んだらキャッシュが消去されるようにしたかったからです。

▲ これで名前を変えればいい感じにいける……と思っていた

その後は、手早く現行の www.hogehoge.com を切り戻し用に退避させ、開発環境をdev.hogehoge.comから本番のサブドメインに変更します。

名前	タイプ	値	TTL(秒)
www2.hogehoge.com	A	XXX.XXX.XXX.XXX	60
www.hogehoge.com	A	ALIAS dualstack.hogehoge-alb-XXXXXXXXX.ap-northeast-1.elb.amazonaws.com.	60(ALBの設定に準拠)

実際にこの作業をやってみました。
書き換え自体は、コンソールから直接でも60秒程度で終わりました。
直後に名前解決が上手くできなかったりもしましたが、無事開発環境がwww.hogehoge.comで解決できるようになりました！

以前のwww.hogehoge.comのキャッシュも切れたので、レコードを削除しておきます。

後掃除も済んだので、これで作業は完了です。

ところで、これいつまで帰ってくるの？

サブドメインの移行でNXDOMAINをdigったらTTLと改めて向き合う事になった(本題)

名前解決が正常にできているのに、digコマンドを叩き続けると断続的に「NXDOMAIN」状態の結果が帰ってきてしまいます。
……そういえば、昔どこかで見かけた話がありました。
それは確か、DNSを馴染ませる為にほげほげ……と言った話でした。
また、DNSの浸透という言葉もよく耳にします。
DNSって化粧水か何かなのかな？
こういうものなのか、と妥協しかけたのですが、digコマンドの結果をもう一度よく見てみる事にしました。

Route53は権威DNSサーバであり再帰的DNSサーバである事から、SOAレコードが存在します。
ここからはSOAレコードを見ながら、今回関係していると思われるパラメータについて説明します。

SOAレコードに答えはある？

一番最後のパラメータ(86400秒)に注目します。
これは、 最小有効期限 (Time To Live、以下TTL) と言い、MINIMAMやNegative cache TTLといった方が分かる方も多いのではないでしょうか。
NXDOMAIN や NODATA と言った、名前解決ができなかった際のネガティブな結果をキャッシュしている時間をここで設定できます。
つまり、先ほどからずっと「NXDOMAIN」が帰ってきてしまうのにはここの設定が響いているのではないかと考えられます。

前述のレコードの、二番目のパラメータこそが現状のキャッシュの残り時間(TTL)を表しているのですが…… 私はレコードを設定してから、役85500秒近く経ってからdigった訳ではありません。
このTTLはどこから？と言った話になります。

補足ですが、digコマンドを用いた際のその他パラメータの読み方は弊社 濱田のブログが分かり易かったので良かったら参考にして下さい。

DNSド素人がdigコマンドとRoute 53を使って、DNSについてあれこれ学んでみた ｜ Developers.IO

そのTTLはどこから？

digコマンドを叩いた結果を振り返ってみると、このTTLは900秒から始まっているように見えました。
では、この「900」という数字はどこから来ているのでしょうか。

ここで、AWS公式ガイドを見てみます。

DNS リゾルバーで NXDOMAIN または NODATA をキャッシュすることは、ネガティブキャッシングと呼ばれます。 ネガティブキャッシングの期間は、次の値にうち小さいほうです。 - SOA レコードの最小 TTL であるこの値。前述の例では、この値は 86400 (1 日) です。 - SOA レコードの TTL の値。デフォルト値は 900 秒です。この値の変更については、「レコードの編集」を参照してください。

Amazon Route 53 がパブリックホストゾーンに作成する NS レコードと SOA レコード - Amazon Route 53

これだな？

先ほど見た設定は、「SOAレコードの最小TTL」の方である事が分かります。
ここで、もう一つのSOAレコードのTTLの値を確認してみましょう。

▲ お前だ！

デフォルト値である900秒になっています。
ここから、公式ガイドにある規則と照らし合わせると、今回NXDOMAINのキャッシュは時間の短いSOAレコードのTTL値である「900秒」になっている事が分かりました。

原因が分かったので解決させる

今回は、サブドメインの切り替え後、不必要にネガティブキャッシュが残っていた為、上記のTTLを300秒に書き換えました。

結果、NXDOMAINが帰って来てしまう時間が15分→5分に短縮されました。
原因が分かってしまえば案外あっさり片がつくものです。

DNSレコードのTTLを変更する時に意識するべき事

さて、ここまで読んでもらったら「とりあえずTTLは短くしておいた方が良いんだな」と思われたかもしれませんが、そうとは言い切れない事を最後にお話ししたいと思います。

端的に説明すると、キャッシュが短くなるという事は、すなわち「リクエストを送る頻度が増える」 という事です。
リクエストを送る回数が増えれば、必然的に負荷もかかるし通信量も増えます。
なので、 キャッシュを早めに無くしたい今回のような状況の時だけ 一時的にTTLを短くしてあげる運用 が楽になるのではないかと思います。

サブドメインを切り替える時に、「切り替えたんだけどDNSの浸透を待たないといけない……」とお悩みな方の助けになれば幸いです。