Korzystanie z sieci iDNS w usłudze Azure Stack Hub
iDNS jest funkcją sieciową usługi Azure Stack Hub, która umożliwia rozpoznawanie zewnętrznych nazw DNS (na przykład https://www.bing.com). Umożliwia również rejestrowanie wewnętrznych nazw sieci wirtualnych. Dzięki temu można rozpoznać maszyny wirtualne w tej samej sieci wirtualnej według nazwy, a nie adresu IP. Takie podejście eliminuje konieczność podania niestandardowych wpisów serwera DNS. Aby uzyskać więcej informacji na temat systemu DNS, zobacz Omówienie usługi Azure DNS.
Co robi usługa iDNS?
Dzięki usłudze iDNS w usłudze Azure Stack Hub uzyskasz następujące możliwości bez konieczności określania niestandardowych wpisów serwera DNS:
- Udostępnione usługi rozpoznawania nazw DNS dla obciążeń tenantów.
- Autorytatywna usługa DNS do rozpoznawania nazw i rejestracji DNS w wirtualnej sieci najemcy.
- Rekursywna usługa DNS do rozpoznawania nazw internetowych z maszyn wirtualnych najemcy. Najemcy nie muszą już określać niestandardowych wpisów DNS w celu rozwiązywania nazw internetowych (na przykład www.bing.com).
Możesz nadal korzystać z własnego systemu DNS i używać niestandardowych serwerów DNS. Jednak przy użyciu iDNS można rozpoznać internetowe nazwy DNS i połączyć się z innymi maszynami wirtualnymi w tej samej sieci wirtualnej bez konieczności tworzenia niestandardowych wpisów DNS.
Co nie robi iDNS?
Usługa iDNS nie umożliwia utworzenia rekordu DNS dla nazwy, którą można rozpoznać spoza sieci wirtualnej.
Na platformie Azure możesz określić etykietę nazwy DNS skojarzona z publicznym adresem IP. Możesz wybrać etykietę (prefiks), ale platforma Azure wybiera sufiks oparty na regionie, w którym tworzysz publiczny adres IP.
Jak pokazano na poprzedniej ilustracji, platforma Azure utworzy rekord "A" w systemie DNS dla etykiety nazwy DNS określonej w strefie westus.cloudapp.azure.com. Prefiks i sufiks są łączone w celu utworzenia w pełni kwalifikowanej nazwy domeny (FQDN), które można rozpoznać z dowolnego miejsca w publicznym Internecie.
Usługa Azure Stack Hub obsługuje tylko iDNS na potrzeby rejestracji nazw wewnętrznych, więc nie może wykonywać następujących czynności:
- Utwórz rekord DNS w istniejącej hostowanej strefie DNS (na przykład local.azurestack.external).
- Utwórz strefę DNS (na przykład Contoso.com).
- Utwórz rekord w ramach własnej strefy DNS.
- Obsługa zakupu nazw domen.
Pokaz działania sieci iDNS
Wszystkie nazwy hostów maszyn wirtualnych w sieciach wirtualnych są przechowywane jako rekordy zasobów DNS w tej samej strefie, ale w ramach ich własnej unikatowej przestrzeni zdefiniowanej jako identyfikator GUID, skorelowanej z identyfikatorem sieci wirtualnej w infrastrukturze SDN, na której została wdrożona maszyna wirtualna. W pełni kwalifikowane nazwy domen (FQDN) maszyn wirtualnych dzierżawcy składają się z nazwy komputera i ciągu sufiksu DNS dla sieci wirtualnej w formacie GUID.
Poniżej przedstawiono proste laboratorium, które pokazuje, jak to działa. Utworzyliśmy 3 maszyny wirtualne w jednej sieci wirtualnej i innej maszynie wirtualnej w oddzielnej sieci wirtualnej:
| VM | Sieć wirtualna | Prywatny adres IP | Publiczny adres IP | Etykieta 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 | Ciąg sufiksu DNS |
|---|---|---|
| Sieć wirtualna 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 |
Możesz wykonać kilka testów rozpoznawania nazw, aby lepiej zrozumieć, jak działa system iDNS:
Z VM-A1 (Linux VM): Wyszukując VM-A2, można zobaczyć, że dodano sufiks DNS dla VNetA, a nazwa rozwiązuje się na prywatny adres 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
Wyszukiwanie maszyny wirtualnejA2-Label bez podawania pełnej nazwy domeny (FQDN) kończy się niepowodzeniem, jak zakładano:
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
Jeśli podasz nazwę FQDN etykiety DNS, nazwa zostanie rozpoznana jako publiczny adres 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
Próba rozwiązania VM-B1 (która pochodzi z innej sieci wirtualnej), kończy się niepowodzeniem, ponieważ ten rekord nie istnieje w tej strefie.
carlos@caalcobi-vm4:~$ nslookup VM-B1
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find VM-B1: SERVFAIL
Użycie nazwy FQDN dla VM-B1 nie pomaga, ponieważ ten rekord pochodzi z innej strefy.
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
Jeśli używasz nazwy FQDN dla etykiety DNS, zostanie rozpoznana pomyślnie:
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
Z VM-A3 (maszyna wirtualna z systemem Windows). Zwróć uwagę na różnicę między autorytatywnymi i nieautorytatywnymi odpowiedziami.
Rejestry wewnętrzne
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
Rekordy zewnętrzne:
> 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
Krótko mówiąc, z powyższego wynika, że:
- Każda sieć wirtualna ma własną strefę zawierającą rekordy A dla wszystkich prywatnych adresów IP, składających się z nazwy maszyny wirtualnej i sufiksu DNS sieci wirtualnej (czyli identyfikatora GUID).
- <vmname>.<vnetGUID>.internal.<region>.<stackinternalFQDN>
- Odbywa się to automatycznie
- Jeśli używasz publicznych adresów IP, możesz również utworzyć etykiety DNS dla nich. Są one rozwiązywane jak każdy inny adres zewnętrzny.
- Serwery iDNS są autorytatywnymi serwerami dla stref DNS wewnętrznych, a także działają jako resolver dla nazw publicznych, gdy maszyny wirtualne należące do dzierżawców próbują nawiązać połączenie z zasobami zewnętrznymi. Jeśli istnieje zapytanie dotyczące zasobu zewnętrznego, serwery iDNS przekazują żądanie do autorytatywnych serwerów DNS w celu rozwiązania problemu.
Jak widać w wynikach laboratorium, masz kontrolę nad używanym adresem IP. Jeśli używasz nazwy maszyny wirtualnej, otrzymasz prywatny adres IP, a jeśli używasz etykiety DNS, otrzymasz publiczny adres IP.