DNS ゾーンとレコードの概要

この記事では、ドメイン、DNS ゾーン、DNS レコードおよびレコード セットの主要な概念について説明します。 それらが Azure DNS でどのようにサポートされているかについて説明します。

ドメイン名

ドメイン ネーム システムはドメインの階層構造です。 階層は、'.' という名前の root ドメインから始まります。 その下には com、net、org、uk、jp などのトップ レベル ドメインがあります。 さらに、トップレベル ドメインの下には org.uk や co.jp などの第 2 レベル ドメインがあります。 DNS 階層のドメインはグローバルに分散していて、世界中の DNS ネーム サーバーでホストされています。

contoso.com などのドメイン名は、ドメイン名レジストラーという組織から購入できます。 ドメイン名を購入すると、www.contoso.com という名前で会社の Web サイトを表示するなど、その名前で DNS 階層を制御する権限が付与されます。 レジストラーは、ユーザーの代わりに独自のネーム サーバーでドメインをホストしたり、代替ネーム サーバーを指定したりできます。

Azure DNS では世界各地に分散された高可用性ネーム サーバー インフラストラクチャを提供しており、お客様はこれを利用してドメインをホストできます。 Azure DNS でドメインをホストすることで、他の Azure サービスと同じ資格情報、API、ツール、課金情報、サポートを使用して DNS レコードを管理できます。

Azure DNS では、現在、ドメイン名の購入はサポートされていません。 年会費をお支払いになると、App Service のドメインまたはサードパーティのドメイン名レジストラーを使用して、ドメイン名を購入できます。 購入したドメインは、Azure DNS でホストし、レコードを管理できます。 詳細については、「Azure DNS へのドメインの委任」を参照してください。

DNS ゾーン

DNS ゾーンは、特定のドメインの DNS レコードをホストするために使用されます。 Azure DNS でドメインのホストを開始するには、そのドメイン名用に DNS ゾーンを作成する必要があります。 ドメインの DNS レコードはすべて、この DNS ゾーン内に作成されます。

たとえば、ドメイン "contoso.com" に、"mail.contoso.com" (メール サーバー用) や "www.contoso.com" (Web サイト用) など、複数の DNS レコードを含めることができます。

Azure DNS に DNS ゾーンを作成する場合:

• ゾーンの名前がリソース グループ内で一意であること、および作成するゾーンがまだ存在していないことが必要です。 それ以外の場合は、操作が失敗します。
• 同じゾーン名は、別のリソース グループまたは別の Azure サブスクリプション内であれば再利用できます。
• 複数のゾーンで同じ名前を共有できますが、各インスタンスには異なるネーム サーバー アドレスが割り当てられます。 ドメイン名レジストラーで構成できるアドレスのセットは 1 つだけです。

注意

自社で所有していないドメイン名でも、Azure DNS 内にそのドメイン名で DNS ゾーンを作成できます。 ただし、ドメイン名レジストラーでドメイン名の正しい名前サーバーとして Azure DNS ネーム サーバーを構成する場合は、ドメインを所有する必要があります。

詳細については、「Azure DNS へのドメインの委任」を参照してください。

DNS レコード

レコード名

Azure DNS では、相対名を使用してレコードを指定します。 "完全修飾" ドメイン名 (FQDN) にはゾーン名が含まれますが、"相対" 名には含まれません。 たとえば、contoso.com ゾーン内の相対レコード名 www によって、完全修飾レコード名 www.contoso.com が示されます。

DNS ゾーンのルート ("頂点") にある DNS レコードを apex (頂点) レコードと言います。 たとえば、DNS ゾーン contoso.com であれば、apex レコードの完全修飾名も contoso.com です (これを "ネイキッド" ドメインと呼ぶことがあります)。 慣例により、apex レコードを表すには相対名として \'\@\' を使用します。

レコードの種類

各 DNS レコードには名前と種類があります。 レコードは、含まれるデータによってさまざまな種類に分けられます。 最も一般的な種類は "A" レコードで、名前が IPv4 アドレスにマップされます。 また、"MX" レコードもよく使用される種類で、名前がメール サーバーにマップされます。

Azure DNS では、一般的な DNS レコードの種類である A、AAAA、CAA、CNAME、MX、NS、PTR、SOA、SRV、TXT をすべてサポートしています。 SPF レコードは TXT レコードを使用して表されることに注意してください。

委任署名者 (DS) やトランスポート層セキュリティ認証 (TLSA) リソース レコードなど、ゾーンが DNS セキュリティ拡張機能 (DNSSEC) で署名されている場合は、追加のレコードの種類がサポートされます。

DNSKEY、RRSIG、NSEC3 レコードなどの DNSSEC リソース レコードの種類は、ゾーンが DNSSEC で署名されると自動的に追加されます。 これらの種類の DNSSEC リソース レコードは、ゾーン署名後に作成または変更することはできません。

レコード セット

場合によっては、特定の名前と種類の DNS レコードを複数作成する必要があることもあります。 たとえば、"www.contoso.com" という Web サイトが 2 つの異なる IP アドレスでホストされているとします。 この Web サイトには、IP アドレスごとに異なる A レコードが、合計 2 つ必要になります。 次に、レコード セットの例を示します:

www.contoso.com.        3600    IN    A    134.170.185.46
www.contoso.com.        3600    IN    A    134.170.188.221

Azure DNS は、"レコード セット" を使用してすべての DNS レコードを管理します。 レコード セット ("リソース" レコード セットとも呼ばれます) とは、1 つのゾーン内にある同じ名前、同じ種類の DNS レコードのコレクションです。 ほとんどのレコード セットには、1 つのレコードが含まれています。 ただし、上の例のように複数のレコードが含まれているレコード セットも珍しくはありません。

たとえば、ゾーン "contoso.com" に A レコード "www" が既に作成されているとします。この A レコードは IP アドレス "134.170.185.46" (上記の 1 つ目のレコード) を指しています。 2 つ目のレコードを作成する際は、追加のレコード セットを作成するのではなく、そのレコードを既存のレコード セットに追加します。

SOA レコードと CNAME レコードは例外です。 DNS 標準では、これらのレコードの種類で同じ名前を持つ複数のレコードを作成することが許可されていません。そのため、これらのレコード セットにはレコードを 1 つしか含めることができません。

Time-To-Live

Time-to-Live (TTL) は、各レコードが照会されるまでクライアントによってキャッシュされる期間を指定します。 上の例では、TTL は 3600 秒、つまり 1 時間です。

Azure DNS では、TTL は各レコードではなくレコード セットに対して指定されるため、そのレコード セット内のすべてのレコードに同じ値が使用されます。 TTL には 1 秒から 2,147,483,647 秒までの間の値を指定できます。

ワイルドカード レコード

Azure DNS は、ワイルドカード レコードをサポートしています。 ワイルドカード レコードは、一致する名前を含むクエリへの応答として返されます (非ワイルドカード レコード セットに、より近い一致がない場合)。 Azure DNS では、NS と SOA を除くすべてのレコードの種類でワイルドカード レコード セットをサポートします。

ワイルドカード レコード セットを作成するには、レコード セット名に * を使用します。 *.foo のように、名前の左端に * を付けることもできます。

CAA レコード

ドメイン所有者は CAA レコードで、ドメインの証明書を発行する権限のある証明機関 (CA) を指定できます。 このレコードにより、CA が状況によって証明書を誤発行することを防ぐことができます。 CAA レコードには、3 つのプロパティがあります。

• フラグ: このフィールドは 0 から 255 の整数です。RFC6844 ごとに特別な意味を持つ重要なフラグを表すために使われます
• タグ: 次のいずれかの ASCII 文字列。
  • issue: 証明書 (すべての種類) の発行を許可されている CA を指定する場合。
  • issuewild: 証明書 (ワイルドカード証明書のみ) の発行を許可されている CA を指定する場合。
  • iodef: 承認されていない証明書発行要求について CA が通知できるメール アドレスまたはホスト名を指定します。
• 値: 選択した特定のタグの値。

CNAME レコード

CNAME レコード セットは、同じ名前を持つ他のレコード セットとは共存できません。 たとえば、相対名 www を持つ CNAME レコード セットと相対名 www を持つ A レコードを同時に作成することはできません。

ゾーンを作成する際、zone apex (名前は “@”) には常に NS および SOA レコード セットが存在するため、zone apex に CNAME レコード セットを作成することはできません。

これらの制約は、DNS 標準から生じるものであり、Azure DNS の制限事項ではありません。

NS レコード

ゾーンの頂点の NS レコード セット (名前は '@') は各 DNS ゾーンで自動的に作成され、ゾーンが削除されると自動的に削除されます。 個別に削除することはできません。

このレコード セットには、ゾーンに割り当てられている Azure DNS ネーム サーバーの名前が含まれています。 複数の DNS プロバイダーによる共同ホスト ドメインをサポートする目的で、この NS レコード セットにネーム サーバーを追加できます。 このレコード セットの TTL とメタデータを変更することもできます。 ただし、事前に設定された Azure DNS ネーム サーバーを削除または変更することはできません。

この制限は、ゾーンの頂点にある NS レコード セットにのみ適用されます。 (子ゾーンの委任に使用される) ゾーンの他の NS レコード セットは制約なしで作成、変更、削除できます。

SOA レコード

SOA レコード セットは自動的に各ゾーンの zone apex (名前は “@”) に作成され、そのゾーンを削除すると自動的に削除されます。 SOA レコードを個別に作成または削除することはできません。

host プロパティを除き、SOA レコードのすべてのプロパティを変更できます。 このプロパティは、Azure DNS によって指定されるプライマリ ネーム サーバー名を参照するよう事前構成されています。

ゾーン内のレコードに変更が加えられても、SOA レコード内にあるゾーンのシリアル番号が自動的に更新されることはありません。 必要に応じて、これは SOA レコードを編集することによって、手動で更新できます。

Note

現在、Azure DNS では、SOA ホストマスター メールボックス エントリの '@' の前にあるドット (.) の使用はサポートされていません。 たとえば、john.smith@contoso.xyz (john.smith.contoso.xyz に変換) と john\.smith@contoso.xyz は許可されません。

SPF レコード

Sender Policy Framework (SPF) レコードは、ドメイン名を使って電子メールを送信することができる電子メール サーバーを指定するために使用されます。 送信した電子メールが受信者に迷惑メールとして分類されないようにするには、SPF レコードを正しく構成することが重要です。

もともと DNS に関する RFC では、このようなシナリオに対応するレコード タイプとして、新しい SPF が導入されていました。 また、旧式のネーム サーバーに対応するために、TXT レコード タイプを使用して SPF レコードを指定することも許可されていました。 このあいまいさが原因で混乱が生じていましたが、RFC 7208 によって解決されました。 RFC 7208 では、SPF レコードは TXT レコード タイプを使用して作成する必要があると規定されています。 また、SPF レコード タイプが非推奨であることも規定されています。

SPF レコードは Azure DNS でもサポートされていますが、TXT レコード タイプを使用して作成する必要があります。 廃止された SPF レコード タイプはサポートされていません。 DNS ゾーン ファイルをインポートする際、SPF レコード タイプを使用している SPF レコードは、TXT レコード タイプに変換されます。

SRV レコード

SRV レコードは、さまざまなサービスでサーバーの場所を指定するために使用されます。 Azure DNS で SRV レコードを指定する際は、次の点に注意してください。

• "サービス" と "プロトコル" は、レコード セット名の一部として、先頭に '_sip._tcp.name' のようなアンダースコアを付けて指定する必要があります。 ゾーンの頂点にあるレコードの場合は、レコード名に '@' を指定する必要はありません。'_sip._tcp' のように、サービスとプロトコルを使用するだけです。
• "優先度"、"重み"、"ポート"、および "ターゲット" は、レコード セット内の各レコードのパラメーターとして指定されます。

TXT レコード

TXT レコードは、ドメイン名を任意のテキスト文字列にマップするために使用されます。 TXT レコードは多様なアプリケーションで使用されますが、特に SPF (Sender Policy Framework) や DKIM (DomainKeys Identified Mail) などの電子メール構成に関連して使用されます。

DNS 標準では、1 つの TXT レコードに複数の文字列を含めることができます。各文字列の長さは最大 255 文字です。 複数の文字列が使われている場合は、クライアントごとに文字列の連結が行われて、1 つの文字列として処理されます。

Azure DNS の REST API を呼び出す場合は、各 TXT 文字列を別々に指定する必要があります。 Azure portal、PowerShell または CLI のインターフェイスを使用する場合は、レコードごとに文字列を 1 つ指定する必要があります。 この文字列は、必要に応じて 255 文字のセグメントに自動分割されます。

DNS レコード内の複数の文字列と TXT レコード セット内の複数の TXT レコードを混同しないでください。 TXT レコード セットには、複数のレコードを含めることができ、"レコードごとに" 複数の文字列を含めることができます。 Azure DNS は、TXT レコード セット (結合されたすべてのレコード全体) ごとに最長 4,096 文字 の文字列をサポートします。

DS レコード

委任署名者 (DS) レコードは、委任をセキュリティ保護するために使用される DNSSEC リソース レコードの種類です。 ゾーンに DS レコードを作成するには、まずそのゾーンに DNSSEC で署名する必要があります。

TLSA レコード

TLSA (トランスポート層セキュリティ認証) レコードは、TLS サーバー証明書または公開キーを、レコードが見つかったドメイン名に関連付けるために使用されます。 TLSA レコードは、公開キー (TLS サーバー証明書) をドメイン名にリンクし、TLS 接続のセキュリティ層を追加します。

TLSA レコードを効果的に使用するには、ドメインで DNSSEC を有効にする必要があります。 これにより、TLSA レコードを信頼でき、適切に検証できるようになります

タグとメタデータ

Tags

タグは名前と値のペアのリストで、Azure Resource Manager でリソースのラベル付けに使用されます。 Azure Resource Manager ではこのタグを使用して、Azure の課金内容に関するフィルター ビューを表示したり、特定のタグにポリシーを設定したりできます。 タグの詳細については、 タグを使用した Azure リソースの整理を参照してください。

Azure DNS では、DNS ゾーン リソースに対して Azure Resource Manager のタグを使用できます。 DNS レコード セットのタグはサポートされませんが、その代わりとして、DNS レコード セットでは、後述するメタデータがサポートされます。

Metadata

レコード セットのタグの代わりに、Azure DNS では "メタデータ" を使用してレコード セットに注釈を付けることができます。 メタデータを使用すると、タグと同じように、各レコード セットに名前と値のペアを関連付けることができます。 この機能は、各レコード セットの用途を記録しておきたい場合などに便利です。 タグと異なる点として、メタデータは、Azure の課金内容に関するフィルター ビューを提供するためには使うことができず、Azure Resource Manager のポリシーで指定することもできません。

Etag

たとえば、2 人のユーザーまたは 2 つのプロセスが同時に DNS レコードを変更しようとするとします。 どちらの変更が優先されるでしょうか。 また、優先された側は、他のユーザーまたはプロセスによって行われた変更を上書きしたことに気付くのでしょうか。

Azure DNS は、Etag を使用して同じリソースへの同時変更を安全に処理します。 Etag と Azure Resource Manager の 'タグ' は独立しています。 各 DNS リソース (ゾーンまたはレコード セット) には、関連付けられている Etag があります。 リソースが取得されるときは、常に Etag も取得されます。 リソースを更新する場合は、Azure DNS がサーバー上の Etag の一致を確認できるように Etag を返すこともできます。 リソースを更新するたびに Etag が再生成されるため、Etag の不一致は同時変更が発生していることを示します。 Etag は、既存のリソースがないことを確認するために、新しいリソースの作成時にも使用できます。

Azure DNS PowerShell は、既定で、ゾーンおよびレコード セットへの同時変更のブロックに Etag を使用します。 オプションの -Overwrite スイッチを使用すると、Etag チェックを実行しないように設定できます。この場合、発生したすべての同時変更が上書きされます。

Azure DNS REST API のレベルでは、HTTP ヘッダーを使用して Etag を指定します。 次の表に各ヘッダーの動作を示します。

ヘッダー	動作
なし	PUT は常に成功します (Etag チェックなし)。
If-match <etag>	PUT は、リソースが存在し、Etag が一致する場合にのみ成功します
If-match *	PUT はリソースが存在する場合にのみ成功します
If-none-match *	PUT はリソースが存在しない場合にのみ成功します

制限

Azure DNS を使用する際は、次の制限が既定で適用されます。

パブリック DNS ゾーン

リソース	制限
サブスクリプションごとのパブリック DNS ゾーンの数	250 1
パブリック DNS ゾーンあたりのレコード セット数	10,000 1
パブリック DNS ゾーン内のレコード セットあたりのレコード数	20
1 つの Azure リソースのエイリアス レコードの数	20

¹これらの制限値を引き上げる必要がある場合は、Azure サポートにお問い合せください。

次のステップ

• Azure DNS の使用を開始する場合は、DNS ゾーンの作成方法と DNS レコードの作成方法について確認してください。
• 既存の DNS ゾーンを移行する場合は、DNS ゾーン ファイルのインポートとエクスポートの実行方法を確認してください。