Использование iDNS в Azure Stack Hub
iDNS — это сетевая функция Azure Stack Hub, которая позволяет разрешать внешние DNS-имена (например, https://www.bing.com.) она также позволяет регистрировать имена внутренних виртуальных сетей). Таким образом можно разрешать виртуальные машины в одной и той же виртуальной сети по имени, а не по IP-адресу. Это избавляет от необходимости предоставлять пользовательские записи DNS-сервера. Дополнительные сведения о DNS см. в статье Общие сведения об Azure DNS.
Возможности iDNS
С iDNS в Azure Stack Hub вы получаете следующие возможности без необходимости указывать пользовательские записи DNS-сервера:
- Общие службы разрешения DNS-имен для клиентских рабочих нагрузок.
- Полномочная служба DNS для разрешения имен и регистрации DNS в клиентской виртуальной сети.
- Рекурсивная служба DNS для разрешения имен Интернета из клиентских виртуальных машин. Клиенту больше не требуется указывать пользовательские записи DNS для разрешения имен Интернета (например, www.bing.com).
Вы по-прежнему можете подключить собственный DNS-сервер и использовать пользовательские DNS-серверы. Однако с помощью iDNS можно разрешать DNS-имена в Интернете и подключаться к другим виртуальным машинам в той же виртуальной сети, не создавая пользовательские записи DNS.
Что не делает iDNS?
iDNS не позволяет создать запись DNS для имени, которое можно разрешить за пределами виртуальной сети.
В Azure можно указать метку имени DNS, которая связана с общедоступным IP-адресом. Вы можете выбрать метку (префикс), но Azure выбирает суффикс, зависящий от региона, в котором создается общедоступный IP-адрес.
На приведенном выше рисунке показано создание платформой Azure записи "A" в DNS для метки имени DNS, указанной в зоне westus.cloudapp.azure.com. Префикс и суффикс объединяются для создания полного доменного имени (FQDN), которое можно разрешить из любого места в общедоступном Интернете.
В Azure Stack Hub iDNS поддерживается только для внутренней регистрации имен, поэтому iDNS не позволяет выполнить следующие действия:
- создать запись DNS в существующей размещенной зоне DNS (например, local.azurestack.external);
- создать зону DNS (например, Contoso.com);
- создать запись в пользовательской зоне DNS;
- купить доменное имя.
Демонстрация работы iDNS
Все имена узлов для виртуальных машин в виртуальных сетях хранятся в виде записей ресурсов DNS в одной зоне, но в отдельных уникальных секциях с некоторыми идентификаторами GUID, которые соответствуют идентификаторам виртуальных сетей в инфраструктуре SDN, в которых развернуты эти виртуальные машины. Полные доменные имена (FQDN) клиентских виртуальных машин состоят из строковых значений имени компьютера и DNS-суффикса виртуальной сети в формате GUID.
Ниже показана простая лаборатория для демонстрации этой технологии. Мы создали 3 виртуальных машины в одной виртуальной сети и еще одну виртуальную машину в отдельной виртуальной сети:
| ВМ | Виртуальная сеть | Частный 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 |
| Виртуальная сеть | GUID | DNS suffix string |
|---|---|---|
| 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-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
Поиск VM-A2-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
Если вы предоставите FQDN для метки DNS, имя будет разрешено в общедоступный 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
Попытка разрешить 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 не поможет, так как эта запись относится к другой зоне.
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
Если вы предоставите FQDN для метки DNS, имя разрешается успешно:
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) обратите внимание на разницу между заслуживающим и не заслуживающим доверия ответами.
Внутренние записи:
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
Полученный выше результат можно описать так:
- Каждая виртуальная сеть имеет собственную зону с записями A для всех частных IP-адресов, которые состоят из имени виртуальной машины и DNS-суффикса виртуальной сети (который совпадает с ее GUID).
- <vmname>.<vnetGUID.internal>.<регион>.<stackinternalFQDN>
- Все это выполняется автоматически
- Если вы используете общедоступные IP-адреса, для них можно дополнительно создать метки DNS. Они разрешаются так же, как любые другие внешние адреса.
- Серверы iDNS считаются полномочными серверами для внутренних зон DNS, а также выполняют роль распознавателя для общедоступных имен, когда клиентские виртуальные машины пытаются подключиться к внешним ресурсам. При получении запроса на адрес внешнего ресурса, серверы iDNS перенаправляют его для разрешения полномочным DNS-серверам.
Как показала работа в лаборатории, вы можете контролировать используемый IP-адрес. Если вы используете имя виртуальной машины, то получите частный IP-адрес, а для метки DNS — общедоступный IP-адрес.