Route 53 の名前の由来と DNS の雑学 - なぜ 53 なのか、なぜ UDP なのか
Route 53 の名前がポート番号 53 と米国の国道 Route 66 に由来する経緯から始め、DNS がなぜ UDP ポート 53 を使うのか、DNS 解決の裏側で何が起きているのかを雑学的に解説します。
Route 53 の名前に隠された二重の意味
Amazon Route 53 の「53」は、DNS が使用する TCP/UDP ポート番号 53 に由来しています。DNS のリクエストとレスポンスは、デフォルトで UDP ポート 53 を使用します。「Route」の部分は、DNS がドメイン名を IP アドレスに「ルーティング」する機能を表すと同時に、米国の有名な国道「Route 66」へのオマージュでもあります。Route 66 はシカゴからロサンゼルスを結ぶ歴史的な幹線道路で、「アメリカの大動脈」と呼ばれました。Route 53 も同様に、インターネットのトラフィックを正しい宛先に導く「インターネットの大動脈」という意味が込められています。AWS のサービス名には、このような技術的な意味と文化的な意味の二重構造を持つものがいくつかあります。ちなみに、実在する US Route 53 はウィスコンシン州の短い州道で、Route 66 ほどの知名度はありません。
DNS はなぜ UDP ポート 53 を使うのか
DNS が UDP を使用する理由は、1983 年に DNS が設計された当時のネットワーク環境に遡ります。当時のインターネットは帯域幅が極めて限られており、TCP の 3 ウェイハンドシェイク (SYN → SYN-ACK → ACK) による接続確立のオーバーヘッドは無視できないコストでした。DNS のクエリとレスポンスは通常 512 バイト以下の小さなデータで、1 往復で完結します。TCP の接続確立に 3 パケット、データ送受信に 2 パケット、接続終了に 4 パケットの計 9 パケットが必要なのに対し、UDP なら 2 パケット (クエリ + レスポンス) で済みます。ポート番号 53 が割り当てられた経緯は、IANA (Internet Assigned Numbers Authority) のポート番号割り当ての歴史に関係しています。1983 年に DNS が RFC 882 と RFC 883 で標準化された際、当時まだ空いていたポート番号 53 が割り当てられました。ポート番号 1〜1023 は「ウェルノウンポート」と呼ばれ、主要なプロトコルに予約されています。HTTP が 80、HTTPS が 443、SSH が 22 であるのと同様に、DNS は 53 です。ただし、DNS レスポンスが 512 バイトを超える場合 (DNSSEC のレスポンスなど) は TCP にフォールバックします。
ブラウザに URL を入力してから何が起きているのか
ブラウザに example.com と入力してからページが表示されるまでの間に、DNS 解決は複数の段階を経ます。まず、ブラウザは自身の DNS キャッシュを確認します。キャッシュになければ、OS の DNS キャッシュ (macOS の場合は mDNSResponder、Linux の場合は systemd-resolved) を確認します。OS のキャッシュにもなければ、設定された DNS リゾルバ (通常は ISP の DNS サーバーか、8.8.8.8 のような公開 DNS) にクエリを送信します。DNS リゾルバは、自身のキャッシュを確認し、なければ再帰的な名前解決を開始します。まず、ルート DNS サーバー (世界に 13 クラスター) に「.com の権威 DNS サーバーはどこか」を問い合わせます。次に、.com の権威 DNS サーバーに「example.com の権威 DNS サーバーはどこか」を問い合わせます。最後に、example.com の権威 DNS サーバー (Route 53 の場合は ns-xxx.awsdns-xx.com) に「example.com の IP アドレスは何か」を問い合わせます。この 3 段階の問い合わせが、キャッシュがない場合の DNS 解決の全体像です。各段階のレスポンスには TTL (Time to Live) が設定されており、TTL の期間中はキャッシュが有効です。
Route 53 のエイリアスレコード - AWS 独自の発明
Route 53 のエイリアスレコードは、DNS の標準仕様にはない AWS 独自の機能です。標準の DNS では、ドメインの頂点 (Zone Apex、例: example.com) に CNAME レコードを設定できません。RFC 1034 で、Zone Apex には CNAME と他のレコードタイプを共存させてはならないと規定されているためです。しかし、CloudFront ディストリビューションや ELB のエンドポイントは動的な DNS 名 (d1234.cloudfront.net など) で提供されるため、Zone Apex からこれらのサービスを指すには CNAME が必要です。Route 53 のエイリアスレコードは、この問題を解決するために発明されました。エイリアスレコードは Route 53 の内部で DNS クエリを解決し、最終的な IP アドレスを A レコードとして返します。クライアントから見ると通常の A レコードと区別がつきません。エイリアスレコードのもう一つの利点は、Route 53 から AWS リソース (CloudFront、ELB、S3 ウェブサイトホスティングなど) へのエイリアスクエリが無料であることです。通常の DNS クエリは 100 万クエリあたり 0.40 USD ですが、エイリアスクエリは課金されません。Azure DNS や Google Cloud DNS にはエイリアスレコードに相当する機能がなく、Zone Apex の CNAME 問題は各社が異なるアプローチで対処しています。
DNS の障害がインターネット全体に波及する理由
DNS はインターネットの基盤中の基盤であり、DNS が停止するとほぼすべてのインターネットサービスが利用不能になります。2016 年の Dyn DNS への大規模 DDoS 攻撃では、Twitter、Netflix、GitHub、Spotify など多数のサービスが数時間にわたってアクセス不能になりました。これらのサービス自体は正常に稼働していましたが、DNS が応答しないためにユーザーがサービスの IP アドレスを解決できなかったのです。Route 53 はこの種の障害に対して、いくつかの対策を講じています。第 1 に、Route 53 の権威 DNS サーバーは世界中に分散配置された Anycast ネットワーク上で動作しており、特定の拠点への攻撃が全体に波及しにくい構造です。第 2 に、Route 53 は 100% の可用性 SLA を提供する数少ない AWS サービスの一つです。この SLA は、DNS クエリに対して正しい応答を返すことを保証しています。第 3 に、Route 53 のヘルスチェック機能により、バックエンドのサーバーが障害を起こした場合に自動的に正常なサーバーにトラフィックを切り替える DNS フェイルオーバーが可能です。DNS の仕組みとネットワーク設計を体系的に学ぶには、専門書籍 (Amazon)が参考になります。