DNS-Name muss auf die App zeigen? Erstelle eine Azure-DNS-Zone

Veröffentlicht am:
#networking

CloudTrips ist über einen generierten azurefd.net-Hostnamen erreichbar. Ein eigener DNS-Name ist leichter zu erkennen. Die vorhandene Parent Domain cloudtrips.dev wird jedoch bereits von Vercel DNS gehostet. Das Ersetzen ihrer Nameserver könnte die aktuelle Website und weitere Einträge unterbrechen.

Delegiere deshalb nur azure.cloudtrips.dev an Azure DNS und erstelle anschließend diesen Anwendungsnamen in der Child Zone:

www.azure.cloudtrips.dev
.dev-Registry
    |
    `-- cloudtrips.dev -> Vercel DNS bleibt autoritativ
            |
            `-- azure.cloudtrips.dev -> an Azure DNS delegiert
                    |
                    `-- www CNAME -> CloudTrips-Front-Door-Endpunkt

Dieser Trip konfiguriert die öffentliche DNS-Auflösung und schließt danach die Anwendungskonfiguration ab: www.azure.cloudtrips.dev wird validiert, mit Front Door verknüpft und mit einem vertrauenswürdigen, von Front Door verwalteten TLS-Zertifikat bereitgestellt.

Dieser Trip hängt von Eine globale Webanwendung benötigt einen Edge-Einstieg? Erstelle Azure Front Door ab. Behalte afd-cloudtrips-test und den Endpunkt cloudtrips-edge-2930ec0f. Du benötigst außerdem Zugriff auf die Vercel-DNS-Einstellungen für cloudtrips.dev.

Die Zonendelegierung verstehen

Eine DNS-Zone speichert Einträge für einen DNS-Namensraum. Eine Parent Zone delegiert eine Child Zone mit NS Records, die die autoritativen Server der Child Zone benennen.

Für dieses Design gilt:

Parent Zone: cloudtrips.dev
DNS-Provider der Parent Zone: Vercel
Name des Delegierungseintrags: azure
Child Zone: azure.cloudtrips.dev
DNS-Provider der Child Zone: Azure DNS
Anwendungseintrag: www.azure.cloudtrips.dev

Die NS Records in cloudtrips.dev weisen rekursive DNS Resolver an, Azure DNS nach Namen unterhalb von azure.cloudtrips.dev zu fragen. Einträge außerhalb dieser Child Zone bleiben unter der Kontrolle von Vercel.

Einfach ausgedrückt teilt Vercel dem Resolver mit, wo er als Nächstes suchen soll:

Der Resolver fragt Vercel:
"Wer verwaltet azure.cloudtrips.dev?"

Vercel antwortet:
"Frage diese vier Azure-DNS-Server."

Der Resolver fragt Azure DNS:
"Was ist www.azure.cloudtrips.dev?"

Azure DNS antwortet:
"Das ist ein CNAME zum Front-Door-Endpunkt."

Die Zuständigkeitskette lautet damit:

cloudtrips.dev             -> Vercel DNS
azure.cloudtrips.dev       -> Azure DNS durch NS-Delegierung
www.azure.cloudtrips.dev   -> Front Door durch einen CNAME in Azure DNS

Bei der Delegierung werden die Child Records nicht nach Vercel kopiert. Vercel speichert nur den NS-Verweis; Azure DNS speichert und beantwortet die Einträge innerhalb der Child Zone.

Ersetze nicht die Nameserver für die gesamte Domain cloudtrips.dev. Dieser Trip fügt eine Child-Zone-Delegierung hinzu und migriert nicht die Parent Zone.

Das vorhandene Parent DNS bestätigen

Prüfe die autoritativen Nameserver, bevor du Änderungen vornimmst:

dig +short NS cloudtrips.dev

Das aktuelle Ergebnis sollte enthalten:

ns1.vercel-dns.com.
ns2.vercel-dns.com.

Speichere außerdem den Front-Door-Hostnamen:

AFD_HOST=$(az afd endpoint list \
  --resource-group rg-cloudtrips-network-test-weu \
  --profile-name afd-cloudtrips-test \
  --query '[0].hostName' \
  --output tsv)

printf 'Front-Door-Hostname: %s\n' "$AFD_HOST"

Der Wert muss ein Hostname wie cloudtrips-edge-...z03.azurefd.net sein, ohne https:// oder einen Pfad.

Die Azure DNS Child Zone erstellen

Suche im Azure-Portal nach DNS zones, wähle + Create und konfiguriere:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu
This zone is a child of an existing zone already hosted in Azure DNS: Cleared
Name: azure.cloudtrips.dev

Lasse die Child-Zone-Option deaktiviert, weil die Parent Zone bei Vercel und nicht bei Azure DNS gehostet wird. DNS-Zonen sind global; die Region der Resource Group schränkt die DNS-Antworten nicht regional ein.

Wähle Review + create > Create und öffne anschließend die neue Zone.

Azure-Portal-Seite Create DNS zone für die delegierte Child Zone azure.cloudtrips.dev

Azure erstellt automatisch den SOA Record und das autoritative NS Record Set der Zone. Bearbeite oder lösche diese Einträge nicht.

Die Azure Nameserver kopieren

Kopiere auf der Übersichtsseite von azure.cloudtrips.dev alle vier Werte unter Name servers. Azure weist jeder Zone eine eindeutige Gruppe zu; kopiere keine Werte aus einem Beispiel oder einem anderen Abonnement.

Rufe dieselben Werte mit Azure CLI ab:

az network dns zone show \
  --resource-group rg-cloudtrips-network-test-weu \
  --name azure.cloudtrips.dev \
  --query 'nameServers[]' \
  --output tsv

Dieser Befehl muss alle vier Nameserver ausgeben. Kopiere alle vier beim Erstellen der Delegierung in die Parent Zone.

Speichere für spätere Diagnoseabfragen nur den ersten Server in einer eindeutig singulär benannten Variablen. Ein autoritativer Server reicht für einen direkten dig-Test aus. Die Delegierung muss trotzdem alle vier enthalten:

AZURE_DNS_TEST_NS=$(az network dns zone show \
  --resource-group rg-cloudtrips-network-test-weu \
  --name azure.cloudtrips.dev \
  --query 'nameServers[0]' \
  --output tsv)

printf 'Azure-DNS-Testserver: %s\n' "$AZURE_DNS_TEST_NS"

Übersicht der Azure-DNS-Zone mit den vier autoritativen Nameservern für azure.cloudtrips.dev

Die Child Zone von Vercel delegieren

Öffne das Vercel-Team, das cloudtrips.dev verwaltet, wähle Domains, öffne cloudtrips.dev und danach seine DNS Records. Füge für jeden der vier Azure-Nameserver einen eigenen NS Record hinzu:

Type: NS
Name: azure
Value: Use one Azure DNS name-server value
TTL: Use the provider default

Alle vier Records verwenden denselben Namen azure, aber jeweils einen anderen Azure-Nameserver-Wert. Gib die Werte exakt ein. Ein abschließender Punkt ist gültig, wenn Vercel ihn beibehält.

Verwende nicht @ als Record-Namen und ändere nicht die Vercel-Nameserver auf Domain-Ebene. Diese Änderungen würden die gesamte Parent Domain betreffen, anstatt nur azure.cloudtrips.dev zu delegieren.

Vercel-DNS-Einstellungen mit vier azure-NS-Records zur Delegierung der Child Zone an Azure DNS

DNS-Änderungen benötigen Zeit, weil Resolver vorherige Antworten zwischenspeichern. Teste zuerst die Parent-Delegierung direkt gegen Vercel:

dig @ns1.vercel-dns.com azure.cloudtrips.dev NS +short

Die Antwort sollte dieselben vier Azure-DNS-Server auflisten.

Die Azure Child Zone überprüfen

Shell-Variablen gelten nur in der Terminal-Sitzung, in der sie gesetzt wurden. Wenn du seit dem vorherigen Schritt ein neues Terminal geöffnet hast, rufe den Testserver erneut ab und bestätige, dass der Wert nicht leer ist:

AZURE_DNS_TEST_NS=$(az network dns zone show \
  --resource-group rg-cloudtrips-network-test-weu \
  --name azure.cloudtrips.dev \
  --query 'nameServers[0]' \
  --output tsv)

printf 'Azure-DNS-Testserver: %s\n' "$AZURE_DNS_TEST_NS"

Führe den nächsten Befehl nur aus, wenn die Ausgabe einen Hostnamen wie ns1-08.azure-dns.com. enthält. Bei einem leeren Wert meldet dig couldn't get address for '': not found.

Frage den zugewiesenen Azure-Server nach dem SOA Record der Child Zone:

dig @"$AZURE_DNS_TEST_NS" azure.cloudtrips.dev SOA +short

Dieser Befehl umgeht den normalen öffentlichen DNS-Pfad und fragt einen zugewiesenen Azure-DNS-Server direkt:

@"$AZURE_DNS_TEST_NS"  Anfrage an genau diesen Azure-DNS-Server senden
azure.cloudtrips.dev   Apex der Child Zone abfragen
SOA                    Start-of-Authority-Record anfordern
+short                 Nur den Record-Wert anzeigen

Ein SOA Record kennzeichnet die Autorität und Betriebsparameter einer DNS-Zone. Eine erfolgreiche Antwort sieht beispielsweise so aus:

ns1-08.azure-dns.com. azuredns-hostmaster.microsoft.com. 1 3600 300 604800 300

Der erste Wert bezeichnet den primären Azure-DNS-Server der Zone. Der zweite repräsentiert den administrativen Kontakt; der erste Punkt steht dabei für das @ einer E-Mail-ähnlichen Adresse. Die übrigen Zahlen sind Serial-, Refresh-, Retry-, Expiry- und Negative-Cache-Zeitwerte der Zone.

Diese direkte Antwort beweist, dass die Azure-DNS-Child-Zone existiert und der ausgewählte Azure-Server dafür autoritativ ist. Sie beweist noch nicht, dass öffentliche Resolver diesen Server über cloudtrips.dev finden. Die folgenden öffentlichen dig-Befehle testen separat die NS-Delegierung bei Vercel.

Prüfe danach den öffentlichen Delegierungspfad:

dig +short NS azure.cloudtrips.dev
dig +short SOA azure.cloudtrips.dev

Wenn die direkten Abfragen funktionieren, die öffentliche Abfrage aber leer ist, warte auf die DNS-Propagation und versuche es erneut. Erstelle die Azure-Zone nicht neu, weil dadurch andere Nameserver zugewiesen und die Parent-Delegierung ungültig würden.

Den Front-Door-CNAME erstellen

Kehre zur Azure-DNS-Zone azure.cloudtrips.dev zurück, wähle + Record set und konfiguriere:

Name: www
Type: CNAME
Alias record set: No
TTL: 300
TTL unit: Seconds
Alias: Use the AFD_HOST value

Der fertige Eintrag bildet Folgendes ab:

www.azure.cloudtrips.dev
    -> cloudtrips-edge-2930ec0f-...z03.azurefd.net

Gib als CNAME-Wert nur den Front-Door-Hostnamen ein. Verwende weder https:// noch / oder einen URL-Pfad.

Azure-DNS-Record-Set mit www als CNAME zum generierten CloudTrips-Front-Door-Hostnamen

Die DNS-Auflösung testen

Wenn dieser Test in einem neuen Terminal läuft, rufe den Testserver erneut ab:

AZURE_DNS_TEST_NS=$(az network dns zone show \
  --resource-group rg-cloudtrips-network-test-weu \
  --name azure.cloudtrips.dev \
  --query 'nameServers[0]' \
  --output tsv)

dig @"$AZURE_DNS_TEST_NS" www.azure.cloudtrips.dev CNAME +short

Er sollte den generierten Front-Door-Hostnamen zurückgeben. Teste danach die gesamte öffentliche DNS-Kette:

dig www.azure.cloudtrips.dev CNAME +short

Das Ergebnis sollte $AFD_HOST entsprechen:

cloudtrips-edge-2930ec0f-...z03.azurefd.net.

Lokales Terminal mit der Vercel-Child-Zone-Delegierung und dem über Azure DNS zu Front Door aufgelösten www-CNAME

DNS-Auflösung allein bedeutet nicht, dass die Anwendungs-URL bereits einsatzbereit ist. Bis Front Door die Custom Domain validiert und verknüpft, kann dieser Befehl bei der TLS-Prüfung fehlschlagen oder eine unerwartete Front-Door-Antwort liefern:

curl --head https://www.azure.cloudtrips.dev/

Dieses Verhalten ist an dieser Stelle zu erwarten. DNS beantwortet, wohin der Hostname zeigt. Die Front-Door-Domain-Konfiguration entscheidet, ob der Dienst diesen Hostnamen akzeptiert und ein passendes Zertifikat bereitstellen kann.

Die zwei TLS-Verbindungen verstehen

Front Door beendet die TLS-Verbindung des Clients am Edge und erstellt danach eine separate Verbindung zum ausgewählten Origin:

Browser -- HTTPS/TLS --> Front Door -- HTTP in diesem Lab --> Origin

Das nachfolgend konfigurierte verwaltete Zertifikat schützt die erste Verbindung und ist für www.azure.cloudtrips.dev gültig. Es ändert nicht das Origin-Forwarding-Protocol der Route. Das CloudTrips Application Gateway aus dem vorausgesetzten Trip besitzt einen HTTP-Listener. Route und Health Probes bleiben in diesem Lab deshalb auf HTTP. End-to-End-TLS würde HTTPS-Unterstützung und vertrauenswürdige Zertifikate auf jedem Origin voraussetzen, bevor das Forwarding Protocol von Front Door umgestellt wird.

Die Top-Level-Domain .dev ist in wichtigen Browsern per HSTS vorgeladen. Browser erwarten daher HTTPS. Vor der normalen Verwendung des neuen Namens im Browser ist ein gültiges Zertifikat erforderlich.

DigiCert mit einem CAA Record autorisieren

Ein Certification Authority Authorization (CAA) Record beschränkt, welche Zertifizierungsstellen Zertifikate für eine Domain ausstellen dürfen. Wenn ein Hostname keinen CAA Record besitzt, sucht eine Zertifizierungsstelle in den übergeordneten Domains weiter, bis sie eine CAA Policy findet.

Prüfe die Child Zone und Parent Zone:

dig +short CAA azure.cloudtrips.dev
dig +short CAA cloudtrips.dev

azure.cloudtrips.dev besitzt derzeit keinen CAA Record und erbt deshalb die Parent Policy von cloudtrips.dev. Wenn die Parent-Ausgabe andere Zertifizierungsstellen erlaubt, aber digicert.com nicht enthält, kann Front Door sein verwaltetes Zertifikat nicht beziehen. Azure Front Door verwendet DigiCert für dieses Zertifikat.

Erstelle einen CAA Record am Apex der Azure Child Zone. Öffne azure.cloudtrips.dev, wähle + Record set und konfiguriere:

Name: @
Type: CAA
TTL: 300 seconds
Flags: 0
Tag: issue
Value: digicert.com

Der Name @ bezeichnet den Apex der Zone azure.cloudtrips.dev. Der dort veröffentlichte Record erstellt eine CAA Policy für die Child Zone. Die Suche der Zertifizierungsstelle erbt dadurch nicht mehr die restriktivere Parent Policy. Die CAA Records der bei Vercel gehosteten Site cloudtrips.dev werden nicht verändert.

Der entsprechende Azure-CLI-Befehl lautet:

az network dns record-set caa add-record \
  --resource-group rg-cloudtrips-network-test-weu \
  --zone-name azure.cloudtrips.dev \
  --record-set-name @ \
  --flags 0 \
  --tag issue \
  --value digicert.com

Prüfe die autoritative und öffentliche Antwort:

dig @"$AZURE_DNS_TEST_NS" azure.cloudtrips.dev CAA +short
dig azure.cloudtrips.dev CAA +short

Beide sollten schließlich zurückgeben:

0 issue "digicert.com"

Wenn nur dieser Record vorhanden ist, ist DigiCert die einzige autorisierte Ausgabestelle für Namen unter der Child Zone. Benötigt ein anderer Dienst dort später eine andere Zertifizierungsstelle, füge einen weiteren passenden issue-CAA-Record hinzu, anstatt die DigiCert-Autorisierung zu entfernen.

Azure-DNS-Child-Zone mit einem CAA Record am Apex, der DigiCert für verwaltete Front-Door-Zertifikate autorisiert

Die Custom Domain zu Front Door hinzufügen

Öffne afd-cloudtrips-test, wähle Settings > Domains und danach + Add. Konfiguriere:

Domain type: Non-Azure pre-validated domain
DNS management: Azure managed DNS (Recommended)
DNS zone: azure.cloudtrips.dev
Custom domain: www.azure.cloudtrips.dev
HTTPS: AFD managed (Recommended)
Minimum TLS version: TLS 1.2, if displayed

Dies ist eine nicht von Azure vorab validierte Domain, weil kein unterstützter Azure-Anwendungsdienst sie bereits für Front Door validiert hat. Das Hosting ihrer DNS-Zone in Azure macht sie nicht zu einer Azure-prevalidated Anwendungsdomain.

Wähle Add. Front Door erstellt eine Custom-Domain-Konfiguration und startet die Eigentumsvalidierung sowie die Zertifikatbereitstellung.

Azure-Front-Door-Dialog Add a domain für www.azure.cloudtrips.dev mit Azure-managed DNS und AFD-managed certificate

Den Domainbesitz validieren

Prüfe auf der Front-Door-Seite Domains den Validation State von www.azure.cloudtrips.dev. Wenn Azure die ausgewählte DNS-Zone verwalten kann, kann das Portal anbieten, den erforderlichen Validation Record automatisch hinzuzufügen. Verwende diese Option, wenn sie verfügbar ist.

Wenn die Domain Pending bleibt, öffne ihre Validation Details und kopiere den von Front Door bereitgestellten TXT-Token. Erstelle in der DNS-Zone azure.cloudtrips.dev:

Name: _dnsauth.www
Type: TXT
TTL: 300 seconds
Value: Use the exact validation token supplied by Front Door

Der vollständig qualifizierte Name lautet:

_dnsauth.www.azure.cloudtrips.dev

Kopiere keinen Token aus diesem Trip oder einem anderen Profil. Front Door generiert einen eindeutigen Wert für die Custom-Domain-Konfiguration.

Prüfe, ob der autoritative Azure-Server den Token zurückgibt:

AZURE_DNS_TEST_NS=$(az network dns zone show \
  --resource-group rg-cloudtrips-network-test-weu \
  --name azure.cloudtrips.dev \
  --query 'nameServers[0]' \
  --output tsv)

dig @"$AZURE_DNS_TEST_NS" \
  _dnsauth.www.azure.cloudtrips.dev TXT +short

Prüfe ihn anschließend über das öffentliche DNS:

dig _dnsauth.www.azure.cloudtrips.dev TXT +short

Kehre zu Front Door zurück und aktualisiere den Domain State. Warte, bis die Validierung Approved anzeigt. DNS- und Front-Door-Propagation können mehrere Minuten dauern.

Die Domain mit Endpunkt und Route verknüpfen

Die Domainvalidierung beweist den Besitz, wählt aber noch nicht den Endpunkt und die Route für Anfragen aus. Wähle auf der Front-Door-Seite Domains den Status Unassociated der Domain. Konfiguriere:

Endpoint: cloudtrips-edge-2930ec0f
Routes: route-cloudtrips-all

Wähle Associate. Dadurch kann die vorhandene /*-Route Anfragen mit dem Host Header www.azure.cloudtrips.dev verarbeiten. Es wird weder ein zweiter Endpunkt erstellt noch die Route dupliziert.

Azure-Front-Door-Custom-Domain mit dem CloudTrips-Endpunkt und route-cloudtrips-all verknüpft

Das von AFD verwaltete Zertifikat wird nach erfolgreicher Validierung und Verknüpfung bereitgestellt. Warte auf der Domains-Seite auf diese Zustände:

Validation state: Approved
Endpoint association: Associated
Certificate state: Deployed

Zertifikatausstellung und globale Edge-Bereitstellung können mehrere Minuten und in manchen Fällen bis zu einer Stunde dauern. Der vorhandene azurefd.net-Endpunkt bleibt währenddessen verfügbar.

Du kannst die Bereitstellung mit der CLI prüfen:

az afd custom-domain show \
  --resource-group rg-cloudtrips-network-test-weu \
  --profile-name afd-cloudtrips-test \
  --custom-domain-name www-azure-cloudtrips-dev-e9e4 \
  --query '{validation:domainValidationState, provisioning:provisioningState, deployment:deploymentStatus, certificate:tlsSettings.certificateType}' \
  --output table

Teste den benutzerdefinierten Hostnamen erst, wenn deployment den Wert Succeeded meldet und das Portal Certificate state: Deployed anzeigt. Meldet curl den Fehler 60 und dass kein alternativer Zertifikatsname zum Hostnamen passt, liefert Front Door noch ein Zertifikat für einen anderen Hostnamen aus. Das ist während deploymentStatus: InProgress zu erwarten. Warte und versuche es erneut. Verwende nicht curl -k, denn damit würdest du genau die Zertifikatsprüfung abschalten, die dieser Test nachweisen soll.

HTTPS und das Zertifikat überprüfen

Rufe die Anwendung über die Custom Domain auf:

curl --silent --show-error \
  --dump-header - \
  "https://www.azure.cloudtrips.dev/" \
  --output -

Die Anfrage sollte über HTTPS erfolgreich sein und den normalen CloudTrips- Body von WEB01 oder WEB02 enthalten. Ein x-azure-ref-Header sollte außerdem belegen, dass Front Door die Anfrage verarbeitet hat.

Untersuche das für den Hostnamen bereitgestellte Zertifikat:

openssl s_client \
  -connect www.azure.cloudtrips.dev:443 \
  -servername www.azure.cloudtrips.dev \
  </dev/null 2>/dev/null \
  | openssl x509 \
      -noout \
      -subject \
      -issuer \
      -dates

Zeige die Subject Alternative Names mit einem Befehl an, der auch mit der von macOS mitgelieferten LibreSSL-Version funktioniert:

openssl s_client \
  -connect www.azure.cloudtrips.dev:443 \
  -servername www.azure.cloudtrips.dev \
  </dev/null 2>/dev/null \
  | openssl x509 -noout -text \
  | sed -n '/Subject Alternative Name/{n;p;}'

Das Zertifikat muss innerhalb seines Gültigkeitszeitraums liegen und www.azure.cloudtrips.dev in den Subject Alternative Names enthalten. Das Argument -servername sendet TLS Server Name Indication, damit Front Door das Zertifikat für diese Custom Domain auswählt.

Lokales Terminal mit erfolgreichem HTTPS und Details des von Front Door verwalteten Zertifikats für www.azure.cloudtrips.dev

Bestätige abschließend, dass die vorhandene Rules-Engine-Logik auch über die neue Domain funktioniert:

curl --silent --show-error \
  --dump-header - \
  --header 'X-CloudTrips-Mode: maintenance' \
  "https://www.azure.cloudtrips.dev/" \
  --output -

Nach der Propagation der Regel sollte die Antwort x-cloudtrips-rule: maintenance und die Storage-Maintenance-Seite enthalten. Dieselbe Route und dasselbe Rule Set verarbeiten sowohl die generierte Front-Door-Domain als auch die Custom Domain.

Lokales Terminal mit der Antwort der Maintenance-Regel über www.azure.cloudtrips.dev

Das DNS-Lab behalten oder entfernen

Behalte die Azure-DNS-Zone, ihre Records, die vier NS Records in der Parent Zone und die Front-Door-Custom-Domain für spätere Front-Door- und DNS-Trips.

Wenn du hier stoppst, entferne zuerst die Endpoint-and-Route-Verknüpfung der Custom Domain und lösche danach die Front-Door-Custom-Domain-Konfiguration. Entferne anschließend die vier azure-NS-Records aus Vercel. Warte, bis die Delegierung verschwunden ist, und lösche danach die Azure-DNS-Zone azure.cloudtrips.dev. Beim Löschen der Child Zone als ersten Schritt würde eine defekte Delegierung in der Parent Zone zurückbleiben.