こんにちは。インフラ担当の小林匠です。
本記事では、「Webエンジニアなら知っておきたい」と題して、Webサービスを支える基盤技術の一つであるDNS（Domain Name System）について解説していきます。

DNSそのものは、普段の開発や運用において意識されることは多くありません。
しかし、環境切り替えや障害対応といった場面では、原因をたどっていくとDNSだった、なんてケースも少なくないと思います。

また、DNSはアプリケーションコードやインフラ構成と比べると、更新頻度が低く、「一度設定したら触らないもの」として扱われがちです。
そのため、問題が発生した際に初めてDNSを意識する、というケースもあると思われます。

本記事では、DNSの仕組みに関する前提知識と併せて、業務に関わるエンジニアが最低限押さえておきたいポイントを中心に整理していきます。

DNSとは何か

DNSは、ドメイン名とIPアドレスを対応づける仕組みです。
私たちは普段、example.comのような人にとってわかりやすい名前を使ってWebサービスにアクセスしていますが、実際の通信はIPアドレスをもとに行われています。 DNSは、この「名前からIPアドレスを変換する」という役割を担っています。

また、IPアドレスを直接指定してアクセスすることも技術的には可能です。しかし、サーバーの入れ替えやスケールアウト、ロードバランサーの追加などにより、接続先のIPアドレスは運用中に変わることがあります。
その度に利用者側が接続先を変更するのは現実的ではありません。 DNSを介すことで、内部のIPアドレスが変わっても同じドメイン名でアクセスし続けることができます。

Webサービスへのアクセスを簡略化すると、以下のような流れになります。

DNSは、アプリケーションの前段に位置する仕組みであり、ここで問題が起きると後続が正しく実装できていてもサービスにはアクセスできません。
DNSで問題が起きるとアプリケーションにアクセスすることすらできないため、仕組みを理解し問題に対処できるようになっておくことが重要です。

DNSの仕組みをざっくり理解する

DNSによる名前解決は、複数のサーバーを経由して行われます。

フルリゾルバー（再帰リゾルバー）
権威DNSサーバー

DNSは世界一巨大な「分散データベース」といえます。
例えば、ブラウザが「example.com」を名前解決するとき、

ルートサーバー（.）→　TLDサーバー（.com）→　権威DNSサーバー（example.com）

というように、反復横跳びのように問い合わせを繋いで行きます。
この裏側の反復横跳びを知っていると、ドメインを取得したばかりの時に「なぜ反映が遅いのか（TLDの更新待ちなど）」が理解できるようになります。

実際、ブラウザから名前解決が行われると、フルリゾルバーが権威DNSサーバーに問い合わせを行い、最終的な回答を取得します。
また、フルリゾルバーは取得した結果を一定時間キャッシュします。
これにより、同じ名前解決が繰り返し行われることを防ぎ、全体の通信効率を高めています。

この一連の流れは通常ユーザーからは見えませんが、障害時や切り分けの際には理解しておくと役立ちます。

詳細なプロトコル仕様についてはRFCに定義されています。

www.rfc-editor.org

よく使われるDNSレコードの種類

実務で特に登場頻度の高いDNSレコードを紹介します。

A / AAAAレコード

Aレコード：IPv4アドレスを指定
AAAAレコード：IPv6アドレスを指定

CNAMEレコード

別のドメイン名を参照するためのレコードを指定

CDNや外部サービスと連携する際によく使われますが、CNAMEを設定できないケース（ルートドメインなど）がある点には注意が必要です。

TXTレコード

文字列を設定できるレコードを指定

ドメイン所有権の確認や、メール認証（SPF / DKIMなど）で利用されることが多く、Webサービス運用においても頻繁に登場します。

TTLとは何か

DNSの話題でよく出てくるのが、TTL（Time To Live）です。
TTLは、DNSの問い合わせ結果をどれくらいキャッシュして良いかを示す値です。
この仕組みによって、DNSサーバーへの負荷軽減や応答速度の向上が実現されます。

一方で、

「設定を変えたのに反映されない」
「人によって見える状態が違う」

といった事象の原因になることもあります。
事前に下げておく、反映までの時間を考慮する、といった運用が重要になります。

メンテナンス前はTTLを下げておくことが鉄則

例えば、TTLが「300(5分)」なら良いですが、「86400(24時間)」のまま切り替えを行うと、古いサーバーにアクセスし続けるユーザーが丸一日残ってしまうことになります。
切り替え作業の数日前にTTLを「60(1分)」など短くしておくことで、当日の切り替えミスによるダウンタイムを最小限に抑えることができます。

DNSトラブルと考え方

DNSが原因のトラブルには、次のようなものがあります。

サービスが突然表示されなくなった
環境切り替え後に一部のアクセスだけ失敗する
HTTPS設定は正しいのに接続できない

こうした場合、

DNS設定が正しいのか
TTLによるキャッシュは残っていないか
参照先のリソースが変わっていないか

といった観点で切り分けを行うことが重要です。

例えば、反映されないと思ったらまず実行するコマンド例です。今回はGoogleのDNSサーバー（8.8.8.8）を明示的に指定しています。

dig @8.8.8.8 example.com

出力結果の一部です。

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52991
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            300     IN      A       104.18.26.120
example.com.            300     IN      A       104.18.27.120

;; Query time: 18 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)

上記コマンドによる出力結果としてわかることは、

status: NOERROR（ステータス）
ここがNOERRORであれば名前解決に成功しています。
もし、NXDOMAINならドメインが存在しない、SERVFAILなら権威サーバー側の問題、といった切り分けができます。
ANSWER SECTION（回答内容）
- IPアドレス：自分が設定した新しいIPアドレスが表示されているかを確認します。(104.18.26.120, 104.18.27.120)
- TTL：これはあと300秒間はキャッシュが有効である、ということを示しています。
SERVER: 8.8.8.8（問い合わせ先）
コマンド実行時に@8.8.8.8を指定することで、自分のPCや社内ネットワークのキャッシュを通さず、Googleの公開DNSサーバーに直接聞きに行っていることを証明しています。