Zrozumienie rozwiązywania nazw DNS w usłudze Application Gateway

Usługa Application Gateway jest dedykowanym wdrożeniem w ramach sieci wirtualnej. Rozpoznawanie nazw DNS dla wystąpień zasobu bramy aplikacyjnej, obsługującej ruch przychodzący, jest również zależne od konfiguracji sieci wirtualnej. W tym artykule omówiono konfiguracje systemu nazw domen (DNS) i ich wpływ na rozpoznawanie nazw.

Potrzeba rozwiązywania nazw domenowych

Usługa Application Gateway wykonuje rozpoznawanie nazw DNS dla w pełni kwalifikowanych nazw domen (FQDN)

• Nazwy FQDN udostępniane przez klienta, takie jak

  • Serwer zaplecza oparty na nazwie domeny
  • Punkt dostępu magazynu kluczy dla certyfikatu nasłuchującego
  • Adres URL niestandardowej strony błędu
  • Adres URL weryfikacji protokołu OCSP (Online Certificate Status Protocol)

• FQDN zarządzania które są używane dla różnych punktów końcowych infrastruktury platformy Azure (płaszczyzna sterowania). Są to bloki konstrukcyjne, które tworzą kompletny zasób usługi Application Gateway. Na przykład komunikacja z punktami końcowymi monitorowania umożliwia przepływ dzienników i metryk. Dlatego ważne jest, aby bramy aplikacji komunikowały się wewnętrznie z punktami końcowymi innych usług platformy Azure, które mają sufiksy, takie jak .windows.net, .azure.netitp.

Krótkie nazwy i nazwy domen z jedną etykietą

Usługa Application Gateway obsługuje krótkie nazwy (np. server1, webserver) w pulach zaplecza. Rozwiązanie zależy od konfiguracji DNS:

• Azure DNS (168.63.129.16): Rozpoznaje krótkie nazwy tylko w tej samej sieci wirtualnej
• Niestandardowe serwery DNS: wymaga konfiguracji domeny wyszukiwania
• Lokalny system DNS (za pośrednictwem sieci VPN/usługi ExpressRoute): rozpoznaje wewnętrzne nazwy hostów

Typy konfiguracji DNS

Klienci mają różne potrzeby dotyczące infrastruktury, wymagając różnych podejść do rozpoznawania nazw. W tym dokumencie opisano ogólne scenariusze implementacji DNS i przedstawiono zalecenia dotyczące wydajnej operacji zasobów usługi Application Gateway.

Bramy z publicznym adresem IP (networkIsolationEnabled: False)

W przypadku bram publicznych cała komunikacja płaszczyzny sterowania z domenami platformy Azure odbywa się za pośrednictwem domyślnego serwera DNS platformy Azure pod adresem 168.63.129.16. W tej sekcji przeanalizujemy możliwą konfigurację strefy DNS w połączeniu z publicznymi bramami aplikacyjnymi oraz jak unikać konfliktów przy rozpoznawaniu nazw domen w Azure.

Korzystanie z domyślnego systemu DNS udostępnianego przez platformę Azure

Dostępny na platformie Azure system DNS jest ustawieniem domyślnym dla wszystkich sieci wirtualnych na platformie Azure i ma adres IP 168.63.129.16. Oprócz rozpoznawania nazw domen publicznych usługa DNS zapewnia wewnętrzne rozpoznawanie nazw maszyn wirtualnych znajdujących się w tej samej sieci wirtualnej. W tym scenariuszu wszystkie instancje bramy aplikacji łączą się z 168.63.129.16 do rozpoznawania nazw DNS.

Przepływy

• Na tym diagramie widzimy, jak instancja usługi Application Gateway komunikuje się z dostarczanym przez Azure serwerem DNS (168.63.129.16) w celu rozwiązywania nazw FQDN serwerów zaplecza "server1.contoso.com" i "server2.contoso.com", jak pokazano niebieską linią.
• Podobnie wystąpienie wysyła zapytanie do 168.63.129.16, aby rozpoznać nazwę DNS zasobu usługi Key Vault z obsługą łącza prywatnego, jak pokazano pomarańczową linią. Aby umożliwić bramie aplikacji rozpoznawanie punktu końcowego usługi Key Vault jako prywatnego adresu IP, należy połączyć prywatną strefę DNS z siecią wirtualną tej bramy aplikacji.
• Po pomyślnym rozwiązaniu DNS dla tych FQDN, wystąpienie może komunikować się z Key Vault oraz punktami końcowymi serwera backend.

Zagadnienia do rozważenia:

• Nie twórz i łączyj prywatnych stref DNS dla nazw domen platformy Azure najwyższego poziomu. Musisz utworzyć strefę DNS dla poddomeny tak konkretnej, jak to możliwe. Na przykład posiadanie prywatnej strefy DNS dla privatelink.vaultcore.azure.net prywatnego punktu końcowego magazynu kluczy działa lepiej we wszystkich przypadkach niż posiadanie strefy dla vaultcore.azure.net lub azure.net.
• W przypadku komunikacji z serwerami zaplecza lub dowolną usługą korzystającą z prywatnego punktu końcowego upewnij się, że strefa DNS łącza prywatnego jest połączona z siecią wirtualną bramy aplikacji.

Używanie niestandardowych serwerów DNS

W sieci wirtualnej można wyznaczyć niestandardowe serwery DNS. Ta konfiguracja może być wymagana do zarządzania strefami niezależnie dla określonych nazw domen. Takie rozwiązanie nakazuje wystąpieniom bramy aplikacji w sieci wirtualnej, aby korzystały z określonych niestandardowych serwerów DNS do rozpoznawania nazw domen innych niż Azure.

Przepływy

• Diagram pokazuje, że instancja Application Gateway używa dostarczonego przez Azure systemu DNS (168.63.129.16) do rozwiązywania nazw punktu końcowego Private Link Key Vault "contoso.privatelink.vaultcore.azure.net". Zapytania DNS dotyczące nazw domen platformy Azure, które obejmują azure.net, są przekierowywane do usługi DNS udostępnianej przez platformę Azure (pokazanej w pomarańczowym wierszu).
• W przypadku rozpoznawania nazw DNS "server1.contoso.com" wystąpienie honoruje niestandardową konfigurację DNS (jak pokazano w niebieskiej linii).

Zagadnienia do rozważenia:

Użycie niestandardowych serwerów DNS w sieci wirtualnej bramy aplikacji wymaga podjęcia następujących działań, aby upewnić się, że nie ma to wpływu na funkcjonowanie bramy aplikacji.

• Po zmianie serwerów DNS skojarzonych z siecią wirtualną bramy sieciowej aplikacji, należy ponownie uruchomić (zatrzymać i uruchomić) bramę sieciową aplikacji, aby te zmiany zaczęły obowiązywać dla wystąpień.
• W przypadku korzystania z prywatnego punktu końcowego w sieci wirtualnej bramy aplikacji prywatna strefa DNS musi pozostać połączona z siecią wirtualną bramy aplikacji, aby umożliwić rozpoznawanie prywatnego adresu IP. Ta strefa DNS musi być dla poddomeny tak konkretnej, jak to możliwe.
• Jeśli niestandardowe serwery DNS znajdują się w innej sieci wirtualnej, upewnij się, że jest połączona z siecią wirtualną Application Gateway i nie jest wpływana przez konfiguracje grupy zabezpieczeń sieciowych lub tabel routingu.

Bramy z tylko prywatnym adresem IP (networkIsolationEnabled: True)

Wdrożenie prywatnej bramy aplikacji zostało zaprojektowane w celu oddzielenia ruchu w płaszczyźnie danych klienta od ruchu w płaszczyźnie zarządzania. W związku z tym posiadanie domyślnych serwerów DNS lub niestandardowych serwerów DNS nie ma wpływu na krytyczne rozwiązania nazw punktów końcowych zarządzania. Jednak w przypadku korzystania z niestandardowych serwerów DNS należy dbać o rozwiązania nazw wymagane dla wszystkich operacji ścieżki danych.

Przepływy

• Zapytania DNS dla "contoso.com" docierają do niestandardowych serwerów DNS za pośrednictwem płaszczyzny ruchu klienta.
• Zapytania DNS dla "contoso.privatelink.vaultcore.azure.net" również docierają do niestandardowych serwerów DNS. Jednak ponieważ serwer DNS nie jest autorytatywny dla tej nazwy domeny, przekazuje zapytanie rekursywnie do usługi Azure DNS 168.63.129.16. Taka konfiguracja jest ważna, aby umożliwić rozpoznawanie nazw za pośrednictwem prywatnej strefy DNS połączonej z siecią wirtualną.
• Rozwiązywanie wszystkich punktów końcowych zarządzania odbywa się za pośrednictwem ruchu płaszczyzny zarządzania, który bezpośrednio współdziała z DNS dostarczanym przez platformę Azure.

Zagadnienia do rozważenia:

• Po zmianie serwerów DNS skojarzonych z siecią wirtualną bramy sieciowej aplikacji, należy ponownie uruchomić (zatrzymać i uruchomić) bramę sieciową aplikacji, aby te zmiany zaczęły obowiązywać dla wystąpień.
• Należy ustawić reguły przekazywania, aby wysyłać wszystkie inne zapytania rozpoznawania domen do usługi Azure DNS 168.63.129.16. Ta konfiguracja jest szczególnie ważna, gdy masz prywatną strefę DNS na potrzeby rozpoznawania prywatnego punktu końcowego.
• W przypadku korzystania z prywatnego punktu końcowego prywatna strefa DNS musi pozostać połączona z siecią wirtualną bramy aplikacji, aby umożliwić rozpoznawanie prywatnego adresu IP.