[AWS][Terraform]既存のレコードをRoute53で管理する

前回Terraformで既存のレコードをRoute53で管理するためにブログしましたが、今回、ネームサーバーを切り替える前と後に自分の経験上ちゃんと確認手順が明確にできていなかったので、この機会にまとめていきたいと思います。


■adachin.meをtraceしてみる

まず始めにドメインの動きですが、 root-servers.netルートサーバー といい、世界に 13 個しかなく、起点となるサーバになります。ちなみにmが日本管轄のルートDNSサーバで、世界各地に問い合わせをしています。

そこから次は me.nic.me へ問い合わせをし、最後に adachin.me.  の ns1.digitalocean.com. へ問い合わせしていることがわかります。 しかもTTLは 86400秒=最大1日 でNSが切り替わることも確認できます。


■MX/NSレコードを確認する場合

今回はRoute53で管理したい場合、発行されたNSレコード/MXレコードは以下と仮定します。

  • ns-1546.awsdns-01.co.uk.
  • ns-723.awsdns-26.net.
  • ns-1167.awsdns-17.org.
  • ns-211.awsdns-26.com.

結局のところ上記のNSすべて接続できているか、確認をしないといけないので以下のようにdigります。

  • ns-1546.awsdns-01.co.uk.

  • ns-723.awsdns-26.net.

  • ns-1167.awsdns-17.org.

  • ns-211.awsdns-26.com.


■Aレコードを確認する場合

  • adachin.me

  • blog.adachin.me

  • wiki.adachin.me


■TXTレコードを確認する場合

  • adachin.me

これでちゃんと返ってきたら完璧ですな。


■まとめ

しかしNS切り替えは毎回緊張しまくりですね。失敗したらサービス止まるので、ここはちゃんと上記のようにペアで慎重に確認することが大事。ちなみに、最近わたし初心にかえっております。(大事)

あと13個の理由はそもそもDNSはUDPを用いており512バイトのパケットに収める決まりになっており、13個分の*.root-servers.netとIPv4のIPアドレスまでなら512バイト中、ぎりで収めることができるからだそうだ。


カテゴリー: DNS

adachin

1989年生まれのFindy/SRE。ホスティングから大規模なアドテクなどのインフラエンジニアとして携わる。現在はサービスの信頼性向上、DevOps、可用性、レイテンシ、パフォーマンス、モニタリング、オブザーバビリティ、緊急対応、AWSでのインフラ構築、Docker開発環境の提供、IaC、新技術の検証、リファクタリング、セキュリティ強化、分析基盤の運用などを担当している。個人事業主では数社サーバー保守とベンチャー企業のSREインフラコンサルティングやMENTA/TechBullで未経験者にインフラのコーチング/コミュニティマネージャーとして立ち上げと運営をしている。また、過去「脆弱性スキャナVuls」のOSS活動もしており、自称エバンジェリスト/技術広報/テクニカルサポート/コントリビュータでもある。

0件のコメント

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください