Azure NetApp Files のドメインネームシステムについて

[アーティクル]
02/08/2025

Azure NetApp Files は、Active Directory 統合 DNS またはスタンドアロン DNS サーバーの使用をサポートしており、ドメインネームシステム (DNS) サービスと最新の DNS レコードへの信頼性の高いアクセスを必要とします。 Azure NetApp Files と DNS のサーバー間のネットワーク接続が不適切な場合、クライアントアクセスの中断やクライアントのタイムアウトが発生する可能性があります。 Active Directory Domain Services (AD DS) または Azure NetApp Files の DNS レコードが不完全であったり正しくなかったりすると、クライアントアクセスの中断やクライアントのタイムアウトが発生する可能性があります。

DNS サービスは、Azure NetApp Files でのデータアクセスの重要なコンポーネントです。 SMB、NFSV4.1 Kerberos、LDAP、Active Directory サイト検出を介したファイルプロトコルアクセスはすべて、その動作に DNS を多用します。 DNS に一元的に格納されたホスト名を使うと、ボリュームへのアクセスが簡単になり、IP アドレスが変化するシナリオから保護されます。管理者が新しい IP アドレスをユーザーに通知する必要はなく、ユーザーはユーザーフレンドリなホスト名を引き続き使用できます。

DNS サーバーは、Active Directory 接続の下で構成されます。プライマリとセカンダリサーバーおよび Active Directory DNS 名を追加できます。

Note

冗長性のために複数の DNS サーバーを構成するのがベストプラクティスです。

DNS サーバーについて

Azure NetApp Files には、SMB と NFSv4.1 Kerberos の機能に対する Active Directory 接続が必要です。 Active Directory が適切に機能するには DNS が必要です。ほとんどの場合、Active Directory の展開は、ドメインコントローラーと統合された DNS サーバーと共にインストールされます。この構成は、使いやすさと、ドメインサービスに必要なすべての DNS レコードが確実に作成されることの両方の点で、Microsoft のベストプラクティスです。

場合によっては、Active Directory でホストされる DNS サービスの代わりに (またはそれに追加して)、外部 DNS サーバー (BIND など) が使われることがあります。これは、不整合な名前空間と呼ばれます。

Azure NetApp Files では、統合と外部の両方の DNS サーバーの使用がサポートされていますが、Active Directory を統合しないで外部 DNS サーバーを使う場合は、サービスの適切な機能と冗長性のために、必要なサービス (SRV) のレコードを DNS に追加することが重要です。 Azure NetApp Files と DNS のサーバー間のネットワーク接続が不適切な場合、クライアントアクセスの中断やクライアントのタイムアウトが発生する可能性があります。 AD DS または Azure NetApp Files のための DNS レコードが不完全であったり正しくなかったりすると、クライアントアクセスが中断したり、クライアントがタイムアウトしたりする可能性があります。

サービスで使われる SRV レコードの一覧については、Azure NetApp Files の DNS レコードに関するセクションをご覧ください。また、Active Directory での DNS のガイドラインに関する記事と、「既存の DNS インフラストラクチャへの AD DS の統合」も確認してください。

Azure DNS と Azure NetApp Files の統合

Azure DNS は、Microsoft Azure でのホストされた DNS 管理と名前解決のサービスです。それを使って、Azure にデプロイする他のアプリケーションやサービス (Azure NetApp Files など) のためにパブリックまたはプライベートの DNS 名を作成できます。 Azure に DNS をデプロイすると、Azure NetApp Files とオンプレミスの DNS や Active Directory ドメインとの間で (ポート 53 経由で) DNS 要求を直接送信する必要がなくなります。さらに、Azure DNS を使って、(Azure プライベート DNS リゾルバーを使用する) 条件付きフォワーダーを作成できます。それを使うと、Azure でホストされているプライベート DNS サーバーを使って、Azure NetApp Files から特定の DNS サーバーに DNS 要求を送信でき、それを Active Directory 接続で使うように指定できます。

Azure DNS の使用については、以下を参照してください。

Azure NetApp Files の DNS でのロードバランサーの IP アドレスの使用

ロードバランサーデバイスは、1 つの IP アドレスを使ってバックエンドの複数の IP アドレスに対応するための方法です。これには、難読化によるセキュリティと、エンタープライズ環境でのパフォーマンスと冗長性のメリットがあります。

DNS ロードバランサーは、要求を処理して、プールで指定されている複数の DNS サーバーに送信できます。 Microsoft Azure にはネイティブな負荷分散サービスが用意されており、複数のユースケースに対応します。

DNS ロードバランサーがエンドポイントとして IP アドレスを提供し、その IP アドレスがポート 53 経由で Azure NetApp Files ネットワークと通信できる場合、Azure NetApp Files はその使用をサポートします。たとえば、Azure Traffic Manager はレイヤー 7 で DNS 負荷分散を提供しますが、使用できるのはフロントエンドホスト名のみです。 Azure NetApp Files の Active Directory 接続では、DNS サーバーに対して IP アドレスのみを指定できます。

Azure NetApp Files での DNS レコードの種類

Azure NetApp Files では、ファイルサービスへのアクセスにさまざまな種類の DNS レコードが使われます。

DNS レコードの種類	Definition
A/AAAA	DNS の A レコードは、ホスト名の IPv4 アドレスを示すアドレスレコードです。 AAAA レコードは、ホスト名の IPv6 アドレスを示します。 Azure NetApp Files では、次の方法で A/AAAA レコードが使われます。ユーザーフレンドリなホスト名の背後にある IP アドレスのマスク Kerberos サービスプリンシパルの要求ルートドメインクエリ
ポインターレコード (PTR)	PTR レコードは、逆引き参照ゾーンを使って、IP アドレスをホスト名にマップします。 PTR レコードは、主に、Azure NetApp Files でマウントや共有に IP アドレスが指定されている場合に使われます。マウントや共有の要求で IP アドレスを使うと、使われている認証方法に影響する可能性があります。詳細については、「Kerberos でアクセスするための IP アドレス」を参照してください。
サービスレコード (SRV)	SRV レコードは、LDAP、NFS、CIFS、Kerberos などの特定のサービスに使われるホストとポートを指定するために使われます。Azure NetApp Files の SRV レコードは、ファイルサービスのセキュリティ (Kerberos など)、Active Directory でのサイト検出、LDAP サーバークエリなどに多用されます。 Azure NetApp Files サービスが適切に機能するには、これらのレコードが存在することを確認することが重要です。 SRV レコードは、`nslookup` または `dig` コマンドを使ってクエリできます。例については、「DNS クエリに対する `nslookup` と `dig` の使用」をご覧ください。
正規名 (CNAME)	CNAME レコードは、A/AAAA レコードの DNS エイリアスを提供する手段です。 CNAME レコードはなくてもかまいませんが、Azure NetApp Files によって提供されるホスト名レコードの複雑さを軽減するのに役立ちます。詳しくは、「DNS エイリアスと正規名 (CNAME) レコード」をご覧ください。
Uniform Resource Identifier (URI)	URI レコードは、サービスのホスト名と IP アドレスを URI にマップする手段です。 URI は次のような形式で表されます: service://fqdn.contoso.com。 Azure NetApp Files では、NFS Kerberos 要求に対して Kerberos KDC の参照を実行するときにのみ、URI レコードのクエリが使われます。既定では、URI レコードは Active Directory DNS の展開では作成されません。そのため、URI 参照要求は通常失敗し、SRV レコード参照にフォールバックします。

Azure NetApp Files で使用されるサービスレコード (SRV)

Azure NetApp Files では、次の SRV レコードが使われます。

NFS Kerberos*
- _kerberos-master._tcp.CONTOSO.COM (ポート 88)*
- _kerberos-master._tcp.CONTOSO.COM (ポート 88)*
SMB/Active Directory サイト検出**
- _kerberos.CONTOSO.COM (ポート 88)
- _kerberos._tcp.CONTOSO.COM (ポート 88)
- _kerberos._tcp.dc_msdcs.CONTOSO.COM (ポート 88)
- _kpasswd._tcp.dc._msdcs.CONTOSO.COM (ポート 464)
- _kpasswd._tcp.CONTOSO.COM (ポート 464)
- _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.CONTOSO.COM (ポート 88)
- _kerberos._tcp.<他のサイト名>._sites.dc._msdcs.CONTOSO.COM (ポート 88)
- _kerberos.udp.CONTOSO.COM (ポート 88)
- _kerberos._udp.dc_msdcs.CONTOSO.COM (ポート 88)
- _kpasswd._udp.dc._msdcs.CONTOSO.COM (ポート 464)
- _kpasswd._udp.CONTOSO.COM (ポート 464)
- _kerberos._udp.Default-First-Site-Name._sites.dc._msdcs.CONTOSO.COM (ポート 88)
- _kerberos._udp.<他のサイト名>._sites.dc._msdcs.CONTOSO.COM (ポート 88)
LDAP**
- _ldap.CONTOSO.COM (ポート 389)
- _ldap._tcp.CONTOSO.COM (ポート 389)
- _ldap._udp.CONTOSO.COM (ポート 389)

* Active Directory DNS では、これらの SRV レコードは既定では作成されません。 NFS Kerberos をお使いの場合は、作成することを強くお勧めします。

** Active Directory DNS では、これらの SRV レコードは既定で作成されます。

Azure NetApp Files での SRV レコードの使用方法について詳しくは、以下をご覧ください。

Note

NFS Kerberos での適切なキー配布センターの検出と冗長性のためには、URI レコードと kerberos-master SRV レコードの一方または両方を作成する必要があります。

動的 DNS

Azure NetApp Files ボリュームでは、ボリュームに対して 1 つの IP アドレスが提供され、それが動的 DNS (DDNS) によって DNS に自動的に追加されます (DNS サーバーで動的 DNS がサポートされている場合)。特定の構成では、(IP アドレスではなく) ホスト名がボリュームマウントパスに使われます。マウントパスでのホスト名の使用が適切に機能するには、DNS が必要です。

SMB ボリューム
NFSv4.1 Kerberos
デュアルプロトコルボリューム

NFSv4.1 Kerberos:

SMB

デュアルプロトコル

Azure NetApp Files ボリュームに DNS が必要ない場合は (NFSv3 や、Kerberos を使わない NFSv4.1 など)、IP アドレスがマウントパスに使われます。

NFSv3

考慮事項

Azure NetApp Files では、動的 DNS 更新によって、構成されている DNS サーバーに 2 つの異なる要求が送信されます。1 つは PTR 用で、1 つは A/AAAA レコードの作成と更新用です。

ホスト名を使って作成された Azure NetApp Files ボリュームは、A/AAAA レコードの作成を DNS サーバーに自動的に通知します。これは、ボリュームの作成が完了した直後に行われます。
IP アドレスとホスト名の組み合わせに対して DNS A/AAAA レコードが既に存在する場合、新しいレコードは作成されません。
ホスト名は同じでも IP アドレスが "異なる" DNS A/AAAA レコードが存在する場合は、同じ名前で 2 つ目の A/AAAA レコードが作成されます。
ホスト名を持たずに作成される Azure NetApp Files ボリューム (NFSv3 ボリュームなど) の場合は、サービスで割り当てられたホスト名がないため、動的 DNS によって DNS レコードは作成されません。手動でレコードを作成する必要があります。
インターフェイスの IP サブネットに逆引き参照ゾーンが存在する場合は、DNS サーバーによって PTR レコードも作成されます。必要な逆引き参照ゾーンが存在しない場合は、PTR レコードを自動作成できません。ユーザーが手動で PTR レコードを作成する必要があります。
動的 DNS によって作成された DNS エントリは、DNS サーバー上で削除された場合、Azure NetApp Files からの新しい動的 DNS 更新によって 24 時間以内に再作成されます。
SMB またはデュアルプロトコルのボリュームが作成されると、セキュリティ保護された DDNS が有効になります。 NFS ボリュームでは、セキュリティ保護された DDNS は有効になりませんが、DDNS は有効になります。セキュリティ保護された DDNS が DNS サーバーで無効になっている場合、または Kerberos 認証が失敗した場合は、DDNS 更新は機能しません。

動的 DNS の種類ポート

標準 DNS UDP 53

セキュリティ保護された DNS TCP 53
Azure NetApp Files では、Microsoft Active Directory DNS サーバーでのみセキュリティ保護された DDNS がサポートされます。

動的 DNS の種類	ポート
標準 DNS	UDP 53
セキュリティ保護された DNS	TCP 53

動的 DNS のエントリの詳細

Azure NetApp Files で、動的 DNS を使用して DNS A/AAAA レコードを作成する場合、次の構成を使用します。

関連付けられている PTR レコードのチェックボックスをオンにします。サブネットの逆引き参照ゾーンが存在する場合、A/AAAA レコードにより、管理者の介入なしに PTR レコードが自動的に作成されます。
[古くなったらこのレコードを削除する] チェックボックスはオンにされます: DNS の清掃が有効になっている場合、DNS レコードが "古く" なると、そのレコードは DNS によって削除されます。
DNS レコードの "Time to Live (TTL)" は 1 日 (24 時間) に設定されます: DNS 管理者は、必要に応じて TTL の設定を変更できます。 DNS レコードの TTL は、DNS エントリがクライアントの DNS キャッシュ内に存在する時間の長さを決定します。

Note

Windows Active Directory DNS で DNS レコードが作成されたときのタイムスタンプと Time to Live (TTL) を表示するには、DNS Manager の [表示] メニューに移動して [詳細] を選びます。そこから、A/AAAA レコードエントリを選んでプロパティを表示します。

Azure NetApp Files での標準動的 DNS のしくみ

Azure NetApp Files では、4 つの基本的なステップに従って、構成された DNS サーバーに対する動的 DNS 更新が作成されます。標準の動的 DNS (DDNS) 更新は、UDP ポート 53 を通過します。

Azure NetApp Files ボリュームインターフェイスの IP アドレスに対する SOA DNS クエリが実行されます。
PTR の DDNS 更新が実行されます。 PTR が存在しない場合は、作成されます。
Azure NetApp Files ボリュームの完全修飾ドメイン名 (FQDN) に対して、DNS Start of Authority (SOA) クエリが行われます。
A/AAAA レコードの DDNS 更新が実行されます。レコードが存在しない場合は、作成されます。

パケットキャプチャによる動的 DNS

パケットキャプチャは、分析にログを利用できない場合があるサービスの問題のトラブルシューティングに役立つ可能性があります。パケットキャプチャの詳細については、このビューを展開してください。

Azure NetApp Files ボリュームインターフェイスの IP アドレスに対する SOA DNS クエリが実行されます。

143 x.x.x.y	x.x.x.x	DNS	86	Standard query 0x77c8 SOA y.x.x.x.in-addr.arpa

144 x.x.x.x	x.x.x.y	DNS	229	Standard query response 0x77c8 No such name SOA y.x.x.x.in-addr.arpa SOA dc1.anf.local A x.x.x.x AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111 AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111

PTR の DDNS 更新が実行されます。 PTR が存在しない場合は、作成されます。

145 x.x.x.y	x.x.x.x	DNS	121	Dynamic update 0x1a43 SOA x.x.x.in-addr.arpa PTR ANF1234.anf.local

146 x.x.x.x	x.x.x.y	DNS	121	Dynamic update response 0x1a43 SOA x.x.x.in-addr.arpa PTR ANF1234.anf.local

Azure NetApp Files ボリュームの完全修飾ドメイン名 (FQDN) に対して、DNS Start of Authority (SOA) クエリが行われます。

147 x.x.x.y	x.x.x.x	DNS	81	Standard query 0xcfab SOA ANF1234.anf.local

148 x.x.x.x	x.x.x.y	DNS	214	Standard query response 0xcfab No such name SOA ANF1234.anf.local SOA dc1.anf.local A x.x.x.x AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111

A/AAAA レコードの DDNS 更新が実行されます。レコードが存在しない場合は、作成されます。

149 x.x.x.y	x.x.x.x	DNS	97	Dynamic update 0x83b2 SOA anf.local A x.x.x.y

150 x.x.x.x	x.x.x.y	DNS	97	Dynamic update response 0x83b2 SOA anf.local A x.x.x.y

Azure NetApp Files でのセキュリティ保護された DDNS のしくみ

セキュリティ保護された DNS が有効になっている場合、Azure NetApp Files は DNS サーバーとネゴシエートし、Secret Key Transaction Authentication for DNS を使って GSS 経由で認証を行って、要求された更新が正当なソースからのものであることを確認します。次に示すのは、このプロセスの間に使われる手順です。セキュリティ保護された DDNS 更新は、TCP ポート 53 を通過します。

Azure NetApp Files ボリュームインターフェイスの IP アドレスに対する SOA DNS クエリが実行されます。
Kerberos サービスチケットが、DNS サーバー上の DNS サービスと交換されます。
その後、このチケットは、Azure NetApp Files から DNS サーバーへのトランザクションキー (TKEY) の DNS クエリで使われます。これは、GSS-TSIG (トランザクション署名) を使って認証に渡されます。
認証が成功すると、TKEY を使って PTR を作成するためのセキュリティ保護された動的 DNS 更新が、GSS-TSIG を使って送信されます。レコードがまだ存在しない場合は、作成されます。
Azure NetApp Files ボリュームの完全修飾ドメイン名 (FQDN) に対して DNS SOA クエリが送信されて応答されます。
DNS サーバーと Azure NetApp Files の間で新しい TKEY ID が交換されます。
FQDN の A/AAAA レコードを作成するために、セキュリティ保護された動的 DNS 更新が TKEY を使って送信されます。同じ IP アドレスを持つレコードが既に存在する場合、変更は行われません。

パケットキャプチャによる動的 DNS

Azure NetApp Files ボリュームインターフェイスの IP アドレスに対する SOA DNS クエリが実行されます。

1135 x.x.x.y 	x.x.x.x	DNS	86	Standard query 0xd29a SOA y.x.x.x.in-addr.arpa

1136 x.x.x.x	x.x.x.y	DNS	229	Standard query response 0xd29a No such name SOA y.x.x.x.in-addr.arpa SOA dc1.anf.local A x.x.x.x AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111

Kerberos サービスチケットが、DNS サーバー上の DNS サービスと交換されます。

1141 x.x.x.y	x.x.x.x	KRB5	406	TGS-REQ
•	SNameString: DNS
•	SNameString: dc1.anf.local

1143 x.x.x.x	x.x.x.y	KRB5	1824	TGS-REP

その後、このチケットは、Azure NetApp Files から DNS サーバーへのトランザクションキー (TKEY) の DNS クエリで使われます。これは、GSS-TSIG (トランザクション署名) を使って認証に渡されます。

    1152 x.x.x.y	x.x.x.x	DNS	191	Standard query 0x147c TKEY 1492998148.sig-dc1.anf.local TKEY
•	Name: 1492998148.sig-dc1.anf.local
•	Type: TKEY (249) (Transaction Key)
•	Algorithm name: gss-tsig

1154 x.x.x.x	x.x.x.y	DNS	481	Standard query response 0x147c TKEY 1492998148.sig-dc1.anf.local TKEY TSIG

認証が成功すると、TKEY を使って PTR を作成するためのセキュリティ保護された動的 DNS 更新が、GSS-TSIG を使って送信されます。レコードがまだ存在しない場合は、作成されます。

1155 x.x.x.y	x.x.x.x	DNS	240	Dynamic update 0xf408 SOA x.x.x.in-addr.arpa PTR ANF1234.anf.local TSIG
•	Zone
o	x.x.x.in-addr.arpa: type SOA, class IN
o	y.x.x.x.in-addr.arpa: type PTR, class IN, ANF1234.anf.local
•	Type: PTR (12) (domain name PoinTeR)
o	Additional records
o	1492998148.sig-dc1.anf.local: type TSIG, class ANY

1156 x.x.x.x	x.x.x.y	DNS	240	Dynamic update response 0xf408 SOA x.x.x.in-addr.arpa PTR ANF1234.anf.local TSIG
•	Updates
o	y.x.x.x.in-addr.arpa: type PTR, class IN, ANF1234.anf.local
o	Type: PTR (12) (domain name PoinTeR)

Azure NetApp Files ボリュームの完全修飾ドメイン名 (FQDN) に対して DNS SOA クエリが送信されて応答されます。

1162 x.x.x.y	x.x.x.x	DNS	81	Standard query 0xe872 SOA ANF1234.anf.local

1163 x.x.x.x	x.x.x.y	DNS	214	Standard query response 0xe872 No such name SOA ANF1234.anf.local SOA dc1.anf.local A x.x.x.x AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111 AAAA aaaa:bbbb:cccc:d:eeee:ffff:0000:1111

DNS サーバーと Azure NetApp Files の間で新しい TKEY ID が交換されます。

1165 x.x.x.y	x.x.x.x	DNS	191	Standard query 0x020e TKEY 1260534462.sig-dc1.anf.local TKEY

1167 x.x.x.x	x.x.x.y	DNS	481	Standard query response 0x020e TKEY 1260534462.sig-dc1.anf.local TKEY TSIG

FQDN の A/AAAA レコードを作成するために、セキュリティ保護された動的 DNS 更新が TKEY を使って送信されます。同じ IP アドレスを持つレコードが既に存在する場合、変更は行われません。

    1168 x.x.x.y	x.x.x.x	DNS	216	Dynamic update 0x014a SOA anf.local A x.x.x.y TSIG
•	Zone
o	anf.local: type SOA, class IN
•	Updates
o	ANF1234.anf.local: type A, class IN, addr x.x.x.y
o	Type: A (1) (Host Address)
o	Address: x.x.x.y
•	Additional records
o	1260534462.sig-dc1.anf.local: type TSIG, class ANY

1170 x.x.x.x	x.x.x.y	DNS	216	Dynamic update response 0x014a SOA anf.local A x.x.x.y TSIG
•	Updates
o	ANF1234.anf.local: type A, class IN, addr x.x.x.y
o	Type: A (1) (Host Address)

DNS キャッシュ

DNS サーバーの負荷を軽減するため、DNS クライアントはキャッシュの概念を利用して以前のクエリをメモリに格納し、DNS レコードの TTL で定義されている間は、ホスト名、IP、またはサービスに対して繰り返された要求が、ローカル環境で処理されるようにします。

Azure NetApp Files では、他の標準 DNS クライアントと同じように DNS キャッシュが使われます。サービスが DNS レコードを要求するとき、そのレコードには TTL が定義されています。他の値が指定されていない場合、Active Directory DNS エントリの TTL の既定値は 600 秒 (10 分) です。ある DNS レコードが更新されて、Azure NetApp Files キャッシュに存在し、TTL が 10 分の場合、タイムアウト値の後でキャッシュが消去されるまで、Azure NetApp Files でその新しいレコードは更新されません。現在、このキャッシュを手動で消去する方法はありません。 TTL を短くしたい場合は、DNS サーバーから変更します。

外部 DNS サーバー (BIND など) を使っているときは、既定のタイムアウト値が異なる場合があります。未定義の場合、BIND DNS レコードの TTL は 604,800 秒 (7 日間) であり、有効な DNS キャッシュには長すぎます。そのため、DNS レコードを手動で作成する場合は、レコードの TTL を適切な値に手動で設定することが重要です。 DNS 参照のパフォーマンスと信頼性を両立させるには、Microsoft の既定値である 10 分を使うことをお勧めします。

nslookup または dig コマンドを使って、手動で DNS レコードの TTL のクエリを実行できます。例については、「DNS クエリに対する nslookup と dig の使用」をご覧ください。

DNS レコードの排除または清掃

ほとんどの DNS サーバーには、期限切れのレコードを取り除いて清掃するための方法があります。排除は、古いレコードによって DNS サーバーが乱雑になり、重複する A/AAAA レコードや PTR レコードが存在するシナリオが発生するのを防止するのに役立ちます。このような場合、Azure NetApp Files ボリュームに予期しない結果が生じる可能性があります。

同じ IP アドレスの複数の PTR レコードが異なるホスト名を指している場合、DNS 参照中に誤った SPN が取得されるため、Kerberos 要求が失敗する可能性があります。 DNS は、どの PTR レコードがどのホスト名に属しているかを識別しません。代わりに、逆引き参照では、各新しい参照の各 A/AAAA レコードをラウンドロビン検索します。

例:

C:\> nslookup x.x.x.x
Server:  contoso.com
Address:  x.x.x.x

Name:    ANF-1234.contoso.com
Address:  x.x.x.x

C:\> nslookup x.x.x.x
Server:  contoso.com
Address:  x.x.x.x

Name:    ANF-5678.contoso.com
Address:  x.x.x.x

DNS エイリアスと正規名 (CNAME) レコード

Azure NetApp Files は、SMB、デュアルプロトコル、Kerberos を使用した NFSv4.1 など、適切に機能するために DNS を必要とするプロトコル用に構成されたボリュームの DNS ホスト名を作成します。作成された名前は、NetApp アカウントの Active Directory 接続を作成するときに、SMB サーバーの形式 (コンピューターアカウント) をプレフィックスとして使用します。同じ NetApp アカウント内の複数のボリュームエントリが一意の名前になるように、追加の英数字が付加されます。ほとんどの場合、ホスト名を必要とし、同じ NetApp アカウント内に存在する複数のボリュームは、同じホスト名と IP アドレスを使用しようとします。たとえば、SMB サーバー名が SMB-West.contoso.com の場合、ホスト名エントリは、SMB-West-XXXX.contoso.com の形式に従います。

場合によっては、Azure NetApp Files で使われる名前が、エンドユーザーにとって十分にわかりやすい名前ではないことがあります。または、データがオンプレミスストレージから Azure NetApp Files に移行されたときの使い慣れた DNS 名を、管理者がそのままにしておきたい場合があります (つまり、元の DNS 名が datalake.contoso.com だった場合、エンドユーザーは引き続きその名前を使いたいことがあります)。

Azure NetApp Files では、使用される DNS ホスト名の指定がネイティブに許可されません。同じ機能を持つ代替の DNS 名が必要な場合は、DNS エイリアス/正規名 (CNAME) を使用する必要があります。

Azure NetApp Files ボリュームの A/AAAA レコードを指す CNAME レコード (追加の A/AAAA レコードではありません) を使用すると、SMB サーバーと同じ SPN を利用して、A/AAAA レコードと CNAME の両方に対して Kerberos アクセスが有効になります。 SMB-West-XXXX.contoso.com の A/AAAA レコードの例について考えてみましょう。 datalake.contoso.com の CNAME レコードは、SMB-West-XXXX.contoso.com の A/AAAA レコードを指すように構成されます。 datalake.contoso.com に対して行われた SMB または NFS Kerberos 要求では、SMB-West-XXXX の Kerberos SPN を使用して、ボリュームへのアクセスを提供します。

DNS クエリに対する nslookup と dig の使用

nslookup (Windows と Linux クライアント) や dig (Linux クライアント) などの DNS ツールを使うと、DNS サーバーのクエリを手動で実行できます。これらのツールを使うと、サービスの機能の検証、ホスト名と IP の解決のテスト、既存や古い DNS レコードの検索、サーバーの構成の確認、TTL の検証などのシナリオで役立ちます。また、Azure の接続トラブルシューティングツールを使って、さらに問題解決を行うこともできます。

nslookup と dig コマンドは、VM へのリモート接続 (Bastion など) から実行することも、VM 自体で実行コマンドオプションを使って VM に対して直接実行することもできます。

Windows での nslookup

オプションを指定しないで nslookup を実行すると、基本的な IP アドレス情報を収集できます。

C:\>nslookup anf.local
Server:  dns.anf.local
Address:  x.x.x.a

Name:    anf.local
Addresses:  x.x.x.x
            x.x.x.y

レコードの TTL 情報のみのクエリを実行するには、-query=hinfo コマンドオプションを使います。

C:\>nslookup -query=hinfo anf.local
Server:  dns.anf.local
Address:  x.x.x.a

anf.local
        primary name server = dns.anf.local
        responsible mail addr = root.dns.anf.local
        serial  = 7
        refresh = 604800 (7 days)
        retry   = 86400 (1 day)
        expire  = 2419200 (28 days)
        default TTL = 604800 (7 days)

-debug オプションを使うと、DNS レコードに関するさらに詳細な情報を収集することもできます。

C:\>nslookup -debug anf.local
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 1, rcode = NOERROR
        header flags:  response, auth. answer, want recursion, recursion avail.
        questions = 1,  answers = 1,  authority records = 0,  additional = 0

    QUESTIONS:
        x.x.x.x.in-addr.arpa, type = PTR, class = IN
    ANSWERS:
    ->  x.x.x.x.in-addr.arpa
        name = dns.anf.local
        ttl = 604800 (7 days)

------------
Server:  dns.anf.local
Address:  x.x.x.a

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 2, rcode = NXDOMAIN
        header flags:  response, auth. answer, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:
        anf.local.ANF.LOCAL, type = A, class = IN
    AUTHORITY RECORDS:
    ->  anf.local
        ttl = 604800 (7 days)
        primary name server = dns.anf.local
        responsible mail addr = root.dns.anf.local
        serial  = 7
        refresh = 604800 (7 days)
        retry   = 86400 (1 day)
        expire  = 2419200 (28 days)
        default TTL = 604800 (7 days)

Linux での dig

# dig anf.local

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.6 <<>> anf.local
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12196
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;anf.local.                     IN      A

;; ANSWER SECTION:
anf.local.              604800  IN      A       x.x.x.x
anf.local.              604800  IN      A       x.x.x.y

;; Query time: 0 msec
;; SERVER: 10.193.67.250#53(10.193.67.250)
;; WHEN: Thu Aug 29 15:27:47 EDT 2024
;; MSG SIZE  rcvd: 70

Azure NetApp Files の DNS に関するベストプラクティス

次の DNS 構成要件を満たしていることを確認します。

冗長性のため、DNS の構成で複数の DNS サーバーを指定します。
最良の結果を得るには、Active Directory と統合またはインストールされた DNS を使います。
スタンドアロン DNS サーバーを使用している場合:
- Azure NetApp Files ボリュームをホストしている Azure NetApp Files の委任されたサブネットへのネットワーク接続が、DNS サーバーにあることを確認します。
- ネットワークポート UDP 53 と TCP 53 が、ファイアウォールまたはネットワークセキュリティグループによってブロックされていないことを確認します。
AD DS Net Logon サービスによって登録された SRV レコードが DNS サーバーに作成されていること、および「Azure NetApp Files での DNS レコードの種類」の一覧で示されているサービスレコードを確認します。
Azure NetApp Files 構成と同じドメインで、DNS サーバー上に、Azure NetApp Files で使用する AD DS ドメインコントローラーの PTR レコードが作成されていることを確認してください。
Azure NetApp Files では、標準およびセキュリティで保護された動的 DNS 更新がサポートされます。セキュリティで保護された動的 DNS 更新が必要な場合は、セキュリティで保護された更新が DNS サーバーで構成されていることを確認してください。
動的 DNS が A/AAAA レコードに加えて PTR レコードを作成できるように、Azure NetApp Files サブネットに対して逆引き参照ゾーンが作成されていることを確認します。
DNS エイリアスが必要な場合は、CNAME レコードを使います。 CNAME レコードで Azure NetApp Files の A/AAAA レコードを指し示します。
動的 DNS 更新を使っていない場合、Azure NetApp Files LDAP 署名、LDAP over TLS、SMB、デュアルプロトコル、または Kerberos NFSv4.1 ボリュームをサポートするには、(Azure NetApp Files AD 接続で指定されている) AD DS 組織単位内に作成された AD DS コンピューターアカウントに対する A レコードと PTR レコードを、手動で作成する必要があります。
複雑な、または大規模な AD DS トポロジでは、LDAP 対応の NFS ボリュームをサポートするために、DNS ポリシーまたは DNS サブネットの優先順位付けが必要になる場合があります。
DNS の清掃が有効 (タイムスタンプ/経過時間に基づいて古い DNS エントリを自動的に除去) になっていて、動的 DNS を使用して Azure NetApp Files ボリュームの DNS レコードが作成されている場合、スカベンジャープロセスによってボリュームのレコードが誤って排除される可能性があります。この排除は、名前ベースのクエリのサービス停止につながる可能性があります。この問題が解決されるまで、DNS の清掃を有効にする場合には、Azure NetApp Files ボリュームの DNS A/AAAA エントリと PTR エントリを手動で作成します。

次の方法で共有

Azure NetApp Files のドメインネームシステムについて

DNS サーバーについて

Azure DNS と Azure NetApp Files の統合

Azure NetApp Files の DNS でのロードバランサーの IP アドレスの使用

Azure NetApp Files での DNS レコードの種類

Azure NetApp Files で使用されるサービスレコード (SRV)

動的 DNS

考慮事項

動的 DNS のエントリの詳細

Azure NetApp Files での標準動的 DNS のしくみ

パケットキャプチャによる動的 DNS

Azure NetApp Files でのセキュリティ保護された DDNS のしくみ

パケットキャプチャによる動的 DNS

DNS キャッシュ

DNS レコードの排除または清掃

DNS エイリアスと正規名 (CNAME) レコード

DNS クエリに対する nslookup と dig の使用

Windows での nslookup

Linux での dig

Azure NetApp Files の DNS に関するベストプラクティス

次のステップ

フィードバック

その他のリソース

次の方法で共有

Azure NetApp Files のドメイン ネーム システムについて

DNS サーバーについて

Azure DNS と Azure NetApp Files の統合

Azure NetApp Files の DNS でのロード バランサーの IP アドレスの使用

Azure NetApp Files での DNS レコードの種類

Azure NetApp Files で使用されるサービス レコード (SRV)

動的 DNS

考慮事項

動的 DNS のエントリの詳細

Azure NetApp Files での標準動的 DNS のしくみ

パケット キャプチャによる動的 DNS

Azure NetApp Files でのセキュリティ保護された DDNS のしくみ

パケット キャプチャによる動的 DNS

DNS キャッシュ

DNS レコードの排除または清掃

DNS エイリアスと正規名 (CNAME) レコード

DNS クエリに対する nslookup と dig の使用

Windows での nslookup

Linux での dig

Azure NetApp Files の DNS に関するベスト プラクティス

次のステップ

フィードバック

その他のリソース

Azure NetApp Files のドメインネームシステムについて

Azure NetApp Files の DNS でのロードバランサーの IP アドレスの使用

Azure NetApp Files で使用されるサービスレコード (SRV)

パケットキャプチャによる動的 DNS

パケットキャプチャによる動的 DNS

Azure NetApp Files の DNS に関するベストプラクティス