Azure NetApp Files のドメイン ネーム システムについて
ドメイン ネーム システム (DNS) サービスは、Kerberos に依存するファイル プロトコル (SMB、NFSv4.1 など) を認証に使用する場合、Azure NetApp Files でのデータ アクセスの重要なコンポーネントです。 ホスト名は、ボリュームへのアクセスを簡素化すると共に、IP アドレスが変更されるシナリオで、変更されないように保護されます。そのため、ユーザーは、新しい IP アドレスの通知を受け取るのではなく、ホスト名を引き続き使用できます。
既定では、Kerberos 認証は名前から IP アドレスへの解決を利用して、Kerberos チケットを取得するために使用されるサービス プリンシパル名 (SPN) を作成します。 たとえば、\SMB.CONTOSO.COM などの汎用名前付け規則パス (UNC) を使用して SMB 共有にアクセスすると、SMB.CONTOSO.COM に対して DNS 要求が発行され、Azure NetApp Files ボリュームの IP アドレスが取得されます。 DNS エントリが存在しない場合 (または、存在するエントリが要求されたもの (エイリアス/CNAME など) と異なる場合)、適切な SPN を取得できず、Kerberos 要求は失敗します。 その結果、フォールバック認証方法 (New Technology LAN Manager など) が無効になっている場合は、ボリュームへのアクセスが許可されない可能性があります。
NFSv4.1 Kerberos は、SPN を取得するために同様の方法で動作し、DNS ルックアップは認証プロセスに不可欠であり、Kerberos 領域の検出にも使用できます。
Azure NetApp Files は、Active Directory 統合 DNS またはスタンドアロン DNS サーバーの使用をサポートしており、ドメイン ネーム システム (DNS) サービスと最新の DNS レコードへの信頼性の高いアクセスを必要とします。 Azure NetApp Files サーバーと DNS サーバー間のネットワーク接続が不適切な場合、クライアント アクセスの中断やクライアントのタイムアウトが発生する可能性があります。 AD DS または Azure NetApp Files の DNS レコードが不完全であったり正しくなかったりすると、クライアント アクセスが中断したり、クライアントのタイムアウトが発生したりする可能性があります。
Kerberos を使用したアクセスの IP アドレス
Azure NetApp Files ボリュームへのアクセス要求で IP アドレスが使用されている場合、Kerberos 要求は、使用されているプロトコルに応じて動作が異なります。
SMB
SMB を使用する場合、\x.x.x.x を使用する UNC の要求は、既定で、認証に NTLM の使用を試みます。 セキュリティ上の理由から NTLM が許可されていない環境では、IP アドレスを使用する SMB 要求で、既定で Kerberos または NTLM を認証に使用することはできません。 その結果、Azure NetApp Files ボリュームへのアクセスは拒否されます。 Windows の以降のリリース (Windows 10 バージョン 1507 および Windows Server 2016 以降) では、SMB 通信用に SPN で IPv4 および IPv6 のホスト名をサポートするように Kerberos クライアントを構成できます。
NFSv4.1
NFSv4.1 を使用する場合、sec=[krb5/krb5i/krb5p] オプションのいずれかを使用する IP アドレスへのマウント要求では、ポインタ レコード (PTR) を介した逆引き DNS 参照を使用して IP アドレスをホスト名に解決します。その後、このホスト名を使用して、チケット取得用の SPN が作成されます。 Kerberos を使用した NFSv4.1 を使用する場合、マウントへのホスト名と IP アドレスの両方のアクセスをカバーするために、Azure NetApp Files ボリュームに A/AAAA と PTR が必要です。
Azure NetApp Files の DNS エントリ
DNS サーバーが動的 DNS をサポートしている場合、Azure NetApp Files ボリュームは、動的 DNS 更新をサポートします。 動的 DNS を使用すると、ホスト名を使用して作成されたボリュームにより、DNS サーバーに対して、A/AAAA レコードを作成するように自動的に通知されます。 逆引き参照ゾーンが存在する場合、DNS によって PTR レコードも作成されます。 逆引き参照ゾーンが存在しない場合、PTR レコードは自動的に作成されません。つまり、手動で作成する必要があります。
(IP アドレスではなく) ホスト名は、特定の構成 (適切に機能するために DNS を必要とするすべての構成) でボリューム マウント パスに使用されます。
- SMB ボリューム
- NFSv4.1 Kerberos
- デュアル プロトコル ボリューム
Azure NetApp File ボリュームに DNS が必要ない場合 (Kerberos を使用しない NFSv3 または NFSv4.1 など)、IP アドレスが使用されます。 このような場合、必要に応じて、DNS エントリを手動で作成できます。
動的 DNS によって作成された DNS エントリは、DNS サーバー上で削除された場合、Azure NetApp Files からの新しい動的 DNS 更新によって 24 時間以内に再作成されます。
Azure NetApp Files で、動的 DNS を使用して DNS A/AAAA レコードを作成する場合、次の構成を使用します。
- 関連付けられている PTR レコードのチェック ボックスをオンにします。サブネットの逆引き参照ゾーンが存在する場合、A/AAAA レコードにより、管理者の介入なしに PTR レコードが自動的に作成されます。
- [古くなったときにこのレコードを削除する] チェックボックスをオンにします。 DNS の清掃が有効になっている場合、DNS レコードが "古く" なると、そのレコードは DNS によって削除されます。
- DNS レコードの [Time to Live (TTL)] を 1 日 (24 時間) に設定されます。 TTL の設定は、必要に応じて、DNS 管理者が変更できます。 DNS レコードの TTL は、DNS エントリがクライアントの DNS キャッシュ内に存在する時間の長さを決定します。
Note
Windows Active Directory DNS で DNS レコードが作成されたときのタイムスタンプを表示するには、DNS Manager の [表示] メニューに移動し、[詳細] を選択します。
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 を使用して、ボリュームへのアクセスを提供します。
Azure NetApp Files の DNS に関するベスト プラクティス
DNS 構成に関する次の要件を満たしていることを確認してください。
- スタンドアロン DNS サーバーを使用している場合:
- DNS サーバーに、Azure NetApp Files ボリュームをホストする Azure NetApp Files 委任サブネットへのネットワーク接続があることを確認してください。
- ネットワーク ポート UDP 53 と TCP 53 が、ファイアウォールまたは NSG によってブロックされていないことを確認してください。
- AD DS Net Logon サービスによって登録された SRV レコードが DNS サーバーに作成されていることを確認してください。
- Azure NetApp Files 構成と同じドメインで、DNS サーバー上に、Azure NetApp Files で使用する AD DS ドメイン コントローラーの PTR レコードが作成されていることを確認してください。
- Azure NetApp Files では、標準およびセキュリティで保護された動的 DNS 更新がサポートされます。 セキュリティで保護された動的 DNS 更新が必要な場合は、セキュリティで保護された更新が DNS サーバーで構成されていることを確認してください。
- 動的 DNS 更新を使用しない場合、Azure NetApp Files LDAP 署名、LDAP over TLS、SMB、デュアルプロトコル、または Kerberos NFSv4.1 ボリュームをサポートするために、AD DS 組織単位 (Azure NetApp Files AD 接続で指定) 内に作成した AD DS コンピューター アカウントの A レコードと PTR レコードを手動で作成する必要があります。
- 複雑な AD DS トポロジや大規模な AD DS トポロジでは、LDAP 対応の NFS ボリュームをサポートするために、DNS ポリシーまたは DNS サブネットの優先順位付けが必要になる場合があります。
- DNS の清掃が有効 (タイムスタンプ/経過時間に基づいて古い DNS エントリを自動的に除去) になっていて、動的 DNS を使用して Azure NetApp Files ボリュームの DNS レコードが作成されている場合、スカベンジャー プロセスによってボリュームのレコードが誤って排除される可能性があります。 この排除は、名前ベースのクエリのサービス停止につながる可能性があります。 この問題が解決されるまで、DNS の清掃を有効にする場合には、Azure NetApp Files ボリュームの DNS A/AAAA エントリと PTR エントリを手動で作成します。