DNS_システム設計ノート 3

一.DNS とは何か？

DNS（Domain Name System）はインターネットの電話帳に相当し、ドメイン名（www.example.com）を IP アドレス（93.184.216.34）に翻訳できます：

Address book for all of internet.

技術的な観点から言えば、DNS は階層型分散データベースに、いくつかの既定プロトコルを加えたもの です。データベースの照会と更新メカニズム、異なるサーバー間でのデータベース情報の複製メカニズム、およびデータベーススキーマ（Schema）を含みます

DNS architecture is a hierarchical distributed database and an associated set of protocols.

P.S.階層型データベースの他に、関係型データベースと網状データベースがあります

二.DNS の由来

DNS はインターネットの初期に由来し、当時のインターネットはアメリカ国防総省（the United States Department of Defense）が研究目的で構築した小規模なネットワークでした。HOSTS ファイルを通じてネットワーク内の各コンピュータのホスト名を管理し、この HOSTS ファイルは集中管理サーバーに置かれ、ホスト名を解決する必要がある各サイトはこのファイルをまずダウンロードする必要がありました

ネットワーク内のホスト数の増加に伴い、HOSTS ファイルの更新プロセスで発生するトラフィックとファイルサイズの 문제가徐々に露呈しました。そこで、柔軟に拡張でき、様々なデータタイプをサポートする分散ホスト名管理システムの構築が期待され、インターネットの重要なインフラストラクチャとなりました

この新しい分散システムが*DNS（Domain Name System）*です

P.S.最初の DNS 仕様は RFC 882 と RFC 883 で、後に RFC 1034 と RFC 1035 に置き換えられ、その後の関連仕様はこれに基づいてセキュリティ、実装、管理などの部分を拡張しました

三.基本概念

ドメイン名

その中で、各部分には対応する名称があります：

ルートドメイン（Root domain）：木の根、名前なしのレベル 1 を表す。例えば www.example.com. 末尾のドット
トップレベルドメイン（Top-level domain）：国、地域、または組織タイプを表すために使用。例えば .com、.edu
セカンドレベルドメイン（Second-level domain）：長さは固定されておらず、個人または組織によって登録される。例えば example.com. 中の example 部分
サブドメイン（Subdomain）：セカンドレベルドメインから派生し、セカンドレベルドメインを保有する組織/個人によって自行作成。例えば www.example.com
ホスト名/リソース名（Host or resource name）：ツリー構造の葉。例えば api.aws.amazon.com 中最左の api

P.S.また、図中の FQND は完全修飾ドメイン名（Fully Qualified Domain Name）を指し、ホスト名とドメイン名で構成され、ツリー構造内のホストの位置を一意に識別できます

トップレベルドメインは DNS を管理するドメイン名登録機関によって維持され、国または地域に応じて各組織に割り当てられます。例えば：

.com：商業組織（Commercial organizations）
.edu：教育機関（Educational institutions）
.org：非営利組織（Non-profit organizations）
.net：ネットワークプロバイダー（Networks (the backbone of the Internet)）
.gov：非軍事的政府組織（Non-military government organizations）
mil：軍事的政府組織（Military government organizations）
arpa：リバース DNS（Reverse DNS）
.**：2 文字の国コード。例えば .us、.au、.ca、.fr

mydomain.microsoft.com.（末尾ドット.はルートドメインを表す）を例に：

リソースレコード

リソースレコード（resource record、略称 RR）が DNS データベースを構成し、一般的には以下の種類があります：

A レコード（Address record）：アドレスレコード。ドメイン名を IP アドレスに向ける
AAAA レコード（IPv6 address record）：IPv6 アドレスレコード。IPv6 をサポートする A レコードに相当
CAA レコード（Certification Authority Authorization）：認証局認可レコード。どの CA 機関がドメインに証明書を発行することを許可されているかを指定するために使用
CNAME レコード（Canonical name record）：別名レコード。あるドメイン名を別のドメイン名、または其它の CNAME レコード、A レコードに向ける
MX レコード（Mail exchange record）：メール交換レコード。メッセージを受信するメールサーバーを指定。複数のメールサーバーがある場合、それぞれの優先度を指定可能
NAPTR レコード（Naming Authority Pointer）：正規表現を通じてドメイン名をマッチングおよび置換することを許可。例えばネットワーク電話システムがユーザーが入力した電話番号を SIP URI に変換
NS レコード（Name server record）：ドメイン名サーバーレコード。ドメイン名とサブドメイン名の解決に使用する DNS サーバーを指定
PTR レコード（PTR Resource Record）：PTR レコード。IP アドレスをドメイン名に向ける。CNAME との違いは直接終了して結果を返すことで、主にリバース解決（IP によるドメイン名逆引き）に使用
SOA レコード（Start of authority record）：DNS 権限情報を指定。主ドメイン名サーバー、ドメイン管理者のメールボックス、ドメインシリアル番号などを含む
SPF レコード（Sender Policy Framework record）：送信者ポリシーフレームワークレコード。早期にはメール送信者の身元を検証するために使用されたが、廃止され、TXT レコードでの代替を推奨
SRV レコード（Service locator record）：汎用サービスロケータレコード。サービスが所在するサーバー（ドメイン名とポート番号）を指定。主に SIP（Session Initiation Protocol、セッション開始プロトコル）に使用
TXT レコード（Text record）：テキストレコード。文字列に使用

その中で、CAA レコードは証明書のセキュリティメカニズムの一種で、CA 機関は証明書を発行する際に CAA レコードをチェックし、認可されていない場合はそのドメインへの証明書発行を拒否します。詳細は DNS Certification Authority Authorization を参照

注意、NS レコードと SOA レコードは理解しにくく、DNS の構造に関連しています。詳細は後文の構造部分を参照

P.S.その他数百種類の DNS レコードタイプについては、List of DNS record types を参照

例えば：

# A 記録
$ dig -t A ayqy.net
ayqy.net.		600	IN	A	121.42.135.10

# CNAME 記録
$ dig -t CNAME www.baidu.com
www.baidu.com.		600	IN	CNAME	www.a.shifen.com.

# NS 記録
$ dig -t NS ayqy.net
ayqy.net.		86400	IN	NS	dns10.hichina.com.
ayqy.net.		86400	IN	NS	dns9.hichina.com.

# MX 記録
$ dig -t MX ayqy.net
ayqy.net.		600	IN	MX	10 mxw.mxhichina.com.
ayqy.net.		600	IN	MX	5 mxn.mxhichina.com.

P.S.その中で 2 列目は上記で言及したキャッシュ関連の TTL（Time-to-Live）値で、単位は秒

ルーティングポリシー

基本的なマッピングルールの他に、DNS サービスはいくつかのルーティングポリシーをサポートする可能性があります。例えば：

重み付きルーティングポリシー（Weighted routing policy）：指定された重み値に応じて優先度でトラフィックを配信。A/B テスト、ブルーグリーンデプロイメントなどのシナリオに使用可能
遅延ベースルーティングポリシー（Latency routing policy）：遅延状況に応じてドメイン名を解決。例えば遅延が最小の IP を選択
地理位置ベースルーティングポリシー（Geolocation routing policy）：ユーザーの地理位置（各国、各大州など）に応じてドメイン名を解決
地理位置近接度ベースルーティングポリシー（Geoproximity routing policy）：ユーザーの所在地とターゲットリソースの所在地の近接度に応じてドメイン名を解決
フェイルオーバー・ルーティングポリシー（Failover routing policy）：アクティブ - パッシブフェイルオーバーモードに使用。1 つの IP に問題が発生した後、別の IP に切り替え
多値応答ルーティングポリシー（Multivalue answer routing policy）：シンプルな DNS レイヤーロードバランシング。1 対多マッピングを設定可能。そこからランダムに選択

P.S.ルーティングポリシーの詳細については、トラフィックポリシーの作成と管理を参照

四.構造

DNS ドメインスペースはゾーン（Zone）に分割されて管理され、ゾーンは DNS サーバーの管轄範囲に相当します

ゾーン

1 つの DNS データベースは複数のゾーンに分割され、各ゾーンはドメインスペース内の連続した部分のリソースレコードとその owner 情報を含み、形成される*ゾーンファイル（Zone files）*は DNS サーバーによって維持され、1 つの DNS サーバーは 0 から複数のゾーンを管理できます

各ゾーンは特定のドメイン名に対応し、そのゾーンのルートドメイン（Root domain）と呼ばれ、ゾーンにはゾーンのルートドメインで終わるすべてのドメイン名情報が含まれます。ゾーンファイル内の最初のレコードは SOA（Start of Authority）リソースレコードで、そのゾーン内の最良の情報源である主 DNS ドメイン名サーバー、および情報更新に関連するいくつかのタイマー（Refresh Interval、Expire Time など）を識別します

委任

ゾーン内のドメイン名は、別の DNS サーバー上にある別の��ーンに委任できます。*委任（Delegation）*は DNS スペースの一部を別の DNS サーバーに担当させるプロセスで、例えば別の組織、部門、またはワークグループです。この委任関係は NS リソースレコードを通じて識別され、レコード内には委任されたゾーンとそれに対応する権威サーバーのドメイン名が指定されます

クロスゾーン委任は DNS の最初の設計目標の 1 つで、以下を満たすために：

1 つの DNS ドメインの管理作業を複数の組織または部門に委任
大きな DNS データベースの維持作業を複数の DNS サーバーに分散し、ドメイン名解決パフォーマンスとフォールトトレランスを向上
組織の所属関係に応じて、ホストを適切なドメインの下に配置

クロスゾーンでドメイン名を解決する必要がある場合、NS レコード内のターゲットゾーンの DNS サーバーに問い合わせます

例えば、microsoft.com. は microsoft.com と mydomain.microsoft.com の 2 つのゾーン管理に委任されています：

五.実装原理

複製メカニズム

ドメインスペース内の同一部分は複数のゾーンで表すことができ、以下に分けられます：

主ゾーン（Primary）
補助ゾーン（Secondary）
スタブゾーン（Stub）

ゾーン下のすべてのレコードの更新は主ゾーンで発生し、補助ゾーンとスタブゾーンはどちらも読み取り専用の主ゾーンのコピーで、違いはスタブゾーンが権威サーバー（これら 3 つのゾーンをホストする DNS サーバー）を識別するためのレコードのみを含むことです。主ゾーンをホストする DNS サーバーはそのゾーンの主 DNS サーバーで、補助ゾーンをホストする DNS サーバーは補助 DNS サーバーです

主 DNS サーバー（または補助 DNS サーバー）上のゾーンファイルは複数の DNS サーバーに複製でき、このプロセスは*ゾーン転送（Zone transfer）*と呼ばれ、転送方式は 2 種類に分けられます：

プッシュ：主 DNS サーバーはゾーンファイルが変化した時、1 つまたは複数の補助 DNS サーバーに通知
プル：補助 DNS サーバー上の DNS サービスが起動した時、およびゾーンファイルの更新間隔が期限切れになった時、補助サーバーは積極的に主 DNS サーバーに変化を問い合わせ

転送されるデータ量に応じて以下に分けられます：

全量：AXFR（A Full Zone Transfer）。すべてのレコードを転送
増分：IXFR（incremental zone transfer）。変更されたレコードのみを転送

照会メカニズム

DNS 照会は DNS クライアントと DNS サーバー、および 2 つの DNS サーバー間で発生し、一般的には特定のドメイン名の一連のレコードを一度に照会します。例えばそのすべての A レコード

具体的には、DNS 照会は 2 種類に分けられます：

再帰照会（Recursive）：DNS サーバーは関連する其它の DNS サーバーに連絡する必要がある
反復照会（Iterative）：DNS サーバーはローカルデータに基づいて応答し、もし本当に解決できない場合、否定応答を返す

前者は主に DNS クライアント（DNS リゾルバなど）と DNS 転送サービスで使用され、ローカルデータ（ローカルゾーンファイルおよび以前の照会結果のキャッシュ）のみでは解決できない場合、ルート DNS サーバーに上昇します（転送サービスはまずソースサーバーに上昇）。後者は主に DNS サービスがそのドメイン外のドメイン名を照会する際に使用され、この時複数の外部 DNS サーバーに問い合わせないと解決できない可能性があります

www.whitehouse.gov を例に：

具体的な照会プロセスは以下の通り：

クライアントがローカル DNS サーバーに再帰照会（A レコード）を開始
ローカル DNS サーバーがルート DNS サーバーに反復照会（A レコード）を開始
ルート DNS サーバーが .gov ドメイン名サーバーの参照（A レコード）を返す
ローカル DNS サーバーが .gov ドメイン名サーバーに反復照会（A レコード）を開始
.gov ドメイン名サーバーが whitehouse.gov ドメイン名サーバーの参照（NS レコード）を返す
ローカル DNS サーバーが whitehouse.gov ドメイン名サーバーに反復照会（A レコード）を開始
whitehouse.gov ドメイン名サーバーが反復照会に応答（www.whitehouse.gov の IP アドレス）
ローカル DNS サーバーが最初の再帰照会に応答（www.whitehouse.gov の IP アドレス）

P.S.その中で、参照（DNS Referral）は間接的な答えを指します：

DNS Referrals. The term referral indicates a response to a query which does not contain an answer section (it is empty) but which contains one or more authoritative name servers (in the Domain Authority section) that are closer to the required query question.

詳細は DNS Referrals を参照

キャッシュメカニズム

リソースレコード内の TTL（Time-to-Live）値はそのレコードの有効期限に相当し、其它の DNS サーバーは TTL に基づいてこの情報をどのくらいキャッシュするかを決定します。もしレコードが自身の TTL を指定していない場合、DNS サーバーは SOA レコードからデフォルト TTL を継承し、其它の DNS サーバーがリソースレコードを拡張キャッシュすることを防ぎます

クライアントの DNS リゾルバも受信した DNS 照会結果をキャッシュし、キャッシュ期間も TTL に従います。DNS サーバーはキャッシュで照会に応答する時、キャッシュの TTL を引き渡し、受信側は受信した TTL 値を基準とし（自身の TTL でリセットせず）、リソースレコードが正常に期限切れになることを保証します

TTL を設定する際は、キャッシュ情報の正確性、および DNS サーバーの効用とネットワークトラフィックの問題を考慮する必要があり、これら 2 つは少し衝突します。もし TTL が短すぎると、古い情報が現れる可能性は低下しますが、DNS サーバーの効用問題とトラフィック問題が現れ、TTL が長すぎると、キャッシュ情報が古くなる可能性があり、リゾルバが間違った結果を返す可能性を意味しますが、効用問題とトラフィック問題を軽減できます

P.S.DNS キャッシュおよび更新の詳細については、DNS Processes and Interactions を参照

これで、DNS の内外がすべて明確になりました