iDNS は、外部 DNS 名 ( https://www.bing.com など) を解決できる Azure Stack Hub ネットワーク機能です。また、内部仮想ネットワーク名を登録することもできます。 これにより、同じ仮想ネットワーク上の仮想マシン (VM) を IP アドレスではなく名前で解決できます。 この方法では、カスタム DNS サーバー エントリを提供する必要がなくなります。 DNS の詳細については、「 Azure DNS の概要」を参照してください。
iDNS の機能
Azure Stack Hub の iDNS では、カスタム DNS サーバー エントリを指定しなくても、次の機能を利用できます。
- テナント ワークロード用の共有 DNS 名前解決サービス。
- テナント仮想ネットワーク内の名前解決と DNS 登録のための権限のある DNS サービス。
- テナント VM からのインターネット名を解決するための再帰 DNS サービス。 テナントは、インターネット名を解決するためにカスタム DNS エントリを指定する必要がなくなりました (例: www.bing.com.
引き続き独自の DNS を使用し、カスタム DNS サーバーを使用できます。 ただし、iDNS を使用すると、カスタム DNS エントリを作成しなくても、インターネット DNS 名を解決し、同じ仮想ネットワーク内の他の VM に接続できます。
iDNS では何が行われませんか?
iDNS では、仮想ネットワークの外部から解決できる名前の DNS レコードを作成することはできません。
Azure では、パブリック IP アドレスに関連付けられている DNS 名ラベルを指定できます。 ラベル (プレフィックス) は選択できますが、パブリック IP アドレスを作成するリージョンに基づいてサフィックスが選択されます。
前の図に示すように、Azure はゾーン westus.cloudapp.azure.com で指定された DNS 名ラベルの "A" レコードを DNS に作成します。 プレフィックスとサフィックスを組み合わせて、パブリック インターネット上のどこからでも解決できる 完全修飾ドメイン名 (FQDN) を構成します。
Azure Stack Hub では、内部名の登録に対して iDNS のみがサポートされるため、次の操作は実行できません。
- 既存のホストされている DNS ゾーン (local.azurestack.external など) の下に DNS レコードを作成します。
- DNS ゾーン (Contoso.com など) を作成します。
- 独自のカスタム DNS ゾーンの下にレコードを作成します。
- ドメイン名の購入をサポートします。
iDNS のしくみのデモ
仮想ネットワーク上の VM のすべてのホスト名は、同じゾーンの下に DNS リソース レコードとして格納されますが、VM がデプロイされた SDN インフラストラクチャの VNET ID に関連付ける GUID として定義された独自の一意のコンパートメントの下に格納されます。 テナント VM の完全修飾ドメイン名 (FQDN) は、コンピューター名と Virtual Network の DNS サフィックス文字列 (GUID 形式) で構成されます。
このしくみを示す簡単なラボを次に示します。 1 つの VNet 上に 3 つの VM を作成し、別の VNet 上に別の VM を作成しました。
| 仮想マシン (VM) | vNet | プライベート IP | パブリック IP | DNS ラベル |
|---|---|---|---|---|
| VM-A1 | VNetA | 10.0.0.5 | 172.31.12.68 | VM-A1-Label.lnv1.cloudapp.azscss.external |
| VM-A2 | VNetA | 10.0.0.6 | 172.31.12.76 | VM-A2-Label.lnv1.cloudapp.azscss.external |
| VM-A3 | VNetA | 10.0.0.7 | 172.31.12.49 | VM-A3-Label.lnv1.cloudapp.azscss.external |
| VM-B1 | VNetB | 10.0.0.4 | 172.31.12.57 | VM-B1-Label.lnv1.cloudapp.azscss.external |
| VNet | GUID（グローバルユニーク識別子） | DNS サフィックス文字列 |
|---|---|---|
| VNetA | e71e1db5-0a38-460d-8539-705457a4cf75 | e71e1db5-0a38-460d-8539-705457a4cf75.internal.lnv1.azurestack.local |
| VNetB | e8a6e386-bc7a-43e1-a640-61591b5c76dd | e8a6e386-bc7a-43e1-a640-61591b5c76dd.internal.lnv1.azurestack.local |
iDNS のしくみをより深く理解するために、いくつかの名前解決テストを実行できます。
VM-A1 (Linux VM): VM-A2 を参照すると、VNetA の DNS サフィックスが追加され、名前がプライベート IP に解決されることがわかります。
carlos@VM-A1:~$ nslookup VM-A2
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: VM-A2.e71e1db5-0a38-460d-8539-705457a4cf75.internal.lnv1.azurestack.local
Address: 10.0.0.6
FQDN を指定せずに VMA2-Label を検索すると、想定どおりに失敗します。
carlos@VM-A1:~$ nslookup VM-A2-Label
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find VM-A2-Label: SERVFAIL
DNS ラベルの FQDN を指定すると、名前はパブリック IP に解決されます。
carlos@VM-A1:~$ nslookup VM-A2-Label.lnv1.cloudapp.azscss.external
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: VM-A2-Label.lnv1.cloudapp.azscss.external
Address: 172.31.12.76
このレコードがこのゾーンに存在しないため、(別の VNet からの) VM-B1 を解決しようとすると失敗します。
carlos@caalcobi-vm4:~$ nslookup VM-B1
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find VM-B1: SERVFAIL
このレコードは別のゾーンからであるため、VM-B1 に FQDN を使用しても役に立ちません。
carlos@VM-A1:~$ nslookup VM-B1.e8a6e386-bc7a-43e1-a640-61591b5c76dd.internal.lnv1.azurestack.local
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find VM-B1.e8a6e386-bc7a-43e1-a640-61591b5c76dd.internal.lnv1.azurestack.local: SERVFAIL
DNS ラベルに FQDN を使用すると、正常に解決されます。
carlos@VM-A1:~$ nslookup VM-B1-Label.lnv1.cloudapp.azscss.external
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: VM-B1-Label.lnv1.cloudapp.azscss.external
Address: 172.31.12.57
VM-A3 (Windows VM) から。 権限のある回答と権限のない回答の違いに注目してください。
内部レコード:
C:\Users\carlos>nslookup
Default Server: UnKnown
Address: 168.63.129.16
> VM-A2
Server: UnKnown
Address: 168.63.129.16
Name: VM-A2.e71e1db5-0a38-460d-8539-705457ª4cf75.internal.lnv1.azurestack.local
Address: 10.0.0.6
外部レコード:
> VM-A2-Label.lnv1.cloudapp.azscss.external
Server: UnKnown
Address: 168.63.129.16
Non-authoritative answer:
Name: VM-A2-Label.lnv1.cloudapp.azscss.external
Address: 172.31.12.76
要するに、上記から次のことがわかります。
- 各 VNet には独自のゾーンがあり、すべてのプライベート IP アドレスの A レコードが含まれ、VM 名と VNet の DNS サフィックス (GUID) で構成されます。
- <vmname>.<vnetGUID>.internal.<region>.<stackinternalFQDN>
- これは自動的に行われます
- パブリック IP アドレスを使用する場合は、それらの DNS ラベルを作成することもできます。 これらは、他の外部アドレスと同様に解決されます。
- iDNS サーバーは、それの内部 DNS ゾーンの権限を持つサーバーであり、テナント VM が外部リソースに接続するときのパブリック名のリゾルバーとして機能します。 外部リソースのクエリがある場合、iDNS サーバーは、解決する権限のある DNS サーバーに要求を転送します。
ラボの結果からわかるように、使用される IP を制御できます。 VM 名を使用すると、プライベート IP アドレスが取得され、DNS ラベルを使用するとパブリック IP アドレスが取得されます。