Korzystanie z sieci iDNS w usłudze Azure Stack Hub
IDNS to funkcja sieci 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ść podawania 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 uzyskujesz 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ń dzierżawy.
- Autorytatywna usługa DNS do rozpoznawania nazw i rejestracji DNS w sieci wirtualnej dzierżawy.
- Rekursywna usługa DNS do rozpoznawania nazw internetowych z maszyn wirtualnych dzierżawy. Dzierżawy nie muszą już określać niestandardowych wpisów DNS do rozpoznawania 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 sieci 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?
IDNS nie umożliwia utworzenia rekordu DNS dla nazwy, którą można rozpoznać spoza sieci wirtualnej.
Na platformie Azure można określić etykietę nazwy DNS skojarzona z publicznym adresem IP. Możesz wybrać etykietę (prefiks), ale platforma Azure wybiera sufiks, który jest 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 westus.cloudapp.azure.com strefy. Prefiks i sufiks są łączone w celu utworzenia w pełni kwalifikowanej nazwy domeny (FQDN), którą 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 niestandardowej 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, jednak w ramach własnego unikatowego przedziału zdefiniowanego jako identyfikator GUID, który jest skorelowany z identyfikatorem sieci wirtualnej w infrastrukturze SDN wdrożonej przez maszynę wirtualną. W pełni kwalifikowane nazwy domen maszyny wirtualnej dzierżawy (FQDN) składają się z nazwy komputera i ciągu sufiksu DNS dla Virtual Network w formacie GUID.
Poniżej przedstawiono proste laboratorium, w których pokazano, jak to działa. Utworzyliśmy 3 maszyny wirtualne w jednej sieci wirtualnej, a drugą maszynę wirtualną w oddzielnej sieci wirtualnej:
| VM | Sieć wirtualna | Prywatny adres IP | Publiczny adres IP | Etykieta DNS |
|---|---|---|---|---|
| MASZYNA WIRTUALNA-A1 | Sieć wirtualna | 10.0.0.5 | 172.31.12.68 | VM-A1-Label.lnv1.cloudapp.azscss.external |
| VM-A2 | Sieć wirtualna | 10.0.0.6 | 172.31.12.76 | VM-A2-Label.lnv1.cloudapp.azscss.external |
| MASZYNA WIRTUALNA-A3 | Sieć wirtualna | 10.0.0.7 | 172.31.12.49 | VM-A3-Label.lnv1.cloudapp.azscss.external |
| MASZYNA WIRTUALNA-B1 | VNetB | 10.0.0.4 | 172.31.12.57 | VM-B1-Label.lnv1.cloudapp.azscss.external |
| Sieć wirtualna | GUID | Ciąg sufiksu DNS |
|---|---|---|
| Sieć wirtualna | 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 |
Aby lepiej zrozumieć, jak działa system iDNS, możesz wykonać kilka testów rozpoznawania nazw:
Z maszyny wirtualnej VM-A1 (Linux): Szukanie maszyny wirtualnej VM-A2. Widać, że sufiks DNS dla sieci wirtualnej jest dodawany, a nazwa jest rozpoznawana jako 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
Szukanie etykiety VM-A2 bez podawania nazwy FQDN kończy się niepowodzeniem zgodnie z oczekiwaniami:
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 problemu z maszyną wirtualną 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 maszyny wirtualnej 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 ona 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 maszyny wirtualnej VM-A3 (Maszyna wirtualna z systemem Windows). Zwróć uwagę na różnicę między autorytatywnymi i nieautorytatywnymi odpowiedziami.
Rekordy 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, można zobaczyć z powyższych:
- 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 (który jest jego identyfikatorem GUID).
- <vmname>.<vnetGUID.internal>.<region>.<stackinternalFQDN>
- Odbywa się to automatycznie
- Jeśli używasz publicznych adresów IP, możesz również utworzyć dla nich etykiety DNS. Są one rozwiązywane jak każdy inny adres zewnętrzny.
- Serwery iDNS to autorytatywne serwery dla ich wewnętrznych stref DNS, a także pełnią rolę rozpoznawania nazw publicznych, gdy maszyny wirtualne dzierżawy próbują połączyć się z zasobami zewnętrznymi. Jeśli istnieje zapytanie dotyczące zasobu zewnętrznego, serwery iDNS przekazują żądanie do autorytatywnych serwerów DNS w celu rozpoznania.
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.