Einen Domainnamen für eine Anwendung konfigurieren

Einführung

Die Anwendung beantwortet bereits HTTP-Anfragen, doch ihre Nutzer benötigen einen Namen. Erstelle eine gehostete Route-53-Zone und einen A-Eintrag, beobachte die tatsächliche DNS-Antwort und verwende die zurückgegebene Adresse für die vorbereitete Anwendung.

Schließe zuerst AWS Foundations ab. Diese unabhängige VM stellt einen konfigurierten AWS-CLI-Zugang, einen DNS-Abfrageendpunkt und eine separate Referenzzone bereit. Du brauchst weder ein persönliches AWS-Konto noch eine gekaufte Domain. Beobachte die Einträge oben in AWS View und führe Befehle unten im Terminal aus. Der Übungsname endet auf .test; dieses Labor registriert oder delegiert keine öffentliche Domain.

Bezug zur Zertifizierung

Zertifizierung	Prüfungsaufgabe	Übung
Cloud Practitioner (CLF-C02)	Aufgabe 3.5	Route 53, DNS-Einträge und Namensauflösung für eine Anwendung.

Laborübersicht

Konzeptdiagramm: Route-53-Eintrag konfigurieren, DNS-Antwort erhalten und mit der zurückgegebenen Adresse die Anwendung anfragen.

Den Anwendungsnamen erstellen

In diesem Schritt erstelle eine gehostete Zone und einen A-Eintrag für die vorbereitete Anwendung.

DNS übersetzt Namen in Informationen wie IP-Adressen. Eine gehostete Zone enthält die Einträge einer Domain. Ein A-Eintrag ordnet einen Namen einer IPv4-Adresse zu. Er startet keine Anwendung und öffnet keine Netzwerkverbindung.

Die Domain heißt labex-n01.test, der Anwendungsname wird app.labex-n01.test. Die Anwendung lauscht auf 127.0.0.1 am HTTP-Port 8081. Diese Loopback-Adresse bezeichnet die VM; alle Anfragen bleiben deshalb in der Übungsumgebung.

Erstelle die Zone:

cd /home/labex/project
ZONE_ID=$(aws route53 create-hosted-zone \
  --name labex-n01.test \
  --caller-reference labex-n01-application \
  --query HostedZone.Id \
  --output text)

$(...) speichert die Befehlsausgabe in der Shell-Variablen ZONE_ID. --query wählt die neue Zonen-ID und --output text macht sie als Argument nutzbar. CallerReference unterscheidet diese Erstellungsanfrage. Lass dieses Terminal geöffnet, damit die Variable erhalten bleibt.

Die Eintragsänderung wird als JSON übergeben. Das Here-Dokument mit Anführungszeichen schreibt wörtlichen Text nach record.json. TTL gibt in Sekunden an, wie lange DNS-Caches die Antwort wiederverwenden dürfen. Dieser Server beantwortet direkt eine autoritative Abfrage; das Labor misst keinen rekursiven Cache.

cat > record.json <<'JSON'
{
  "Changes": [{
    "Action": "CREATE",
    "ResourceRecordSet": {
      "Name": "app.labex-n01.test",
      "Type": "A",
      "TTL": 60,
      "ResourceRecords": [{"Value": "127.0.0.1"}]
    }
  }]
}
JSON

Wende die Änderung auf deine Zone an. file:// liest die lokale JSON-Datei:

aws route53 change-resource-record-sets \
  --hosted-zone-id "$ZONE_ID" \
  --change-batch file://record.json

Die Antwort identifiziert die Änderung und belegt die Konfiguration. Der nächste Schritt prüft eine tatsächliche DNS-Antwort. Lies den gespeicherten Eintrag:

aws route53 list-resource-record-sets \
  --hosted-zone-id "$ZONE_ID" \
  --query "ResourceRecordSets[?Type=='A']"

Finde den Anwendungsnamen, A, TTL 60 und 127.0.0.1. AWS View zeigt den Eintrag in deiner Zone neben der separaten Referenzzone. Ändere die Referenzzone nicht. Führe vor dem nächsten Schritt die Prüfung aus.

Beispiel nach der Erstellung: Der A-Eintrag der Anwendung erscheint neben der unveränderten Referenzzone.

DNS abfragen und die Anwendung aufrufen

In diesem Schritt unterscheide eine gültige DNS-Antwort, einen fehlenden Namen und eine erfolgreiche HTTP-Anfrage.

dig ist ein DNS-Abfragewerkzeug. @127.0.0.1 wählt den vorbereiteten Server, -p 1053 seinen Übungsport. +norecurse fordert eine autoritative Antwort ohne rekursive Suche an. Damit prüfst du diesen Server ausdrücklich, ohne den Systemresolver der VM zu ändern.

dig +norecurse @127.0.0.1 -p 1053 app.labex-n01.test A

Erwarte status: NOERROR und einen ANSWER-Eintrag mit dem Namen, TTL 60, Typ A und Adresse 127.0.0.1. Die Antwort stammt aus deinem tatsächlichen Route-53-Eintrag. Vergleiche einen nicht erstellten Namen:

dig +norecurse @127.0.0.1 -p 1053 missing.labex-n01.test A

Erwarte status: NXDOMAIN und keine Antwort. Der DNS-Austausch war erfolgreich und meldet einen fehlenden Namen; die Verbindung zum Server ist nicht fehlgeschlagen. AWS View zeigt die letzte echte Abfrage und die Anzahl der Antworten.

Speichere jetzt die Adresse. +short gibt nur die Antwort aus:

APP_IP=$(dig +norecurse @127.0.0.1 -p 1053 app.labex-n01.test A +short)
printf '%s\n' "$APP_IP"

curl führt die HTTP-Anfrage aus. --resolve verwendet die gerade ermittelte Adresse für den genauen Namen und Port dieser Anfrage. Es registriert keine Domain und verändert das System-DNS nicht.

curl --fail --noproxy '*' \
  --resolve "app.labex-n01.test:8081:${APP_IP}" \
  http://app.labex-n01.test:8081/

Erwartete Ausgabe:

Delivery application ready

DNS lieferte eine Adresse; HTTP erreichte anschließend eine Anwendung an dieser Adresse. Dies sind zwei unterschiedliche Ergebnisse. Eine gültige DNS-Antwort allein beweist nicht, dass die Anwendung läuft. Führe die Abfrage- und Zugriffsprüfung aus.

Beispiel nach einer tatsächlichen Abfrage: Eine A-Antwort wird zurückgegeben, während beide Zonen erhalten bleiben.

Nur die Anwendungszone entfernen

In diesem Schritt entferne deinen Eintrag und deine gehostete Zone und beobachte, dass der Name nicht mehr aufgelöst wird.

Eine Zone mit Anwendungseinträgen kann normalerweise nicht gelöscht werden. Eine DELETE-Änderung muss Name, Typ, TTL und Wert des Eintrags genau übernehmen. Schreibe denselben Eintrag mit der Löschaktion:

cat > delete-record.json <<'JSON'
{
  "Changes": [{
    "Action": "DELETE",
    "ResourceRecordSet": {
      "Name": "app.labex-n01.test",
      "Type": "A",
      "TTL": 60,
      "ResourceRecords": [{"Value": "127.0.0.1"}]
    }
  }]
}
JSON

Wende die Löschung an und entferne die nun leere Anwendungszone:

aws route53 change-resource-record-sets \
  --hosted-zone-id "$ZONE_ID" \
  --change-batch file://delete-record.json
aws route53 delete-hosted-zone \
  --id "$ZONE_ID"

Frage den entfernten Namen erneut ab:

dig +norecurse @127.0.0.1 -p 1053 app.labex-n01.test A

Erwarte NXDOMAIN. Die vorbereitete Anwendung gehört nicht zu deinen DNS-Ressourcen und kann weiterlaufen: Ein DNS-Eintrag entfernt nur die Namenszuordnung, nicht die Anwendung. AWS View soll nur noch die Referenzzone anzeigen. Führe die Bereinigungsprüfung aus.

Bereinigungsbeispiel: Der entfernte Name liefert NXDOMAIN und die unveränderte Referenzzone bleibt erhalten.

Zusammenfassung

Du hast eine gehostete Zone und einen A-Eintrag erstellt, tatsächliche DNS-Antworten gelesen, die Anwendung mit der zurückgegebenen Adresse aufgerufen und nur deine eigenen DNS-Ressourcen entfernt. Du hast Eintragskonfiguration, Namensauflösung und Anwendungsverfügbarkeit unterschieden. Als Nächstes lernst du, wie CloudFront Inhalte aus einem zugriffsbeschränkten S3-Ursprung liefert.