Route 53 の名前の由来と DNS の雑学 - なぜ 53 なのか、なぜ UDP なのか
Route 53 の名前とポート番号 53 にまつわる通説から始め、DNS がなぜ UDP ポート 53 を使うのか、ブラウザに URL を入力してから DNS 解決の裏側で何が起きているのかまでを、雑学を交えて解説します。
Route 53 の「53」はどこから来たのか
Amazon Route 53 の「53」がどこから来たのか、実は AWS の公式資料には明記されていません。サービスの FAQ や公式ドキュメントを探しても、名前の由来を説明した一次資料は見当たらないのです。ただし技術者の間では、DNS が標準で使う TCP/UDP のポート番号 53 に対応する、という説が広く語られています。DNS のクエリとレスポンスはデフォルトで UDP ポート 53 を使うため、この対応づけは技術的に自然です。とはいえ、これはあくまで通説であり、AWS が公式に認めた由来ではありません。「Route」の部分も、DNS がドメイン名を IP アドレスへ「ルーティング」する機能を表すという解釈が一般的ですが、こちらも公式の裏付けがあるわけではありません。名前をめぐる雑学として、実在する US Route 53 にも触れておきましょう。これは州道ではなく国道 (U.S. Numbered Highway) で、ウィスコンシン州ラクロスからミネソタ州インターナショナルフォールズ (カナダ国境) までを結ぶ、約 400 マイル (650 km) の路線です。同じ番号付き国道でも、シカゴからロサンゼルスを結び「マザーロード」「アメリカのメインストリート」と呼ばれた Route 66 ほどの知名度はありません。由来が公式に語られていない以上、これらはいずれも確定した事実ではなく、DNS サービスとしての Route 53 の機能とは切り離して受け止めるのが正確です。
DNS はなぜ UDP ポート 53 を使うのか
DNS が UDP を使う理由は、DNS が標準化された 1980 年代前半のネットワーク環境に遡ります。当時のインターネットは帯域幅が極めて限られており、TCP の 3 ウェイハンドシェイク (SYN → SYN-ACK → ACK) による接続確立のオーバーヘッドは無視できないコストでした。DNS のクエリとレスポンスは通常とても小さく、1 往復で完結します。TCP は接続確立と切断だけでも複数回の往復を要し、実装によってはクエリ 1 件のために 9 パケット前後をやり取りします。一方 UDP なら、基本的にクエリとレスポンスの 2 パケットで済みます。DNS が UDP と TCP の両方でポート 53 を使うことは、IANA (Internet Assigned Numbers Authority) のポート番号割り当てに登録されています。DNS は 1983 年 11 月に RFC 882 と RFC 883 で標準化され、以来ポート 53 が DNS 用に予約されています。ポート番号 1〜1023 は「ウェルノウンポート」と呼ばれ、主要なプロトコルに予約されています。HTTP が 80、HTTPS が 443、SSH が 22 であるのと同様に、DNS は 53 です。なお、元々の DNS 仕様 (RFC 1035) では UDP のペイロードは 512 バイトが上限とされていましたが、現在は EDNS0 (RFC 6891) という拡張により、UDP でより大きなメッセージをやり取りするのが標準です。DNSSEC のように応答が大きくなる場合でも、まずは EDNS0 で拡張した UDP を試み、それでも応答が収まらず切り詰め (TC ビット) が起きたときに初めて、クライアントが TCP で再問い合わせします。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 のエイリアスレコードと Zone Apex 問題
Route 53 のエイリアスレコードは、標準の DNS 仕様にはない拡張機能で、Route 53 が先駆けて提供したものです。標準の DNS では、ドメインの頂点 (Zone Apex、例: example.com) に CNAME レコードを設定できません。これは RFC 1034 が、CNAME レコードを持つノードには他のレコードタイプを共存させてはならないと定めているためです。Zone Apex には必ず SOA レコードと NS レコードが存在するので、その帰結として Apex には CNAME を置けない、という理屈です。しかし、CloudFront ディストリビューションや ELB のエンドポイントは動的な DNS 名 (d1234.cloudfront.net など) で提供されるため、Zone Apex からこれらのサービスを指すには CNAME 的な仕組みが必要になります。Route 53 のエイリアスレコードは、この問題を解決するために作られました。エイリアスレコードは Route 53 の内部で対象の DNS 名を解決し、最終的な IP アドレスを A レコード (または AAAA レコード) として返します。クライアントから見ると通常の A レコードと区別がつきません。エイリアスレコードのもう一つの利点は、Route 53 から AWS リソース (CloudFront、ELB、S3 ウェブサイトホスティングなど) へのエイリアスクエリが無料であることです。通常の DNS クエリは 100 万クエリあたり 0.40 USD ですが、エイリアスクエリは課金されません (2026 年 8 月時点)。なお、Zone Apex から動的なエンドポイントを指す仕組みは Route 53 に固有のものではありません。たとえば Azure DNS も、A/AAAA/CNAME を対象とする「エイリアスレコードセット」を提供しており、通常の CNAME と違って Zone Apex に作成できます。指定できるターゲットは Azure のパブリック IP・Traffic Manager プロファイル・Azure CDN・Front Door などで、1 リソースあたり 50 件までという上限があります。各クラウドがそれぞれの形で Zone Apex 問題に対処しているのが実情です。
DNS の障害がインターネット全体に波及する理由
DNS はインターネットの基盤中の基盤であり、DNS が停止するとほぼすべてのインターネットサービスが利用不能になります。2016 年の Dyn DNS への大規模 DDoS 攻撃では、Twitter、Netflix、GitHub、Spotify など多数のサービスが数時間にわたってアクセス不能になりました。これらのサービス自体は正常に稼働していましたが、DNS が応答しないためにユーザーがサービスの IP アドレスを解決できなかったのです。Route 53 はこの種の障害に対して、いくつかの対策を講じています。第 1 に、Route 53 の権威 DNS サーバーは世界中に分散配置された Anycast ネットワーク上で動作しており、特定の拠点への攻撃が全体に波及しにくい構造です。第 2 に、Route 53 は権威 DNS 応答 (データプレーン) について 100% の可用性 SLA を掲げており、これは AWS のサービスの中でも唯一とされています。ただしこの 100% はあくまでデータプレーン (DNS クエリへの応答) に対するもので、レコードの追加・変更といったコントロールプレーンや、Route 53 Resolver のエンドポイントは別の SLA (除外条項を含む) の対象です。第 3 に、Route 53 のヘルスチェック機能により、バックエンドのサーバーが障害を起こした場合に自動的に正常なサーバーにトラフィックを切り替える DNS フェイルオーバーが可能です。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。