Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Konfigurieren von Amazon Route 53 als DNS-Service
Sie können Route 53 als DNS-Service für Ihre Domäne verwenden, z. B. "example.com". Wenn Route 53 Ihr DNS-Service ist, leitet dieser Internetdatenverkehr an Ihre Website weiter, indem er benutzerfreundliche Domänennamen wie www.beispiel.de in numerische IP-Adressen wie 192.0.2.1 übersetzt, die zur Verbindung zwischen Computern verwendet werden. Wenn ein Benutzer Ihren Domänennamen in einen Browser eingibt oder Ihnen eine E-Mail sendet, wird eine DNS-Abfrage an Route 53 weitergeleitet und daraufhin mit dem entsprechenden Wert beantwortet. Beispielsweise könnte Route 53 mit der IP-Adresse für den Web-Server für example.com antworten.
**DNS-Hosting im Vergleich zur Domainregistrierung**
In diesem Kapitel wird *nur die Verwendung von Route 53 für DNS-Hosting* behandelt. Das bedeutet, dass Ihre Domainregistrierung bei Ihrem derzeitigen Registrar verbleibt und Sie ihn weiterhin für Domainverlängerungen bezahlen müssen. Route 53 verwaltet nur Ihre DNS-Einstellungen und bearbeitet DNS-Abfragen für Ihre Domain.
Wenn Sie Ihre Domainregistrierung auch auf Route 53 übertragen möchten (sodass Route 53 sowohl Ihr Registrar als auch Ihr DNS-Dienst ist), finden Sie weitere Informationen unter [Checkliste vor der Übertragung für Domainübertragungen](domain-transfer-checklist.md) und[Übertragen der Registrierung für eine Domain an Amazon Route 53](domain-transfer-to-route-53.md).
In diesem Abschnitt wird erläutert, wie Sie Route 53 so konfigurieren, dass Ihr Internetdatenverkehr korrekt weitergeleitet wird. Außerdem wird erläutert, wie Sie einen DNS-Service zu Route 53 migrieren, wenn Sie aktuell einen anderen DNS-Service nutzen, und wie Sie Route 53 als DNS-Service für eine neue Domäne verwenden.
**Topics**
+ [Amazon Route 53 zum DNS-Dienst für eine vorhandene Domäne machen](MigratingDNS.md)
+ [Konfigurieren von DNS-Routing für eine neue Domäne](dns-configuring-new-domain.md)
+ [Weiterleiten des Datenverkehrs an Ihre Ressourcen](dns-routing-traffic-to-resources.md)
+ [Arbeiten mit gehosteten Zonen](hosted-zones-working-with.md)
+ [Arbeiten mit Datensätzen](rrsets-working-with.md)
+ [Konfigurieren der DNSSEC-Signatur in Amazon Route 53](dns-configuring-dnssec.md)
+ [Wird AWS Cloud Map zum Erstellen von Datensätzen und Zustandsprüfungen verwendet](autonaming.md)
+ [DNS-Einschränkungen und Verhaltensweisen](DNSBehavior.md)
+ [Verwandte Themen](dns-configuring-related-topics.md)
# Amazon Route 53 zum DNS-Dienst für eine vorhandene Domäne machen
Wenn Sie eine oder mehrere Domänenregistrierungen zu Route 53 übertragen und Sie derzeit eine Domänenvergabestelle verwenden, die keinen kostenpflichtigen DNS-Dienst anbietet, müssen Sie vor dem Migrieren der Domäne zuerst den DNS-Dienst migrieren. Andernfalls bietet die Vergabestelle keinen DNS-Dienst mehr an, wenn Sie Ihre Domänen übertragen, und die verknüpften Websites und Webanwendungen sind im Internet nicht mehr verfügbar. (Sie können auch den DNS-Dienst von der aktuellen Vergabestelle zu einem anderen DNS-Dienstanbieter migrieren. Es ist nicht erforderlich, dass Sie Route 53 als DNS-Dienstanbieter für Domänen verwenden, die bei Route 53 registriert sind.)
Der Prozess hängt davon ab, ob Sie die Domäne derzeit nutzen:
+ Wenn die Domäne derzeit Datenverkehr erhält, zum Beispiel, wenn Ihre Benutzer den Domänennamen verwenden, um eine Website zu suchen oder auf eine Webanwendung zuzugreifen, finden Sie weitere Informationen unter [Route 53 als DNS-Dienst für eine Domäne nutzen, die in Gebrauch ist](migrate-dns-domain-in-use.md).
+ Wenn die Domäne keinen (oder nur sehr wenig) Datenverkehr erhält, finden Sie weitere Informationen unter [Route 53 als DNS-Dienst für eine inaktive Domäne nutzen](migrate-dns-domain-inactive.md).
Bei beiden Optionen bleibt Ihre Domäne während des gesamten Migrationsprozesses verfügbar. In dem unwahrscheinlichen Fall, dass Probleme auftreten, können Sie die Migration mit der ersten Option schnell zurücksetzen. Mit der zweiten Option ist Ihre Domäne möglicherweise einige Tage nicht verfügbar.
Wenn Sie sich mit einem Experten unter in Verbindung setzen möchten AWS, besuchen Sie den [Vertriebssupport](https://aws.amazon.com/contact-us/sales-support/?pg=ln&sec=hs).
# Route 53 als DNS-Dienst für eine Domäne nutzen, die in Gebrauch ist
Wenn Sie den DNS-Dienst zu Amazon Route 53 für eine Domäne migrieren möchten, die derzeit Datenverkehr erhält, z. B. wenn Ihre Benutzer den Domänennamen verwenden, um eine Website zu finden oder auf eine Webanwendung zuzugreifen, führen Sie die Schritte in diesem Abschnitt aus.
**Topics**
+ [Schritt 1: Abrufen Ihrer aktuellen DNS-Konfiguration vom aktuellen DNS-Dienstanbieter (optional, jedoch empfohlen)](#migrate-dns-get-zone-file)
+ [Schritt 2: Erstellen einer gehosteten Zone](#migrate-dns-create-hosted-zone)
+ [Schritt 3: Erstellen von Datensätzen](#migrate-dns-create-records)
+ [Schritt 4: Senken der TTL-Einstellungen](#migrate-dns-lower-ttl)
+ [Schritt 5: (Wenn Sie DNSSEC konfiguriert haben) Entfernen Sie den DS-Eintrag aus der übergeordneten Zone](#migrate-remove-ds)
+ [Schritt 6: Warten, bis die alte TTL abgelaufen ist](#migrate-dns-wait-for-ttl)
+ [Schritt 7: Aktualisieren Sie die NS-Einträge, um Route 53-Nameserver zu verwenden](#migrate-dns-change-name-servers-with-provider)
+ [Schritt 8: Überwachen des Datenverkehrs für die Domäne](#migrate-dns-monitor-traffic)
+ [Schritt 9: Zurückändern der TTL für den NS-Datensatz in einen höheren Wert](#migrate-dns-change-ttl-back)
+ [Schritt 10: Übertragen der Domänenregistrierung an Amazon Route 53](#migrate-dns-transfer-domain-registration)
+ [Schritt 11: DNSSEC-Signatur erneut aktivieren (falls erforderlich)](#migrate-dns-re-enable-dnssec)
## Schritt 1: Abrufen Ihrer aktuellen DNS-Konfiguration vom aktuellen DNS-Dienstanbieter (optional, jedoch empfohlen)
Wenn Sie einen DNS-Dienst von einem anderen Anbieter zu Route 53 migrieren, reproduzieren Sie Ihre aktuelle DNS-Konfiguration in Route 53. Erstellen Sie in Route 53 erst eine gehostete Zone mit demselben Namen wie Ihre Domäne und dann Datensätze in dieser gehosteten Zone. Jeder Datensatz gibt an, wie der Datenverkehr für einen bestimmten Domänen- oder Subdomänennamen weitergeleitet werden soll. Wenn beispielsweise jemand Ihren Domainnamen in einen Webbrowser eingibt, möchten Sie, dass der Datenverkehr an einen Webserver in Ihrem Rechenzentrum, an eine Amazon EC2 EC2-Instance, an eine CloudFront Distribution oder an einen anderen Ort weitergeleitet wird?
Der Prozess, den Sie verwenden, hängt von der Komplexität Ihrer aktuellen DNS-Konfiguration ab:
+ **Wenn Ihre aktuelle DNS-Konfiguration einfach ist** - Wenn Sie den Internetdatenverkehr nur für einige Subdomänen an eine geringe Anzahl von Ressourcen, wie Webserver oder Amazon-S3-Buckets, weiterleiten, können Sie einige Datensätze in der Route 53-Konsole manuell erstellen.
+ **Wenn Ihre aktuelle DNS-Konfiguration eher komplex ist und Sie Ihre aktuelle Konfiguration lediglich reproduzieren möchten** - Sie können die Migration vereinfachen, wenn Sie eine Zonendatei vom aktuellen DNS-Dienstanbieter abrufen können, und die Zonendatei in Route 53 importieren. (Nicht alle DNS-Dienstanbieter stellen Zonendateien zur Verfügung.) Beim Importieren einer Zonendatei reproduziert Route 53 die vorhandene Konfiguration automatisch, indem die entsprechenden Datensätze in Ihrer gehosteten Zone erstellt werden.
Fragen Sie beim Kundenservice Ihres aktuellen DNS-Dienstanbieters nach, wie Sie eine *Zonendatei* oder eine *Datensatzliste* erhalten. Informationen über das erforderliche Format der Zonendatei finden Sie unter [Erstellen von Datensätzen durch Importieren einer Zonendatei](resource-record-sets-creating-import.md).
+ **Wenn Ihre aktuelle DNS-Konfiguration eher komplex ist und Sie an Route 53-Routing-Funktionen interessiert sind** - Sehen Sie sich die folgende Dokumentation an, um festzustellen, ob Sie Route 53-Funktionen verwenden möchten, die von anderen DNS-Dienstanbietern nicht zur Verfügung gestellt werden. Wenn dies der Fall ist, können Sie entweder Datensätze manuell erstellen oder eine Zonendatei importieren und Datensätze zu einem späteren Zeitpunkt erstellen oder aktualisieren:
+ [Wählen zwischen Alias- und Nicht-Alias-Datensätzen](resource-record-sets-choosing-alias-non-alias.md)erklärt die Vorteile von Route 53-Aliasdatensätzen, die den Datenverkehr kostenlos an einige AWS Ressourcen wie CloudFront Distributionen und Amazon S3 S3-Buckets weiterleiten.
+ [Auswählen einer Routing-Richtlinie](routing-policy.md) erläutert die Route 53-Routing-Optionen, z. B. Routing basierend auf dem Standort Ihrer Benutzer, Routing auf Basis der Latenz zwischen Ihren Benutzern und Ressourcen, Routing basierend darauf, ob Ihre Ressourcen fehlerfrei sind, und Routing an Ressourcen basierend auf den von Ihnen angegebenen Gewichtungen.
**Anmerkung**
Sie können eine Zonendatei auch importieren und die Konfiguration zu einem späteren Zeitpunkt ändern, um Aliasdatensätze und komplexe Routing-Richtlinien zu nutzen.
Wenn Sie keine Zonendatei abrufen können oder Datensätze in Route 53 manuell erstellen möchten, müssen Sie wahrscheinlich u. a. folgende Datensätze migrieren:
+ **A (Address) -Datensätze** — verknüpfen einen Domainnamen oder Subdomainnamen mit der IPv4 Adresse (z. B. 192.0.2.3) der entsprechenden Ressource
+ **AAAA-Einträge (Address)** — verknüpfen einen Domainnamen oder Subdomainnamen mit der IPv6 Adresse (z. B. 2001:0 db 8:85 a 3:0000:0000:abcd: 0001:2345) der entsprechenden Ressource
+ **MX-Datensätze (Mail Server)** - Datenverkehr an Mail-Server weiterleiten
+ **CNAME-Datensätze** - Den Datenverkehr für einen Domänennamen (example.net) an einen anderen Domänennamen (example.com) weiterleiten
+ **Datensätze für andere unterstützte DNS-Datensatztypen** - Eine Liste der unterstützen Datensatztypen finden Sie unter [Unterstützte DNS-Datensatztypen](ResourceRecordTypes.md).
## Schritt 2: Erstellen einer gehosteten Zone
Um Amazon Route 53 mitzuteilen, wie Sie den Datenverkehr für Ihre Domäne weiterleiten möchten, erstellen Sie zuerst eine gehostete Zone mit demselben Namen wie Ihre Domäne und dann die Datensätze in der gehosteten Zone.
**Wichtig**
Sie können eine gehostete Zone nur für eine Domäne erstellen, die Sie über die Berechtigung zur Verwaltung verfügen. Das heißt in der Regel, dass Sie Eigentümer der Domäne sind. Es könnte aber auch bedeuten, dass Sie eine Anwendung für den Eigentümer entwickeln.
Bei der Erstellung einer gehosteten Zone erstellt Route 53 automatisch einen NS-Eintrag (Namenserver) und einen SOA-Eintrag (Start of Authority, Autoritätsursprung) für die Zone. Der NS-Datensatz identifiziert die vier Namenserver, die Route 53 Ihrer gehosteten Zone zugeordnet hat. Um Route 53 als DNS-Dienst für Ihre Domäne festzulegen, aktualisieren Sie die Registrierung für die Domäne mit diesen vier Namenservern.
**Wichtig**
Erstellen Sie keine zusätzlichen NS- (Namenserver) oder SOA-Datensätze (Autoritätsursprung) und löschen Sie die vorhandenen NS- und SOA-Datensätze nicht.
**So erstellen Sie eine gehostete Zone**
1. Melden Sie sich bei [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)der an und öffnen AWS-Managementkonsole Sie die Route 53-Konsole unter.
1. Wenn Sie neu bei Route 53 sind, wählen Sie**Melden Sie sich in der &console; an und öffnen Sie die Seite &ConsolePageURL;.**UNDER**DNS-Verwaltung**Wählen Sie und anschließend aus**Gehostete Zonen erstellen**aus.
Wenn Sie bereits Route 53 nutzen, wählen Sie**Gehostete Zonen**Wählen Sie im Navigationsbereich und dann**Gehostete Zonen erstellen**aus.
1. Geben Sie im Bereich **Create Hosted Zone** einen Domänennamen und optional einen Kommentar ein. Weitere Informationen zu einer Einstellung erhalten Sie, indem Sie das Hilfefenster auf der rechten Seite öffnen.
Erläuterungen dazu, wie Sie andere Zeichen als a-z, 0-9 und - (Bindestrich) eingeben und wie internationale Domainnamen angegeben werden, erhalten Sie unter [Format für DNS-Domänennamen](DomainNameFormat.md).
1. Übernehmen Sie für **Type** den Standardwert **Public Hosted Zone**.
1. Wählen Sie **Create Hosted Zone**.
## Schritt 3: Erstellen von Datensätzen
Nachdem Sie eine gehostete Zone angelegt haben, erstellen Sie Datensätze in der gehosteten Zone, die definieren, wie Sie den Datenverkehr für eine Domäne (example.com) oder Subdomäne (www.example.com) weiterleiten möchten. Wenn Sie beispielsweise den Datenverkehr für example.com und www.example.com an einen Webserver auf einer Amazon EC2 Instance weiterleiten möchten, erstellen Sie zwei Datensätze, und zwar einen mit dem Namen example.com und den anderen mit dem Namen www.example.com. In jedem Datensatz geben Sie die IP-Adresse für Ihre EC2-Instance an.
Für das Erstellen von Datensätzen gibt es verschiedene Möglichkeiten:
**Importieren einer Zonendatei**
Dies ist die einfachste Methode, wenn Sie eine Zonendatei von Ihrem aktuellen DNS-Dienst in erhalten haben [Schritt 1: Abrufen Ihrer aktuellen DNS-Konfiguration vom aktuellen DNS-Dienstanbieter (optional, jedoch empfohlen)](#migrate-dns-get-zone-file). Amazon Route 53 kann nicht vorhersagen, wann Aliasdatensätze erstellt oder spezielle Routing-Typen wie gewichtete oder Failover-Datensätze verwendet werden sollen. Daher erstellt Route 53 DNS-Standarddatensätze mithilfe der einfachen Routing-Richtlinie, wenn Sie eine Zonendatei importieren.
Weitere Informationen finden Sie unter [Erstellen von Datensätzen durch Importieren einer Zonendatei](resource-record-sets-creating-import.md).
**Erstellen von einzelnen DNS-Datensätzen in der Konsole**
Wenn Sie keine Zonendatei erhalten haben und nur einige Datensätze mit der einfachen Routing-Richtlinie für die ersten Schritte erstellen möchten, können Sie die Datensätze in der Route 53 -Konsole erstellen. Sie können sowohl Alias- als auch Nicht-Alias-Datensätze erstellen.
Weitere Informationen finden Sie unter den folgenden Themen:
+ [Auswählen einer Routing-Richtlinie](routing-policy.md)
+ [Wählen zwischen Alias- und Nicht-Alias-Datensätzen](resource-record-sets-choosing-alias-non-alias.md)
+ [Erstellen von Datensätzen mithilfe der Amazon-Route-53-Konsole](resource-record-sets-creating.md)
**Programmgesteuertes Erstellen von Datensätzen**
Sie können Datensätze erstellen, indem Sie einen der AWS SDKs Befehle AWS CLI, oder verwenden AWS Tools for Windows PowerShell. Weitere Informationen finden Sie in der [AWS Dokumentation](https://docs.aws.amazon.com/).
Wenn Sie eine Programmiersprache verwenden, für die AWS kein SDK bereitgestellt wird, können Sie auch die Route 53-API verwenden. Weitere Informationen finden Sie unter [Amazon Route 53 API Reference](https://docs.aws.amazon.com/Route53/latest/APIReference/).
## Schritt 4: Senken der TTL-Einstellungen
Die TTL-Einstellung (Time-to-live, Gültigkeitsdauer) für einen Datensatz gibt an, wie lange DNS-Resolver den Datensatz zwischenspeichern und die zwischengespeicherten Informationen verwenden sollen. Wenn die TTL abgelaufen ist, sendet ein Resolver eine weitere Abfrage an den DNS-Dienstanbieter für eine Domäne, um die neuesten Informationen zu erhalten.
Die typische TTL-Einstellung für den NS Datensatz ist 172 800 Sekunden oder 2 Tage. Der NS-Datensatz listet die Namenserver auf, die das Domain Name System (DNS) verwenden kann, um Informationen zum Weiterleiten des Datenverkehrs für Ihre Domäne abzurufen. Durch Senken der TTL für den NS-Datensatz sowohl für Ihren aktuellen DNS-Dienstanbieter als auch Amazon Route 53 werden die Ausfallzeiten für Ihre Domäne reduziert, wenn Sie beim Migrieren von DNS zu Route 53 ein Problem feststellen. Wenn Sie die TTL nicht senken, ist Ihre Domäne bis zu zwei Tage im Internet nicht verfügbar, wenn ein Fehler auftritt.
**Anmerkung**
Einige Vollresolver können die TTL des NS-Datensatzes des übergeordneten autoritativen Servers zwischenspeichern. Daher muss auch die TTL der auf dem übergeordneten autoritativen DNS-Server registrierten NS-Datensätze reduziert werden.
Wir empfehlen, die TTL in den folgenden NS-Datensätzen zu ändern:
+ Im NS-Datensatz in der gehosteten Zone für den aktuellen DNS-Dienstanbieter. (Ihr aktueller Anbieter verwendet möglicherweise eine andere Terminologie.)
+ Im NS-Datensatz in der gehostete Zone, die Sie in [Schritt 2: Erstellen einer gehosteten Zone](#migrate-dns-create-hosted-zone) erstellt haben.
**So senken Sie die TTL-Einstellung im NS-Datensatz für den aktuellen DNS-Dienstanbieter**
+ Verwenden Sie die Methode, die vom aktuellen DNS-Serviceanbieter für die Domäne zur Verfügung gestellt wird, um die TTL für den NS-Datensatz in der gehosteten Zone für Ihre Domäne zu ändern.
**So senken Sie die TTL-Einstellung im NS-Datensatz in einer gehosteten Route 53-Zone**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Klicken Sie im Navigationsbereich auf **Hosted Zones (Gehostete Zonen)**.
1. Wählen Sie den Namen der gehosteten Zone aus.
1. Wählen Sie den NS-Datensatz und anschließend aus**Bearbeiten**aus.
1. Ändern Sie den Wert **TTL (Seconds)**. Wir empfehlen, einen Wert zwischen 60 Sekunden und 900 Sekunden (15 Minuten) anzugeben.
1. Wählen Sie **Save Changes (Änderungen speichern)**.
## Schritt 5: (Wenn Sie DNSSEC konfiguriert haben) Entfernen Sie den DS-Eintrag aus der übergeordneten Zone
Wenn Sie DNSSEC für Ihre Domäne konfiguriert haben, entfernen Sie den Eintrag Delegation Signer (DS) aus der übergeordneten Zone, bevor Sie Ihre Domäne zu Route 53 migrieren.
Wenn die übergeordnete Zone über Route 53 oder eine andere Vergabestelle gehostet wird, kontaktieren Sie sie, um den DS-Datensatz zu entfernen.
Da es derzeit nicht möglich ist, die DNSSEC-Signatur bei zwei Anbietern zu aktivieren, müssen Sie alle DS entfernen oder DNSKEYs DNSSEC deaktivieren. Dies signalisiert DNS-Resolvern vorübergehend, die DNSSEC-Validierung zu deaktivieren. In [Schritt 11](#migrate-dns-re-enable-dnssec)können Sie die DNSSEC-Validierung bei Bedarf wieder aktivieren, nachdem der Übergang zu Route 53 abgeschlossen ist.
Weitere Informationen finden Sie unter [Löschen von öffentlichen Schlüsseln für eine Domäne](domain-configure-dnssec.md#domain-configure-dnssec-deleting-keys).
## Schritt 6: Warten, bis die alte TTL abgelaufen ist
Wenn Ihre Domäne verwendet wird (z. B. wenn Ihre Benutzer den Domänennamen verwenden, um eine Website zu suchen oder auf eine Webanwendung zuzugreifen), dann wurden die Namen der Namenserver, die von Ihrem aktuellen DNS-Serviceanbieter zur Verfügung gestellt wurden, von DNS-Resolvern zwischengespeichert. Ein DNS-Resolver, der diese Informationen einige Minuten zuvor zwischengespeichert hat, hält sie fast zwei weitere Tage gespeichert.
Um sicherzustellen, dass die Migration des DNS-Service zu Route 53 zum gleichen Zeitpunkt erfolgt, warten Sie zwei Tage, nachdem Sie die TTL gesenkt haben. Nachdem die zweitägige TTL abgelaufen ist und die Resolver den Namenserver für Ihre Domäne anfordern, rufen die Resolver die aktuellen Namenserver sowie die neue TTL ab, die Sie in [Schritt 4: Senken der TTL-Einstellungen](#migrate-dns-lower-ttl) angegeben haben.
## Schritt 7: Aktualisieren Sie die NS-Einträge, um Route 53-Nameserver zu verwenden
Um Amazon Route 53 als DNS-Dienst für eine Domäne zu verwenden, nutzen Sie die vom aktuellen DNS-Dienstanbieter bereitgestellte Methode, um die aktuellen Namenserver im NS-Datensatz durch Route 53-Namenserver zu ersetzen.
**Anmerkung**
Wenn Sie den NS-Eintrag mit dem aktuellen DNS-Dienstanbieter aktualisieren, um Route 53 -Namensserver zu verwenden, aktualisieren Sie die DNS-Konfiguration für die Domäne. (Dies ist vergleichbar mit dem Aktualisieren des NS-Datensatzes in der gehosteten Route 53-Zone für eine Domäne, mit der Ausnahme, dass Sie die Einstellung mit dem DNS-Service aktualisieren, von dem Sie weggehen.)
**So aktualisieren Sie den NS-Eintrag im Registrar oder in der übergeordneten Zone, um Route 53-Namenserver zu verwenden**
1. Rufen Sie in der Route 53-Konsole die Namenserver für Ihre gehostete Zone ab:
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. Klicken Sie im Navigationsbereich auf **Hosted Zones (Gehostete Zonen)**.
1. Wählen Sie auf der Seite **Hosted zones (Gehostete Zonen)** das Optionsfeld (nicht den Namen) für die gültige gehostete Zone aus.
1. Notieren Sie sich die vier Namen, die für **Namensserver** im Abschnitt **Hosted zone details (Details der gehosteten Zone)** erstellt.
1. Verwenden Sie die Methode, die vom aktuellen DNS-Dienst für die Domäne zur Verfügung gestellt wird, um die NS-Datensätze für die gehostete Zone zu aktualisieren. Wenn die Domäne bei Route 53 registriert wurde, lesen Sie [Hinzufügen oder Ändern der Nameserver und Glue-Datensätze in einer Domäne](domain-name-servers-glue-records.md).Der Prozess hängt davon ab, ob Sie mit dem aktuellen DNS-Dienst Nameserver löschen können:
**Wenn Sie Namenserver löschen können**
+ Notieren Sie die Namen der aktuellen Nameserver im NS-Datensatz für die gehostete Zone. Geben Sie diese Server an, wenn Sie das System auf die aktuelle DNS-Konfiguration zurücksetzen müssen.
+ Löschen Sie die aktuellen Nameserver aus dem NS-Datensatz.
+ Aktualisieren Sie den NS-Datensatz mit den Namen aller vier Route 53-Nameserver, die Sie in Schritt 1 dieses Verfahrens erhalten haben.
**Anmerkung**
Anschließend sind nur noch die vier Route 53 -Nameserver im NS-Datensatz enthalten.
**Wenn Sie Namenserver nicht löschen können**
+ Wählen Sie die Option zum Verwenden benutzerdefinierter Nameserver aus.
+ Fügen Sie alle vier Route 53-Nameserver hinzu, die Sie in Schritt 1 erhalten haben.
## Schritt 8: Überwachen des Datenverkehrs für die Domäne
Überwachen Sie den Datenverkehr für die Domäne, einschließlich des Datenverkehrs für die Website oder Anwendung, und E-Mail:
+ **Wenn der Datenverkehr langsamer wird oder abbricht** - Verwenden Sie die Methode des vorherigen DNS-Dienst, um die Namenserver für die Domäne wieder in die vorherigen Namenserver zu ändern. Hierbei handelt es sich um die Namenserver, die Sie unter in Schritt 7 von [So aktualisieren Sie den NS-Eintrag im Registrar oder in der übergeordneten Zone, um Route 53-Namenserver zu verwenden](#migrate-dns-change-name-servers-with-provider-procedure) notiert haben. Ergründen Sie anschließend, was schiefgelaufen ist.
+ **Wenn der Datenverkehr nicht betroffen ist** - Fahren Sie mit [Schritt 9: Zurückändern der TTL für den NS-Datensatz in einen höheren Wert](#migrate-dns-change-ttl-back) fort.
## Schritt 9: Zurückändern der TTL für den NS-Datensatz in einen höheren Wert
Ändern Sie die TTL für den NS-Datensatz in der gehosteten Amazon Route 53-Zone für die Domäne in einen typischen Wert, z. B. 172800 Sekunden (2 Tage). Dadurch wird die Latenz für Ihre Benutzer verbessert, da sie nicht so oft darauf warten müssen, dass DNS-Resolver eine Abfrage für die Namenserver Ihrer Domäne senden.
**So ändern Sie die TTL für den NS-Datensatz in der gehosteten Route 53-Zone**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Klicken Sie im Navigationsbereich auf **Hosted Zones (Gehostete Zonen)**.
1. Wählen Sie den Namen der gehosteten Zone aus.
1. Wählen Sie in der Liste der Datensätze für die gehostete Zone den NS-Datensatz aus.
1. Wählen Sie **Edit (Bearbeiten)** aus.
1. Ändern Sie den Wert **TTL (Seconds)** in die Anzahl von Sekunden, die DNS-Resolver die Namen der Namenserver für Ihre Domäne zwischenspeichern sollen. Wir empfehlen einen Wert von 172 800 Sekunden.
1. Wählen Sie **Save Changes (Änderungen speichern)**.
## Schritt 10: Übertragen der Domänenregistrierung an Amazon Route 53
Nachdem Sie den DNS-Dienst für eine Domäne an Amazon Route 53 übertragen haben, können Sie die Registrierung für die Domäne optional an Route 53 übertragen. Weitere Informationen finden Sie unter [Übertragen der Registrierung für eine Domain an Amazon Route 53](domain-transfer-to-route-53.md).
## Schritt 11: DNSSEC-Signatur erneut aktivieren (falls erforderlich)
Nachdem Sie den DNS-Dienst für eine Domäne an Amazon Route 53 übertragen haben, können Sie die DNSSEC-Signatur erneut aktivieren.
Das Aktivieren der DNSSEC-Signatur erfolgt in zwei Schritten:
+ Schritt 1: Aktivieren Sie die DNSSEC-Signatur für Route 53 und fordern Sie Route 53 auf, einen Key Signing Key (KSK) auf der Grundlage eines vom Kunden verwalteten Schlüssels in AWS Key Management Service () zu erstellen.AWS KMS
+ Schritt 2: Erstellen Sie eine Vertrauenskette für die gehostete Zone, indem Sie einen Delegation Signer (DS)-Datensatz zur übergeordneten Zone hinzufügen, damit DNS-Antworten mit vertrauenswürdigen kryptografischen Signaturen authentifiziert werden können.
Detaillierte Anweisungen finden Sie unter [Aktivieren der DNSSEC-Signierung und Aufbau einer Vertrauenskette](dns-configuring-dnssec-enable-signing.md).
# Route 53 als DNS-Dienst für eine inaktive Domäne nutzen
Wenn Sie den DNS-Dienst zu Amazon Route 53 für eine Domäne migrieren möchten, die keinen (oder nur sehr wenig Datenverkehr) erhält, führen Sie die Schritte in diesem Abschnitt aus.
**Topics**
+ [Schritt 1: Abrufen Ihrer aktuellen DNS-Konfiguration vom aktuellen DNS-Dienstanbieter (inaktive Domänen)](#migrate-dns-get-zone-file-domain-inactive)
+ [Schritt 2: Erstellen einer gehosteten Zone (inaktive Domänen)](#migrate-dns-create-hosted-zone-domain-inactive)
+ [Schritt 3: Erstellen von Datensätzen (inaktive Domänen)](#migrate-dns-create-records-domain-inactive)
+ [Schritt 4: Aktualisieren der Domänenregistrierung zur Verwendung von Amazon-Route-53-Nameservern (inaktive Domänen)](#migrate-dns-update-domain-inactive)
## Schritt 1: Abrufen Ihrer aktuellen DNS-Konfiguration vom aktuellen DNS-Dienstanbieter (inaktive Domänen)
Wenn Sie einen DNS-Service von einem anderen Anbieter zu Route 53 migrieren, reproduzieren Sie Ihre aktuelle DNS-Konfiguration in Route 53. Erstellen Sie in Route 53 erst eine gehostete Zone mit demselben Namen wie Ihre Domäne und dann Datensätze in dieser gehosteten Zone. Jeder Datensatz gibt an, wie der Datenverkehr für einen bestimmten Domänen- oder Subdomänennamen weitergeleitet werden soll. Wenn beispielsweise jemand Ihren Domainnamen in einen Webbrowser eingibt, möchten Sie, dass der Datenverkehr an einen Webserver in Ihrem Rechenzentrum, an eine Amazon EC2 EC2-Instance, an eine CloudFront Distribution oder an einen anderen Ort weitergeleitet wird?
Der Prozess, den Sie verwenden, hängt von der Komplexität Ihrer aktuellen DNS-Konfiguration ab:
+ **Wenn Ihre aktuelle DNS-Konfiguration einfach ist** - Wenn Sie den Internetdatenverkehr nur für einige Subdomänen an eine geringe Anzahl von Ressourcen, wie Webserver oder Amazon-S3-Buckets, weiterleiten, können Sie einige Datensätze in der Route 53-Konsole manuell erstellen.
+ **Wenn Ihre aktuelle DNS-Konfiguration eher komplex ist und Sie Ihre aktuelle Konfiguration lediglich reproduzieren möchten** - Sie können die Migration vereinfachen, wenn Sie eine Zonendatei vom aktuellen DNS-Dienstanbieter abrufen können, und die Zonendatei in Route 53 importieren. (Nicht alle DNS-Dienstanbieter stellen Zonendateien zur Verfügung.) Beim Importieren einer Zonendatei reproduziert Route 53 die vorhandene Konfiguration automatisch, indem die entsprechenden Datensätze in Ihrer gehosteten Zone erstellt werden.
Fragen Sie beim Kundenservice Ihres aktuellen DNS-Dienstanbieters nach, wie Sie eine *Zonendatei* oder eine *Datensatzliste* erhalten. Informationen über das erforderliche Format der Zonendatei finden Sie unter [Erstellen von Datensätzen durch Importieren einer Zonendatei](resource-record-sets-creating-import.md).
+ **Wenn Ihre aktuelle DNS-Konfiguration eher komplex ist und Sie an Route 53-Routing-Funktionen interessiert sind** - Sehen Sie sich die folgende Dokumentation an, um festzustellen, ob Sie Route 53-Funktionen verwenden möchten, die von anderen DNS-Dienstanbietern nicht zur Verfügung gestellt werden. Wenn dies der Fall ist, können Sie entweder Datensätze manuell erstellen oder eine Zonendatei importieren und Datensätze zu einem späteren Zeitpunkt erstellen oder aktualisieren:
+ [Wählen zwischen Alias- und Nicht-Alias-Datensätzen](resource-record-sets-choosing-alias-non-alias.md)erklärt die Vorteile von Route 53-Aliasdatensätzen, die den Datenverkehr kostenlos an einige AWS Ressourcen wie CloudFront Distributionen und Amazon S3 S3-Buckets weiterleiten.
+ [Auswählen einer Routing-Richtlinie](routing-policy.md) erläutert die Route 53-Routing-Optionen, z. B. Routing basierend auf dem Standort Ihrer Benutzer, Routing auf Basis der Latenz zwischen Ihren Benutzern und Ressourcen, Routing basierend darauf, ob Ihre Ressourcen fehlerfrei sind, und Routing an Ressourcen basierend auf den von Ihnen angegebenen Gewichtungen.
**Anmerkung**
Sie können eine Zonendatei auch importieren und die Konfiguration zu einem späteren Zeitpunkt ändern, um Aliasdatensätze und komplexe Routing-Richtlinien zu nutzen.
Wenn Sie keine Zonendatei abrufen können oder Datensätze in Route 53 manuell erstellen möchten, müssen Sie wahrscheinlich u. a. folgende Datensätze migrieren:
+ **A (Address) -Datensätze** — verknüpfen einen Domainnamen oder Subdomainnamen mit der IPv4 Adresse (z. B. 192.0.2.3) der entsprechenden Ressource
+ **AAAA-Einträge (Address)** — verknüpfen einen Domainnamen oder Subdomainnamen mit der IPv6 Adresse (z. B. 2001:0 db 8:85 a 3:0000:0000:abcd: 0001:2345) der entsprechenden Ressource
+ **MX-Datensätze (Mail Server)** - Datenverkehr an Mail-Server weiterleiten
+ **CNAME-Datensätze** - Den Datenverkehr für einen Domänennamen (example.net) an einen anderen Domänennamen (example.com) weiterleiten
+ **Datensätze für andere unterstützte DNS-Datensatztypen** - Eine Liste der unterstützen Datensatztypen finden Sie unter [Unterstützte DNS-Datensatztypen](ResourceRecordTypes.md).
## Schritt 2: Erstellen einer gehosteten Zone (inaktive Domänen)
Um Amazon Route 53 mitzuteilen, wie Sie den Datenverkehr für Ihre Domäne weiterleiten möchten, erstellen Sie zuerst eine gehostete Zone mit demselben Namen wie Ihre Domäne und dann die Datensätze in der gehosteten Zone.
**Wichtig**
Sie können eine gehostete Zone nur für eine Domäne erstellen, die Sie über die Berechtigung zur Verwaltung verfügen. Das heißt in der Regel, dass Sie Eigentümer der Domäne sind. Es könnte aber auch bedeuten, dass Sie eine Anwendung für den Eigentümer entwickeln.
Bei der Erstellung einer gehosteten Zone erstellt Route 53 automatisch einen NS-Eintrag (Namenserver) und einen SOA-Eintrag (Start of Authority, Autoritätsursprung) für die Zone. Der NS-Datensatz identifiziert die vier Namenserver, die Route 53 Ihrer gehosteten Zone zugeordnet hat. Um Route 53 als DNS-Dienst für Ihre Domäne festzulegen, aktualisieren Sie die Registrierung für die Domäne mit diesen vier Namenservern.
**Wichtig**
Erstellen Sie keine zusätzlichen NS- (Namenserver) oder SOA-Datensätze (Autoritätsursprung) und löschen Sie die vorhandenen NS- und SOA-Datensätze nicht.
**So erstellen Sie eine gehostete Zone**
1. Melden Sie sich bei [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)der an und öffnen AWS-Managementkonsole Sie die Route 53-Konsole unter.
1. Wenn Sie noch keine Erfahrung mit Route 53 haben, wählen Sie **Get Started (Erste Schritte)** aus.
Wenn Sie Route 53 bereits nutzen, wählen Sie **Hosted zones** im Navigationsbereich aus.
1. Wählen Sie **Create Hosted Zone (Gehostete Zone erstellen)**.
1. Geben Sie im Bereich **Create Hosted Zone (Gehostete Zone erstellen)** einen Domänennamen und optional einen Kommentar ein. Weitere Informationen über Einstellungen erhalten Sie in Quickinfos, wenn Sie mit dem Mauszeiger auf die jeweilige Beschriftung zeigen.
Erläuterungen dazu, wie Sie andere Zeichen als a-z, 0-9 und - (Bindestrich) eingeben und wie internationale Domainnamen angegeben werden, erhalten Sie unter [Format für DNS-Domänennamen](DomainNameFormat.md).
1. Übernehmen Sie für **Type** den Standardwert **Public Hosted Zone**.
1. Wählen Sie **Create hosted zone (Gehostete Zone erstellen)** aus.
## Schritt 3: Erstellen von Datensätzen (inaktive Domänen)
Nachdem Sie eine gehostete Zone angelegt haben, erstellen Sie Datensätze in der gehosteten Zone, die definieren, wie Sie den Datenverkehr für eine Domäne (example.com) oder Subdomäne (www.example.com) weiterleiten möchten. Wenn Sie beispielsweise den Datenverkehr für example.com und www.example.com an einen Webserver auf einer Amazon EC2 Instance weiterleiten möchten, erstellen Sie zwei Datensätze, und zwar einen mit dem Namen example.com und den anderen mit dem Namen www.example.com. In jedem Datensatz geben Sie die IP-Adresse für Ihre EC2-Instance an.
Für das Erstellen von Datensätzen gibt es verschiedene Möglichkeiten:
**Importieren einer Zonendatei**
Dies ist die einfachste Methode, wenn Sie eine Zonendatei von Ihrem aktuellen DNS-Dienst in erhalten haben [Schritt 1: Abrufen Ihrer aktuellen DNS-Konfiguration vom aktuellen DNS-Dienstanbieter (inaktive Domänen)](#migrate-dns-get-zone-file-domain-inactive). Amazon Route 53 kann nicht vorhersagen, wann Aliasdatensätze erstellt oder spezielle Routing-Typen wie gewichtete oder Failover-Datensätze verwendet werden sollen. Daher erstellt Route 53 DNS-Standarddatensätze mithilfe der einfachen Routing-Richtlinie, wenn Sie eine Zonendatei importieren.
Weitere Informationen finden Sie unter [Erstellen von Datensätzen durch Importieren einer Zonendatei](resource-record-sets-creating-import.md).
**Erstellen von einzelnen DNS-Datensätzen in der Konsole**
Wenn Sie keine Zonendatei erhalten haben und nur einige Datensätze mit der einfachen Routing-Richtlinie für die ersten Schritte erstellen möchten, können Sie die Datensätze in der Route 53 -Konsole erstellen. Sie können sowohl Alias- als auch Nicht-Alias-Datensätze erstellen.
Weitere Informationen finden Sie unter den folgenden Themen:
+ [Auswählen einer Routing-Richtlinie](routing-policy.md)
+ [Wählen zwischen Alias- und Nicht-Alias-Datensätzen](resource-record-sets-choosing-alias-non-alias.md)
+ [Erstellen von Datensätzen mithilfe der Amazon-Route-53-Konsole](resource-record-sets-creating.md)
**Programmgesteuertes Erstellen von Datensätzen**
Sie können Datensätze erstellen, indem Sie einen der AWS SDKs Befehle AWS CLI, oder verwenden AWS Tools for Windows PowerShell. Weitere Informationen finden Sie in der [AWS Dokumentation](https://docs.aws.amazon.com/).
Wenn Sie eine Programmiersprache verwenden, für die AWS kein SDK bereitgestellt wird, können Sie auch die Route 53-API verwenden. Weitere Informationen finden Sie unter [Amazon Route 53 API Reference](https://docs.aws.amazon.com/Route53/latest/APIReference/).
## Schritt 4: Aktualisieren der Domänenregistrierung zur Verwendung von Amazon-Route-53-Nameservern (inaktive Domänen)
Nachdem Sie die Datensätze für die Domäne erstellt haben, können Sie den DNS-Service für Ihre Domäne in Amazon Route 53 ändern. Führen Sie die folgenden Schritte aus, um die Einstellungen bei der Domänenvergabestelle zu aktualisieren.
**So aktualisieren Sie die Namenserver für die Domäne**
1. Rufen Sie die Nameserver für eine öffentliche gehostete Zone mithilfe der Route 53-Konsole ab.
1. Öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Klicken Sie im Navigationsbereich auf **Hosted Zones (Gehostete Zonen)**.
1. Wählen Sie auf der Seite **Hosted Zones (Gehostete Zonen)** das Optionsfeld (nicht den Namen) für die gehostete Zone aus, und dann **View details (Details anzeigen)**.
1. Wählen Sie auf der Detailseite für die gehostete Zone **Hosted Zone details (Details der gehosteten Zone)** aus.
1. Notieren Sie sich die vier Namen, die für **Name Servers (Namenserver)** aufgelistet werden.
1. Ändern Sie unter Verwendung der von der Vergabestelle für die Domäne bereitgestellten Methode die Namenserver für die Domäne in die vier Route 53-Namenserver, die Sie in Schritt 2 dieses Verfahrens erhalten haben.
Wenn die Domäne mit Route 53 registriert wurde, lesen Sie [Hinzufügen oder Ändern der Nameserver und Glue-Datensätze in einer Domäne](domain-name-servers-glue-records.md).
# Konfigurieren von DNS-Routing für eine neue Domäne
**Eine neue Domain, die Sie bei Route 53 gekauft haben**
Wenn Sie eine Domäne bei Route 53 registrieren, machen wir Route 53 automatisch als DNS-Service für die Domäne. Route 53 erstellt eine gehostete Zone, die denselben Namen wie die Domäne hat, weist der gehosteten Zone vier Namenserver zu und aktualisiert die Domäne zur Verwendung dieser Nameserver.
**Eine neue Domain, die Sie bei einem anderen Registrar gekauft haben**
Wenn Sie beispielsweise eine Domain von einem anderen Registrar kaufen, weil die Top-Level-Domain (TLD) nicht von Route 53 angeboten wird, haben Sie zwei Möglichkeiten:
+ **Verwenden Sie Route 53 nur für DNS-Hosting:** Behalten Sie Ihren aktuellen Registrar, aber delegieren Sie die DNS-Verwaltung an Route 53. Gehen Sie wie folgt vor, um eine gehostete Zone zu erstellen und die Nameserver Ihres Registrars zu aktualisieren.
+ **Übertragen Sie die Domainregistrierung auf Route 53:** Machen Sie Route 53 zu Ihrem Registrar und DNS-Dienst. Informationen zu [Checkliste vor der Übertragung für Domainübertragungen](domain-transfer-checklist.md) den Voraussetzungen und [Übertragen der Registrierung für eine Domain an Amazon Route 53](domain-transfer-to-route-53.md) zum Übertragungsprozess finden Sie unter.
Weitere Informationen zur TLDs Unterstützung durch Route 53 finden Sie unter[Domains, die Sie mit Amazon Route 53 registrieren können](registrar-tld-list.md).
Folgen Sie diesen Anweisungen, um eine öffentlich gehostete Zone zu erstellen und dann die mit dem Registrar erstellten Nameserver zu verwenden:
**So erstellen Sie eine gehostete Zone für eine Domäne, die nicht zu Route 53 gehört**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Wählen Sie im Navigationsbereich **Gehostete Zonen** aus und wählen Sie dann **Gehostete Zone erstellen** aus.
1. Geben Sie als **Name** den Namen der Domain ein, für die Sie eine Hosting-Zone erstellen möchten, z. B. eine optionale Beschreibung`example.com`, wählen Sie **Public Hosted Zone** und dann **Create Hosted Zone** aus.
1. Nachdem Sie die Hosting-Zone erstellt haben, notieren Sie sich die vier Nameserver-Einträge (NS), die erstellt wurden. Jeder beginnt mit „ns-“.
Geben Sie bei Ihrem Domain-Registrar die Nameserver von oben ein, um die Domainverwaltung an Ihre von Route 53 gehostete Zone zu delegieren.
**DNS-Verkehr weiterleiten**
Um anzugeben, wie Route 53 den Datenverkehr für die Domäne weiterleiten soll, erstellen Sie Datensätze in der gehosteten Zone. Wenn Sie beispielsweise Anfragen für example.com an einen Webserver weiterleiten möchten, der auf einer EC2 Amazon-Instance läuft, erstellen Sie einen Datensatz in der gehosteten Zone example.com und geben die Elastic IP-Adresse für die EC2 Instance an. Weitere Informationen finden Sie unter den folgenden Themen:
+ Weitere Informationen zum Erstellen von Datensätzen in Ihrer gehosteten Zone finden Sie unter [Arbeiten mit Datensätzen](rrsets-working-with.md).
+ Informationen darüber, wie Sie Traffic zu ausgewählten AWS Ressourcen weiterleiten, finden Sie unter. [Weiterleitung des Internetverkehrs zu Ihren AWS Ressourcen](routing-to-aws-resources.md)
+ Weitere Information zur Funktionsweise von DNS finden Sie unter [Wie Internetdatenverkehr an Ihre Website oder die Webanwendung geleitet wird](welcome-dns-service.md).
+ Informationen zur Überprüfung der DNS-Speicherung finden Sie unter[Überprüfen der DNS-Antworten von Route 53](dns-test.md).
# Weiterleiten des Datenverkehrs an Ihre Ressourcen
Wenn Benutzer Ihre Website oder Webanwendung anfordern, indem sie beispielsweise den Namen Ihrer Domäne in einen Webbrowser eingeben, hilft Route 53 dabei, Benutzer zu Ihren Ressourcen wie einem Amazon-S3-Bucket oder einem Webserver in Ihrem Rechenzentrum zu leiten. Zum Konfigurieren von Route 53 zur Weiterleitung des Datenverkehrs an Ihre Ressourcen gehen Sie wie folgt vor:
1. Erstellen Sie eine gehostete Zone. Sie können eine öffentliche gehostete Zone oder eine private gehostete Zone erstellen:
**Öffentliche gehostete Zone**
Erstellen Sie eine öffentliche gehostete Zone, wenn Sie möchten, dass Internetdatenverkehr zu Ihren Ressourcen geleitet wird, sodass Ihre Kunden beispielsweise die Unternehmens-Website anzeigen können, die Sie auf EC2-Instances hosten. Weitere Informationen finden Sie unter [Arbeiten mit öffentlichen gehosteten Zonen](AboutHZWorkingWith.md).
**Privat gehostete Zone**
Erstellen Sie eine private gehostete Zone, wenn Sie den Datenverkehr innerhalb einer Amazon VPC weiterleiten wollen. Weitere Informationen finden Sie unter [Arbeiten mit privat gehosteten Zonen](hosted-zones-private.md).
1. Erstellen von Datensätzen in der gehosteten Zone. Datensätze definieren, wohin der Datenverkehr für einen bestimmten Domänen- oder Subdomänennamen weitergeleitet werden soll. Um beispielsweise den Datenverkehr für www.example.com zu einem Webserver in Ihrem Rechenzentrum weiterzuleiten, erstellen Sie in der Regel einen www.example.com-Datensatz in der gehosteten Zone example.com.
Weitere Informationen finden Sie unter den folgenden Themen:
+ [Arbeiten mit Datensätzen](rrsets-working-with.md)
+ [Weiterleiten von Datenverkehr für Subdomänen](dns-routing-traffic-for-subdomains.md)
+ [Weiterleitung des Internetverkehrs zu Ihren AWS Ressourcen](routing-to-aws-resources.md)
# Weiterleiten von Datenverkehr für Subdomänen
Wenn Sie Datenverkehr zu Ihren Ressourcen für eine Subdomäne wie acme.example.com oder zenith.example.com weiterleiten möchten, haben Sie zwei Möglichkeiten:
**Sie erstellen Datensätze in der gehosteten Zone für die Domäne**
Um den Datenverkehr für eine Subdomäne weiterzuleiten, erstellen Sie normalerweise einen Datensatz in der gehosteten Zone, der den gleichen Namen wie die Domäne hat. Um beispielsweise den Internet-Datenverkehr für acme.example.com zu einem Webserver in Ihrem Rechenzentrum weiterzuleiten, erstellen Sie in der Regel einen Datensatz namens acme.example.com in der gehosteten Zone example.com. Weitere Informationen finden Sie unter dem Thema [Arbeiten mit Datensätzen](rrsets-working-with.md) und seinen Unterthemen.
**Sie erstellen eine gehostete Zone für die Subdomäne und erstellen Datensätze in der neuen gehosteten Zone**
Sie können auch eine gehostete Zone für die Subdomäne erstellen. Die Verwendung einer separaten gehosteten Zone zum Weiterleiten von Internetverkehr für eine Subdomäne wird manchmal als „Delegieren der Verantwortung für eine Subdomäne an eine gehostete Zone“ oder als „Delegieren einer Subdomäne an andere Nameserver“ oder als eine ähnliche Kombination von Begriffen bezeichnet. Im Folgenden finden Sie eine Übersicht über die Funktionsweise:
1. Sie erstellen eine gehostete Zone, die denselben Namen wie die Subdomäne hat, für die Sie Datenverkehr weiterleiten möchten, z. B. acme.example.com.
1. Anschließend erstellen Sie Datensätze in der neuen gehosteten Zone, die definieren, wie Sie den Datenverkehr für die Subdomäne (acme.example.com) und deren Unterdomänen weiterleiten möchten, wie z. B. backend.acme.example.com.
1. Sie erhalten die Nameserver, die Route 53 der neuen gehosteten Zone zugewiesen hat, als sie von ihnen erstellt wurde.
1. Sie erstellen einen neuen NS-Eintrag in der Hosting-Zone für die Domain (example.com). Der Name des NS-Eintrags muss der Subdomänenname (acme.example.com) sein, und Sie geben die vier Nameserver, die Sie in Schritt 3 erhalten haben, als Datensatzwerte an.
Wenn Sie eine separate gehostete Zone zum Weiterleiten des Datenverkehrs für eine Subdomäne verwenden, können Sie mithilfe von IAM-Berechtigungen den Zugriff auf die gehostete Zone für die Subdomäne beschränken. Wenn Sie mehrere Subdomänen haben, die von verschiedenen Gruppen verwaltet werden, kann das Erstellen einer gehosteten Zone für jede Subdomäne die Anzahl der Personen, die Zugriff auf Datensätze in der gehosteten Zone für die Domäne haben müssen, erheblich reduzieren.
Um diesen Delegierungsprozess zu implementieren, benötigen Sie die folgenden IAM-Berechtigungen. Weitere Informationen zu Route 53 53-IAM-Richtlinien finden Sie unter[Identity and Access Management in Amazon Route 53](security-iam.md):
**Elternkonto (besitzt example.com)**
Der Benutzer oder die Rolle benötigt Berechtigungen, um Datensätze in der Hosting-Zone der übergeordneten Domain zu ändern:
**Kinderkonto (erstellt acme.example.com)**
Der Benutzer oder die Rolle benötigt Berechtigungen, um die gehostete Subdomain-Zone zu erstellen und zu verwalten:
Wenn Sie eine separate gehostete Zone für eine Subdomäne verwenden, können Sie auch andere DNS-Dienste für die Domäne und die Subdomäne verwenden. Weitere Informationen finden Sie unter [Verwendung von Amazon Route 53 als DNS-Service für eine Subdomäne ohne Migration der übergeordneten Domäne](creating-migrating.md).
Es entsteht eine geringe Auswirkung auf die Performance dieser Konfiguration bei der ersten DNS-Abfrage von jedem DNS-Auflöser. Der Auflöser muss Informationen von der gehosteten Zone für die Stammdomäne und dann von der gehosteten Zone für die Subdomäne erhalten. Nach der ersten DNS-Abfrage für eine Subdomäne speichert der Auflöser die Informationen und muss sie nicht erneut abrufen, bis die TTL abläuft und ein anderer Client die Subdomäne von diesem Auflöser anfordert. Weitere Informationen finden Sie unter [TTL (Sekunden)](resource-record-sets-values-basic.md#rrsets-values-basic-ttl) im Abschnitt [Werte, die Sie beim Erstellen oder Bearbeiten von Amazon Route 53-Datensätzen angeben](resource-record-sets-values.md).
**Topics**
+ [Erstellen einer anderen gehosteten Zone zur Weiterleitung des Datenverkehrs für eine Subdomäne](#dns-routing-traffic-for-subdomains-new-hosted-zone)
+ [Weiterleiten von Datenverkehr für zusätzliche Ebenen von Subdomänen](#dns-routing-traffic-for-sub-subdomains)
## Erstellen einer anderen gehosteten Zone zur Weiterleitung des Datenverkehrs für eine Subdomäne
Eine Möglichkeit, den Datenverkehr für eine Subdomäne weiterzuleiten, besteht darin, eine gehostete Zone für die Subdomäne zu erstellen und dann Datensätze für die Subdomäne in der neuen gehosteten Zone zu erstellen. (Die gebräuchlichere Option ist, Datensätze für die Subdomäne in der gehosteten Zone für die Domäne zu erstellen.)
**Anmerkung**
Dieses Verfahren zeigt, wie eine Subdomain an Route 53 delegiert wird. Sie können eine Subdomain auch an andere DNS-Dienste delegieren, indem Sie stattdessen NS-Einträge erstellen, die auf die Nameserver dieser Dienste verweisen.
Es folgt eine Übersicht über den Prozess:
1. Erstellen einer gehosteten Zone für die Subdomäne. Weitere Informationen finden Sie unter [Erstellen einer neuen gehosteten Zone für eine Subdomäne](#dns-routing-traffic-for-subdomains-creating-hosted-zone).
1. Hinzufügen von Datensätzen für die Subdomäne zu der gehosteten Zone. Wenn die gehostete Zone für die Domäne Datensätze enthält, die in die gehostete Zone für die Subdomäne gehören, duplizieren Sie diese Datensätze in der gehosteten Zone für die Subdomäne. Weitere Informationen finden Sie unter [Erstellen von Datensätzen in der gehosteten Zone für die Subdomäne](#dns-routing-traffic-for-subdomains-creating-records)
1. Erstellen Sie einen NS-Datensatzes für die Subdomäne in der gehosteten Zone für die Domäne, wodurch die Verantwortung für die Subdomäne an die Namensserver in der neuen gehosteten Zone delegiert wird. Wenn die gehostete Zone für die Domäne Datensätze enthält, die in die gehostete Zone für die Subdomäne gehören, löschen Sie die Datensätze aus der gehosteten Zone für die Domäne. (Sie haben Kopien in der gehosteten Zone für die Subdomäne in Schritt 2 erstellt.) Weitere Informationen finden Sie unter [Aktualisieren der gehosteten Zone für die Domäne](#dns-routing-traffic-for-subdomains-delegating-responsibility).
### Erstellen einer neuen gehosteten Zone für eine Subdomäne
Zum Erstellen einer gehosteten Zone für eine Subdomäne unter Verwendung der Route 53-Konsole führen Sie die folgenden Schritte aus.
**Erstellen einer gehosteten Zone für eine Subdomäne (Konsole)**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. Wenn Sie noch keine Erfahrung mit Route 53 haben, wählen Sie **Get Started (Erste Schritte)** aus.
Wenn Sie Route 53 bereits nutzen, wählen Sie **Hosted zones** im Navigationsbereich aus.
1. Wählen Sie **Create Hosted Zone**.
1. Geben Sie im Bereich rechts den Namen der Unterdomäne ein, zum Beispiel acme.example.com. Optional können Sie auch einen Kommentar eingeben.
Erläuterungen dazu, wie Sie andere Zeichen als a-z, 0-9 und - (Bindestrich) eingeben und wie internationale Domainnamen angegeben werden, erhalten Sie unter [Format für DNS-Domänennamen](DomainNameFormat.md).
1. Übernehmen Sie für **Type** den Standardwert **Public Hosted Zone**.
1. Wählen Sie im rechten Bereich unten die Option **Create** (Erstellen) aus.
### Erstellen von Datensätzen in der gehosteten Zone für die Subdomäne
Um festzulegen, wie Route 53 den Datenverkehr für die Subdomäne (acme.example.com) und ihre Subdomänen (backend.acme.example.com) weiterleiten soll, erstellen Sie Datensätze in der gehosteten Zone für die Subdomäne.
Beachten Sie Folgendes zum Erstellen von Datensätzen in der gehosteten Zone für die Subdomäne:
+ Erstellen Sie keine zusätzlichen Namensserver (NS)- oder Autoritätsursprung (SOA)-Datensätze in der gehosteten Zone für die Subdomäne, und löschen Sie nicht die vorhandenen NS- und SOA-Datensätze.
+ Erstellen Sie alle Datensätze für die Subdomäne in der gehosteten Zone für die Subdomäne. Wenn Sie beispielsweise Zonen für example.com und für die Domäne acme.example.com gehostet haben, erstellen Sie alle Datensätze für die Unterdomäne acme.example.com in der gehosteten Zone acme.example.com. Dazu gehören Datensätze wie backend.acme.example.com und beta.backend.acme.example.com.
+ Wenn die gehostete Zone für die Domäne (example.com) bereits Datensätze enthält, die in die gehostete Zone für die Subdomäne (acme.example.com) gehören, kopieren Sie diese Datensätze in der gehosteten Zone für die Subdomäne. Im letzten Schritt des Prozesses löschen Sie die doppelten Datensätze aus der gehosteten Zone für die Domäne später.
**Wichtig**
Wenn Sie sowohl in der gehosteten Zone für die Domäne als auch in der gehosteten Zone für die Subdomäne Datensätze für die Subdomäne haben, ist das DNS-Verhalten inkonsistent. Das Verhalten hängt davon ab, welche Nameserver ein DNS-Resolver zwischengespeichert hat, die Nameserver für die gehostete Zone der Domäne (example.com) oder die Nameserver für die gehostete Zone der Subdomäne (acme.example.com). In einigen Fällen gibt Route 53 NXDomäne (nicht vorhandene Domäne) zurück, wenn der Datensatz vorhanden ist, jedoch nicht in der gehosteten Zone, an die DNS-Resolver die Abfrage senden.
Weitere Informationen finden Sie unter [Arbeiten mit Datensätzen](rrsets-working-with.md).
### Aktualisieren der gehosteten Zone für die Domäne
Wenn Sie eine gehostete Zone erstellen, weist Route 53 der Zone automatisch vier Namensserver zu. Der NS-Eintrag für eine gehostete Zone identifiziert die Nameserver, die auf DNS-Abfragen für die Domäne oder Subdomäne reagieren. Um die Datensätze in der gehosteten Zone für die Subdomäne zur Weiterleitung des Internetverkehrs zu verwenden, erstellen Sie einen neuen NS-Datensatz in der gehosteten Zone für die Domäne (example.com) und geben ihm den Namen der Subdomäne (acme.example.com). Für den Wert des NS-Datensatzes geben Sie die Namen der Nameserver aus der gehosteten Zone für die Subdomäne an.
Das passiert, wenn Route 53 eine DNS-Abfrage von einem DNS-Auflöser für die Subdomäne acme.example.com oder eine ihrer Subdomänen erhält:
1. Route 53 sucht in der gehosteten Zone nach der Domäne (example.com) und findet den NS-Datensatz für die Subdomäne (acme.example.com).
1. Route 53 ruft die Nameserver vom NS-Eintrag acme.example.com in der gehosteten Zone für die Domäne example.com ab und gibt diese Nameserver an den DNS-Resolver zurück.
1. Der Auflöser sendet die Anfrage für acme.example.com erneut an die Namensserver der gehosteten Zone acme.example.com.
1. Route 53 beantwortet die Abfrage unter Verwendung eines Datensatzes in der gehosteten Zone acme.example.com.
Führen Sie die folgenden Schritte aus, um Route 53 so zu konfigurieren, dass der Datenverkehr für die Subdomäne mithilfe der gehosteten Zone für die Subdomäne weitergeleitet und doppelte Datensätze aus der gehosteten Zone für die Domäne gelöscht werden:
**So konfigurieren Sie Route 53 für die Verwendung der gehosteten Zone für die Subdomäne (Konsole)**
1. Rufen Sie in der Route 53-Konsole die Namensserver für die gehostete Zone für die Subdomäne ab:
1. Klicken Sie im Navigationsbereich auf **Hosted Zones (Gehostete Zonen)**.
1. Wählen Sie auf der Seite **Hosted Zones** (Gehostete Zonen) das Optionsfeld (nicht den Namen) für die gehostete Zone für die Subdomäne aus.
1. Kopieren Sie im rechten Bereich die Namen der vier Server, die für **Name Server** im Bereich **Details zur gehosteten Zone** aufgeführt sind.
1. Wählen Sie den Namen der gehosteten Zone für die Domäne (example.com), nicht für die Subdomäne.
1. Wählen Sie **Datensatz erstellen**.
1. Wählen Sie **Simple Routing (Einfaches Routing)**, und wählen Sie **Next (Weiter)**.
1. Wählen Sie **Define simple record (Einfachen Datensatz definieren)**.
1. Geben Sie die folgenden Werte an:
**Name**
Geben Sie den Namen der Subdomain ein (z. B.`acme.example.com`). Dieser muss genau mit dem Namen der von Ihnen erstellten Subdomain-Hosting-Zone übereinstimmen.
**Bewerten/Weiterleiten des Datenverkehrs an**
Klicken Sie auf**IP-Adresse oder ein anderer Wert, abhängig vom Datensatztyp**, und fügen Sie die Namen der Namenserver ein, die Sie in Schritt 1 kopiert haben.
**Datensatztyp**
Klicken Sie auf**NS — Namenserver für eine gehostete -Zone:**aus.
**TTL (Sekunden)**
Ändern Sie dies in einen gebräuchlicheren Wert für einen NS-Datensatz, z. B. 172800 Sekunden.
1. Klicken Sie auf**Einfachen Datensatz definieren**, und wählen Sie**Erstellen von Datensätzen**aus.
1. Wenn die gehostete Zone für die Domäne Datensätze enthält, die Sie in der gehosteten Zone für die Subdomäne neu erstellt haben, löschen Sie diese Datensätze aus der gehosteten Zone für die Domäne. Weitere Informationen finden Sie unter [Löschen von Datensätzen](resource-record-sets-deleting.md).
Wenn Sie fertig sind, sollten sich alle Datensätze für die Subdomäne in der gehosteten Zone für die Subdomäne befinden.
## Weiterleiten von Datenverkehr für zusätzliche Ebenen von Subdomänen
Sie leiten Datenverkehr zu einer Subdomäne einer Subdomäne, wie z. B. backend.acme.example.com, genauso weiter, wie Sie Datenverkehr zu einer Subdomäne weiterleiten, wie z. B. acme.example.com. Entweder Sie erstellen Datensätze in der gehosteten Zone für die Domäne, oder Sie erstellen eine gehostete Zone für die untergeordnete Subdomäne, und dann erstellen Sie Datensätze in dieser neuen gehosteten Zone.
Wenn Sie eine separate gehostete Zone für die untergeordnete Subdomäne erstellen möchten, erstellen Sie den NS-Datensatz für die untergeordnete Subdomäne in der gehosteten Zone für die Subdomäne, die eine Ebene näher am Domänennamen liegt. Auf diese Weise können Sie sicherstellen, dass der Datenverkehr ordnungsgemäß an Ihre Ressourcen weitergeleitet wird. Angenommen, Sie möchten Datenverkehr für die folgenden Subdomänen weiterleiten:
+ subdomain1.example.com
+ subdomain2.subdomain1.example.com
Um eine andere gehostete Zone zur Weiterleitung des Datenverkehrs für subdomain2.subdomain1.example.com zu verwenden, gehen Sie wie folgt vor:
1. Erstellen Sie eine gehostete Zone mit dem Namen subdomain2.subdomain1.example.com.
1. Erstellen Sie Datensätze in der gehosteten Zone subdomain2.subdomain1.example.com. Weitere Informationen finden Sie unter [Erstellen von Datensätzen in der gehosteten Zone für die Subdomäne](#dns-routing-traffic-for-subdomains-creating-records).
1. Kopieren Sie die Namen der Namensserver für die gehostete Zone subdomain2.subdomain1.example.com.
1. Erstellen Sie in der gehosteten Zone subdomain1.example.com einen NS-Datensatz namens subdomain2.subdomain1.example.com und fügen Sie die Namen der Namensserver für die gehostete Zone subdomain2.subdomain1.example.com ein.
Löschen Sie außerdem alle doppelten Datensätze aus der Subdomäne1.example.com. Weitere Informationen finden Sie unter [Aktualisieren der gehosteten Zone für die Domäne](#dns-routing-traffic-for-subdomains-delegating-responsibility).
Nachdem Sie diesen NS-Datensatz erstellt haben, verwendet Route 53 die gehostete Zone subdomain2.subdomain1.example.com, um den Datenverkehr für die Subdomäne subdomain2.subdomain1.example.com weiterzuleiten.
# Arbeiten mit gehosteten Zonen
Eine gehostete Zone ist ein Container für Datensätze. Diese Datensätze enthalten Informationen darüber, wie Sie Datenverkehr zu einer bestimmten Domäne (z. B. example.com) und ihren Unterdomänen (z. B. acme.example.com, zenith.example.com) weiterleiten wollen. Eine gehostete Zone trägt denselben Namen wie die entsprechende Domäne. Es gibt zwei Arten von Hosting-Zonen:
+ *Öffentliche gehostete Zonen* enthalten Datensätze, die angeben, wie Sie Datenverkehr im Internet weiterleiten wollen. Weitere Informationen finden Sie unter [Arbeiten mit öffentlichen gehosteten Zonen](AboutHZWorkingWith.md).
+ *Private gehostete Zonen* enthalten Datensätze, die angeben, wie Sie Datenverkehr in einer Amazon VPC weiterleiten wollen. Weitere Informationen finden Sie unter [Arbeiten mit privat gehosteten Zonen](hosted-zones-private.md).
# Arbeiten mit öffentlichen gehosteten Zonen
Eine öffentliche gehostete Zone ist ein Container mit Informationen darüber, wie Sie im Internet Datenverkehr zu einer bestimmten Domäne (z. B. example.com) und ihren Unterdomänen (z. B. acme.example.com, zenith.example.com) weiterleiten wollen. Sie erhalten eine öffentliche gehostete Zone auf eine von zwei Arten:
+ Wenn Sie eine Domäne bei Route 53 registrieren, erstellen wir für Sie automatisch eine gehostete Zone.
+ Bei der Übertragung von DNS-Dienst für eine vorhandene Domäne nach Route 53 erstellen Sie zuerst eine gehostete Zone für die Domäne. Weitere Informationen finden Sie unter [Amazon Route 53 zum DNS-Dienst für eine vorhandene Domäne machenRoute 53 zum DNS-Dienst für eine vorhandene Domäne machen](MigratingDNS.md).
In beiden Fällen erstellen Sie anschließend Datensätze in der gehosteten Zone, um anzugeben, wie der Datenverkehr für die Domäne und die Unterdomänen weitergeleitet werden soll. Sie können beispielsweise einen Datensatz erstellen, um den Verkehr für www.example.com an eine CloudFront Distribution oder einen Webserver in Ihrem Rechenzentrum weiterzuleiten. Weitere Informationen über Einträge finden Sie unter [Arbeiten mit Datensätzen](rrsets-working-with.md).
In diesem Thema wird erläutert, wie Sie die Amazon Route 53-Konsole verwenden, um öffentlich gehostete Zonen zu erstellen, aufzulisten und zu löschen.
**Anmerkung**
Sie können auch eine *privat* gehostete Route 53-Zone verwenden, um den Verkehr innerhalb einer oder mehrerer Zonen weiterzuleiten VPCs , die Sie mit dem Amazon VPC-Service erstellen. Weitere Informationen finden Sie unter [Arbeiten mit privat gehosteten Zonen](hosted-zones-private.md).
**Topics**
+ [Überlegungen zum Arbeiten mit öffentlichen gehosteten Zonen](hosted-zone-public-considerations.md)
+ [Erstellen einer öffentlichen gehosteten Zone](CreatingHostedZone.md)
+ [Das Abrufen der Nameserver für eine öffentliche gehostete Zone](GetInfoAboutHostedZone.md)
+ [Auflisten der öffentlichen gehosteten Zonen](ListInfoOnHostedZone.md)
+ [Anzeigen von DNS-Abfragemetriken für eine öffentliche gehostete Zone](hosted-zone-public-viewing-query-metrics.md)
+ [Löschen einer öffentlichen gehosteten Zone](DeleteHostedZone.md)
+ [Überprüfen der DNS-Antworten von Route 53](dns-test.md)
+ [Konfigurieren von White-Label-Nameservern](white-label-name-servers.md)
+ [NS- und SOA-Datensätze, die Amazon Route 53 für eine öffentliche gehostete Zone erstellt](SOA-NSrecords.md)
+ [Aktivierung der beschleunigten Wiederherstellung für die Verwaltung öffentlicher DNS-Einträge](accelerated-recovery.md)
# Überlegungen zum Arbeiten mit öffentlichen gehosteten Zonen
Beachten Sie die folgenden Überlegungen, wenn Sie mit öffentlichen gehosteten Zonen arbeiten:
**NS- und SOA-Datensätze**
Bei der Erstellung einer gehosteten Zone erstellt Amazon Route 53 automatisch einen NS-Eintrag (Namenserver) und einen SOA-Eintrag (Start of Authority, Autoritätsursprung) für die Zone. Der NS-Eintrag identifiziert die vier Namenserver, die Sie der Vergabestelle oder dem DNS-Dienst nennen, sodass DNS-Abfragen an die Route 53-Namenserver weitergeleitet werden. Weitere Informationen über NS- und SOA-Einträge finden Sie unter [NS- und SOA-Datensätze, die Amazon Route 53 für eine öffentliche gehostete Zone erstellt](SOA-NSrecords.md).
**Mehrere gehostete Zonen mit demselben Namen**
Sie können mehr als eine gehostete Zone mit demselben Namen erstellen und verschiedene Datensätze für jede gehostete Zone hinzufügen. Route 53 weist jeder gehosteten Zone vier Nameserver zum, und die Nameserver sind jeweils unterschiedlich. Wenn Sie die Nameserverdatensätze Ihrer Vergabestellt ändern, achten Sie darauf, Route 53-Nameserver für die richtige gehostete Zone verwenden, nämlich die mit den Ressourcendatensätze, die Route 53 für die Antwort auf Abfragen für Ihre Domäne verwenden soll. Route 53 gibt nie Werte für Datensätze in anderen gehosteten Zonen aus, die denselben Namen haben.
**Wiederverwendbare Delegationssätze**
Standardmäßig weist Route 53 einen eindeutigen Satz von vier Nameservern (gemeinsam Delegierungsgruppe genannt) jeder gehosteten Zone zu, die Sie erstellen. Wenn Sie eine große Anzahl von gehosteten Zonen erstellen möchten, können Sie programmgesteuert eine wiederverwendbare Delegierungsgruppe erstellen. (Wiederverwendbare Delegierungsgruppen sind nicht in der Route 53-Konsole verfügbar.) Anschließend können Sie gehostete Zonen programmgesteuert erstellen und jeder gehostete Zone dieselbe wiederverwendbare Delegierungsgruppe zuordnen – dieselben vier Namenserver.
Wiederverwendbare Delegierungsgruppen vereinfachen die Migration des DNS-Dienst in Route 53, da Sie Ihre Domänenname-Vergabestelle anweisen können, dieselben vier Namenserver für alle Domänen zu verwenden, für die Route 53 als DNS-Dienst verwendet werden soll. Weitere Informationen finden Sie [CreateReusableDelegationSet](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateReusableDelegationSet.html)in der *Amazon Route 53 API-Referenz*.
# Erstellen einer öffentlichen gehosteten Zone
Eine öffentliche gehostete Zone ist ein Container mit Informationen darüber, wie Sie im Internet Datenverkehr zu einer bestimmten Domäne (z. B. example.com) und ihren Unterdomänen (z. B. acme.example.com, zenith.example.com) weiterleiten wollen. Nachdem Sie eine gehostete Zone erstellt haben, legen Sie Datensätze an, um anzugeben, wie der Datenverkehr für die Domäne und die Unterdomänen weitergeleitet werden soll.
**Einschränkungen**
Beachten Sie die folgenden Einschränkungen für die Erstellung von Hosting-Zonen mit Route 53.
Sie können eine gehostete Zone nur für eine Domäne erstellen, die Sie über die Berechtigung zur Verwaltung verfügen. Das heißt in der Regel, dass Sie Eigentümer der Domäne sind. Es könnte aber auch bedeuten, dass Sie eine Anwendung für den Eigentümer entwickeln.
Sie können Hosting-Zonen nur für Domains und Subdomains erstellen. Route 53 unterstützt nicht das Hosten von Top-Level-Domains (TLD) wie. `.com`
**So erstellen Sie eine öffentlich gehostete Zone mit der Route 53-Konsole**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. Wenn Sie erst mit der Verwendung von Route 53 begonnen haben, wählen Sie **Get Started (Erste Schritte)** unter **DNS Management** aus.
Wenn Sie Route 53 bereits nutzen, wählen Sie **Hosted zones (Gehostete Zonen)** im Navigationsbereich aus.
1. Wählen Sie **Create Hosted Zone (Gehostete Zone)** aus.
1. Geben Sie im Bereich **Create Hosted Zone (Gehostete Zone erstellen)** den Namen der Domäne ein, zu der Sie Datenverkehr weiterleiten wollen. Optional können Sie auch einen Kommentar eingeben.
Erläuterungen dazu, wie Sie andere Zeichen als a-z, 0-9 und - (Bindestrich) eingeben und wie internationale Domainnamen angegeben werden, erhalten Sie unter [Format für DNS-Domänennamen](DomainNameFormat.md).
1. Übernehmen Sie für **Type (Typ)** den Standardwert **Public Hosted Zone (Öffentlich gehostete Zone)**.
1. Wählen Sie **Erstellen** aus.
1. Erstellen Sie Datensätze, die angeben, wie Sie den Datenverkehr für die Domäne und die Unterdomänen weiterleiten möchten. Weitere Informationen finden Sie unter [Arbeiten mit Datensätzen](rrsets-working-with.md).
1. Informationen zur Verwendung von Datensätzen in der neuen gehosteten Zone zur Weiterleitung des Datenverkehrs für Ihre Domäne finden Sie unter dem entsprechenden Thema:
+ Wenn Sie Route 53 als DNS-Dienst für eine Domäne verwenden, die bei einer anderen Domänenvergabestelle registriert ist, lesen Sie nach unter [Amazon Route 53 zum DNS-Dienst für eine vorhandene Domäne machenRoute 53 zum DNS-Dienst für eine vorhandene Domäne machen](MigratingDNS.md).
+ Wenn die Domäne mit Route 53 registriert wurde, lesen Sie [Hinzufügen oder Ändern der Nameserver und Glue-Datensätze in einer Domäne](domain-name-servers-glue-records.md).
# Das Abrufen der Nameserver für eine öffentliche gehostete Zone
Sie erhalten die Nameserver für eine öffentliche gehostete Zone, wenn Sie den DNS-Dienst für Ihre Domänenregistrierung ändern möchten. Informationen zum Ändern des DNS-Dienstes finden Sie unter [Amazon Route 53 zum DNS-Dienst für eine vorhandene Domäne machenRoute 53 zum DNS-Dienst für eine vorhandene Domäne machen](MigratingDNS.md).
**Anmerkung**
Bei einigen Vergabestellen ist die Angabe von vollständig qualifizierten Domänennamen unzulässig. Dort können Sie Namenserver nur unter Verwendung von IP-Adressen angeben. Wenn Ihre Vergabestelle voraussetzt, dass Sie IP-Adressen verwenden, können Sie die IP-Adressen für Ihre Namensserver mithilfe von "dig" (für Mac, Unix oder Linux) oder "nslookup" (für Windows) abrufen. Wir ändern die IP-Adressen von Namensservern selten. Wenn wir die IP-Adressen ändern müssen, benachrichtigen wir Sie im Voraus.
**So rufen Sie die Nameserver für eine gehostete Zone mithilfe der Route 53-Konsole ab**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Klicken Sie im Navigationsbereich auf **Hosted Zones (Gehostete Zonen)**.
1. Wählen Sie auf der Seite **Hosted Zones (Gehostete Zonen)** das Optionsfeld (nicht den Namen) für die gehostete Zone aus und wählen Sie dann **View Details (Details anzeigen)** aus.
1. Wählen Sie auf der Detailseite für die gehostete Zone **Hosted Zone details (Details der gehosteten Zone)** aus.
1. Notieren Sie sich die vier Namen, die für **Name Servers** aufgelistet werden.
# Auflisten der öffentlichen gehosteten Zonen
Sie können die Amazon Route 53-Konsole verwenden, um alle Hosting-Zonen aufzulisten, die Sie mit dem aktuellen AWS Konto erstellt haben. Informationen zum Auflisten von Hosting-Zonen mithilfe der Route 53-API finden Sie [ListHostedZones](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZones.html)in der *Amazon Route 53-API-Referenz*.
**So listen Sie mithilfe der Route 53-Konsole die öffentlichen Hosting-Zonen auf, die einem AWS Konto zugeordnet sind**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Klicken Sie im Navigationsbereich auf **Hosted Zones (Gehostete Zonen)**. Auf der Seite wird eine Liste der Hosting-Zonen angezeigt, die dem AWS Konto zugeordnet sind, mit dem Sie derzeit angemeldet sind.
1. Verwenden Sie die Suchleiste oben in der Tabelle, um gehostete Zonen zu filtern.
Das Suchverhalten hängt davon ab, ob die gehostete Zone bis zu 2.000 Datensätze oder mehr als 2.000 Datensätze enthält:
**Bis zu 2.000 gehostete Zonen**
+ Um Datensätze anzuzeigen, die einen bestimmten Wert haben, klicken Sie auf die Suchleiste, wählen Sie eine Eigenschaft in der Dropdown-Liste aus, und geben Sie einen Wert ein. Sie können einen Wert auch direkt in der Suchleiste eingeben und die Eingabetaste drücken. Um beispielsweise die gehosteten Zonen anzuzeigen, die einen Namen haben, der mit**abc**Geben Sie diesen Wert in die Suchleiste ein und drücken Sie die Eingabetaste.
+ Um nur die gehosteten Zonen anzuzeigen, die denselben gehosteten Zonentyp haben, wählen Sie den Typ in der Dropdown-Liste aus, und geben Sie den Typ ein.
**Mehr als 2.000 gehostete Zonen**
+ Sie können nach Eigenschaften basierend auf dem genauen Domänennamen, allen Eigenschaften und dem Typ suchen.
+ Suchen Sie mit dem genauen Domainnamen für schnellere Suchergebnisse.
# Anzeigen von DNS-Abfragemetriken für eine öffentliche gehostete Zone
Sie können die Gesamtzahl der DNS-Abfragen anzeigen, die Route 53 für eine bestimmte öffentliche gehostete Zone oder eine Kombination aus öffentlichen gehosteten Zonen beantwortet. Die Metriken werden in angezeigt CloudWatch, sodass Sie ein Diagramm anzeigen, den Zeitraum auswählen können, den Sie anzeigen möchten, und die Metriken auf eine Vielzahl anderer Arten anpassen können. Sie können auch Alarme erstellen und Benachrichtigungen konfigurieren, sodass Sie benachrichtigt werden, wenn die Anzahl der DNS-Abfragen in einem bestimmten Zeitraum ein bestimmtes Level über- oder unterschreitet.
**Anmerkung**
Route 53 sendet automatisch die Anzahl der DNS-Abfragen an CloudWatch alle öffentlich gehosteten Zonen, sodass Sie nichts konfigurieren müssen, bevor Sie die Abfragemetriken anzeigen können. Für DNS-Abfragemetriken fallen keine Gebühren an.
**Welche DNS-Abfragen werden gezählt?**
Metriken enthalten nur die Abfragen, die DNS-Resolver an Route 53 weiterleiten. Wenn ein DNS-Auflöser die Antwort auf eine Abfrage (z. B. die IP-Adresse für einen Load Balancer für example.com) bereits zwischengespeichert hat, gibt der Auflöser die zwischengespeicherte Antwort weiter zurück, ohne die Abfrage an Route 53 weiterzuleiten, bis die TTL für den entsprechenden Datensatz abgelaufen ist.
Abhängig davon, wie viele DNS-Abfragen für einen Domänennamen (example.com) oder Subdomänennamen (www.example.com) übermittelt werden, welche Resolver von Ihren Benutzern verwendet werden und welche TTL für den Datensatz gilt, enthalten die DNS-Abfragemetriken möglicherweise Informationen zu nur einer von mehreren tausend Abfragen, die an DNS-Resolver übermittelt wurden. Weitere Information zur Funktionsweise von DNS finden Sie unter [So leitet Amazon Route 53 Datenverkehr an Ihre Domain weiter](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
**Wann werden Abfragemetriken für eine gehostete Zone in CloudWatch angezeigt?**
Nachdem Sie eine gehostete Zone erstellt haben, kommt es zu einer Verzögerung von bis zu mehreren Stunden, bevor die gehostete Zone in CloudWatch angezeigt werden kann. Darüber hinaus müssen Sie eine DNS-Abfrage für einen Datensatz in der gehosteten Zone senden, damit Daten angezeigt werden können.
**Abrufen von Metriken sind nur in USA Ost (Nord-Virginia) verfügbar**
Um Metriken für gehostete Zonen abzurufen, müssen Sie als Region USA Ost (Nord-Virginia) angeben. Um Metriken mit der AWS CLI abzurufen, müssen Sie die AWS Region entweder nicht spezifizieren oder `us-east-1` als Region angeben. Route 53 Metriken sind nicht verfügbar, wenn Sie eine andere Region auswählen.
**CloudWatch Metrik und Dimension für DNS-Abfragen**
Informationen zur CloudWatch Metrik und Dimension für DNS-Abfragen finden Sie unter[Überwachung von Hosting-Zonen mit Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md). Informationen zu CloudWatch Metriken finden Sie unter [Verwenden von CloudWatch Amazon-Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) im * CloudWatch Amazon-Benutzerhandbuch*.
**Anfordern detaillierterer Daten zu DNS-Abfragen**
Um detailliertere Informationen zu jeder DNS-Abfrage zu erhalten, die Route 53 beantwortet, einschließlich der folgenden Werte, können Sie die Abfrageprotokollierung konfigurieren:
+ Domain oder Subdomain, die angefordert wurde
+ Das Datum und die Uhrzeit der Anforderung
+ DNS-Datensatztyp (z. B. A oder AAAA)
+ Der Edge-Standort von Route 53, der auf die DNS-Abfrage geantwortet hat
+ Der DNS-Antwortcode, wie z. B. `NoError` oder `ServFail`
Weitere Informationen finden Sie unter [Öffentliche DNS-Abfrageprotokollierung](query-logs.md).
**So erhalten Sie DNS-Abfragemetriken**
Kurz nachdem Sie eine gehostete Zone erstellt haben, beginnt Amazon Route 53, Metriken und Dimensionen einmal pro Minute an zu senden CloudWatch. Sie können die folgenden Verfahren verwenden, um die Metriken auf der CloudWatch Konsole oder mithilfe von AWS Command Line Interface (AWS CLI) anzuzeigen.
**Topics**
+ [DNS-Abfragemetriken für eine öffentlich gehostete Zone in der CloudWatch Konsole anzeigen](#hosted-zone-public-viewing-query-metrics-console)
+ [Abrufen von DNS-Abfragemetriken mithilfe der AWS CLI](#hosted-zone-public-viewing-query-metrics-cli)
## DNS-Abfragemetriken für eine öffentlich gehostete Zone in der CloudWatch Konsole anzeigen
Gehen Sie wie folgt vor, um DNS-Abfragemetriken für öffentlich gehostete Zonen in der CloudWatch Konsole anzuzeigen.
**Um DNS-Abfragemetriken für eine öffentlich gehostete Zone auf der CloudWatch Konsole anzuzeigen**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die CloudWatch Konsole unter [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Wählen Sie im Navigationsbereich **Metriken** aus.
1. Wählen Sie in der Liste der AWS Regionen in der oberen rechten Ecke der Konsole die Option **USA Ost (Nord-Virginia)** aus. Route 53-Metriken sind nicht verfügbar, wenn Sie eine andere AWS Region auswählen.
1. Klicken Sie auf der Registerkarte **All metrics** auf **Route 53**.
1. Wählen Sie **Hosted Zone Metrics (Metriken für gehostete Zonen)** aus.
1. Aktivieren Sie das Kontrollkästchen für eine oder mehrere Hosting-Zonen, die den Metriknamen haben **DNSQueries**.
1. Ändern Sie auf der Registerkarte **Graphed metrics (Grafische Metriken)** die entsprechenden Werte, um die Metriken im gewünschten Format anzuzeigen.
Wählen Sie für **Statistik** die Option **Summe** oder **SampleCount**; beide Statistiken zeigen denselben Wert an.
## Abrufen von DNS-Abfragemetriken mithilfe der AWS CLI
Um DNS-Abfragemetriken mit dem AWS CLI abzurufen, verwenden Sie den [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html)Befehl. Beachten Sie Folgendes:
+ Sie geben die meisten Werte für den Befehl in einer separaten JSON-Datei an. Weitere Informationen finden Sie unter [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html).
+ Der Befehl gibt einen Wert für jedes Intervall zurück, das Sie für `Period` in der JSON-Datei angeben. `Period` wird in Sekunden angegeben. Wenn Sie also einen Zeitraum von fünf Minuten und `60` für `Period` angeben, erhalten Sie fünf Werte. Wenn Sie einen Zeitraum von fünf Minuten und `300` für `Period` angeben, erhalten Sie einen Wert.
+ In der JSON-Datei können Sie einen beliebigen Wert für `Id` angeben.
+ Lassen Sie die AWS Region entweder unspezifiziert oder geben Sie `us-east-1` sie als Region an. Route 53 Metriken sind nicht verfügbar, wenn Sie eine andere Region auswählen. Weitere Informationen finden Sie unter [Konfiguration der AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html) im *AWS Command Line Interface Benutzerhandbuch*.
Hier ist der AWS CLI Befehl, mit dem Sie DNS-Abfragemetriken für den Zeitraum von fünf Minuten zwischen 4:01 und 4:07 Uhr am 1. Mai 2019 abrufen. Der `metric-data-queries`-Parameter verweist auf die JSON-Beispieldatei, die dem Befehl folgt.
```
aws cloudwatch get-metric-data --metric-data-queries file://./metric.json --start-time 2019-05-01T04:01:00Z --end-time 2019-05-01T04:07:00Z
```
Hier sehen Sie die Beispiel-JSON-Datei:
```
[
{
"Id": "my_dns_queries_id",
"MetricStat": {
"Metric": {
"Namespace": "AWS/Route53",
"MetricName": "DNSQueries",
"Dimensions": [
{
"Name": "HostedZoneId",
"Value": "Z1D633PJN98FT9"
}
]
},
"Period": 60,
"Stat": "Sum"
},
"ReturnData": true
}
]
```
Hier sehen Sie die Ausgabe dieses Befehls. Beachten Sie Folgendes:
+ Die Start- und Endzeit im Befehl decken einen Zeitraum von sieben Minuten ab, `2019-05-01T04:01:00Z` bis `2019-05-01T04:07:00Z`.
+ Es gibt nur sechs Rückgabewerte. Es gibt keinen Wert für `2019-05-01T04:05:00Z`, da während dieser Minute keine DNS-Abfragen stattgefunden haben.
+ Der in der JSON-Datei `Period` angegebene Wert ist `60` (Sekunden), sodass die Werte in 1-Minuten-Intervallen gemeldet werden.
```
{
"MetricDataResults": [
{
"Id": "my_dns_queries_id",
"StatusCode": "Complete",
"Label": "DNSQueries",
"Values": [
101.0,
115.0,
103.0,
127.0,
111.0,
120.0
],
"Timestamps": [
"2019-05-01T04:07:00Z",
"2019-05-01T04:06:00Z",
"2019-05-01T04:04:00Z",
"2019-05-01T04:03:00Z",
"2019-05-01T04:02:00Z",
"2019-05-01T04:01:00Z"
]
}
]
}
```
# Löschen einer öffentlichen gehosteten Zone
In diesem Abschnitt wird erläutert, wie Sie eine öffentlich gehostete Zone mithilfe der Amazon-Route-53-Konsole verwenden können.
Sie können eine gehostete Zone nur dann löschen, wenn keine Datensätze (abgesehen von den Standard-SOA- und NS-Datensätzen) vorhanden sind. Wenn Ihre gehostet Zone andere Datensätze enthält, müssen Sie diese löschen, bevor Sie Ihre gehostete Zone löschen können. Dadurch wird verhindert, dass Sie versehentlich eine gehostete Zone löschen, die noch Datensätze enthält.
**Topics**
+ [Verhindern einer Weiterleitung des Datenverkehrs zu Ihrer Domäne](#delete-public-hosted-zone-stop-routing)
+ [Löschen von öffentlichen gehosteten Zonen, die von einem anderen Dienst erstellt wurden](#delete-public-hosted-zone-created-by-another-service)
+ [Löschen einer öffentlichen gehosteten Zone mit der Route 53-Konsole.](#delete-public-hosted-zone-procedure)
## Verhindern einer Weiterleitung des Datenverkehrs zu Ihrer Domäne
Wenn Sie Ihre Domänenregistrierung behalten möchten, aber die Weiterleitung von Internetdatenverkehr an Ihre Website oder Webanwendung beenden möchten, empfehlen wir, dass Sie *Datensätze* in der gehosteten Zone löschen, statt die gehostete Zone zu löschen.
**Wichtig**
Wenn Sie eine gehostete Zone löschen, können Sie diese nicht wiederherstellen. Sie müssen eine neue gehostete Zone erstellen und Sie die Namensserver für Ihre Domain-Registrierung aktualisieren. Es kann bis zu 48 Stunden dauern, bis diese Einstellungen wirksam werden. Wenn Sie eine gehostete Zone löschen, könnte sich außerdem jemand die Domäne aneignen und den Datenverkehr über Ihren Domänennamen an die eigenen Ressourcen weiterleiten.
Wenn Sie die Zuständigkeit für eine Subdomäne an eine gehostete Zone delegiert haben und die untergeordnete gehostete Zone löschen möchten, müssen Sie auch die übergeordnete gehostete Zone aktualisieren. Löschen Sie hierzu den NS-Datensatz, der denselben Namen wie die untergeordnete gehostete Zone hat. Wenn Sie z. B. die gehostete Zone „acme.example.com“ löschen möchten, müssen Sie auch den NS-Datensatz „acme.example.com“ in der gehosteten Zone „example.com“ löschen. Es wird empfohlen, zuerst den NS-Datensatz zu löschen und auf die Dauer der TTL für den NS-Datensatz zu warten, bevor Sie die untergeordnete gehostete Zone löschen. Dadurch wird sichergestellt, dass sich niemand die untergeordnete gehostete Zone aneignen kann, während die Nameserver für die untergeordnete gehostete Zone noch in DNS-Resolvern zwischengespeichert sind.
Wenn Sie die monatliche Gebühr für die gehostete Zone vermeiden möchten, können Sie den DNS-Dienst für die Domäne auf einen kostenlosen DNS-Dienst übertragen. Wenn Sie den DNS-Dienst übertragen, müssen Sie die Nameserver für die Domänenregistrierung aktualisieren. Wenn die Domäne bei Route 53 registriert ist, finden Sie unter [Hinzufügen oder Ändern der Nameserver und Glue-Datensätze in einer Domäne](domain-name-servers-glue-records.md) Informationen darüber, wie Sie Route 53-Nameserver durch Nameserver für den neuen DNS-Dienst ersetzen können. Wenn die Domäne mit einer anderen Vergabestellt registriert wurde, verwenden Sie die Methode der Vergabestelle, um Namensserver für die Domänenregistrierung zu aktualisieren. Weitere Informationen finden Sie über eine Internet-Suche nach „kostenloser DNS-Dienst“.
## Löschen von öffentlichen gehosteten Zonen, die von einem anderen Dienst erstellt wurden
Wenn eine gehostete Zone von einem anderen Dienst erstellt wurde, können Sie diese nicht mithilfe der Route 53-Konsole löschen. Stattdessen müssen Sie den entsprechenden Vorgang für den anderen Dienst verwenden:
+ **AWS Cloud Map**— Um eine gehostete Zone zu löschen, die bei der AWS Cloud Map Erstellung eines öffentlichen DNS-Namespace erstellt wurde, löschen Sie den Namespace. AWS Cloud Map löscht die gehostete Zone automatisch. Weitere Informationen finden Sie unter [Löschen von Namespaces](https://docs.aws.amazon.com/cloud-map/latest/dg/deleting-namespaces.html) im *AWS Cloud Map Entwicklerleitfaden*.
+ **Amazon Elastic Container Service (Amazon ECS) Service Discovery** - So löschen Sie eine öffentlich gehostete Zone, die Amazon ECS erstellt hat, als Sie einen Dienst mithilfe der Dienst-Erkennung erstellt haben, löschen Sie die Amazon-ECS-Dienste, die den Namespace verwenden und löschen Sie den Namespace. Weitere Informationen finden Sie unter [Angeben vertraulicher Daten](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/delete-service.html) im *Amazon Elastic Container Service-Entwicklerleitfaden*.
## Löschen einer öffentlichen gehosteten Zone mit der Route 53-Konsole.
Um die Route 53-Konsole zu verwenden, um eine öffentlich gehostete Zone zu löschen, führen Sie folgendes Verfahren durch.
**Löschen einer öffentlichen gehosteten Zone mit der Route 53-Konsole.**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Wählen Sie im Navigationsbereich **Gehostete Zonen** aus und wählen Sie den hervorgehobenen Link für die gehostete Zone aus, die Sie löschen möchten.
1. Vergewissern Sie sich, dass die gehostete Zone, die Sie löschen möchten, nur einen NS- und einen SOA-Datensatz enthält. Enthält sie zusätzliche Datensätze, löschen Sie diese. Sie müssen auch die DNSSEC-Signierung deaktivieren:
**Anmerkung**
Wenn Sie versuchen, die gehostete Zone zu löschen, ohne diese Anforderungen zu erfüllen, gibt Route 53 einen Fehler zurück:
Wenn die DNSSEC-Signatur aktiviert ist: Die angegebene Hosting-Zone enthält DNSSEC-Schlüssel zur Schlüsselsignatur und kann daher nicht gelöscht werden
Falls andere Ressourcendatensätze existieren (außer den standardmäßigen SOA- und NS-Datensätzen): Die angegebene Hosting-Zone enthält nicht erforderliche Ressourcendatensätze und kann daher nicht gelöscht werden
1. Klicken Sie auf der Detailseite für die gehostete Zone in der Liste **Records** (Datensätze), wenn die Liste der Datensätze irgendwelche Datensätze enthält, für die der Wert der Spalte **Type** (Typ) ein anderer ist als NS oder SOA, auf die entsprechende Zeile, und wählen Sie **Delete** (Löschen) aus.
Um mehrere aufeinander folgende Datensätze auszuwählen, wählen Sie die erste Zeile aus, halten Sie die **Umschalttaste** gedrückt, und klicken Sie dann auf die letzte Zeile. Um mehrere nicht aufeinander folgende Datensätze auszuwählen, wählen Sie die erste Zeile aus, halten Sie die **Strg-Taste** gedrückt, und klicken Sie dann auf die gewünschten Zeilen.
**Anmerkung**
Wenn Sie NS-Datensätze für Subdomänen in der gehosteten Zone erstellt haben, löschen Sie auch diese Datensätze.
1. Navigieren Sie zurück auf die Seite **Hosted Zones** (Gehostete Zonen) und wählen Sie die Zeile für die gehostete Zone aus, die Sie löschen möchten.
1. Wählen Sie **Löschen** aus.
1. Geben Sie den Bestätigungsschlüssel ein und wählen Sie **Delete (Löschen)** aus.
1. Wenn Sie möchten, dass die Domäne im Internet nicht verfügbar ist, empfehlen wir Ihnen, den DNS-Dienst auf einen kostenlosen DNS-Dienst zu übertragen und dann die in Route 53 gehostete Zone zu löschen. Dadurch wird verhindert, dass zukünftige DNS-Abfragen möglicherweise fehlgeleitet werden.
Wenn die Domäne bei Route 53 registriert ist, finden Sie unter [Hinzufügen oder Ändern der Nameserver und Glue-Datensätze in einer Domäne](domain-name-servers-glue-records.md) Informationen darüber, wie Sie Route 53-Nameserver durch Nameserver für den neuen DNS-Dienst ersetzen können. Wenn die Domäne mit einer anderen Vergabestellt registriert wurde, verwenden Sie die Methode der Vergabestelle, um Namensserver für die Domäne zu ändern.
**Anmerkung**
Wenn Sie eine gehostete Zone für eine Subdomäne (acme.example.com) löschen, müssen Sie keine Namensserver für die Domäne (example.com) ändern.
# Überprüfen der DNS-Antworten von Route 53
Wenn Sie eine gehostete Amazon Route 53-Zone für Ihre Domain erstellt haben, können Sie die DNS-Überprüfung in der Konsole verwenden, um zu sehen, wie Route 53 auf DNS-Abfragen antwortet, wenn Sie Ihre Domain so konfigurieren, dass sie Route 53 als DNS-Dienst verwendet. Für Daten zu Geolokalisierung, Geonähe und Latenz können Sie auch Abfragen von einer bestimmten and/or Client-IP-Adresse des DNS-Resolver-Clients simulieren, um herauszufinden, welche Antwort Route 53 zurückgeben würde.
**Wichtig**
Das Tool sendet keine Abfragen an das Domain Name System. Es antwortet nur basierend auf den Einstellungen in den Datensätzen in der gehosteten Zone. Das Tool gibt unabhängig davon, ob die gehostete Zone derzeit verwendet wird dieselben Informationen zurück, um Datenverkehr für die Domäne weiterzuleiten.
Die DNS-Überprüfung funktioniert nur bei öffentlichen gehosteten Zonen.
**Anmerkung**
Das DNS-Prüftool gibt ähnliche Informationen zurück wie im Antwortabschnitt des Befehls `dig`. Wenn Sie also die Namenserver einer Unterdomain abfragen, die auf die übergeordneten Namenserver verweisen, werden diese nicht zurückgegeben.
**Topics**
+ [Mit der Überprüfung die Antworten von Amazon Route 53 auf DNS-Abfragen anzeigen](#dns-test-how-route-53-responds)
+ [Verwendung der Überprüfung zur Simulation von Abfragen von spezifischen IP-Adressen (nur Datensätze für Geolokation und Latenz)](#dns-test-simulate-requests)
## Mit der Überprüfung die Antworten von Amazon Route 53 auf DNS-Abfragen anzeigen
Sie können das Tool verwenden, um zu sehen, welche Antwort Amazon Route 53 als Antwort auf eine DNS-Abfrage für einen Datensatz gibt.
**So sehen Sie anhand der Überprüfung, wie Route 53 auf DNS-Abfragen reagiert**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. Klicken Sie im Navigationsbereich auf **Hosted Zones**.
1. Wählen Sie auf der Seite **Hosted Zones (Gehostete Zonen)** den Namen der gehosteten Zone aus. Auf der Konsole wird die Liste der Datensätze für diese gehostete Zone angezeigt.
1. Um direkt zur Seite **Check response from Route 53** zu gelangen, wählen Sie **Test record set**.
1. Geben Sie die folgenden Werte an:
+ Der Name des Datensatzes, abgesehen vom Namen der gehosteten Zone. Um beispielsweise **www.example.com**, zu überprüfen, geben Sie **www** ein. Um **example.com** zu überprüfen, lassen Sie das Feld **Record name (Datensatzname)** leer.
+ Der Typ des Datensatzes, den Sie überprüfen möchten, z. B. **A** oder **CNAME**.
1. Wählen Sie **Get Response (Antwort abrufen)**.
1. Der Abschnitt **Response returned by Route 53** enthält die folgenden Werte:
**DNS-Antwortcode**
Ein Code, der angibt, ob die Abfrage gültig war oder nicht. Der gängigste Antwortcode ist **NOERROR** und bedeutet, dass die Abfrage gültig war. Wenn die Antwort nicht gültig ist, gibt Route 53 einen Antwortcode mit Erklärung aus. Eine Liste der möglichen Antwortcodes finden Sie unter [DNS RCODES](http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6) auf der IANA-Website.
**Protocol (Protokoll)**
Das Protokoll, das Amazon Route 53 für die Beantwortung einer Abfrage verwendet hat, entweder **UDP** oder **TCP**.
**Von Route 53 zurückgegebene Antwort**
Der Wert, den Route 53 an eine Webanwendung zurückgeben würde. Der Wert ist einer der folgenden:
+ Bei Nicht-Alias-Datensätzen enthält die Antwort den Wert oder die Werte im Datensatz.
+ Bei mehreren Datensätzen, die denselben Namen und Typ haben, der Gewichtung, Latenz, Geolokation und Failover beinhaltet, enthält die Antwort den Wert aus dem entsprechenden Datensatz und basierend auf der Anforderung.
+ Bei Aliaseinträgen, die auf andere AWS Ressourcen als einen anderen Datensatz verweisen, enthält die Antwort je nach AWS Ressourcentyp eine IP-Adresse oder einen Domänennamen für die Ressource.
+ Bei Alias-Datensätzen, die auf andere Datensätze verweisen, enthält die Antwort den/die Wert(e) aus dem referenzierten Datensatz.
## Verwendung der Überprüfung zur Simulation von Abfragen von spezifischen IP-Adressen (nur Datensätze für Geolokation und Latenz)
Wenn Sie Datensätze für Latenz oder Geolokation erstellt haben, können Sie das Überprüfungstool verwenden, um Abfragen von der IP-Adresse für einen DNS-Resolver und einen Client zu simulieren.
**So verwenden Sie die Überprüfung zur Simulation von Abfragen von angegebenen IP-Adressen**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Klicken Sie im Navigationsbereich auf **Hosted Zones**.
1. Wählen Sie auf der Seite **Hosted Zones (Gehostete Zonen)** den Namen der gehosteten Zone aus. Auf der Konsole wird die Liste der Datensätze für diese gehostete Zone angezeigt.
1. Um direkt zur Seite **Check response from Route 53** zu gelangen, wählen Sie **Test record set**.
Um zur Seite **Check response from Route 53** für einen bestimmten Datensatz zu gelangen, markieren Sie das Kontrollkästchen für den entsprechenden Datensatz, und wählen Sie dann **Test record set**.
1. Wenn Sie **Test record set (Datensatz testen)** ausgewählt haben, ohne vorher einen Datensatz auszuwählen, geben Sie die folgenden Werte an:
+ Der Name des Datensatzes, abgesehen vom Namen der gehosteten Zone. Um beispielsweise **www.example.com**, zu überprüfen, geben Sie **www** ein. Um **example.com** zu überprüfen, lassen Sie das Feld **Record name (Datensatzname)** leer.
+ Der Typ des Datensatzes, den Sie überprüfen möchten, z. B. **A** oder **CNAME**.
1. Geben Sie die anwendbaren Werte an:
**Resolver-IP-Adresse**
Geben Sie eine IPv4 IPv6 Oder-Adresse an, um den Standort des DNS-Resolvers zu simulieren, den ein Client für Anfragen verwendet. Dies ist für das Testen von Datensätzen für Latenz und Geolokation hilfreich. Wenn Sie diesen Wert weglassen, verwendet das Tool die IP-Adresse eines DNS-Resolvers in der Region AWS USA Ost (Nord-Virginia) (us-east-1).
**EDNS0 Client-Subnetz-IP**
Wenn der Resolver dies unterstützt EDNS0, geben Sie die Client-Subnetz-IP für eine IP-Adresse am entsprechenden geografischen Standort ein, z. B. **192.0.2.0** oder **2001:db** 8:85 a3: :8a2e: 370:7334.
**Subnetzmaske**
Wenn Sie eine IP-Adresse für die **EDNS0 Client-Subnetz-IP angeben, können Sie optional die Anzahl der Bits der IP-Adresse** angeben, die das Prüftool in die DNS-Abfrage aufnehmen soll. **Wenn Sie beispielsweise **192.0.2.44** für die **EDNS0 Client-Subnetz-IP und **24** für die **Subnetzmaske**** angeben, simuliert das Überprüfungstool eine Abfrage von 192.0.2.0/24.** Der Standardwert ist 24 Bit für Adressen und 64 Bit für Adressen. IPv4 IPv6
1. Wählen Sie **Get Response (Antwort abrufen)**.
1. Der Abschnitt **Response returned by Route 53** enthält die folgenden Werte:
**An Route 53 gesendete DNS-Abfrage**
Die Abfrage im [BIND format](https://en.wikipedia.org/wiki/Zone_file), welche die Überprüfung an Route 53 gesendet hat. Dies ist dasselbe Format, das eine Webanwendung zum Senden einer Abfrage verwenden würde. Diese drei Werte sind typischerweise der Name des Datensatzes, **IN** (für Internet) und der Typ des Datensatzes.
**DNS-Antwortcode**
Ein Code, der angibt, ob die Abfrage gültig war oder nicht. Der gängigste Antwortcode ist **NOERROR** und bedeutet, dass die Abfrage gültig war. Wenn die Antwort nicht gültig ist, gibt Route 53 einen Antwortcode mit Erklärung aus. Eine Liste der möglichen Antwortcodes finden Sie unter [DNS RCODES](http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6) auf der IANA-Website.
**Protocol (Protokoll)**
Das Protokoll, das Amazon Route 53 für die Beantwortung einer Abfrage verwendet hat, entweder **UDP** oder **TCP**.
**Von Route 53 zurückgegebene Antwort**
Der Wert, den Route 53 an eine Webanwendung zurückgeben würde. Der Wert ist einer der folgenden:
+ Bei Nicht-Alias-Datensätzen enthält die Antwort den Wert oder die Werte im Datensatz.
+ Bei mehreren Datensätzen, die denselben Namen und Typ haben, der Gewichtung, Latenz, Geolokation und Failover beinhaltet, enthält die Antwort den Wert aus dem entsprechenden Datensatz und basierend auf der Anforderung.
+ Bei Aliaseinträgen, die auf andere AWS Ressourcen als einen anderen Datensatz verweisen, enthält die Antwort je nach AWS Ressourcentyp eine IP-Adresse oder einen Domänennamen für die Ressource.
+ Bei Alias-Datensätzen, die auf andere Datensätze verweisen, enthält die Antwort den/die Wert(e) aus dem referenzierten Datensatz.
# Konfigurieren von White-Label-Nameservern
Jede gehostete Amazon Route 53-Zone ist mit vier Namenservern verknüpft, die zusammen als Delegierungsgruppe bezeichnet werden. Standardmäßig haben die Nameserver Namen wie ns-2048.awsdns-64.com. Wenn der Domänenname Ihrer Nameserver derselbe sein soll wie der Domänenname Ihrer gehosteten Zone, beispielsweise ns1.example.com, können Sie die White-Label-Nameserver (auch Vanity-Nameserver oder private Nameserver genannt) konfigurieren.
In den folgenden Schritten wird erläutert, wie Sie eine Gruppe von vier White-Label-Nameservern so konfigurieren, dass Sie sie für mehrere Domänen wiederverwenden können. Angenommen, Sie besitzen die Domänen example.com, example.org und example.net. Mit diesen Schritten können Sie White-Label-Nameserver für example.com konfigurieren und für example.org und example.net wiederverwenden.
**Topics**
+ [Schritt 1: Erstellen einer wiederverwendbaren Route 53-Delegierungsgruppe](#white-label-name-servers-create-reusable-delegation-set)
+ [Schritt 2: Erstellen oder Neuerstellen von gehosteten Amazon Route 53-Zonen und Ändern der TTL für NS- und SOA-Datensätze](#white-label-name-servers-create-hosted-zones)
+ [Schritt 3: Erneutes Erstellen von Datensätzen für Ihre gehosteten Zonen](#white-label-name-servers-create-resource-record-sets)
+ [Schritt 4: IP-Adressen abrufen](#white-label-name-servers-get-ip-addresses)
+ [Schritt 5: Erstellen von Datensätzen für White-Label-Nameserver](#white-label-name-servers-create-white-label-resource-record-sets)
+ [Schritt 6: Aktualisieren der NS- und SOA-Datensätze](#white-label-name-servers-update-ns-soa-records)
+ [Schritt 7: Erstellen und Ändern der Nameserver der Vergabestelle](#white-label-name-servers-create-glue-records)
+ [Schritt 8: Überwachen des Datenverkehrs für die Website oder Anwendung](#white-label-name-servers-monitor-traffic)
+ [Schritt 9: Kehren Sie zu den ursprünglichen Werten TTLs zurück](#white-label-name-servers-change-ttls-back)
+ [Schritt 10: Kontaktieren von rekursiven DNS-Dienstes (optional)](#white-label-name-servers-contact-recursive-dns-services)
## Schritt 1: Erstellen einer wiederverwendbaren Route 53-Delegierungsgruppe
White-Label-Name-Server sind einem wiederverwendbaren Route 53-Delegierungssatz zugeordnet. Sie können White-Label-Nameserver nur dann für eine gehostete Zone verwenden, wenn die gehostete Zone und der wiederverwendbare Delegierungssatz von demselben AWS Konto erstellt wurden.
Um einen wiederverwendbaren Delegierungssatz zu erstellen, können Sie die Route 53-API, die AWS CLI oder eine der folgenden verwenden AWS SDKs. Weitere Informationen finden Sie in der folgenden Dokumentation:
+ **Route 53-API** — Weitere Informationen finden Sie [CreateReusableDelegationSet](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateReusableDelegationSet.html)in der *Amazon Route 53-API-Referenz*
+ **AWS CLI** — siehe [create-reusable-delegation-set](https://docs.aws.amazon.com/cli/latest/reference/route53/create-reusable-delegation-set.html)in der *AWS CLI Befehlsreferenz*
+ **AWS SDKs**Die entsprechende SDK-Dokumentation finden Sie auf der [AWS Dokumentationsseite](https://docs.aws.amazon.com/)
## Schritt 2: Erstellen oder Neuerstellen von gehosteten Amazon Route 53-Zonen und Ändern der TTL für NS- und SOA-Datensätze
Erstellen oder Neuerstellen von Amazon Route 53-gehosteten Zonen:
+ **Wenn Sie Route 53 derzeit nicht als DNS-Dienst für die Domänen verwenden, für die Sie White-Label-Nameserver verwenden möchten** - Erstellen Sie die gehosteten Zonen und geben Sie für jede gehostete Zone die wiederverwendbare Delegierungsgruppe an, die Sie im vorherigen Schritt erstellt haben. Weitere Informationen finden Sie [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)in der *Amazon Route 53 API-Referenz*.
+ **Wenn Sie Route 53 derzeit als DNS-Dienst für die Domänen verwenden, für die Sie White-Label-Nameserver verwenden möchten** - Erstellen Sie die gehosteten Zonen, für die Sie White-Label-Nameserver verwenden möchten, neu, und geben Sie für jede gehostete Zone die wiederverwendbare Delegierungsgruppe an, die Sie im vorherigen Schritt erstellt haben.
**Wichtig**
Sie können die Nameserver, die mit einer vorhandenen gehosteten Zone verknüpft sind, nicht mehr ändern. Sie können eine wiederverwendbare Delegierungsgruppe nur dann mit einer gehosteten Zone verknüpfen, wenn Sie die gehostete Zone erstellen.
Beim Erstellen der gehosteten Zonen und bevor Sie auf die Ressourcen für die entsprechenden Domänen zugreifen, ändern Sie die folgenden TTL-Werte für jede gehostete Zone:
+ Ändern Sie die TTL für den NS-Datensatz für die gehostete Zone auf 60 Sekunden oder weniger.
+ Ändern Sie die Mindest-TTL für den SOA-Datensatz für die gehostete Zone auf 60 Sekunden oder weniger. Dies ist der letzte Wert im SOA-Datensatz.
Wenn Sie Ihrer Vergabestelle versehentlich die falschen IP-Adressen für Ihre White-Label-Nameserver gegeben haben, ist Ihre Website nicht mehr erreichbar und bleibt dies auch für die Dauer der TTL, nachdem Sie das Problem behoben haben. Wenn Sie eine kurze TTL einstellen, ist Ihre Website nur für entsprechend kürzere Zeit nicht verfügbar.
Weitere Informationen zum Erstellen von Hosting-Zonen und zur Angabe eines wiederverwendbaren Delegierungssatzes für die Nameserver für die Hosting-Zonen finden Sie [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)in der *Amazon Route 53 API-Referenz*.
## Schritt 3: Erneutes Erstellen von Datensätzen für Ihre gehosteten Zonen
Erstellen Sie Datensätze in den in Schritt 2 erstellten gehosteten Zonen:
+ **Beim Migrieren des DNS-Dienstes für Ihre Domäne zu Amazon Route 53** können Sie ggf. Datensätze durch Importieren von Informationen über Ihre vorhandenen Datensätze erstellen. Weitere Informationen finden Sie unter [Erstellen von Datensätzen durch Importieren einer Zonendatei](resource-record-sets-creating-import.md).
+ **Wenn Sie vorhandene gehostete Zonen austauschen, so dass Sie White Label-Nameserver verwenden können**, erstellen Sie in den neuen gehosteten Zonen die Datensätze neu, die in Ihren aktuellen gehosteten Zonen erscheinen. Route 53 bietet keine Methode zum Exportieren von Datensätzen aus einer gehosteten Zone; einige Drittanbietern bieten jedoch diese Möglichkeit. Anschließend können Sie mit dem Route 53-Importfeature Nicht-Alias-Datensätze importieren, für die die Routing-Richtlinie einfach ist. Es gibt keine Möglichkeit, Alias-Datensätze oder Datensätze, für die die Routing-Richtlinie nicht einfach ist, zu exportieren und erneut zu importieren.
Informationen zum Erstellen von Datensätzen mithilfe der Route 53-API finden Sie [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)in der *Amazon Route 53-API-Referenz*. Informationen zur Erstellung von Datensätzen mit der Route 53-Konsole finden Sie unter [Arbeiten mit Datensätzen](rrsets-working-with.md).
## Schritt 4: IP-Adressen abrufen
Rufen Sie die IPv6 Adressen IPv4 und Adressen der Nameserver im wiederverwendbaren Delegierungssatz ab und füllen Sie die folgende Tabelle aus.
****
| Der Name eines Nameservers in Ihrer wiederverwendbaren Delegierungsgruppe (Beispiel: Ns-2048.awsdns-64.com) | IPv4 und IPv6 Adressen | Name, den Sie dem White-Label-Nameserver zuweisen möchten (Beispiel: ns1.example.com) |
| --- | --- | --- |
| | IPv4: IPv6: | |
| | IPv4: IPv6: | |
| | IPv4: IPv6: | |
| | IPv4: IPv6: | |
Angenommen, die vier Nameserver für die wiederverwendbare Delegierungsgruppe sind:
+ ns-2048.awsdns-64.com
+ ns-2049.awsdns-65.net
+ ns-2050.awsdns-66.org
+ ns-2051.awsdns-67.co.uk
Hier sehen Sie die Linux- und Windows-Befehle, die Sie ausführen müssen, um die IP-Adressen für den ersten Ihrer vier Nameserver abzurufen:
**dig commands for Linux**
```
% dig A ns-2048.awsdns-64.com +short
192.0.2.117
```
```
% dig AAAA ns-2048.awsdns-64.com +short
2001:db8:85a3::8a2e:370:7334
```
**nslookup command for Windows**
```
c:\> nslookup ns-2048.awsdns-64.com
Non-authoritative answer:
Name: ns-2048.awsdns-64.com
Addresses: 2001:db8:85a3::8a2e:370:7334
192.0.2.117
```
## Schritt 5: Erstellen von Datensätzen für White-Label-Nameserver
Erstellen Sie in der gehosteten Zone mit demselben Namen (z. B. example.com) wie die Domäne des White-Label-Nameservers (z. B. ns1.example.com) acht Datensätze:
+ Einen Datensatz A für jeden White-Label-Nameserver
+ Einen Datensatz AAAA für jeden White-Label-Nameserver
**Wichtig**
Wenn Sie dieselben White-Label-Nameserver für zwei oder mehr gehostete Zonen verwenden, führen Sie diesen Schritt nicht für die anderen gehosteten Zonen aus.
Geben Sie für jeden Datensatz die folgenden Werte an. Weitere Informationen finden Sie in der Tabelle, die Sie im vorherigen Schritt ausgefüllt haben:
**Routing-Richtlinie**
Geben Sie **Einfaches Routing** an.
**Datensatzname**
Der Name, den Sie einem Ihrer White-Label-Nameserver zuweisen möchten (Beispiel: ns1.example.com). Für das Präfix (ns1 in diesem Beispiel) können Sie jeden beliebigen Wert verwenden, der in einem Domänennamen gültig ist.
**Bewerten/Weiterleiten des Datenverkehrs an**
Die IPv4 oder IPv6 Adresse eines der Route 53-Nameserver in Ihrem wiederverwendbaren Delegierungssatz.
Wenn Sie bei der Erstellung von Datensätzen für White-Label-Nameserver falsche IP-Adressen angeben, ist Ihre Website oder Webanwendung im Internet bei der Durchführung von nachfolgenden Schritten nicht mehr verfügbar. Auch wenn Sie die IP-Adressen sofort korrigieren, bleibt Ihre Website oder Webanwendung für die Dauer der TTL unerreichbar.
**Datensatztyp**
Geben Sie **A** an, wenn Sie Datensätze für die IPv4 Adressen erstellen.
Geben Sie **AAAA** an, wenn Sie Datensätze für die IPv6 Adressen erstellen.
**TTL (Sekunden)**
Dieser Wert ist die Dauer, für die DNS-Resolver die Informationen in diesem Datensatz im Cache speichern, bevor sie eine weitere DNS-Abfrage an Route 53 weiterleiten. Wir empfehlen, dass Sie einen Anfangswert von 60 Sekunden oder weniger festlegen, so dass Sie die Informationen schnell wiederherstellen können, wenn Sie versehentlich falsche Werte in diesen Datensätzen angeben.
## Schritt 6: Aktualisieren der NS- und SOA-Datensätze
Aktualisieren Sie SOA- und NS-Datensätze in den gehosteten Zonen, für die Sie White-Label-Nameserver verwenden möchten. Führen Sie Schritt 6 bis Schritt 8 jeweils für eine gehostete Zone und die entsprechende Domäne aus, nicht mehr, und wiederholen Sie anschließend diese Schritte für eine andere gehostete Zone und Domäne.
**Wichtig**
Beginnen Sie mit der gehosteten Amazon Route 53-Zone mit demselben Domainnamen (z. B. example.com) wie die White-Label-Nameserver (z. B. ns1.example.com).
1. Aktualisieren des SOA-Datensatzes durch Austauschen des Namens des Route 53-Namenservers durch den Namen eines White-Label-Nameservers
**Beispiel**
Ersetzen Sie den Namen des Route 53-Namensservers:
`ns-2048.awsdns-64.net. hostmaster.example.com. 1 7200 900 1209600 60`
durch den Namen eines Ihrer White-Label-Nameserver:
`ns1.example.com. hostmaster.example.com. 1 7200 900 1209600 60`
**Anmerkung**
Sie haben den letzten Wert, die TTL (Time to Live), unter [Schritt 2: Erstellen oder Neuerstellen von gehosteten Amazon Route 53-Zonen und Ändern der TTL für NS- und SOA-Datensätze](#white-label-name-servers-create-hosted-zones) geändert.
Informationen zur Aktualisierung von Datensätzen mit der Route 53-Konsole finden Sie unter [Bearbeiten von Datensätzen](resource-record-sets-editing.md).
1. Notieren Sie sich die Namen der aktuellen Nameserver für die Domäne im NS-Datensatz, sodass Sie diese Nameserver bei Bedarf wiederherstellen können.
1. Aktualisieren Sie den NS-Datensatz. Ersetzen Sie den Namen der Route 53-Nameservers durch die Namen Ihrer vier White-Label-Nameserver, beispielsweise `ns1.example.com`, `ns2.example.com`, `ns3.example.com` und `ns4.example.com`.
## Schritt 7: Erstellen und Ändern der Nameserver der Vergabestelle
Verwenden Sie die Methode der Vergabestelle zum Erstellen von Glue-Datensätzen, und ändern Sie die Nameserver der Vergabestelle:
1. Glue-Datensätze hinzufügen:
+ **Beim Aktualisieren der Domäne mit demselben Domänennamen wie die White-Label-Nameservee** - Erstellen Sie vier Glue-Datensätze, deren Namen und IP-Adressen den Werten entsprechen, die Sie in Schritt 4 abgerufen haben. Nehmen Sie IPv4 sowohl die als auch die IPv6 Adresse für einen White-Label-Nameserver in den entsprechenden Glue-Datensatz auf, zum Beispiel:
**ns1.example.com** - IP-Adressen = 192.0.2.117 und 2001:db8:85a3::8a2e:370:7334
Vergabestellen verwenden unterschiedliche Begriffe für Glue-Datensätze. Dieser Vorgang kann beispielsweise auch als das Registrieren neuer Namenserver oder ähnlich bezeichnet werden.
+ **Beim Aktualisieren einer weiteren Domäne** – Wenn Route 53 Ihr DNS-Dienst ist, müssen Sie zuerst den Schritt im vorherigen Aufzählungszeichen ausführen und die Glue-Datensätze erstellen, die mit dem Domainnamen übereinstimmen. Anschließend fahren Sie mit Schritt 2 in diesem Verfahren fort.
1. Ändern Sie die Nameserver für die Domäne auf die Namen Ihrer White-Label-Nameserver.
Siehe , wenn sie Amazon Route 53 als DNS-Dienst verwenden, siehe [Hinzufügen oder Ändern der Nameserver und Glue-Datensätze in einer Domäne](domain-name-servers-glue-records.md).
## Schritt 8: Überwachen des Datenverkehrs für die Website oder Anwendung
Überwachen Sie den Datenverkehr für die Website oder Anwendung, für die Sie in Schritt 7 den Glue-Datensatz erstellt und die Nameserver geändert haben:
+ **Wenn der Datenverkehr abbricht** - Verwenden Sie die Methode der Vergabestelle, um die Nameserver für die Domäne wieder in die vorherigen Route 53-Nameserver zu verwandeln. Hierbei handelt es sich um die Nameserver, die Sie in Schritt 6b notiert haben. Ergründen Sie anschließend, was schiefgelaufen ist.
+ **Wenn der Datenverkehr nicht betroffen ist** - Wiederholen Sie Schritt 6 bis 8 für die übrigen gehosteten Zonen, für die Sie dieselben White-Label-Nameserver verwenden möchten.
## Schritt 9: Kehren Sie zu den ursprünglichen Werten TTLs zurück
Ändern Sie für alle gehosteten Zonen, die nun White-Label-Nameserver verwenden, die folgenden Werte:
+ Ändern Sie die TTL für den NS-Datensatz für die gehostete Zone in einen typischen Wert für NS-Datensätze, z. B. 172800 Sekunden (zwei Tage).
+ Ändern Sie die Mindest-TTL für den SOA-Datensatz für die gehostete Zone in einen typischen Wert für SOA-Datensätze, z. B. 900 Sekunden. Dies ist der letzte Wert im SOA-Datensatz.
## Schritt 10: Kontaktieren von rekursiven DNS-Dienstes (optional)
*Optional* Wenn Sie Amazon Route 53 Geolocation Routing verwenden, wenden Sie sich an die rekursiven DNS-Dienste, die die edns-client-subnet Erweiterung von unterstützen EDNS0, und geben Sie ihnen die Namen Ihrer White-Label-Nameserver. Auf diese Weise wird sichergestellt, dass die DNS-Dienste basierend auf der ungefähren Geolokation, von der die Abfrage stammt, weiterhin DNS-Abfragen an den optimalen Route 53-Standort weiterleiten.
# NS- und SOA-Datensätze, die Amazon Route 53 für eine öffentliche gehostete Zone erstellt
Bei der Erstellung einer öffentlichen gehosteten Zone erstellt Amazon Route 53 automatisch einen NS-Eintrag (Namenserver) und einen SOA-Eintrag (Start of Authority, Autoritätsursprung) für die Zone. Sie müssen diese Datensätze selten ändern.
**Topics**
+ [Der Nameserver(NS)-Datensatz](#NSrecords)
+ [Der Start-of-Authority(SOA)-Datensatz](#SOArecords)
## Der Nameserver(NS)-Datensatz
Amazon Route 53 erstellt automatisch einen Namenserver-(NS)-Datensatz mit demselben Namen wie Ihre gehostete Zone. Es listet die vier Nameserver auf, welche die autoritativen Nameserver für Ihre gehostete Zone sind. Außer in seltenen Fällen empfehlen wir, in diesem Datensatz keine Nameserver hinzuzufügen, zu ändern oder zu löschen.
Die folgenden Beispiele zeigen das Format für die Namen von Route 53-Nameservern (diese Beispiele dienen einzig der Veranschaulichung und sind nicht für die Aktualisierung der NS-Datensätze Ihrer Vergabestellt zu verwenden):
+ *ns-2048.awsdns-64.com*
+ *ns-2049.awsdns-65.net*
+ *ns-2050.awsdns-66.org*
+ *ns-2051.awsdns-67.co.uk*
So rufen Sie die Liste der Nameserver für Ihre gehostete Zone ab:
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. Klicken Sie im Navigationsbereich auf **Hosted Zones (Gehostete Zonen)**.
1. Wählen Sie auf der Seite **Hosted Zones (Gehostete Zonen)** das Optionsfeld (nicht den Namen) für die gehostete Zone aus und wählen Sie dann **View Details (Details anzeigen)** aus.
1. Wählen Sie auf der Detailseite für die gehostete Zone **Hosted Zone details (Details der gehosteten Zone)** aus.
1. Notieren Sie sich die vier Namen, die für **Name Servers (Namenserver)** aufgelistet werden.
Weitere Informationen zur Migration des DNS-Dienst von einem anderen DNS-Dienstanbieter zu Route 53 finden Sie unter [Amazon Route 53 zum DNS-Dienst für eine vorhandene Domäne machenRoute 53 zum DNS-Dienst für eine vorhandene Domäne machen](MigratingDNS.md).
## Der Start-of-Authority(SOA)-Datensatz
Der State-of-Authority- bzw. SOA-Datensatz identifiziert die Basis-DNS-Informationen über die Domäne, zum Beispiel:
```
1. ns-2048.awsdns-64.net. hostmaster.example.com. 1 7200 900 1209600 86400
```
Ein SOA-Datensatz umfasst die folgenden Elemente:
+ Der Route 53-Nameserver, der den SOA-Datensatz erstellt hat, z. B. `ns-2048.awsdns-64.net`.
+ E-Mail-Adresse des Administrators Das Symbol `@` wird durch einen Punkt ersetzt, z. B. `hostmaster.example.com`. Der Standardwert ist ein amazon.com-E-Mail-Adresse, die nicht überwacht wird.
+ Eine Seriennummer, die Sie optional erhöhen können, wenn Sie einen Datensatz in der gehosteten Zone aktualisieren. erhöht den Wert nicht automatisch. Route 53 erhöht die Zahl nicht automatisch. (Die Seriennummer wird von DNS-Dienstes verwendet, die sekundäre DNS unterstützen.) In dem Beispiel lautet dieser Wert `1`.
+ Eine Aktualisierungszeit in Sekunden, die sekundäre DNS-Server warten, bevor sie den SOA-Datensatz des primären DNS-Servers abrufen, um auf Änderungen zu prüfen. In dem Beispiel lautet dieser Wert `7200`.
+ Das Intervall in Sekunden, das ein sekundärer Server bis zur Wiederholung einer fehlgeschlagenen Zonenübertragung abwartet. Normalerweise ist die Zeit bis zu einem Neuversuch kürzer als bis zu einer Aktualisierung. In dem Beispiel lautet dieser Wert `900` (15 Minuten).
+ Die Zeit in Sekunden, für die ein sekundärer Server versucht, eine Zonenübertragung abzuschließen. Wenn diese Zeit abgelaufen ist, bevor eine Zonenübertragung erfolgreich abgeschlossen werden konnte, beantwortet der sekundäre Server keine Abfragen mehr, da er seine Daten als zu alt einstuft, um noch zuverlässig zu sein. In dem Beispiel lautet dieser Wert `1209600` (zwei Wochen).
+ Die Mindest-TTL (Time-to-live). Dieser Wert hilft, die Zeitspanne zu definieren, aus der rekursive Resolver die folgenden Antworten von Route 53 zwischenspeichern sollten:
**NXDOMAIN**
Es gibt keinen Datensatz eines Typs mit dem Namen, der in der DNS-Abfrage angegeben ist, z. B. example.com. Es gibt auch keine Datensätze, die untergeordnete Elemente des Namens sind, der in der DNS-Abfrage angegeben ist, z. B. zenith.example.com.
**NODATA**
Es gibt mindestens einen Datensatz mit dem Namen, der in der DNS-Abfrage angegeben ist, aber keiner dieser Datensätze hat den Typ (z. B. A), der in der DNS-Abfrage angegeben ist.
Wenn ein DNS-Resolver eine NXDOMAIN oder NODATA-Antwort zwischenspeichert, wird dies als *Negative Caching*bezeichnet.
Die Dauer des Negative Caching ist kürzer als die folgenden Werte:
+ Dieser Wert — die Mindest-TTL im SOA-Datensatz. In dem Beispiel lautet der Wert `86400` (ein Tag).
+ Der TTL-Wert für den SOA-Datensatz. Der Standardwert beträgt 900 Sekunden. Weitere Informationen zum Ändern dieses Werts finden Sie unter [Bearbeiten von Datensätzen](resource-record-sets-editing.md).
Wenn Route 53 auf DNS-Abfragen mit einer NXDOMAIN- oder NODATA-Antwort antwortet (eine negative Antwort), wird Ihnen die Rate für Standardabfragen berechnet. (Siehe „Abfragen“ in [Amazon Route 53](https://aws.amazon.com/route53/pricing/). Wenn Sie Bedenken hinsichtlich der Kosten für negative Antworten haben, können Sie die TTL für den SOA-Datensatz, die minimale TTL im SOA-Datensatz (dieser Wert) oder beides ändern. Beachten Sie, dass eine Erhöhung dieser Werte TTLs, die sich auf negative Antworten für die gesamte Hosting-Zone beziehen, sowohl positive als auch negative Auswirkungen haben kann:
+ DNS-Resolver im Internet zwischenspeichern das Nichtvorhandensein von Datensätzen für längere Zeiträume, wodurch die Anzahl der Abfragen reduziert wird, die an Route 53 weitergeleitet werden. Dies reduziert die Route 53-Kosten für DNS-Abfragen.
+ Wenn Sie jedoch einen gültigen Datensatz fälschlicherweise löschen und ihn später neu erstellen, speichern DNS-Resolver die negative Antwort (dieser Datensatz existiert nicht) für einen längeren Zeitraum. Dadurch wird die Zeit verlängert, für die Ihre Kunden oder Benutzer die entsprechende Ressource nicht erreichen können, z. B. einen Webserver für acme.example.com.
**So finden Sie Ihre SOA-Datensätze in Route 53**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Klicken Sie im Navigationsbereich auf **Hosted Zones (Gehostete Zonen)**.
1. Wählen Sie den verknüpften Namen der Domäne aus, für die Sie Datensätze anzeigen möchten.
1. Im Abschnitt **Records** (Datensätze) können Sie alle aufgelisteten Datensätze anzeigen und die Datensätze auch filtern, um Ihren SOA-Wert zu finden.
# Aktivierung der beschleunigten Wiederherstellung für die Verwaltung öffentlicher DNS-Einträge
Route 53 Accelerated Recovery für die Verwaltung öffentlicher DNS-Einträge ist so konzipiert, dass ein 60-minütiges Recovery Time Objective (RTO) erreicht wird, falls der Dienst in der Region USA Ost (Nord-Virginia) nicht verfügbar ist. Wenn die Option für eine öffentlich gehostete Route 53-Zone aktiviert ist, können Sie innerhalb von etwa 60 Minuten wieder Änderungen an DNS-Einträgen in der öffentlich gehosteten Zone vornehmen, nachdem AWS festgestellt wurde, dass der Betrieb in der Region USA Ost (Nord-Virginia) beeinträchtigt ist.
**Wichtig**
Die beschleunigte Wiederherstellung ist nur für öffentlich gehostete Zonen verfügbar. Private gehostete Zonen werden nicht unterstützt.
**Anmerkung**
Die DNS-Abfrageauflösung auf der Route 53-Datenebene funktioniert auch bei Störungen des regionalen Dienstes normal. Unter [Resilienz in Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/disaster-recovery-resiliency.html) finden Sie Informationen zu den Vorgängen auf Datenebene und auf Kontrollebene.
**Topics**
+ [So funktioniert die beschleunigte Wiederherstellung von öffentlichen DNS-Einträgen](#accelerated-recovery-how-it-works)
+ [Erneutes Senden von DNS-Änderungen nach einem Failover](#accelerated-recovery-resubmit)
+ [Failback zur Region USA Ost (Nord-Virginia)](#accelerated-recovery-failback)
+ [Weitere Überlegungen](#accelerated-recovery-considerations)
+ [Wie aktiviert man eine beschleunigte Wiederherstellung für die Verwaltung öffentlicher DNS-Einträge](#accelerated-recovery-enable)
## So funktioniert die beschleunigte Wiederherstellung von öffentlichen DNS-Einträgen
Wenn die beschleunigte Wiederherstellung aktiviert ist, verwaltet Route 53 eine Kopie Ihrer öffentlich gehosteten Zone in der Region USA West (Oregon). Wenn Dienste in der Region USA Ost (Nord-Virginia) für einen längeren Zeitraum nicht verfügbar sind, führt Route 53 innerhalb von 60 Minuten einen Failover durch und leitet den Betrieb der Steuerungsebene für Ihre öffentlich gehosteten Zonen mit aktivierter beschleunigter Wiederherstellung automatisch in die Region USA West (Oregon) um. Sie können dann weiterhin programmgesteuert DNS-Änderungen über die CLI, das SDK und die API vornehmen. Beachten Sie, dass während des Failovers eine begrenzte Anzahl von API-Methoden verfügbar sein wird. Weitere Informationen finden Sie im Abschnitt „Zusätzliche Überlegungen“. Wenn sich die Region erholt, führt Route 53 das Failback-Verfahren durch und leitet den Betrieb der Kontrollebene automatisch zurück in die Region USA Ost (Nord-Virginia).
**Anmerkung**
Bevor die Region USA Ost (Nord-Virginia) beeinträchtigt wird, müssen Sie zunächst die beschleunigte Wiederherstellung für die Verwaltung öffentlicher DNS-Einträge in Ihrer öffentlich gehosteten Zone aktivieren. Dies kann über die Konsole, die CLI, das SDK oder die API erfolgen (weitere Informationen finden Sie im Abschnitt *So aktivieren Sie die beschleunigte Wiederherstellung für die Verwaltung öffentlicher DNS-Einträge* auf dieser Seite weiter unten). Sie können die beschleunigte Wiederherstellung nicht für die Verwaltung öffentlicher DNS-Einträge nach einem Failover aktivieren.
## Erneutes Senden von DNS-Änderungen nach einem Failover
Unter normalen Bedingungen werden Änderungen an öffentlich gehosteten Zonen mit aktivierter beschleunigter Wiederherstellung von der Region USA Ost (Nord-Virginia) akzeptiert und anschließend erfolgreich in die Region USA West (Oregon) repliziert. Wenn es jedoch in der Region USA Ost (Nord-Virginia) zu einer Betriebsunterbrechung kommt, werden einige Änderungen möglicherweise von der Region USA Ost (Nord-Virginia) akzeptiert, aber möglicherweise nicht in die Region USA West (Oregon) repliziert. Diese Änderungen während des Fluges werden als „gestrandete Änderungen“ bezeichnet. Sobald das Failover abgeschlossen ist, empfiehlt Route 53, dass Sie ungenutzte Änderungen erneut einreichen, bevor Sie Ihre DNS-Workflows wieder aufnehmen. Sie können dies entweder mithilfe der API oder mithilfe AWS CloudFormation der unten beschriebenen Methoden erreichen.
### Verwenden der API zum Verfolgen und Einreichen von DNS-Änderungen
Wenn Sie die Route 53-API, AWS CLI oder AWS SDKs zur Verwaltung von DNS-Einträgen verwenden, müssen Sie die [ChangeResourceRecordSets API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html) und die [GetChange API](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html) verwenden, um DNS-Änderungen einzureichen bzw. zu verfolgen.
Wenn Sie die ChangeResourceRecordSets API verwenden, um DNS-Änderungen vorzunehmen, gibt Route 53 eine Kennung (ID) für die von Ihnen vorgenommene Änderung zurück (Einzelheiten [ChangeInfo](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeInfo.html)zum Objekt der Änderungsantwort finden Sie unter). Sie können diese ID in einer nachfolgenden Anfrage an die GetChange API angeben und den Status der Änderung beobachten. DNS-Änderungen mit dem Status INSYNC wurden in die Region USA West (Oregon) repliziert und an alle Route 53-DNS-Server weitergegeben. Vor oder nach einem Failover müssen Sie keine weiteren Maßnahmen ergreifen, um diese Änderungen zu berücksichtigen. Während einer Beeinträchtigung der Region USA Ost (Nord-Virginia) kann es jedoch GetChange sein, dass der Status PENDING zurückgegeben wird, was darauf hindeutet, dass Ihre Änderung möglicherweise nicht in die Region USA West (Oregon) repliziert wurde. Wenn das der Fall ist, kehrt der Failover nach Abschluss des Failovers zurück, GetChange was darauf hinweist NoSuchChange, dass Route 53 diese DNS-Änderung nicht replizieren konnte. Daher können Sie nach einem Failover diese fehlgeschlagenen DNS-Änderungen getrost ignorieren und sie als neue DNS-Änderungen erneut einreichen. Sie werden wissen, dass der Failover-Prozess abgeschlossen ist, wenn Route 53 eine Nachricht an das AWS Health Dashboard sendet.
### Wird verwendet AWS CloudFormation , um Änderungen nachzuverfolgen und einzureichen
AWS CloudFormation verfolgt mithilfe der GetChange API automatisch den Replikationsstatus Ihrer DNS-Änderungen und schließt ein Update erst ab, wenn die DNS-Änderungen als INSYNC bestätigt wurden. Wenn Sie DNS-Einträge CloudFormation zur Verwaltung verwenden und die Region USA Ost (Nord-Virginia) nicht mehr verfügbar ist, können die Aktionen, die Sie verwenden, während des Zeitraums der Nichtverfügbarkeit nicht erfolgreich abgeschlossen CloudFormation werden. Sie können jedoch einfach dieselben Aktionen wiederholen, um DNS-Änderungen erneut einreichen CloudFormation zu können, sobald der Route 53-Failover-Prozess abgeschlossen ist.
## Failback zur Region USA Ost (Nord-Virginia)
Route 53 führt ein Failback für den Betrieb der Kontrollebene für Ihre öffentlich gehostete Zone auf die Region USA Ost (Nord-Virginia) durch, sobald sich die Region erholt hat. Während des Failbacks müssen Sie Ihre DNS-Änderungen nicht erneut einreichen, da bei diesem Vorgang keine Änderungen vorgenommen werden, die in der Vergangenheit gespeichert wurden.
## Weitere Überlegungen
Im Zusammenhang mit der Funktion zur beschleunigten Wiederherstellung sollten Sie einige zusätzliche Überlegungen beachten:
1. Sie können während eines Failovers keine neuen Hosting-Zonen erstellen, bestehende Hosting-Zonen löschen, die DNSSEC-Signatur aktivieren oder die DNSSEC-Signatur deaktivieren.
1. AWS PrivateLink Verbindungen funktionieren nach einem Failover nicht, funktionieren aber nach einem Failback in die Region USA Ost (Nord-Virginia) wieder.
1. [CloudFront Pauschalpläne](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/flat-rate-pricing-plan.html) werden derzeit nicht unterstützt.
1. Gehostete Zonen mit aktivierter beschleunigter Wiederherstellung können nicht gelöscht werden. Sie müssen die beschleunigte Wiederherstellung deaktivieren, bevor Sie versuchen, die gehostete Zone zu löschen.
1. Während eines Failovers werden die folgenden API-Methoden für öffentlich gehostete Zonen mit aktivierter beschleunigter Wiederherstellung weiterhin unterstützt. Alle anderen Route 53-API-Methoden funktionieren jedoch erst, wenn ein Failback auftritt.
+ `ChangeResourceRecordSets`
+ `GetChange`
+ `GetGeoLocation`
+ `GetHostedZone`
+ `GetHostedZoneCount`
+ `GetHostedZoneLimit`
+ `GetReusableDelegationSet`
+ `GetReusableDelegationSetLimit`
+ `ListGeoLocations`
+ `ListHostedZones`
+ `ListHostedZonesByName`
+ `ListResourceRecordSets`
+ `ListReusableDelegationSets`
## Wie aktiviert man eine beschleunigte Wiederherstellung für die Verwaltung öffentlicher DNS-Einträge
Sie können die beschleunigte Wiederherstellung für die Verwaltung öffentlicher DNS-Einträge mithilfe der Route 53-Konsole, API, CLI oder SDK aktivieren. Die Zeit, die benötigt wird, um die beschleunigte Wiederherstellung zu aktivieren, hängt von der Größe Ihrer öffentlich gehosteten Zone und anderen Faktoren ab. Sie sollten für die Aktivierung der beschleunigten Wiederherstellung mehrere Stunden einplanen. Sie können den Status des Aktivierungsprozesses auf der Registerkarte Beschleunigte Wiederherstellung in Ihrer öffentlich gehosteten Zone oder über die `GetHostedZone` API überprüfen. Nach Abschluss des Vorgangs wird es einen kurzen Zeitraum von bis zu mehreren Minuten geben, in dem DNS-Änderungen nicht akzeptiert werden. Sobald die DNS-Änderungen abgeschlossen sind, können sie wie gewohnt fortgesetzt werden.
**Um die beschleunigte Wiederherstellung mit der Route 53-Konsole zu aktivieren und zu deaktivieren**
1. Öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Klicken Sie im Navigationsbereich auf **Hosted Zones (Gehostete Zonen)**.
1. Wählen Sie die öffentlich gehostete Zone aus, für die Sie die beschleunigte Wiederherstellung aktivieren möchten.
1. Wählen Sie auf der Registerkarte **Beschleunigte Wiederherstellung** die Option **Aktivieren** aus.
1. Wählen Sie **Änderungen speichern ** aus.
1. Überwachen Sie den Status der gehosteten Zone. Der Status zeigt während der Installation **Enabling Accelerated Recovery** an und wechselt nach Abschluss zu **Aktiviert**.
Sie können die beschleunigte Wiederherstellung mit den oben genannten Schritten deaktivieren, aber stattdessen **Deaktivieren** wählen.
CLI-Beispiel zum Aktivieren
```
aws route53 update-hosted-zone-features --enable-accelerated-recovery --hosted-zone-id Z123456789
```
CLI-Beispiel zum Deaktivieren
```
aws route53 update-hosted-zone-features --no-enable-accelerated-recovery --hosted-zone-id Z123456789
```
# Arbeiten mit privat gehosteten Zonen
Eine *private gehostete Zone* ist ein Container, der Informationen darüber enthält, wie Amazon Route 53 auf DNS-Abfragen für eine Domain und deren Subdomains innerhalb einer oder mehrerer Domains antworten soll VPCs , die Sie mit dem Amazon VPC-Service erstellen. Privat gehostete Zonen funktionieren folgendermaßen:
1. Sie erstellen Sie eine privat gehostete Zone, z. B. example.com, und geben die VPC an, die Sie der gehosteten Zone zuordnen möchten. Nachdem Sie die gehostete Zone erstellt haben, können Sie ihr weitere VPCs zuordnen.
1. In der gehosteten Zone erstellen Sie Datensätze, die bestimmen, wie Route 53 DNS-Abfragen für Ihre Domäne und Subdomänen innerhalb und zwischen Ihren VPCs beantworten soll. Nehmen wir beispielsweise an, Sie haben einen Datenbankserver, der auf einer EC2-Instance in der VPC ausgeführt wird, die Sie der privat gehosteten Zone zugeordnet haben. Sie erstellen einen A- oder AAAA-Datensatz, wie z. B. db.example.com, und geben die IP-Adresse des Datenbankservers an.
Weitere Informationen über Einträge finden Sie unter [Arbeiten mit Datensätzen](rrsets-working-with.md). Weitere Informationen über die Amazon-VPC-Anforderungen für die Verwendung von privat gehosteten Zonen finden Sie unter [Verwenden von privat gehosteten Zonen](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-private-hosted-zones) im *Amazon-VPC-Benutzerhandbuch*.
1. Wenn eine Anwendung eine DNS-Abfrage für db.example.com sendet, gibt Route 53 die entsprechende IP-Adresse zurück. Um eine Antwort von einer privaten Hosting-Zone zu erhalten, müssen Sie außerdem eine EC2-Instance in einer der zugehörigen Instanzen ausführen VPCs (oder über einen eingehenden Endpunkt aus einem Hybrid-Setup verfügen). Wenn Sie versuchen, eine private gehostete Zone von außerhalb des VPCs oder Ihres Hybrid-Setups abzufragen, wird die Anfrage rekursiv im Internet gelöst.
1. Die Anwendung verwendet die IP-Adresse, die sie von Route 53 erhalten hat, um eine Verbindung mit dem Datenbankserver herzustellen.
Wenn Sie eine privat gehostete Zone erstellen, werden die folgenden Nameserver verwendet:
+ ns-0.awsdns-00.com
+ ns-512.awsdns-00.net
+ ns-1024.awsdns-00.org
+ ns-1536.awsdns-00.co.uk
Diese Nameserver werden verwendet, weil das DNS-Protokoll verlangt, dass für jede gehostete Zone ein Nameserver-Datensatz festgelegt werden muss. Diese Nameserver sind reserviert und werden nie von öffentlich gehosteten Route-53-Zonen verwendet. Sie können diese Zonen nur über VPC Resolver in einer VPC abfragen, die der gehosteten Zone zugeordnet wurde, indem Sie einen eingehenden Endpunkt verwenden, der mit der in der privaten gehosteten Zone VPCs angegebenen Verbindung verbunden ist.
Während die Nameserver im Internet sichtbar sind, stellt VPC Resolver keine Verbindung zu den Nameserveradressen her. Außerdem werden die Informationen zur privaten gehosteten Zone nicht zurückgegeben, wenn Sie die Nameserver direkt über das Internet abfragen. Stattdessen erkennt der VPC-Resolver, dass sich Abfragen innerhalb eines privaten Namespaces befinden, der auf Verbindungen zwischen VPC und gehosteten Zonen basiert, und verwendet direkte, private Konnektivität, um die privaten DNS-Server zu erreichen.
**Anmerkung**
Sie können den Nameserver-Datensatz in einer privaten gehosteten Zone ändern, wenn Sie möchten, und die private DNS-Auflösung wird weiterhin funktionieren. Wir raten davon ab, aber wenn Sie sich dafür entscheiden, sollten Sie reservierte Domänennamen verwenden, die nicht von öffentlichen DNS-Servern verwendet werden.
Wenn Sie Datenverkehr an Ihre Domäne im Internet weiterleiten wollen, können Sie eine *öffentliche* von Route 53 gehostete Zone verwenden. Weitere Informationen finden Sie unter [Arbeiten mit öffentlichen gehosteten Zonen](AboutHZWorkingWith.md).
**Topics**
+ [Überlegungen zum Arbeiten mit einer privaten gehosteten Zone](hosted-zone-private-considerations.md)
+ [Erstellen einer privat gehosteten Zone](hosted-zone-private-creating.md)
+ [Auflisten der privaten gehosteten Zonen](hosted-zone-private-listing.md)
+ [Einer privaten VPCs Hosting-Zone mehr zuordnen](hosted-zone-private-associate-vpcs.md)
+ [Zuordnen einer Amazon VPC und einer privaten gehosteten Zone, die Sie mit verschiedenen Konten erstellt haben AWS](hosted-zone-private-associate-vpcs-different-accounts.md)
+ [Trennung von einer privaten VPCs gehosteten Zone](hosted-zone-private-disassociate-vpcs.md)
+ [Löschen einer privaten gehosteten Zone](hosted-zone-private-deleting.md)
+ [VPC-Berechtigungen](hosted-zone-private-vpc-permissions.md)
# Überlegungen zum Arbeiten mit einer privaten gehosteten Zone
Beachten Sie die folgenden Überlegungen zur Verwendung von privaten gehosteten Zonen.
+ [Amazon VPC settings](#hosted-zone-private-considerations-vpc-settings)
+ [Route 53 health checks](#hosted-zone-private-considerations-health-checks)
+ [Supported routing policies for records in a private hosted zone](#hosted-zone-private-considerations-routing-policies)
+ [Split-view DNS](#hosted-zone-private-considerations-split-view-dns)
+ [Public and private hosted zones that have overlapping namespaces](#hosted-zone-private-considerations-public-private-overlapping)
+ [Private hosted zones that have overlapping namespaces](#hosted-zone-private-considerations-private-overlapping)
+ [Private hosted zones and Route 53 VPC Resolver rules](#hosted-zone-private-considerations-resolver-rules)
+ [Delegating responsibility for a subdomain](#hosted-zone-private-considerations-delegating-subdomain)
+ [Custom DNS servers](#hosted-zone-private-considerations-custom-dns)
+ [Required IAM permissions](#hosted-zone-private-considerations-required-permissions)
**Amazon VPC-Einstellungen**
Zur Verwendung von privat gehosteten Zonen müssen Sie die folgenden Amazon-VPC-Einstellungen auf `true` setzen:
+ `enableDnsHostnames`
+ `enableDnsSupport`
Weitere Informationen finden Sie unter [DNS-Attribute für Ihre VPC anzeigen und aktualisieren](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns-updating.html) im *Amazon VPC-Benutzerhandbuch*.
**Route 53 Zustandsprüfungen**
In einer privat gehosteten Zone können Sie Route 53-Zustandsprüfungen nur mit Failover-, mehrwertigen Antworten-, Gewichtungs-, Latenz-, Geolokalisierungs- und Geoproximitätsdatensätzen verknüpfen. Weitere Informationen zum Zuordnen von Zustandsprüfungen zu Failover-Datensätzen finden Sie unter [Konfigurieren von Failover in einer privaten gehosteten Zone](dns-failover-private-hosted-zones.md).
**Unterstützte Routing-Richtlinien für Datensätze in einer privaten gehosteten Zone**
Sie können die folgenden Routing-Richtlinien verwenden, wenn Sie Datensätze in einer privat gehosteten Zone erstellen:
+ [Einfaches Routing](routing-policy-simple.md)
+ [Failover-Routing](routing-policy-failover.md)
+ [Mehrwertiges Antwort-Routing](routing-policy-multivalue.md)
+ [Gewichtetes Routing](routing-policy-weighted.md)
+ [Latenzbasiertes Routing](routing-policy-latency.md)
+ [Geolocation-Routing](routing-policy-geo.md)
+ [Geoproximity-Routing](routing-policy-geoproximity.md)
Sie können keine Datensätze in einer privat gehosteten Zone mit anderen Routing-Richtlinien erstellen.
**Split-View-DNS**
Sie können Route 53 verwenden, um Split-View-DNS (auch als Split-Horizon-DNS bekannt) zu konfigurieren. In Split-View-DNS verwenden Sie denselben Domänennamen (example.com) für interne Zwecke (accounting.example.com) und externe Zwecke, z. B. für Ihre öffentliche Website (www.example.com). Sie können auch denselben Subdomänennamen intern und extern verwenden, aber unterschiedliche Inhalte bereitstellen oder eine unterschiedliche Authentifizierung für interne und externe Benutzer erfordern.
Um Split-View-DNS zu konfigurieren, führen Sie die folgenden Schritte aus:
1. Erstellen Sie öffentliche und private gehostete Zonen mit demselben Namen. (Split-View-DNS funktioniert auch weiterhin, wenn Sie einen anderen DNS-Service für die öffentliche gehostete Zone verwenden.)
1. Ordnen Sie der privaten VPCs Hosting-Zone ein oder mehrere Amazon zu. Route 53 VPC Resolver verwendet die private gehostete Zone, um DNS-Abfragen in der angegebenen Zone weiterzuleiten. VPCs
1. Erstellen Sie Datensätze in jeder gehosteten Zone. Aufzeichnungen in der öffentlich gehosteten Zone steuern, wie der Internetverkehr weitergeleitet wird, und Aufzeichnungen in der privaten gehosteten Zone steuern, wie der Verkehr in Ihrem Amazon weitergeleitet wird. VPCs
Wenn Sie die Namensauflösung sowohl für Ihre VPC- als auch für Ihre lokalen Workloads durchführen müssen, können Sie Route 53 VPC Resolver verwenden. Weitere Informationen finden Sie unter [Was ist Route 53 VPC Resolver?](resolver.md).
**Öffentliche und private gehostete Zonen mit überlappenden Namespaces**
Wenn Sie private und öffentliche Hosting-Zonen mit sich überschneidenden Namespaces haben, z. B. example.com und accounting.example.com, leitet VPC Resolver den Verkehr auf der Grundlage der genauesten Übereinstimmung weiter. Wenn Benutzer bei einer EC2-Instance in einer Amazon VPC angemeldet sind, die Sie der privaten Hosting-Zone zugeordnet haben, verarbeitet Route 53 VPC Resolver DNS-Abfragen wie folgt:
1. VPC Resolver bewertet, ob der Name der privaten gehosteten Zone mit dem Domainnamen in der Anfrage übereinstimmt, z. B. accounting.example.com. Eine Übereinstimmung wird wie folgt definiert (entweder/oder):
+ Eine identische Übereinstimmung
+ Der Name der privat gehosteten Zone ist ein übergeordneter Domänenname in der Anforderung. Angenommen, der Domänenname in der Anforderung lautet wie folgt:
**seattle.finanzen.beispiel.com**
Die folgenden gehosteten Zonen stimmen überein, da sie "seattle.finanzen.beispiel.com" übergeordnet sind:
+ **finanzen.beispiel.com**
+ **example.com**
Wenn es keine passende private gehostete Zone gibt, leitet VPC Resolver die Anfrage an einen öffentlichen DNS-Resolver weiter, und Ihre Anfrage wird als reguläre DNS-Anfrage gelöst.
1. Wenn es eine privat gehostete Zone gibt, die dem Domänennamen in der Anforderung entspricht, wird die gehostete Zone nach einem Datensatz durchsucht, der dem Domänennamen und dem DNS-Datensatz in der Anforderung entspricht, z. B. ein A-Datensatz für „accounting.example.com“.
**Anmerkung**
Wenn es eine passende private gehostete Zone gibt, aber kein Datensatz vorhanden ist, der dem Domainnamen und dem Typ der Anfrage entspricht, leitet VPC Resolver die Anfrage nicht an einen öffentlichen DNS-Resolver weiter. Stattdessen wird NXDOMAIN (nicht existierende Domäne) an den Client zurückgegeben.
**Öffentliche und private gehostete Zonen mit überlappenden Namespaces**
Wenn Sie über zwei oder mehr privat gehostete Zonen mit überlappenden Namespaces verfügen, z. B. example.com und accounting.example.com, leitet VPC Resolver den Verkehr auf der Grundlage der genauesten Übereinstimmung weiter.
Wenn Sie über eine private gehostete Zone (example.com) und eine Route 53 53-VPC-Resolver-Regel verfügen, die den Datenverkehr für denselben Domainnamen an Ihr Netzwerk weiterleitet, hat die VPC-Resolver-Regel Vorrang. Siehe [Private hosted zones and Route 53 VPC Resolver rules](#hosted-zone-private-considerations-resolver-rules).
Wenn Benutzer bei einer EC2-Instance in einer Amazon VPC angemeldet sind, die Sie mit allen privaten Hosting-Zonen verknüpft haben, behandelt VPC Resolver DNS-Abfragen wie folgt:
1. VPC Resolver bewertet, ob der Domainname in der Anfrage, z. B. accounting.example.com, mit dem Namen einer der privaten gehosteten Zonen übereinstimmt.
1. Wenn es keine gehostete Zone gibt, die genau mit dem Domainnamen in der Anfrage übereinstimmt, sucht VPC Resolver nach einer gehosteten Zone, deren Name dem Domainnamen in der Anfrage übergeordnet ist. Angenommen, der Domänenname in der Anforderung lautet wie folgt:
`seattle.accounting.example.com`
Die folgenden gehosteten Zonen stimmen überein, weil sie übergeordnete Zonen von `seattle.accounting.example.com` sind:
+ `accounting.example.com`
+ `example.com`
VPC Resolver wählt`accounting.example.com`, weil es spezifischer ist als. `example.com`
1. VPC Resolver durchsucht die `accounting.example.com` gehostete Zone nach einem Datensatz, der dem Domainnamen und dem DNS-Typ in der Anfrage entspricht, z. B. einem A-Eintrag für. `seattle.accounting.example.com`
Wenn es keinen Datensatz gibt, der mit dem Domainnamen und dem Typ der Anfrage übereinstimmt, gibt VPC Resolver NXDOMAIN (nicht existierende Domäne) an den Client zurück.
**Private gehostete Zonen und Route 53 VPC Resolver-Regeln**
Wenn Sie über eine private gehostete Zone (example.com) und eine VPC-Resolver-Regel verfügen, die den Datenverkehr für denselben Domainnamen an Ihr Netzwerk weiterleitet, hat die VPC-Resolver-Regel Vorrang.
Angenommen, folgende Konfiguration liegt vor:
+ Sie haben eine private gehostete Zone namens example.com und verknüpfen sie mit einer VPC.
+ Sie erstellen eine Route 53 VPC Resolver-Regel, die den Datenverkehr für example.com an Ihr Netzwerk weiterleitet, und ordnen die Regel derselben VPC zu.
In dieser Konfiguration hat die VPC-Resolver-Regel Vorrang vor der privaten Hosting-Zone. DNS-Abfragen werden an Ihr Netzwerk weitergeleitet, anstatt basierend auf den Datensätzen in der privaten gehosteten Zone aufgelöst zu werden.
**Delegieren der Verantwortlichkeit für eine Subdomäne**
Sie können jetzt NS-Einträge in einer privaten Hosting-Zone erstellen, um die Verantwortung für eine Subdomain zu delegieren. Weitere Informationen finden Sie unter [Tutorial zu Resolver-Delegierungsregeln](outbound-delegation-tutorial.md).
**Benutzerdefinierte DNS-Server**
Wenn Sie benutzerdefinierte DNS-Server auf den Amazon-EC2-Instances in Ihrer VPC konfiguriert haben, müssen Sie diese DNS-Server so konfigurieren, dass Ihre privaten DNS-Abfragen an die IP-Adresse der von Amazon bereitgestellten DNS-Server für Ihre VPC weitergeleitet werden. Diese IP-Adresse ist die IP-Adresse an der Basis der VPC-Netzwerkbereichs "plus zwei". Wenn beispielsweise den CIDR-Bereich für Ihre VPC 10.0.0.0/16 lautet, ist die IP-Adresse des DNS-Servers 10.0.0.2.
Wenn Sie DNS-Abfragen zwischen VPCs und Ihrem Netzwerk weiterleiten möchten, können Sie VPC Resolver verwenden. Weitere Informationen finden Sie unter [Was ist Route 53 VPC Resolver?](resolver.md).
**Erforderliche IAM-Berechtigungen**
Zum Erstellen von privat gehosteten Zonen müssen Sie IAM-Berechtigungen für Amazon EC2-Aktionen zusätzlich zu den Berechtigungen für Route 53-Aktionen gewähren. Weitere Informationen finden Sie unter [Aktionen, Ressourcen und Bedingungsschlüssel für Route 53](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonroute53.html) in der *Service-Autorisierungs-Referenz*.
# Erstellen einer privat gehosteten Zone
Eine privat gehostete Zone ist ein Container für Datensätze für eine Domain, die Sie in einer oder mehreren Amazon Virtual Private Clouds (VPCs) hosten. Sie erstellen eine Hosting-Zone für eine Domain (z. B. example.com) und erstellen dann Datensätze, um Amazon Route 53 mitzuteilen, wie der Traffic für diese Domain innerhalb und zwischen Ihren weitergeleitet werden soll. VPCs
**Wichtig**
Wenn Sie eine privat gehostete Zone erstellen, müssen Sie eine VPC mit der gehosteten Zone verknüpfen, und die angegebene VPC muss mit demselben Konto erstellt worden sein, indem Sie die gehostete Zone erstellt haben. Nachdem Sie die Hosting-Zone erstellt haben, können Sie ihr weitere zuordnen, einschließlich der Zone, VPCs die Sie VPCs mit einem anderen AWS Konto erstellt haben.
Um VPCs das, was Sie mit einem Konto erstellt haben, einer privaten gehosteten Zone zuzuordnen, die Sie mit einem anderen Konto erstellt haben, müssen Sie die Zuordnung autorisieren und dann die Zuordnung programmgesteuert vornehmen. Weitere Informationen finden Sie unter [Zuordnen einer Amazon VPC und einer privaten gehosteten Zone, die Sie mit verschiedenen Konten erstellt haben AWS](hosted-zone-private-associate-vpcs-different-accounts.md).
Informationen zur Verwendung von privat gehosteten Zonen durch die Route 53-API finden Sie unter [Amazon-Route 53-API-Referenz](https://docs.aws.amazon.com/Route53/latest/APIReference/).
**So erstellen Sie eine privat gehostete Zone mit der Route 53-Konsole**
1. Für jede VPC, die Sie der gehosteten Route 53-Zone zuordnen möchten, ändern Sie die folgenden VPC-Einstellungen in `true`:
+ `enableDnsHostnames`
+ `enableDnsSupport`
Weitere Informationen finden Sie unter [Anzeigen und Aktualisieren der DNS-Unterstützung für Ihre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) im *Amazon-VPC-Benutzerhandbuch*.
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. Wenn Sie noch keine Erfahrung mit Route 53 haben, wählen Sie **Get Started (Erste Schritte)** aus.
Wenn Sie Route 53 bereits nutzen, wählen Sie **Hosted zones** im Navigationsbereich aus.
1. Wählen Sie **Create Hosted Zone (Gehostete Zone erstellen)**.
1. Geben Sie im Bereich **Create Private Hosted Zone (Privat gehostete Zone erstellen)** einen Domänennamen und optional einen Kommentar ein.
Erläuterungen dazu, wie Sie andere Zeichen als a-z, 0-9 und - (Bindestrich) eingeben und wie internationale Domainnamen angegeben werden, erhalten Sie unter [Format für DNS-Domänennamen](DomainNameFormat.md).
1. Wählen Sie in der Liste **Type (Typ)** die Option **Private Hosted Zone for ** (Privat gehostete Zone für VPC) aus.
1. Wählen Sie in der Liste **VPC ID** die VPC aus, die Sie der gehosteten Zone zuordnen möchten.
**Anmerkung**
Wenn die Konsole die folgende Meldung anzeigt: Sie versuchen eine gehostete Zone zu verknüpfen, die denselben Namespace wie der einer anderen gehosteten Zone innerhalb derselben VPC verwendet:
"Eine in Konflikt stehende Domäne wurde bereits dieser VPC oder dem Delegierungssatz zugeordnet."
Wenn beispielsweise die gehostete Zone A und die gehostete Zone B denselben Domänennamen, beispielsweise `example.com`, haben, können Sie nicht beide gehosteten Zonen derselben VPC zuordnen.
1. Wählen Sie **Create Hosted Zone (Gehostete Zone erstellen)**.
# Auflisten der privaten gehosteten Zonen
Sie können die Amazon Route 53-Konsole verwenden, um alle Hosting-Zonen aufzulisten, die Sie mit dem aktuellen AWS Konto erstellt haben. Informationen zum Auflisten von Hosting-Zonen mithilfe der Route 53-API finden Sie [ListHostedZones](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZones.html)in der *Amazon Route 53-API-Referenz*.
**Um die Hosting-Zonen aufzulisten, die einem AWS Konto zugeordnet sind**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Klicken Sie im Navigationsbereich auf **Hosted Zones (Gehostete Zonen)**.
Auf der Seite „**Gehostete Zonen**“ wird automatisch eine Liste aller Hosting-Zonen angezeigt, die mit dem aktuellen AWS Konto erstellt wurden. Die Spalte **Type** gibt an, ob eine gehostete Zone privat oder öffentlich ist. Wählen Sie die Spaltenüberschrift aus, um alle privat gehosteten Zonen und alle öffentlich gehosteten Zonen zu gruppieren.
# Einer privaten VPCs Hosting-Zone mehr zuordnen
Sie können die Amazon Route 53-Konsole verwenden, um mehr VPCs mit einer privaten gehosteten Zone zu verknüpfen, wenn Sie die gehostete Zone erstellt haben und dann dasselbe AWS Konto verwenden. VPCs
**Wichtig**
Wenn Sie VPCs das, was Sie mit einem Konto erstellt haben, einer privaten gehosteten Zone zuordnen möchten, die Sie mit einem anderen Konto erstellt haben, müssen Sie die Zuordnung zuerst autorisieren. Darüber hinaus können Sie die AWS Konsole weder verwenden, um die Zuordnung zu autorisieren noch sie VPCs mit der Hosting-Zone zu verknüpfen. Weitere Informationen finden Sie unter [Zuordnen einer Amazon VPC und einer privaten gehosteten Zone, die Sie mit verschiedenen Konten erstellt haben AWS](hosted-zone-private-associate-vpcs-different-accounts.md).
Informationen darüber, wie Sie mithilfe der Route 53-API mehr VPCs mit einer privaten gehosteten Zone verknüpfen können, finden Sie unter [Associate VPCWith HostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html) in der *Amazon Route 53-API-Referenz*.
**So können Sie mithilfe der Route 53-Konsole zusätzliche VPCs Verbindungen zu einer privaten gehosteten Zone herstellen**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Klicken Sie im Navigationsbereich auf **Hosted Zones (Gehostete Zonen)**.
1. Wählen Sie das Optionsfeld für die private gehostete Zone aus, der Sie mehr VPCs zuordnen möchten.
1. Wählen Sie **Bearbeiten** aus.
1. Klicken Sie auf **Add VPC (VPC hinzufügen)**.
1. Wählen Sie die Region aus, in der Sie die VPC erstellt haben, die Sie dieser gehosteten Zone zuordnen möchten.
1. Um dieser VPCs Hosting-Zone mehr zuzuordnen, wiederholen Sie die Schritte 5 und 6.
1. Wählen Sie **Änderungen speichern ** aus.
# Zuordnen einer Amazon VPC und einer privaten gehosteten Zone, die Sie mit verschiedenen Konten erstellt haben AWS
Wenn Sie eine VPC, die Sie mit einem AWS Konto erstellt haben, einer privaten gehosteten Zone zuordnen möchten, die Sie mit einem anderen Konto erstellt haben, gehen Sie wie folgt vor:
**Um eine Amazon-VPC und eine private gehostete Zone, die Sie erstellt haben, mit verschiedenen AWS Konten zu verknüpfen**
1. Autorisieren Sie mit dem Konto, das die gehostete Zone erstellt hat, die Verknüpfung der VPC mit der privat gehosteten Zone mithilfe einer der folgenden Methoden:
+ **AWS CLI**— Weitere Informationen finden Sie [create-vpc-association-authorization](https://docs.aws.amazon.com/cli/latest/reference/route53/create-vpc-association-authorization.html)in der *AWS CLI Befehlsreferenz*
+ ** AWS SDK** oder **AWS Tools for Windows PowerShell**— Die entsprechende Dokumentation finden Sie auf der [AWS Dokumentationsseite](https://docs.aws.amazon.com/)
+ **Amazon Route 53-API** — siehe [VPCAssociationAutorisierung erstellen](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateVPCAssociationAuthorization.html) in der *Amazon Route 53-API-Referenz*
Beachten Sie Folgendes:
+ Wenn Sie mehrere VPCs , die Sie mit einem Konto erstellt haben, einer gehosteten Zone zuordnen möchten, die Sie mit einem anderen Konto erstellt haben, müssen Sie für jede VPC eine Autorisierungsanfrage einreichen.
+ Wenn Sie die Verknüpfung autorisieren, müssen Sie die gehostete Zonen-ID angeben, daher muss die privat gehostete Zone bereits vorhanden sein.
+ Sie können die Route 53-Konsole nicht verwenden, um die Verknüpfung einer VPC mit einer privat gehosteten Zone zu autorisieren oder um die Verknüpfung durchzuführen.
1. Verwenden Sie das Konto, mit dem Sie die VPC erstellt haben, um die VPC mit der gehosteten Zone zu verknüpfen. Wie bei der Autorisierung der Zuordnung können Sie das AWS SDK, Tools for Windows PowerShell AWS CLI, die oder die Route 53-API verwenden. Wenn Sie die API verwenden, verwenden Sie die VPCWith HostedZone Aktion [Zuordnen](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html).
1. *Empfohlen* - Löschen Sie die Autorisierung für die Verknüpfung der VPC mit der gehosteten Zone. Das Löschen der Autorisierung wirkt sich nicht auf die Verknüpfung aus, sondern verhindert nur, dass Sie die VPC künftig erneut mit der gehosteten Zone verknüpfen. Wenn Sie die gehostete Zone erneut mit der VPC verknüpfen möchten, müssen Sie die Schritte 1 und 2 dieses Verfahrens wiederholen.
**Wichtig**
Die `ListHostedZonesByVPC` gibt die gehosteten Zonen zurück, wenn eine VPC vorhanden ist, und die `GetHostedZone` API gibt die der Hosting-Zone VPCs zugeordnete Zone zurück. Diese berücksichtigen APIs nur die Zuordnung zwischen gehosteter Zone und VPC, die über die `AssociateVPCWithHostedZone` API oder bei der Erstellung der privaten gehosteten Zone erstellt wurde. Wenn Sie eine vollständige Liste der Hosting-Zonenzuordnungen zu einer VPC wünschen, rufen Sie auch an [ListProfileResourceAssociations](https://docs.aws.amazon.com/Route53/latest/APIReference/API_route53profiles_ListProfileResourceAssociations.html).
**Anmerkung**
Informationen zur maximalen Anzahl der Autorisierungen, die Sie erstellen können, finden Sie unter [Kontingente für Entitäten](DNSLimitations.md#limits-api-entities).
# Trennung von einer privaten VPCs gehosteten Zone
Sie können die Amazon Route 53-Konsole verwenden, um die Verbindung zu einer privaten gehosteten Zone zu trennen VPCs . Dies veranlasst Route 53, die Weiterleitung von Datenverkehr unter Verwendung von Datensätzen in der gehosteten Zone für DNS-Abfragen, die aus der VPC stammen, zu beenden. Wenn beispielsweise die gehostete Zone example.com mit einer VPC verknüpft ist und Sie die Verknüpfung der gehosteten Zone von dieser VPC aufheben, stellt Route 53 die Auflösung von DNS-Abfragen für example.com oder einen der anderen Datensätze in der gehosteten Zone example.com ein.
**Anmerkung**
Sie können die Zuordnung der letzten VPC zu einer privaten gehosteten Zone nicht aufheben. Wenn Sie die Verknüpfung von dieser VPC aufheben möchten, müssen Sie der gehosteten Zone zunächst eine andere VPC zuordnen.
**Um die Verbindung zu einer privaten VPCs Hosting-Zone zu trennen**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Klicken Sie im Navigationsbereich auf **Hosted Zones (Gehostete Zonen)**.
1. Wählen Sie das Optionsfeld für die private gehostete Zone VPCs aus, zu der Sie die Verbindung zu einer oder mehreren Zonen trennen möchten.
1. Wählen Sie **Bearbeiten** aus.
1. Klicken Sie auf**Remove VPC (VPC entfernen)**Klicken Sie auf die VPC, die Sie von dieser gehosteten Zone trennen möchten.
1. Wählen Sie **Save Changes (Änderungen speichern)**.
# Löschen einer privaten gehosteten Zone
In diesem Abschnitt wird erläutert, wie Sie eine privat gehostete Zone mithilfe der Amazon-Route-53-Konsole löschen können.
Sie können eine privat gehostete Zone nur dann löschen, wenn keine Datensätze (abgesehen von den Standard-SOA- und NS-Datensätzen) vorhanden sind. Wenn Ihre gehostet Zone andere Datensätze enthält, müssen Sie diese löschen, bevor Sie Ihre gehostete Zone löschen können. Dadurch wird verhindert, dass Sie versehentlich eine gehostete Zone löschen, die noch Datensätze enthält.
**Topics**
+ [Löschen von privaten gehosteten Zonen, die von einem anderen Dienst erstellt wurden](#delete-private-hosted-zone-created-by-another-service)
+ [Löschen einer privat gehosteten Zone mit der Route 53-Konsole.](#delete-private-hosted-zone-procedure)
## Löschen von privaten gehosteten Zonen, die von einem anderen Dienst erstellt wurden
Wenn eine privat gehostete Zone von einem anderen Dienst erstellt wurde, können Sie diese nicht mit der Route 53-Konsole löschen. Stattdessen müssen Sie den entsprechenden Vorgang für den anderen Dienst verwenden:
+ **AWS Cloud Map**— Um eine gehostete Zone zu löschen, die bei der AWS Cloud Map Erstellung eines privaten DNS-Namespace erstellt wurde, löschen Sie den Namespace. AWS Cloud Map löscht die gehostete Zone automatisch. Weitere Informationen finden Sie unter [Löschen von Namespaces](https://docs.aws.amazon.com/cloud-map/latest/dg/deleting-namespaces.html) im *AWS Cloud Map Entwicklerleitfaden*.
+ **Amazon Elastic Container Service (Amazon ECS) Service Discovery** - So löschen Sie eine privat gehostete Zone, die Amazon ECS erstellt hat, als Sie einen Dienst mithilfe der Dienst-Erkennung erstellt haben, löschen Sie die Amazon-ECS-Services, die den Namespace verwenden und löschen Sie den Namespace. Weitere Informationen finden Sie unter [Angeben vertraulicher Daten](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/delete-service.html) im *Amazon Elastic Container Service-Entwicklerhandbuch*.
## Löschen einer privat gehosteten Zone mit der Route 53-Konsole.
Um die Route 53-Konsole zu verwenden, löschen Sie eine privat gehostete Zone, und führen Sie folgende Schritte aus.
**Löschen einer privat gehosteten Zone mit der Route 53-Konsole.**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Vergewissern Sie sich, dass die gehostete Zone, die Sie löschen möchten, nur einen NS- und einen SOA-Datensatz enthält. Enthält sie zusätzliche Datensätze, löschen Sie diese:
1. Klicken Sie auf den Namen der gehosteten Zone, die Sie löschen möchten.
1. Klicken Sie auf der Seite **Record**, wenn die Liste der Datensätze irgendwelche Datensätze enthält, für die der Wert der Spalte **Type** ein anderer ist als **NS** oder **SOA**, auf die entsprechende Zeile, und wählen Sie **Delete**.
Um mehrere aufeinander folgende Datensätze auszuwählen, wählen Sie die erste Zeile aus, halten Sie die **Umschalttaste** gedrückt, und klicken Sie dann auf die letzte Zeile. Um mehrere nicht aufeinander folgende Datensätze auszuwählen, wählen Sie die erste Zeile aus, halten Sie die **Strg-Taste** gedrückt, und klicken Sie dann auf die gewünschten Zeilen.
1. Wählen Sie auf der Seite Hosted Zones die Zeile für die gehostete Zone aus, die Sie löschen möchten.
1. Wählen Sie **Löschen** aus.
1. Geben Sie den Bestätigungsschlüssel ein und wählen Sie **Delete (Löschen)** aus.
# VPC-Berechtigungen
[VPC-Berechtigungen verwenden die Richtlinienbedingung Identity and Access Management (IAM), damit Sie detaillierte Berechtigungen für die VPCs Verwendung von [Associate VPCWith HostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html), [Disassociate VPCFrom HostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisassociateVPCFromHostedZone.html), [Create VPCAssociation Authorization, [Delete VPCAssociation](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteVPCAssociationAuthorization.html) Authorization](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateVPCAssociationAuthorization.html) und VPC festlegen können. [CreateHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateHostedZone.html)ListHostedZonesBy](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListHostedZonesByVPC.html) APIs
Mit der IAM-Richtlinienbedingung können Sie anderen `route53:VPCs` Benutzern detaillierte Administratorrechte gewähren. AWS Auf diese Weise können Sie jemandem die Berechtigung erteilen, eine gehostete Zone zuzuordnen, die Hosting-Zone von ihr zu trennen, eine VPC-Zuordnungsautorisierung zu erstellen, die VPC-Zuordnungsautorisierung für zu löschen, eine gehostete Zone zu erstellen oder gehostete Zonen aufzulisten für:
+ Eine einzelne VPC.
+ Alle VPCs innerhalb derselben Region.
+ Mehrfach VPCs.
Weitere Informationen zu VPC-Berechtigungen finden Sie unter[Verwenden von IAM-Richtlinienbedingungen für die differenzierte Zugriffskontrolle](specifying-conditions-route53.md).
Informationen zur Authentifizierung von AWS Benutzern finden Sie unter[Authentifizierung mit Identitäten](security-iam.md#security_iam_authentication). Informationen zur Steuerung des Zugriffs auf Route 53-Ressourcen finden Sie unter. [Zugriffskontrolle](security-iam.md#access-control)
# Migrieren einer Hosting-Zone auf ein anderes Konto AWS
Folgen Sie diesen empfohlenen Schritten AWS-Konto, wenn Sie eine Hosting-Zone in eine andere migrieren.
Diese Schritte eignen sich am besten für Hosting-Zonen mit seltenen Datensatzänderungen. Beachten Sie bei Hosting-Zonen mit häufigen Datensatzaktualisierungen Folgendes:
+ Aktualisieren Sie während der Migration keine Ressourceneinträge.
+ Veröffentlichen Sie Änderungen an den Ressourceneinträgen sowohl in alten als auch in neuen Hosting-Zonen, nachdem die Delegierung übertragen wurde.
**Voraussetzungen**
Installieren oder aktualisieren Sie AWS CLI:
Informationen zum Herunterladen, Installieren und Konfigurieren von finden Sie im [AWS Command Line Interface Benutzerhandbuch](https://docs.aws.amazon.com/cli/latest/userguide/). AWS CLI
**Anmerkung**
Konfigurieren Sie die CLI so, dass Sie einsatzbereit ist, wenn Sie sowohl das Konto, über das die gehostete Zone erstellt wurde, als auch das Konto verwenden, zu dem die gehostete Zone migriert wird. Weitere Informationen finden Sie unter [Konfigurieren der ](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html) im *AWS Command Line Interface -Benutzerhandbuch*.
Wenn Sie die bereits verwenden AWS CLI, empfehlen wir Ihnen, auf die neueste Version der CLI zu aktualisieren, damit die CLI-Befehle die neuesten Route 53-Funktionen unterstützen.
**Topics**
+ [Schritt 1: Bereiten Sie sich auf die Migration vor](#hosted-zones-migrating-prepare)
+ [Schritt 2: Erstellen der neuen gehosteten Zone](#hosted-zones-migrating-create-hosted-zone)
+ [Schritt 3: (Optional) Migrieren Sie die Zustandsprüfungen](#hosted-zones-migrating-health-checks)
+ [Schritt 4: Migrieren Sie Datensätze von der alten Hosting-Zone zur neuen Hosting-Zone](#hosted-zones-migrating-old-to-new)
+ [Schritt 5: Vergleichen Sie Datensätze in den alten und neuen Hosting-Zonen](#hosted-zones-migrating-compare)
+ [Schritt 6: Aktualisieren Sie die Domainregistrierung, um Nameserver für die neue Hosting-Zone zu verwenden](#hosted-zones-migrating-update-domain)
+ [Schritt 7: Ändern Sie die TTL für den NS-Eintrag wieder auf einen höheren Wert](#hosted-zones-migrating-change-ttl)
+ [Schritt 8: Aktivieren Sie die DNSSEC-Signatur erneut und richten Sie die Vertrauenskette ein (falls erforderlich)](#hosted-zones-migrating-enable-dnssec)
+ [Schritt 9: (Optional) Löschen Sie die alte Hosting-Zone](#hosted-zones-migrating-delete-old-hosted-zone)
## Schritt 1: Bereiten Sie sich auf die Migration vor
Die Vorbereitungsschritte helfen Ihnen dabei, die mit der Migration einer gehosteten Zone verbundenen Risiken zu minimieren.
**1. Überwachen Sie die Verfügbarkeit der Zone**
Sie können die Zone auf die Verfügbarkeit Ihrer Domänennamen überwachen. Auf diese Weise können Sie alle Probleme beheben, die zu einem Rollback der Migration führen könnten. Mithilfe der Protokollierung CloudWatch oder Abfrage können Sie überwachen, ob Ihre Domainnamen mit dem meisten Traffic betroffen sind. Für weitere Informationen zum Einrichten einer Abfrage-Protokollierung siehe [Amazon Route 53 überwachen](monitoring-overview.md).
Die Überwachung kann über ein Shell-Skript oder über einen Drittanbieterdienst erfolgen. Dies sollte jedoch nicht das einzige Signal sein, anhand dessen festgestellt werden kann, ob ein Rollback erforderlich ist, da Sie möglicherweise auch Feedback von Ihren Kunden erhalten, wenn eine Domain nicht verfügbar ist.
**2. Senken Sie die TTL-Einstellung**
Die TTL-Einstellung (Time-to-live, Gültigkeitsdauer) für einen Datensatz gibt an, wie lange DNS-Resolver den Datensatz zwischenspeichern und die zwischengespeicherten Informationen verwenden sollen. Wenn die TTL abgelaufen ist, sendet ein Resolver eine weitere Abfrage an den DNS-Dienstanbieter für eine Domäne, um die neuesten Informationen zu erhalten.
Die typische TTL-Einstellung für den NS Datensatz ist 172 800 Sekunden oder 2 Tage. Der NS-Datensatz listet die Namenserver auf, die das Domain Name System (DNS) verwenden kann, um Informationen zum Weiterleiten des Datenverkehrs für Ihre Domäne abzurufen. Wenn Sie die TTL für den NS-Eintrag sowohl bei Ihrem aktuellen DNS-Dienstanbieter als auch bei Route 53 senken, werden die Ausfallzeiten für Ihre Domain reduziert, falls Sie bei der Migration von DNS zu Route 53 ein Problem feststellen. Wenn Sie die TTL nicht senken, ist Ihre Domäne bis zu zwei Tage im Internet nicht verfügbar, wenn ein Fehler auftritt.
**Um die TTL zu senken**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Wählen Sie im Navigationsbereich die Option **Gehostete Zonen** aus.
1. Wählen Sie den Namen der gehosteten Zone aus.
1. Wählen Sie den NS-Eintrag und dann im Bereich **Datensatzdetails** die Option **Datensatz bearbeiten** aus.
1. Ändern Sie den Wert **TTL (Seconds)**. Wir empfehlen, einen Wert zwischen 60 Sekunden und 900 Sekunden (15 Minuten) anzugeben.
1. Wählen Sie **Speichern**.
**3. Entfernen Sie den DS-Eintrag aus der übergeordneten Zone (wenn Sie DNSSEC konfiguriert haben)**
Wenn Sie DNSSEC für Ihre Domäne konfiguriert haben, entfernen Sie den Eintrag Delegation Signer (DS) aus der übergeordneten Zone, bevor Sie Ihre Domäne zu Route 53 migrieren.
Wenn die übergeordnete Zone über Route 53 gehostet wird, finden Sie [Löschen von öffentlichen Schlüsseln für eine Domäne](domain-configure-dnssec.md#domain-configure-dnssec-deleting-keys) weitere Informationen unter. Wenn die übergeordnete Zone bei einem anderen Registrar gehostet wird, wenden Sie sich an diesen, um den DS-Eintrag zu entfernen.
Route 53 unterstützt derzeit nicht die Migration der DNSSEC-Einstellung. Daher müssen Sie die DNSSEC-Validierung, die vor der Migration für Ihre Domain durchgeführt wurde, deaktivieren, indem Sie den DS-Eintrag aus der übergeordneten Zone entfernen. Nach der Migration können Sie die DNSSEC-Validierung wieder aktivieren, indem Sie DNSSEC in der neuen Hosting-Zone konfigurieren und den entsprechenden DS-Eintrag zur übergeordneten Zone hinzufügen.
**4. Stellen Sie sicher, dass keine anderen laufenden Operationen von der migrierenden Hosting-Zone abhängen**
Einige Vorgänge hängen von der DNS-Auflösung in der migrierenden Hostzone ab. Beispielsweise müssen bei der TLS/SSL Zertifikatserneuerung möglicherweise Änderungen am DNS-Eintrag vorgenommen werden, und der Anbieter versucht, den DNS-Eintrag als Validierungsmethode aufzulösen. Vor der Migration sollten Sie sicherstellen, dass kein anderer Vorgang ausgeführt wird, um unerwartete Auswirkungen der Migration der Hosting-Zone zu vermeiden.
## Schritt 2: Erstellen der neuen gehosteten Zone
Erstellen Sie die neue Hosting-Zone in dem Konto, zu dem Sie die Hostzone migrieren möchten.
Wählen Sie die Registerkarte mit den Anweisungen für die Konsole AWS CLI oder.
+ [CLI](#migrate-hz-cli)
+ [Konsole](#migrate-hz-console)
------
#### [ CLI ]
Geben Sie den folgenden Befehl ein:
```
aws route53 create-hosted-zone \
--name $hosted_zone_name \
--caller-reference $unique_string
```
Weitere Informationen finden Sie unter [create-hosted-zone](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/route53/create-hosted-zone.html).
------
#### [ Console ]
**So erstellen Sie die neue gehostete Zone mit einem anderen Konto**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
Melden Sie sich mit den Anmeldeinformationen für das Konto an, zu dem Sie die gehostete Zone migrieren möchten.
1. Erstellen Sie eine gehostete Zone. Weitere Informationen finden Sie unter [Erstellen einer öffentlichen gehosteten Zone](CreatingHostedZone.md).
1. Notieren Sie sich die ID der gehosteten Zone. In einigen Fällen benötigen Sie diese Informationen zu einem späteren Zeitpunkt.
1. Melden Sie sich bei der Route 53-Konsole ab.
Senken Sie die NS-TTL auch in der neuen Zone, ähnlich der Einstellung „Niedrigere TTL“ in Vorbereitung. Schritt 1, Senken Sie die TTL-Einstellung.
------
## Schritt 3: (Optional) Migrieren Sie die Zustandsprüfungen
Sie können DNS-Einträge im neuen Konto den Route 53-Zustandsprüfungen des Kontos zuordnen, von dem Sie migrieren. Um eine Route 53-Zustandsprüfung zu migrieren, müssen Sie in Ihrem neuen Konto neue Zustandsprüfungen mit derselben Konfiguration wie Ihre vorhandenen erstellen. Weitere Informationen finden Sie unter [Amazon Route 53-Zustandsprüfungen erstellen](dns-failover.md).
## Schritt 4: Migrieren Sie Datensätze von der alten Hosting-Zone zur neuen Hosting-Zone
Sie können Datensätze von einem AWS-Konto zu einem anderen migrieren, indem Sie die Konsole oder die verwenden AWS CLI.
------
#### [ Console ]
Wenn Ihre Zone nur wenige Datensätze enthält, können Sie erwägen, die Route 53-Konsole zu verwenden, um die Datensätze in Ihrer alten Zone aufzulisten, sie zu notieren und sie in der neuen Zone zu erstellen. Wenn Sie den Integritätscheck migriert haben[Schritt 3: (Optional) Migrieren Sie die Zustandsprüfungen](#hosted-zones-migrating-health-checks), sollten Sie beim Erstellen der Datensätze in der neuen Hosting-Zone die neue Integritätsprüfungs-ID angeben. Weitere Informationen finden Sie unter den folgenden Themen:
+ [Auflisten von Datensätzen](resource-record-sets-listing.md)
+ [Erstellen von Datensätzen mithilfe der Amazon-Route-53-Konsole](resource-record-sets-creating.md)
+ [Konfigurieren von DNS Failover](dns-failover-configuring.md)
Sie sollten die NS-TTL auch in der neuen Zone senken, ähnlich der Einstellung „Niedrigere TTL“ in Schritt 1.
------
#### [ CLI ]
Wenn Ihre Zone eine große Anzahl von Datensätzen enthält, können Sie die Datensätze, die Sie migrieren möchten, in eine Datei exportieren, die Datei bearbeiten und dann die bearbeitete Datei verwenden, um Datensätze in der neuen Hosting-Zone zu erstellen. Das folgende Verfahren verwendet AWS CLI-Befehle, obwohl zu diesem Zweck auch Tools von Drittanbietern verfügbar sind.
****
1. Führen Sie den folgenden Befehl aus:
```
aws route53 list-resource-record-sets --hosted-zone-id hosted-zone-id > path-to-output-file
```
Beachten Sie Folgendes:
+ Geben Sie für *hosted-zone-id* die ID der alten Hosting-Zone an, die die Datensätze enthält, die Sie migrieren möchten.
+ Geben Sie für *path-to-output-file* den Verzeichnispfad und den Dateinamen an, in dem Sie die Ausgabe speichern möchten.
+ Das `>`-Zeichen sendet die Ausgabe an die angegebene Datei.
+ Die verarbeitet AWS CLI automatisch die Paginierung für Hosting-Zonen, die mehr als 100 Datensätze enthalten. Weitere Informationen finden Sie im *AWS Command Line Interface Benutzerhandbuch* [unter Verwenden der Paginierungsoptionen der AWS Befehlszeilenschnittstelle](https://docs.aws.amazon.com/cli/latest/userguide/pagination.html).
Wenn Sie eine andere programmatische Methode zum Auflisten von Datensätzen verwenden, z. B. einen der AWS SDKs, können Sie maximal 100 Datensätze pro Ergebnisseite abrufen. Wenn die gehostete Zone mehr als 100 Datensätze enthält, müssen Sie mehrere Anforderungen zur Auflistung aller Datensätze übermitteln.
Erstellen Sie eine Kopie dieser Ausgabe. Nachdem Sie Datensätze in der neuen Hosting-Zone erstellt haben, empfehlen wir, den AWS CLI `list-resource-record-sets` Befehl für die neue Hosting-Zone auszuführen und die beiden Ausgaben zu vergleichen, um sicherzustellen, dass alle Datensätze erstellt wurden.
1. Bearbeiten Sie die Datensätze, die Sie migrieren möchten.
Bearbeiten Sie die exportierte Datei, bevor Sie sie mit dem `change-resource-record-sets` Befehl verwenden können. Sie können diese Änderungen mithilfe der Such- und Ersetzungsfunktion in einem Texteditor vornehmen.
**Anmerkung**
Die folgenden Schritte beschreiben die manuelle Bearbeitung mit einem Texteditor. Fortgeschrittene Benutzer können diese Transformationen mithilfe von programmatischen Tools wie jq, Python oder anderen Skriptsprachen automatisieren.
Öffnen Sie eine Kopie der Datei, die Sie in Schritt 1 dieses Verfahrens erstellt haben und die die Datensätze enthält, die Sie migrieren möchten, und nehmen Sie die folgenden Änderungen vor:
+ Ersetzen Sie das ResourceRecordSets Element oben in der Datei durch `Changes` Element.
+ Optional — füge ein `Comment` Element hinzu.
+ Löschen Sie die Zeilen, die sich auf die NS- und SOA-Einträge des Namens der gehosteten Zone beziehen. Die neue gehostete Zone verfügt bereits über diese Datensätze.
+ Fügen Sie für jeden Datensatz ein Element `Action` und ein `ResourceRecordSets` Element hinzu und fügen Sie nach Bedarf öffnende und schließende Klammern (`{ }`) hinzu, damit der JSON-Code gültig ist.
**Anmerkung**
Sie können einen JSON-Validator einsetzen, um sicherzustellen, dass alle Klammern an den erforderlichen Stellen vorhanden sind. Um einen Online-JSON-Validator zu finden, suchen Sie in Ihrem Browser nach „JSON-Validator“.
+ Wenn die gehostete Zone Aliasse enthält, die sich auf andere Datensätze in derselben gehosteten Zone beziehen, nehmen Sie die folgenden Änderungen vor:
+ Ändern Sie die ID der gehosteten Zone in die ID der neuen gehosteten Zone.
**Wichtig**
Wenn der Aliaseintrag auf eine andere Ressource verweist, z. B. auf einen Load Balancer, ändern Sie die Hosting-Zonen-ID nicht in die Hosting-Zonen-ID der Domain. Wenn Sie die Hosting-Zonen-ID versehentlich ändern, setzen Sie die Hosting-Zonen-ID auf die Hosting-Zonen-ID der Ressource selbst zurück, nicht auf die Hosting-Zonen-ID der Domain. Die ID der gehosteten Zone der Ressource befindet sich in der AWS Konsole, in der die Ressource erstellt wurde.
+ Verschieben Sie die Alias-Datensätze an das Ende der Datei. Route 53 muss den Datensatz erstellen, auf den sich ein Alias-Datensatz bezieht, ehe es den Alias-Datensatz erstellen kann.
**Wichtig**
Wenn ein oder mehrere Alias-Datensätze auf andere Alias-Datensätze verweisen, müssen die Datensätze, die das Alias-Ziel darstellen, vor den referenzierenden Datensätzen aufgeführt werden. Beispiel: Wenn das Alias-Ziel für `alias.alias.example.com` `alias.example.com` ist, muss `alias.example.com` zuerst in der Datei aufgeführt werden.
+ Löschen Sie alle Alias-Datensätze, die Datenverkehr zu einer Datenverkehrsrichtlinien-Instance umleiten. Notieren Sie sich die Datensätze, sodass Sie sie zu einem späteren Zeitpunkt erneut erstellen können.
+ Wenn Sie Integritätsprüfungen migriert haben[Schritt 3: (Optional) Migrieren Sie die Zustandsprüfungen](#hosted-zones-migrating-health-checks), ändern Sie die Datensätze, um sie der neu erstellten Zustandsprüfung IDs zuzuordnen.
Das folgende Beispiel zeigt die bearbeitete Version von Datensätzen für eine gehostete Zone für example.com. Der rote, kursive Text ist neu:
```
{
"Comment": "string",
"Changes": [
{
"Action": "CREATE",
"ResourceRecordSet":{
"ResourceRecords": [
{
"Value": "192.0.2.4"
},
{
"Value": "192.0.2.5"
},
{
"Value": "192.0.2.6"
}
],
"Type": "A",
"Name": "route53documentation.com.",
"TTL": 300
}
},
{
"Action": "CREATE",
"ResourceRecordSet":{
"AliasTarget": {
"HostedZoneId": "Z3BJ6K6RIION7M",
"EvaluateTargetHealth": false,
"DNSName": "s3-website-us-west-2.amazonaws.com."
},
"Type": "A",
"Name": "www.route53documentation.com."
}
}
]
}
```
1. Teilen Sie große Dateien in kleinere Dateien auf
Wenn Sie viele Datensätze haben oder Datensätze, die viele Werte enthalten (z. B. zahlreiche IP-Adressen), müssen Sie die Datei möglicherweise in mehrere kleinere Dateien aufteilen. Die Maximalwerte sind:
+ Eine Datei darf maximal 1 000 Datensätze enthalten.
+ Die maximale Gesamtlänge der Werte in allen `Value`-Elementen ist auf 32 000 Byte begrenzt.
1. Erstellen Sie Datensätze in der neuen Hosting-Zone
Geben Sie die folgende CLI ein:
```
aws route53 change-resource-record-sets \
--hosted-zone-id new-hosted-zone-id \
--change-batch file://path-to-file-that-contains-records
```
Geben Sie die folgenden Werte an:
+ Geben Sie für `new-hosted-zone-id` die ID der neuen gehosteten Zone an.
+ Geben Sie für `path-to-file-that-contains-records` den Verzeichnispfad und den Dateinamen an, die Sie in den vorherigen Schritten bearbeitet haben.
Wenn Sie Alias-Datensätze gelöscht haben, mithilfe derer der Datenverkehr zu einer Datenverkehrsrichtlinien-Instance umgeleitet wird, erstellen Sie diese mit der Route 53-Konsole neu. Weitere Informationen finden Sie unter [Erstellen von Datensätzen mithilfe der Amazon-Route-53-Konsole](resource-record-sets-creating.md).
------
## Schritt 5: Vergleichen Sie Datensätze in den alten und neuen Hosting-Zonen
Um zu bestätigen, dass Sie alle Ihre Datensätze in der neuen Hosting-Zone erfolgreich erstellt haben, geben Sie den folgenden CLI-Befehl ein, um die Datensätze in der neuen Hosting-Zone aufzulisten und die Ausgabe mit der Liste der Datensätze aus der alten Hosting-Zone zu vergleichen.
```
aws route53 list-resource-record-sets \
--hosted-zone-id new-hosted-zone-id \
--output json > path-to-output-file
```
Geben Sie die folgenden Werte an:
+ Geben Sie für `new-hosted-zone-id` die ID der neuen Hosting-Zone an.
+ Geben Sie für `path-to-output-file` den Verzeichnispfad und den Dateinamen an, in dem Sie die Ausgabe speichern möchten. Verwenden Sie einen Dateinamen, der sich von dem Dateinamen unterscheidet, den Sie in Schritt 4 verwendet haben.
Das `>`-Zeichen sendet die Ausgabe an die angegebene Datei.
Vergleichen Sie die Ausgabe mit der Ausgabe aus Schritt 4. Abgesehen von den Werten der NS- und SOA-Einträge und allen Änderungen, die Sie in Schritt 4 vorgenommen haben (z. B. unterschiedliche Hostingzonen IDs - oder Domainnamen), sollten die beiden Ausgaben identisch sein.
Wenn die Datensätze in der neuen Hosting-Zone nicht mit den Datensätzen in der alten Hosting-Zone übereinstimmen, gehen Sie wie folgt vor:
+ Nehmen Sie kleinere Korrekturen über die Route 53-Konsole vor. Weitere Informationen finden Sie unter [Bearbeiten von Datensätzen](resource-record-sets-editing.md).
+ Löschen Sie alle Datensätze außer den NS- und SOA-Datensätzen in der neuen Hosting-Zone, und wiederholen Sie den Vorgang in Schritt 4.
## Schritt 6: Aktualisieren Sie die Domainregistrierung, um Nameserver für die neue Hosting-Zone zu verwenden
Wenn Sie mit der Migration der Datensätze in die neue Hosting-Zone fertig sind, ändern Sie die Nameserver für die Domainregistrierung so, dass sie die Nameserver für die neue Hosting-Zone verwenden. Weitere Informationen finden Sie unter Amazon Route 53 zum DNS-Service für eine bestehende Domain machen.
Wenn Ihre gehostete Zone verwendet wird — wenn Ihre Benutzer beispielsweise den Domainnamen verwenden, um eine Website aufzurufen oder auf eine Webanwendung zuzugreifen — sollten Sie weiterhin den Verkehr und die Verfügbarkeit der gehosteten Zone überwachen, einschließlich Website- oder Anwendungsverkehr, E-Mail usw.
+ **Wenn sich der Verkehr verlangsamt oder stoppt** — Stellen Sie den Name-Service für die Domainregistrierung wieder auf die vorherigen Nameserver der alten Hosting-Zone um. Ergründen Sie anschließend, was schiefgelaufen ist.
+ **Wenn der Verkehr nicht beeinträchtigt wird** — Fahren Sie mit dem nächsten Schritt fort.
## Schritt 7: Ändern Sie die TTL für den NS-Eintrag wieder auf einen höheren Wert
Ändern Sie in der neuen Hosting-Zone die TTL für den NS-Eintrag auf einen typischeren Wert, z. B. 172800 Sekunden (zwei Tage). Dadurch wird die Latenz für Ihre Benutzer verbessert, da sie nicht so oft darauf warten müssen, dass DNS-Resolver eine Abfrage für die Namenserver Ihrer Domäne senden.
**Um die TTL zu ändern**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Wählen Sie im Navigationsbereich die Option **Gehostete Zonen** aus.
1. Wählen Sie den Namen der gehosteten Zone aus.
1. Wählen Sie den NS-Eintrag und dann im Bereich **Datensatzdetails** die Option **Datensatz bearbeiten** aus.
1. Ändern Sie den Wert von **TTL (Sekunden)** auf die Anzahl der Sekunden, für die DNS-Resolver die Namen der Nameserver für Ihre Domain zwischenspeichern sollen. Wir empfehlen einen Wert von 172 800 Sekunden.
1. Wählen Sie **Speichern**.
## Schritt 8: Aktivieren Sie die DNSSEC-Signatur erneut und richten Sie die Vertrauenskette ein (falls erforderlich)
Sie können die DNSSEC-Signatur in zwei Schritten wieder aktivieren:
1. Aktivieren Sie die DNSSEC-Signatur für Route 53 und fordern Sie Route 53 auf, einen Key Signing Key (KSK) auf der Grundlage einer vom Kunden verwalteten Schlüsseleingabe zu erstellen. AWS Key Management Service
1. Erstellen Sie eine Vertrauenskette für die gehostete Zone, indem Sie der übergeordneten Zone einen DS-Eintrag (Delegation Signer) hinzufügen, sodass DNS-Antworten mit vertrauenswürdigen kryptografischen Signaturen authentifiziert werden können.
Detaillierte Anweisungen finden Sie unter [Aktivieren der DNSSEC-Signierung und Aufbau einer Vertrauenskette](dns-configuring-dnssec-enable-signing.md).
## Schritt 9: (Optional) Löschen Sie die alte Hosting-Zone
Wenn Sie sicher sind, die alte gehostete Zone nicht mehr zu benötigen, können Sie diese löschen. Detaillierte Anweisungen finden Sie unter [Löschen einer öffentlichen gehosteten Zone](DeleteHostedZone.md).
**Wichtig**
Löschen Sie die alte gehostete Zone bzw. Datensätze in dieser gehosteten Zone nicht während mindestens 48 Stunden, nachdem Sie die Domänenregistrierung aktualisiert haben, damit für die neue gehostete Zone Nameserver verwendet werden. Wenn Sie die alte gehostete Zone löschen, bevor die DNS-Resolver die Verwendung der Datensätze in dieser gehosteten Zone einstellen, könnte Ihre Domäne im Internet nicht verfügbar sein, bis Resolver die neue gehostete Zone verwenden.
# Arbeiten mit Datensätzen
Nach der Erstellung einer gehosteten Zone für Ihre Domain (z. B. example.com) erstellen Sie Datensätze, um dem Domain Name System (DNS) mitzuteilen, wie der Datenverkehr für diese Domain weitergeleitet werden soll.
Sie können beispielsweise Datensätze erstellen, aufgrund derer DNS Folgendes tut:
+ Internetdatenverkehr für example.com wird zur IP-Adresse eines Hosts in Ihrem Rechenzentrum weitergeleitet.
+ E-Mails für diese Domain (ichiro@example.com) werden zu einem Mail-Server (mail.example.com) weitergeleitet.
+ Der Datenverkehr für eine Subdomain mit dem Namen operations.tokyo.example.com wird zur IP-Adresse eines anderen Hosts weitergeleitet.
Jeder Datensatz enthält den Namen einer Domain oder einer Subdomain, einen Datensatztyp (ein Datensatz mit dem Typ MX leitet beispielsweise E-Mail-Nachrichten weiter) und andere Informationen bezüglich des Datensatztyps (den Hostnamen von einem oder mehreren Mail-Servern und eine Priorität für jeden Server für MX-Datensätze). Weitere Informationen zu den verschiedenen Arten von Datensätzen finden Sie unter [Unterstützte DNS-Datensatztypen](ResourceRecordTypes.md).
Der Name jedes Datensatzes in einer gehosteten Zone muss mit dem Namen der gehosteten Zone enden. Die gehostete Zone example.com kann beispielsweise Datensätze für die Subdomains www.example.com und accounting.tokyo.example.com enthalten, aber keine Datensätze für eine Subdomain wie www.example.ca.
**Anmerkung**
Um Datensätze für komplexe Routing-Konfigurationen zu erstellen, können Sie auch den Visual Editor Traffic Flow verwenden und die Konfiguration als Verkehrsrichtlinie speichern. Sie können dann die Datenverkehrsrichtlinie mit einem oder mehreren Domainnamen (z. B. example.com) oder Subdomainnamen (z. B. www.example.com) in derselben gehosteten Zone oder in mehreren gehosteten Zonen verknüpfen. Außerdem können Sie ein Rollback der Aktualisierungen durchführen, wenn die neue Konfiguration sich nicht wie erwartet verhält. Weitere Informationen finden Sie unter [Verwenden von Traffic Flow zum Weiterleiten von DNS-Verkehr](traffic-flow.md).
In Amazon Route 53 werden keine Gebühren für Datensätze berechnet, die Sie einer gehosteten Zone hinzufügen. Informationen zu Höchstwerten für die Anzahl der Datensätze, die Sie in einer gehosteten Zone erstellen können, finden Sie unter [Kontingente](DNSLimitations.md).
**Topics**
+ [Auswählen einer Routing-Richtlinie](routing-policy.md)
+ [Wählen zwischen Alias- und Nicht-Alias-Datensätzen](resource-record-sets-choosing-alias-non-alias.md)
+ [Unterstützte DNS-Datensatztypen](ResourceRecordTypes.md)
+ [Erstellen von Datensätzen mithilfe der Amazon-Route-53-Konsole](resource-record-sets-creating.md)
+ [Berechtigungen für Ressourcendatensätze](resource-record-sets-permissions.md)
+ [Werte, die Sie beim Erstellen oder Bearbeiten von Amazon Route 53-Datensätzen angeben](resource-record-sets-values.md)
+ [Erstellen von Datensätzen durch Importieren einer Zonendatei](resource-record-sets-creating-import.md)
+ [Bearbeiten von Datensätzen](resource-record-sets-editing.md)
+ [Löschen von Datensätzen](resource-record-sets-deleting.md)
+ [Auflisten von Datensätzen](resource-record-sets-listing.md)
# Auswählen einer Routing-Richtlinie
Wenn Sie einen Datensatz erstellen, müssen Sie eine Routing-Richtlinie auswählen, die bestimmt, wie Amazon Route 53 auf Abfragen reagiert:
+ **Einfache Routing-Richtlinie** – wird für eine einzelne Ressource verwendet, die eine bestimmte Funktion für Ihre Domain übernimmt, beispielsweise ein Webserver, der für die Inhalte für die Website example.com zuständig ist. Sie können einfaches Routing verwenden, um Datensätze in einer privat gehosteten Zone zu erstellen.
+ **Failover-Routing-Richtlinie** – wird verwendet, wenn Sie ein Aktiv-Passiv-Failover konfigurieren möchten. Sie können einfaches Failover-Routing verwenden, um Datensätze in einer privat gehosteten Zone zu erstellen.
+ **Geolocation-Routing-Richtlinie** – wird verwendet, wenn Sie den Datenverkehr auf Basis des Standorts Ihrer Benutzer weiterleiten möchten. Sie können einfaches Geolocation-Routing verwenden, um Datensätze in einer privat gehosteten Zone zu erstellen.
+ **Routing-Richtlinie auf der Grundlage der geografischen Nähe**: Wird verwendet, wenn Sie Datenverkehr auf Basis des Standorts Ihrer Ressourcen weiterleiten möchten und optional Datenverkehr von Ressourcen an einem Standort auf Ressourcen an einem anderen Standort verlagern möchten. Sie können Geoproximity-Routing verwenden, um Datensätze in einer privaten, gehosteten Zone zu erstellen.
+ **Latenz-Routing-Richtlinie** — Verwenden Sie diese Richtlinie, wenn Sie über mehrere Ressourcen verfügen AWS-Regionen und den Datenverkehr in die Region weiterleiten möchten, die die beste Latenz bietet. Sie können Latenz-Routing verwenden, um Datensätze in einer privat gehosteten Zone zu erstellen.
+ **IP-basierte Routing-Richtlinie**: Wird verwendet, wenn Sie den Datenverkehr auf Basis des Standorts Ihrer Benutzer weiterleiten möchten und die IP-Adressen haben, von denen der Datenverkehr stammt.
+ **Mehrwertige Antwort-Routing-Richtlinie** – wird verwendet, wenn Sie möchten, dass Route 53 mit bis zu acht zufällig ausgewählten und fehlerfreien Datensätzen auf DNS-Abfragen antwortet. Sie können mehrwertiges Antwort-Routing verwenden, um Datensätze in einer privat gehosteten Zone zu erstellen.
+ **Gewichtete Routing-Richtlinie** – wird verwendet, um Datenverkehr in festgelegten Proportionen zu mehreren Ressourcen weiterzuleiten. Sie können gewichtetes Routing verwenden, um Datensätze in einer privat gehosteten Zone zu erstellen.
**Topics**
+ [Einfaches Routing](routing-policy-simple.md)
+ [Failover-Routing](routing-policy-failover.md)
+ [Geolocation-Routing](routing-policy-geo.md)
+ [Geoproximity-Routing](routing-policy-geoproximity.md)
+ [Latenzbasiertes Routing](routing-policy-latency.md)
+ [IP-basiertes Routing](routing-policy-ipbased.md)
+ [Mehrwertiges Antwort-Routing](routing-policy-multivalue.md)
+ [Gewichtetes Routing](routing-policy-weighted.md)
+ [Wie Amazon Route 53 verwendet EDNS0 , um den Standort eines Benutzers zu schätzen](routing-policy-edns0.md)
# Einfaches Routing
Einfaches Routing ermöglicht die Konfiguration von Standard-DNS-Datensätzen ohne spezielles Route-53-Routing, wie z. B. gewichtet oder Latenz. Bei einfachem Routing leiten Sie den Datenverkehr normalerweise an eine einzelne Ressource weiter, beispielsweise an einen Webserver für Ihre Website.
Sie können einfaches Routing für Datensätze in einer privat gehosteten Zone verwenden.
Wenn Sie die einfache Routing-Richtlinie in der und Route-53-Konsole auswählen, können Sie nicht mehrere Datensätze mit demselben Namen und desselben Typs erstellen. Sie können jedoch mehrere Werte im selben Datensatz angeben, z. B. mehrere IP-Adressen. (Wenn Sie die einfache Routing-Richtlinie für einen Aliaseintrag wählen, können Sie nur eine AWS Ressource oder einen Datensatz in der aktuellen Hosting-Zone angeben.) Wenn Sie mehrere Werte in einem Datensatz angeben, gibt Route 53 alle Werte in zufälliger Reihenfolge an den rekursiven Resolver zurück, und der Resolver gibt die Werte an den Client (z. B. einen Webbrowser) zurück, der die DNS-Abfrage gesendet hat. Der Client wählt dann einen Wert aus und sendet die Abfrage erneut. Mit einer einfachen Routing-Richtlinie können Sie zwar mehrere IP-Adressen angeben, diese IP-Adressen werden jedoch nicht auf den Zustand überprüft.
Informationen zu Werten, die Sie angeben, wenn Sie die einfache Routingrichtlinie zum Erstellen von Datensätzen verwenden, finden Sie in den folgenden Themen:
+ [Spezifische Werte für einfache Datensätze](resource-record-sets-values-basic.md)
+ [Spezifische Werte für einfache Aliasdatensätze](resource-record-sets-values-alias.md)
+ [Typische Werte für alle Routing-Richtlinien](resource-record-sets-values-shared.md)
+ [Werte, die für Aliasdatensätze für alle Routing-Richtlinien typisch sind](resource-record-sets-values-alias-common.md)
# Failover-Routing
Failover-Routing ermöglicht es Ihnen, Datenverkehr zu einer Ressource weiterzuleiten, wenn die Ressource fehlerfrei ist, oder zu einer anderen Ressource, wenn es bei der ersten Ressource ein Problem gibt. Die primären und sekundären Datensätze können Datenverkehr zu allem weiterleiten, von einem als Website konfigurierten Amazon-S3-Bucket bis hin zu einer komplexen Datensatzstruktur. Weitere Informationen finden Sie unter [Aktiv/Passiv-Failover](dns-failover-types.md#dns-failover-types-active-passive).
Sie können Failover-Routing für Datensätze in einer privat gehosteten Zone verwenden.
Informationen zu Werten, die Sie angeben, wenn Sie die einfache Failover-Routingrichtlinie zum Erstellen von Datensätzen verwenden, finden Sie in den folgenden Themen:
+ [Spezifische Werte für Failover-Datensätze](resource-record-sets-values-failover.md)
+ [Spezifische Werte für Failover-Aliasdatensätze](resource-record-sets-values-failover-alias.md)
+ [Typische Werte für alle Routing-Richtlinien](resource-record-sets-values-shared.md)
+ [Werte, die für Aliasdatensätze für alle Routing-Richtlinien typisch sind](resource-record-sets-values-alias-common.md)
# Geolocation-Routing
Geolocation-Routing ermöglicht es Ihnen, die angesteuerten Ressourcen auf Basis des geographischen Standorts Ihrer Benutzer auszuwählen, also auf Basis des Standorts, von dem aus DNS-Abfragen gesendet werden. Sie können beispielsweise alle Abfragen aus Europa an einen Elastic Load Balancing Load Balancer in der Region Frankfurt weiterleiten.
Wenn Sie Geolocation-Routing verwenden, können Sie Ihre Inhalte lokalisieren und Ihre Website ganz oder teilweise in der Sprache Ihrer Benutzer präsentieren. Außerdem können Sie mit dem Geolocation-Routing die Verteilung von Inhalten auf Standorte beschränken, für die Sie Verteilungsrechte besitzen. Eine weitere mögliche Verwendung besteht darin, die Last auf vorhersehbare easy-to-manage Weise zwischen den Endpunkten auszugleichen, sodass jeder Benutzerstandort konsistent an denselben Endpunkt weitergeleitet wird.
Sie können geografische Standorte nach Kontinent, Land oder Staat in den Vereinigten Staaten angeben. Wenn Sie getrennte Datensätze für sich überschneidende geografische Regionen erstellen, z. B. einen Datensatz für Nordamerika und einen für Kanada, hat die kleinste geographische Region Priorität. Auf diese Weise können Sie einige Abfragen für einen Kontinent zu einer Ressource leiten und Abfragen für ausgewählte Länder auf diesem Kontinent zu einer anderen Ressource leiten. (Eine Liste der Länder auf jedem Kontinent finden Sie unter [Speicherort](resource-record-sets-values-geo.md#rrsets-values-geo-location).)
Geolocation funktioniert durch Mapping von IP-Adressen zu Standorten. Einige IP-Adressen werden jedoch nicht auf geografische Standorte abgebildet, sodass, selbst wenn Sie Datensätze für Geolokationen erstellen, die alle sieben Kontinente abdecken, Amazon Route 53 einige DNS-Abfragen von Standorten erhält, die es nicht identifizieren kann. Sie können ein Standarddatensatz erstellen, der für Abfragen von IP-Adressen angewendet wird, die keinem Standort zugeordnet sind, und für Abfragen von Standorten, für die Sie keine Geolocation-Datensätze erstellt haben. Wenn Sie keinen Standarddatensatz erstellen, gibt Route 53 „keine Antwort“ für Abfragen von diesen Standorten zurück.
Sie können einfaches Geolocation-Routing für Datensätze in öffentlich und privat gehosteten Zonen verwenden.
Weitere Informationen finden Sie unter [Wie Amazon Route 53 verwendet EDNS0 , um den Standort eines Benutzers zu schätzen](routing-policy-edns0.md).
Informationen zu Werten, die Sie angeben, wenn Sie die einfache Geolocation-Routingrichtlinie zum Erstellen von Datensätzen verwenden, finden Sie in den folgenden Themen:
+ [Spezifische Werte für Geolocation-Datensätze](resource-record-sets-values-geo.md)
+ [Spezifische Werte für Geolocation-Aliasdatensätze](resource-record-sets-values-geo-alias.md)
+ [Typische Werte für alle Routing-Richtlinien](resource-record-sets-values-shared.md)
+ [Werte, die für Aliasdatensätze für alle Routing-Richtlinien typisch sind](resource-record-sets-values-alias-common.md)
# Geolocation-Routing in privat gehosteten Zonen
Für privat gehostete Zonen antwortet Route 53 auf DNS-Abfragen, die auf AWS-Region der VPC basieren, von der die Anfrage stammt. Eine Liste von AWS-Regionen finden Sie unter [Regionen und Zonen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) im *Amazon EC2 EC2-Benutzerhandbuch*.
Wenn die DNS-Abfrage von einem On-Premises-Teil eines Hybridnetzwerks stammt, wird davon ausgegangen, dass sie aus der AWS-Region stammt, in der sich die VPC befindet.
Wenn Sie Integritätsprüfungen einbeziehen, können Sie Standarddatensätze erstellen für:
+ IP-Adressen, die keinen geografischen Standorten zugeordnet sind.
+ DNS-Abfragen, die von Standorten stammen, für die Sie keine Geolocation-Datensätze erstellt haben.
Wenn der Geolocation-Datensatz für die Region der DNS-Abfrage nicht ordnungsgemäß ist, wird der Standarddatensatz zurückgegeben (falls er fehlerfrei ist).
In der Beispielkonfiguration in der folgenden Abbildung werden DNS-Abfragen, die von einem us-east-1 AWS-Region (Virginia) kommen, an den 1.1.1.1-Endpunkt weitergeleitet.
![\[Ein Screenshot eines Geolocation-Datensatzes für eine private Hosting-Zone\]](http://docs.aws.amazon.com/de_de/Route53/latest/DeveloperGuide/images/geolocation-phz.png)
# Geoproximity-Routing
Mithilfe der Weiterleitung auf der Grundlage der geografischen Nähe kann Amazon Route 53 den Datenverkehr auf der Grundlage des geografischen Standorts Ihrer Benutzer und Ressourcen an Ihre Ressourcen weiterleiten. Es leitet den Verkehr an die nächstgelegene verfügbare Ressource weiter. Sie können optional auch mehr oder weniger Datenverkehr an eine bestimmte Ressource weiterleiten, indem Sie einen Wert angeben, der als *Bias* bezeichnet wird. Ein Bias-Wert vergrößert oder verkleinert die geografische Region, aus der Datenverkehr an eine Ressource weitergeleitet wird.
Sie erstellen Regeln für die geografische Nähe für Ihre Ressourcen und geben für jede Regel einen der folgenden Werte an:
+ Wenn Sie AWS Ressourcen verwenden, geben Sie die AWS-Region oder die lokale Zonengruppe an, in der Sie die Ressource erstellt haben.
+ Wenn Sie Ressourcen verwenden, die keine AWS Ressourcen sind, geben Sie den Breiten- und Längengrad der Ressource an.
Um AWS Local Zones verwenden zu können, müssen Sie sie zuerst aktivieren. Weitere Informationen finden Sie im *Benutzerhandbuch zu AWS Local Zones* unter [Erste Schritte mit Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html).
Weitere Informationen zum Unterschied zwischen AWS-Regionen und Local Zones finden Sie unter [Regionen und Zonen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) im *Amazon EC2 EC2-Benutzerhandbuch*.
Um optional die Größe der geografischen Region zu ändern, aus der Route 53 Datenverkehr an eine Ressource weiterleitet, geben Sie für den Bias-Wert den gültigen Wert an:
+ Um die Größe der geografischen Region zu erweitern, aus der Route 53 Datenverkehr an eine Ressource weiterleitet, geben Sie für den Bias-Wert eine positive Ganzzahl von 1 bis 99 an. Route 53 verkleinert die Größe der angrenzenden Regionen.
+ Um die Größe der geografischen Region zu verkleinern, aus der Route 53 Datenverkehr an eine Ressource weiterleitet, geben Sie einen negativen Bias-Wert zwischen -1 und -99 an. Route 53 erweitert die Größe der angrenzenden Regionen.
**Anmerkung**
Wir aktualisieren die Traffic Flow-Konsole für Route 53. Während der Übergangsphase können Sie weiterhin die alte Konsole verwenden.
Wählen Sie den Tab für die von Ihnen verwendete Konsole aus.
+ [New console](#traffic-flow-geoprox-routing-map-new)
+ [Alte Konsole](#traffic-flow-geoprox-routing-map-old)
------
#### [ New console ]
Die folgende Karte zeigt vier AWS-Regionen (nummeriert von 1 bis 5):
1. USA West (Oregon)
1. Europa (Frankfurt)
1. Asien-Pazifik (Tokio)
1. Afrika (Kapstadt)
1. Middle East (Bahrain)
**Anmerkung**
Die Karten sind nur mit Traffic Flow verfügbar.
![\[Eine Weltkarte, die zeigt, wie der Verkehr geleitet wird, wenn Sie Geoproximitätsdatensätze für Ressourcen AWS-Regionen in den USA West (Oregon), Europa (Frankfurt), Asien-Pazifik (Tokio), Afrika (Kapstadt) und dem Nahen Osten (Bahrain) haben.\]](http://docs.aws.amazon.com/de_de/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-no-bias-new.png)
Die folgende Karte zeigt, was passiert, wenn Sie für die Region USA West (Oregon) (Nummer **1** auf der Karte) eine Abweichung von \$125 hinzufügen. Der Verkehr wird aus einem größeren Teil Nordamerikas und aus ganz Südamerika als zuvor zu der Ressource in dieser Region geleitet.
![\[Eine Weltkarte, die zeigt, wie Datenverkehr weitergeleitet wird, wenn Sie einen Bias-Wert von +25 in der Region USA Ost (Nord-Virginia) hinzufügen.\]](http://docs.aws.amazon.com/de_de/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-plus25-new.png)
Die folgende Karte zeigt, was passiert, wenn Sie die Tendenz für die Region USA West (Oregon) auf -25 ändern. **Der Verkehr wird aus kleineren Teilen Nord- und Südamerikas als zuvor an die Ressource in dieser Region weitergeleitet, und mehr Verkehr wird zu Ressourcen in den angrenzenden Regionen **2**, **3** und 4 geleitet.**
![\[Eine Weltkarte, die zeigt, wie der Verkehr geleitet wird, wenn Sie in der Region USA West (Oregon) eine Abweichung von -25 hinzufügen.\]](http://docs.aws.amazon.com/de_de/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-bias-minus25-new.png)
------
#### [ Old console ]
Die folgende Karte zeigt vier AWS-Regionen (nummeriert von 1 bis 4) und einen Ort in Johannesburg, Südafrika, der nach Breiten- und Längengrad (5) spezifiziert ist.
**Anmerkung**
Die Karten sind nur mit Traffic Flow verfügbar.
![\[Eine Weltkarte, die zeigt, wie der Verkehr geleitet wird, wenn Sie Geoproximitätsdatensätze für Ressourcen AWS-Regionen in den Regionen USA West (Oregon), USA Ost (Nord-Virginia), Europa (Paris) und Asien-Pazifik (Tokio) haben und Sie einen Datensatz für eine AWS Nicht-Ressource in Johannesburg, Südafrika, haben.\]](http://docs.aws.amazon.com/de_de/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-no-bias.png)
Die folgende Karte zeigt, was passiert, wenn Sie einen Bias-Wert von \$125 für die Region USA Ost (Nord-Virginia) (**2** auf der Karte) hinzufügen. Der Datenverkehr wird an die Ressource in dieser Region aus einem größeren Teil Nordamerikas als zuvor und aus ganz Südamerika weitergeleitet.
![\[Eine Weltkarte, die zeigt, wie Datenverkehr weitergeleitet wird, wenn Sie einen Bias-Wert von +25 in der Region USA Ost (Nord-Virginia) hinzufügen.\]](http://docs.aws.amazon.com/de_de/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-plus-25.png)
Die folgende Karte zeigt, was passiert, wenn Sie einen Bias-Wert von -25 für die Region USA Ost (Nord-Virginia) hinzufügen. Der Datenverkehr wird an die Ressource in dieser Region aus kleineren Teilen Nord- und Südamerikas als zuvor weitergeleitet und mehr Datenverkehr an Ressourcen in den angrenzenden Regionen **1**, **3** und **5**.
![\[Eine Weltkarte, die zeigt, wie Datenverkehr weitergeleitet wird, wenn Sie einen Bias-Wert von -25 in der Region USA Ost (Nord-Virginia) hinzufügen.\]](http://docs.aws.amazon.com/de_de/Route53/latest/DeveloperGuide/images/traffic-flow-geoproximity-map-example-bias-minus-25.png)
------
Die Auswirkungen der Änderung des Bias-Werts für Ihre Ressourcen ist von einer Reihe von Faktoren abhängig, einschließlich der folgenden:
+ Die Anzahl der Ressourcen, die Sie besitzen.
+ Die Nähe der Ressourcen zueinander.
+ Die Anzahl der Benutzer, die Sie in der Nähe des Grenzbereichs zwischen geografischen Regionen besitzen. Angenommen, Sie haben Ressourcen in den AWS-Regionen USA Ost (Nord-Virginia) und USA West (Oregon) und Sie haben viele Benutzer in Dallas, Austin und San Antonio, Texas, USA. Diese Städte sind ungefähr gleich weit von Ihren Ressourcen entfernt, sodass eine kleine Änderung der Ausrichtung zu einer starken Verlagerung des Datenverkehrs von Ressourcen zwischen Ressourcen führen kann. AWS-Region
Es wird empfohlen, den Bias-Wert in kleinen Schritten zu ändern, um eine Überlastung Ihrer Ressourcen aufgrund einer unerwarteten Verlagerung des Datenverkehrs zu vermeiden.
Weitere Informationen finden Sie unter [Wie Amazon Route 53 verwendet EDNS0 , um den Standort eines Benutzers zu schätzen](routing-policy-edns0.md).
## So verwendet Amazon Route 53 Bias-Werte
Mit folgender Formel bestimmt Amazon Route 53, wie der Datenverkehr weitergeleitet wird:
**Bias**
`Biased distance = actual distance * [1 - (bias/100)]`
Wenn der Wert der Abweichung positiv ist, behandelt Route 53 die Quelle einer DNS-Abfrage und die Ressource, die Sie in einem Geoproximitätsdatensatz angeben (z. B. eine EC2-Instance in einem AWS-Region), so, als ob sie näher beieinander lägen, als sie tatsächlich sind. Angenommen, Sie haben folgende Datensätze der geografischen Nähe:
+ Einen Datensatz für Webserver A mit dem positiven Bias-Wert 50
+ Einen Datensatz für Webserver B ohne Bias-Wert
Wenn ein Datensatz der geografischen Nähe über den positiven Bias-Wert 50 verfügt, halbiert Route 53 die Entfernung zwischen der Quelle einer Abfrage und der Ressource für diesen Datensatz. Anschließend berechnet Route 53, welche Ressourcen näher an der Quelle der Abfrage liegt. Nehmen wir an, Webserver A ist 150 Kilometer von der Quelle einer Abfrage und Webserver B 100 Kilometer von der Quelle der Abfrage entfernt. Wenn kein Datensatz über einen Bias-Wert verfügt, leitet Route 53 die Abfrage an Webserver B weiter, da dieser näher liegt. Da der Datensatz für Webserver A jedoch über einen positiven Bias-Wert 50 verfügt, behandelt Route 53 Webserver A so, als wäre er 75 Kilometer von der Quelle der Abfrage entfernt. Dies hat zur Folge, dass Route 53 die Abfrage an Webserver A weiterleitet.
Nachfolgend ist die Berechnung für den positiven Bias-Wert 50 aufgeführt:
```
Bias = 50
Biased distance = actual distance * [1 - (bias/100)]
Biased distance = 150 kilometers * [1 - (50/100)]
Biased distance = 150 kilometers * (1 - .50)
Biased distance = 150 kilometers * (.50)
Biased distance = 75 kilometers
```
# Latenzbasiertes Routing
Wenn Ihre Anwendung auf mehreren Servern gehostet wird AWS-Regionen, können Sie die Leistung für Ihre Benutzer verbessern, indem Sie ihre Anfragen von dem Server aus bearbeiten AWS-Region , der die niedrigste Latenz bietet.
**Anmerkung**
Die Daten über die Latenz zwischen Benutzern und Ihren Ressourcen basieren ausschließlich auf dem Datenverkehr zwischen Benutzern und AWS -Rechenzentren. Wenn Sie keine Ressourcen in einem verwenden AWS-Region, kann die tatsächliche Latenz zwischen Ihren Benutzern und Ihren Ressourcen erheblich von den AWS Latenzdaten abweichen. Das gilt auch dann, wenn sich Ihre Ressourcen in der gleichen Stadt befinden wie eine AWS-Region.
Um latenzbasiertes Routing zu verwenden, erstellen Sie Latenzdatensätze für Ihre Ressourcen in mehreren AWS-Regionen. Wenn Route 53 eine DNS-Abfrage für Ihre Domain oder Subdomain (example.com oder acme.example.com) erhält, wird ermittelt, für welche AWS-Regionen Sie Latenzdatensätze erstellt haben und welche Region dem Benutzer die niedrigste Latenz bietet. Anschließend wird ein Latenzdatensatz für diese Region ausgewählt. Route 53 antwortet mit dem Wert aus dem ausgewählten Datensatz, z. B. der IP-Adresse für einen Webserver.
Ein Beispiel: Sie verfügen über Elastic Load Balancing Load Balancer in den Regionen USA West (Oregon) und Asien-Pazifik (Singapur). Sie erstellen einen Latenzdatensatz für jeden Load Balancer. Wenn nun ein Benutzer in London den Namen Ihrer Domain in einen Browser eingibt, geschieht Folgendes:
1. DNS leitet die Abfrage an einen Route-53-Namensserver weiter.
1. Route 53 prüft die Latenzdaten zwischen London und der Region Singapur und zwischen London und der Region Oregon.
1. Wenn die Latenz zwischen den Regionen London und Oregon geringer ist, beantwortet Route 53 die Abfrage mit der IP-Adresse für den Oregon-Load Balancer. Wenn die Latenz zwischen den Regionen London und Singapur geringer ist, beantwortet Route 53 die Abfrage mit der IP-Adresse für den Singapur-Load Balancer.
Die Latenz zwischen Hosts im Internet kann sich im Laufe der Zeit ändern. Der Grund dafür sind Veränderungen in puncto Netzwerkkonnektivität und Routing. Latenzbasiertes Routing basiert auf Latenzmessungen, die während eines bestimmten Zeitraums erfasst werden, und die Messungen tragen diesen Änderungen Rechnung. Eine Anforderung, die diese Woche an die Region Oregon weitergeleitet wird, wird nächste Woche möglicherweise an die Region Singapur weitergeleitet.
**Anmerkung**
Wenn ein Browser oder ein anderer Viewer einen DNS-Resolver verwendet, der die edns-client-subnet Erweiterung von unterstützt EDNS0, sendet der DNS-Resolver an Route 53 eine gekürzte Version der IP-Adresse des Benutzers. Wenn Sie latenzbasiertes Routing konfigurieren, berücksichtigt Route 53 diesen Wert, wenn Datenverkehr zu Ihren Ressourcen weitergeleitet wird. Weitere Informationen finden Sie unter [Wie Amazon Route 53 verwendet EDNS0 , um den Standort eines Benutzers zu schätzen](routing-policy-edns0.md).
Sie können Latenz-Routing für Datensätze in einer privat gehosteten Zone verwenden.
Informationen zu Werten, die Sie angeben, wenn Sie die einfache Latenz-Routingrichtlinie zum Erstellen von Datensätzen verwenden, finden Sie in den folgenden Themen:
+ [Spezifische Werte für Latenz-Datensätze](resource-record-sets-values-latency.md)
+ [Spezifische Werte für Latenz-Aliasdatensätze](resource-record-sets-values-latency-alias.md)
+ [Typische Werte für alle Routing-Richtlinien](resource-record-sets-values-shared.md)
+ [Werte, die für Aliasdatensätze für alle Routing-Richtlinien typisch sind](resource-record-sets-values-alias-common.md)
# Latenzbasiertes Routing in privat gehosteten Zonen
Für privat gehostete Zonen beantwortet Route 53 DNS-Anfragen mit einem Endpunkt AWS-Region, der sich in derselben oder der nächstgelegenen Entfernung zu AWS-Region der VPC befindet, von der die Anfrage stammt.
**Anmerkung**
Wenn Sie einen ausgehenden Endpunkt an einen eingehenden Endpunkt weitergeleitet haben, wird der Datensatz basierend darauf aufgelöst, wo sich der eingehende Endpunkt befindet, nicht der ausgehende Endpunkt.
Wenn Sie Zustandsprüfungen einbeziehen und der Datensatz mit der niedrigsten Latenz zum Ursprung der Abfrage nicht ordnungsgemäß ist, wird ein fehlerfreier Endpunkt mit der nächstniedrigsten Latenz zurückgegeben.
In der Beispielkonfiguration in der folgenden Abbildung werden DNS-Abfragen, die von einem us-east-1 kommen oder AWS-Region diesem am nächsten liegen, an den 1.1.1.1-Endpunkt weitergeleitet. DNS-Abfragen aus „us-west-2“ oder der nächstgelegenen Region werden an den Endpunkt 2.2.2.2 weitergeleitet.
![\[Ein Screenshot von zwei Latenzdatensätzen für eine privat gehostete Zone\]](http://docs.aws.amazon.com/de_de/Route53/latest/DeveloperGuide/images/latency-phz.png)
# IP-basiertes Routing
Mit IP-basiertem Routing in Amazon Route 53 können Sie Ihr DNS-Routing feinabstimmen, indem Sie Ihr Verständnis für Ihr Netzwerk, Ihre Anwendungen und Clients nutzen, um die besten DNS-Routing-Entscheidungen für Ihre Endbenutzer zu treffen. IP-basiertes Routing bietet Ihnen eine detaillierte Steuerung zur Optimierung der Leistung oder zur Senkung der Netzwerkkosten, indem Sie Ihre Daten in Form von Zuordnungen auf Route 53 hochladen. user-IP-to-endpoint
Geolokalisierung und latenzbasiertes Routing basieren auf Daten, die Route 53 sammelt und auf dem neuesten Stand hält. Dieser Ansatz funktioniert gut für die Mehrheit der Kunden, aber IP-basiertes Routing bietet Ihnen die zusätzliche Möglichkeit, das Routing basierend auf spezifischen Kenntnissen Ihres Kundenstamms zu optimieren. Beispielsweise möchte ein globaler Anbieter von Videoinhalten möglicherweise Endbenutzer von einem bestimmten Internetdienstanbieter (ISP) weiterleiten.
Nachfolgend finden Sie einige gängige Anwendungsfälle für IP-basiertes Routing:
+ Sie möchten Endbenutzer von bestimmten zu bestimmten Endpunkten weiterleiten ISPs , um die Kosten oder die Leistung des Netzwerks zu optimieren.
+ Sie möchten bestehenden Route-53-Routing-Typen wie dem Geolocation-Routing basierend auf Ihrem Wissen über die physischen Standorte Ihrer Kunden Außerkraftsetzungen hinzufügen.
**IP-Bereiche verwalten und sie einem Ressourcendatensatz zuordnen () RRSet**
Für IPv4 können Sie CIDR-Blöcke mit einer Länge von 1 bis einschließlich 24 Bit verwenden, während Sie für IPv6 CIDR-Blöcke mit einer Länge von 1 bis einschließlich 48 Bit verwenden können. Um einen Null-Bit-CIDR-Block (0.0.0.0/0 oder: ::/0) zu definieren, verwenden Sie den Standardstandort („\$1“).
Bei DNS-Abfragen mit einem CIDR, der länger ist als der in der CIDR-Sammlung angegebene, ordnet Route 53 ihn dem kürzeren CIDR zu. Wenn Sie beispielsweise 2001:0DB8: :/32 als CIDR-Block in Ihrer CIDR-Sammlung angeben und eine Abfrage von DB8 2001:0:0000:1234: :/48 stammt, entspricht sie. Wenn Sie dagegen 2001:0DB8: 0000:1234: :/48 in Ihrer CIDR-Sammlung angeben und eine Abfrage von 2001:0DB8: :/32 stammt, stimmt dies nicht überein und Route 53 antwortet mit dem Datensatz für den Standardstandort („\$1“).
Sie können Sätze von CIDR-Blöcken (oder IP-Bereichen) in CIDR-Standorten gruppieren, die wiederum in wiederverwendbare Entitäten gruppiert sind, die als CIDR-Sammlungen bezeichnet werden:
**CIDR-Block**
Ein IP-Bereich in CIDR-Notation, zum Beispiel 192.0.2.0/24 oder 2001:: :/32. DB8
**CIDR-Standort**
Eine benannte Liste von CIDR-Blöcken. Zum Beispiel example-isp-seattle = [192.0.2.0/24, 203.0.113.0/22, 198.51.100.0/24, 2001:: :/32]. DB8 Die Blöcke in einer CIDR-Standortliste müssen nicht benachbart sein oder über denselben Bereich verfügen.
Eine einzelne Position kann sowohl als auch IPv6 Blöcke enthalten, und diese Position kann sowohl A IPv4 - als auch AAAA-Datensätzen zugeordnet werden.
Der Standortname ist gemäß Konvention häufig ein Ort, kann aber auch eine beliebige Zeichenfolge sein (z. B. *Unternehmen-A*).
**CIDR-Sammlung**
Eine benannte Sammlung von Standorten. Zum Beispiel mycollection = [example-isp-seattle, example-isp-tokyo].
IP-basierte Routingressourcensätze verweisen auf einen Standort in einer Sammlung, und alle Ressourceneintragssätze für denselben Datensatzsatznamen und -typ müssen auf dieselbe Auflistung verweisen. Wenn Sie beispielsweise Websites in zwei Regionen erstellen und DNS-Abfragen von zwei verschiedenen CIDR-Standorten basierend auf den ursprünglichen IP-Adressen an eine bestimmte Website leiten möchten, müssen beide Standorte in der gleichen CIDR-Sammlung aufgeführt sein.
Sie können Richtlinien für IP-basiertes Routing nicht für Datensätze in einer privat gehosteten Zone verwenden.
Informationen zu Werten, die Sie angeben, wenn Sie die IP-basierte Routingrichtlinie zum Erstellen von Datensätzen verwenden, finden Sie in den folgenden Themen:
+ [Spezifische Werte für IP-basierte Datensätze](resource-record-sets-values-ipbased.md)
+ [Spezifische Werte für IP-basierte Aliasdatensätze](resource-record-sets-values-ipbased-alias.md)
+ [Typische Werte für alle Routing-Richtlinien](resource-record-sets-values-shared.md)
+ [Werte, die für Aliasdatensätze für alle Routing-Richtlinien typisch sind](resource-record-sets-values-alias-common.md)
**Topics**
+ [Erstellen einer CIDR-Sammlung mit CIDR-Standorten und -Blöcken](resource-record-sets-creating-cidr-collection.md)
+ [Arbeiten mit CIDR-Standorten und -Blöcken](resource-record-sets-working-with-cidr-locations.md)
+ [Löschen einer CIDR-Sammlung](resource-record-sets-delete-cidr-collection.md)
+ [Verschieben einer Geolokalisierung zu IP-basiertem Routing](resource-record-sets-move-geolocation-to-cidr.md)
# Erstellen einer CIDR-Sammlung mit CIDR-Standorten und -Blöcken
Erstellen Sie zunächst eine CIDR-Sammlung und fügen Sie CIDR-Blöcke und -Standorte hinzu.
**Erstellen Sie eine CIDR-Sammlung mithilfe der Route-53-Konsole wie folgt:**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Wählen Sie im Navigationsbereich **IP-based routing** (IP-basiertes Routing) und dann **CIDR collections** (CIDR-Sammlungen) aus.
1. Wählen Sie **Create CIDR collection** (CIDR-Sammlung erstellen) aus.
1. Geben Sie im Bereich **Create CIDR collection** (CIDR-Sammlung erstellen) unter **Details** (Details) den Namen für die Sammlung ein.
1. Wählen Sie **Create collection** (Sammlung erstellen) aus, um eine leere Sammlung zu erstellen.
– oder –
Im Abschnitt **CIDR-Standorte erstellen** geben Sie im Feld **CIDR-Standort** einen Namen für den CIDR-Standort ein. Der Standortname kann eine beliebige identifizierende Zeichenfolge sein, z. B. **company 1** oder **Seattle**. Es muss kein tatsächlicher geografischer Standort sein.
**Wichtig**
Der CIDR-Standortsname hat eine maximale Länge von 16 Zeichen.
Geben Sie die CIDR-Blöcke in das Feld **CIDR-Blöcke** ein, einen pro Zeile. Dabei kann es sich IPv4 um IPv6 Adressen im Bereich von /0 bis /24 für IPv4 und /0 bis /48 für handeln. IPv6
1. Nachdem Sie die CIDR-Blöcke eingegeben haben, wählen Sie **Create CIDR collection** (CIDR-Sammlung erstellen) oder **Add another location** (Weiteren Standort hinzufügen), um weitere Standorte und CIDR-Blöcke einzugeben. Sie können mehrere CIDR-Standorte pro Sammlung eingeben.
1. Wählen Sie, nachdem Sie CIDR-Standorte eingegeben haben, **Create CIDR collection** (CIDR-Sammlung erstellen) aus.
# Arbeiten mit CIDR-Standorten und -Blöcken
**Arbeiten Sie mit CIDR-Standorten über die Route-53-Konsole wie folgt:**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. Wählen Sie im Navigationsbereich **IP-based routing** (IP-basiertes Routing), **CIDR collections** (CIDR-Sammlungen) und dann im Bereich **CIDR collections** (CIDR-Sammlungen) einen Link zu einer CIDR-Sammlung aus der Liste **Collection name** (Name der Sammlung) aus.
Auf der Seite **CIDR-Standorte** können Sie einen CIDR-Standort erstellen, löschen oder einen Standort und seine Blöcke bearbeiten.
+ Um einen Standort zu erstellen, wählen Sie **Create CIDR location** (CIDR-Standort erstellen) aus.
+ Geben Sie im Bereich**Create CIDR location** (CIDR-Standort erstellen) einen Namen für den Standort und die mit dem Standort verknüpften CIDR-Blöcke ein, und wählen Sie dann **Create** (Erstellen) aus.
+ Um einen CIDR-Standort und die darin enthaltenen Blöcke anzuzeigen, wählen Sie das Optionsfeld neben einem Standort aus, um den Namen und die CIDR-Blöcke im Standortbereich anzuzeigen.
In diesem Bereich können Sie auch **Bearbeiten** auswählen, um den Namen des Standorts oder seine CIDR-Blöcke zu aktualisieren. Wählen Sie **Save** (Speichern) aus, wenn Sie mit der Bearbeitung fertig sind.
+ Wählen Sie zum Löschen eines CIDR-Standorts und der darin enthaltenen Blöcke das Optionsfeld neben dem Standort, den Sie löschen möchten, und wählen Sie dann **Delete** (Löschen) aus. Um den Löschvorgang zu bestätigen, geben Sie den Standortnamen in das Texteingabefeld ein und wählen Sie erneut **Delete** (Löschen) aus.
**Wichtig**
Das Löschen eines CIDR-Standorts kann nicht rückgängig gemacht werden. Wenn Sie DNS-Datensätze mit dem Standort verknüpft haben, ist Ihre Domain möglicherweise nicht mehr erreichbar.
# Löschen einer CIDR-Sammlung
**Löschen Sie eine CIDR-Sammlung, ihre Standorte und Blöcke mithilfe der Route-53-Konsole wie folgt:**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Wählen Sie im Navigationsbereich **IP-based routing** (IP-basiertes Routing) und dann **CIDR collections** (CIDR-Sammlungen) aus.
1. Klicken Sie im Bereich **CIDR collection** (CIDR-Sammlung) auf den verknüpften Namen der Sammlung, die Sie löschen möchten.
1. Auf der Seite **CIDR locations** wählen Sie jeden Standort einzeln aus. Wählen Sie danach **Delete** (Löschen) aus, geben Sie im Dialogfeld den Namen ein und wählen Sie dann **Delete** (Löschen) aus. Sie müssen jeden Standort löschen, der einer CIDR-Auflistung zugeordnet ist, bevor die Sammlung gelöscht werden kann.
1. Nachdem die Löschung jedes CIDR-Standorts abgeschlossen ist, wählen Sie auf der Seite **CIDR locations** (CIDR-Standorte) das Optionsfeld neben der Sammlung aus, die Sie löschen möchten, und wählen Sie dann **Delete** (Löschen) aus.
# Verschieben einer Geolokalisierung zu IP-basiertem Routing
Wenn Sie entweder Geolokalisierungs- oder Geoproximity-Routing-Richtlinien verwenden und bestimmte Clients konsequent an einen Endpunkt weitergeleitet werden, der basierend auf ihrem physischen Standort oder ihrer Netzwerktopologie nicht optimal ist, können Sie die öffentlichen IP-Bereiche dieser Clients besser mit IP-basiertem Routing ansprechen.
Die folgende Tabelle enthält eine Beispiel-Geolokalisierungskonfiguration für ein vorhandenes Geolokalisierungs-Routing, das wir auf kalifornische IP-Bereiche abstimmen werden.
| Datensatzsatzname | Routing-Richtlinie und -Ursprung | IP-Adresse des Anwendungsendpunkts |
| --- | --- | --- |
| example.com | Geolocation-Routing (USA) | `198.51.100.1` |
| example.com | Geolocation-Routing (EU) | `198.51.100.2` |
Um IP-Bereiche von Kalifornien zu überschreiben und zu einem neuen Anwendungsendpunkt zu wechseln, erstellen Sie zuerst das Geolokalisierungs-Routing unter einem neuen Datensatznamen neu.
| Datensatzname | Routing-Richtlinie und -Ursprung | IP-Adresse des Anwendungsendpunkts |
| --- | --- | --- |
| geo.beispiel.com | Geolocation-Routing (USA) | `198.51.100.1` |
| geo.beispiel.com | Geoloaktion-Routing (EU) | `198.51.100.2` |
Erstellen Sie dann IP-basierte Routing-Datensätze und einen Standarddatensatz, der auf Ihren kürzlich neu erstellten Geolocation-Routing-Datensatz verweist.
| Datensatzname | Routing-Richtlinie und -Ursprung | IP-Adresse des Anwendungsendpunkts |
| --- | --- | --- |
| example.com | IP-basiertes Routing (Standard) | Alias-Datensatz für geo.example.com-Anwendungsendpunkt, den Sie als Standard festlegen möchten Beispiel, `198.51.100.1`. |
| example.com | IP-basiertes Routing (kalifornische IP-Bereiche) | `198.51.100.3` |
# Mehrwertiges Antwort-Routing
Bei mehrwertigem Antwort-Routing können Sie Amazon Route 53 so konfigurieren, dass mehrere Werte als Antwort auf DNS-Abfragen zurückgegeben werden, beispielsweise IP-Adressen für Ihre Webserver. Sie können mehrere Werte für nahezu jeden Datensatz festlegen, doch das mehrwertige Antwort-Routing ermöglicht es Ihnen auch, den Zustand jeder Ressource zu überprüfen, sodass Route 53 nur Werte für fehlerfreie Ressourcen zurückgibt. Dies ist kein Ersatz für einen Load Balancer, doch die Möglichkeit, mehrere IP-Adressen mit überprüfbarem Zustand zurückzugeben, ist eine Möglichkeit, DNS zur Verbesserung der Verfügbarkeit und des Lastenausgleichs zu verwenden.
Um Datenverkehr praktisch zufällig zu mehreren Ressourcen weiterzuleiten, beispielsweise Webserver, erstellen Sie einen mehrwertigen Antwortdatensatz für jede Ressource und ordnen optional jedem Datensatz eine Route-53-Zustandsprüfung zu. Route 53 beantwortet DNS-Abfragen mit bis zu acht fehlerfreien Datensätzen und gibt verschiedenen DNS-Resolvern verschiedene Antworten. Wenn ein Webserver nicht mehr verfügbar ist, nachdem ein Resolver eine Antwort im Cache speichert, kann die Client-Software eine andere IP-Adresse in der Antwort ausprobieren.
Beachten Sie Folgendes:
+ Wenn Sie einem mehrwertigen Antwortdatensatz eine Zustandsprüfung zuordnen, beantwortet Route 53 DNS-Abfragen nur dann mit der entsprechenden IP-Adresse, wenn die Zustandsprüfung ein fehlerfreies Ergebnis liefert.
+ Wenn Sie einen Health Check nicht mit einem mehrwertigen Antwortdatensatz verknüpfen, betrachtet Route 53 den Datensatz immer als fehlerfrei.
+ Wenn Sie über acht oder weniger fehlerfreie Datensätze verfügen, beantwortet Route 53 alle DNS-Abfragen mit allen fehlerfreien Datensätzen.
+ Wenn alle Datensätze fehlerhaft sind, beantwortet Route 53 DNS-Abfragen mit bis zu acht fehlerhaften Datensätzen.
Sie können mehrwertiges Antwort-Routing für Datensätze in einer privat gehosteten Zone verwenden.
Informationen zu den Werten, die Sie angeben, wenn Sie die Routing-Richtlinie von mehrwertigen Antworten zum Erstellen von Datensätzen verwenden, finden Sie unter [Werte für spezifische mehrwertige Antwort-Datensätze](resource-record-sets-values-multivalue.md) und [Typische Werte für alle Routing-Richtlinien](resource-record-sets-values-shared.md).
# Gewichtetes Routing
Beim gewichteten Routing können Sie mehrere Ressourcen einem einzelnen Domainnamen (example.com) oder Subdomainnamen (acme.example.com) zuordnen und auswählen, wieviel Datenverkehr zu jeder Ressource geleitet wird. Dies kann für verschiedene Zwecke nützlich sein, beispielsweise für den Lastenausgleich und das Testen neuer Softwareversionen.
Um gewichtetes Routing zu konfigurieren, müssen Sie Datensätze mit demselben Namen und Typ für jede Ihrer Ressourcen erstellen. Sie ordnen jedem Datensatz eine relative Gewichtung zu, die dem Volumen an Datenverkehr entspricht, das Sie jeder Ressource senden möchten. Amazon Route 53 sendet Datenverkehr auf Basis der Gewichtung, die Sie einem Datensatz zugeordnet haben, an eine Ressource. Diese Gewichtung stellt einen Anteil der Gesamtgewichtung für alle Datensätze in der Gruppe dar:
![\[Formel zur Berechnung, wie viel Datenverkehr an eine bestimmte Ressource weitergeleitet wird: Gewichtung für einen angegebenen Datensatz/Summe der Gewichtung für alle Datensätze.\]](http://docs.aws.amazon.com/de_de/Route53/latest/DeveloperGuide/images/WRR_calculation.png)
Wenn Sie beispielsweise einen sehr kleinen Teil Ihres Datenverkehrs an eine Ressource senden möchten und den Rest an eine andere Ressource, können Sie Gewichtungen von 1 und 255 angeben. Die Ressource mit der Gewichtung 1 erhält 1/256 des Datenverkehrs (1/1\$1255) und die andere Ressource erhält 255/256 des Datenverkehrs (255/1\$1255). Sie können die Waage schrittweise ändern, indem Sie die Gewichte ändern. Wenn Sie keinen Datenverkehr mehr an eine Ressource senden möchten, können Sie die Gewichtung für diesen Datensatz auf 0 setzen.
Informationen zu Werten, die Sie angeben, wenn Sie die einfache gewichtete Routingrichtlinie zum Erstellen von Datensätzen verwenden, finden Sie in den folgenden Themen:
+ [Spezifische Werte für gewichtete Datensätze](resource-record-sets-values-weighted.md)
+ [Spezifische Werte für gewichtete Aliasdatensätze](resource-record-sets-values-weighted-alias.md)
+ [Typische Werte für alle Routing-Richtlinien](resource-record-sets-values-shared.md)
+ [Werte, die für Aliasdatensätze für alle Routing-Richtlinien typisch sind](resource-record-sets-values-alias-common.md)
Sie können gewichtetes Routing für Datensätze in einer privat gehosteten Zone verwenden.
## Zustandsprüfungen und gewichtetes Routing
Wenn Sie Zustandsprüfungen für alle Datensätze in einer Gruppe von gewichteten Datensätzen hinzufügen, Sie einigen Datensätze jedoch Gewichtungen ungleich Null und anderen Gewichtungen gleich Null geben, funktionieren Zustandsprüfungen ebenso, als ob alle Datensätze Gewichtungen ungleich Null hätten, mit den folgenden Ausnahmen:
+ Route 53 berücksichtigt zu Beginn nur die mit nicht-null gewichteten Datensätze, wenn vorhanden.
+ Wenn alle Datensätze mit einer Gewichtung größer als 0 fehlerhaft sind, berücksichtigt Route 53 die mit Null gewichteten Datensätze.
In der folgenden Tabelle erfahren Sie, was passiert, wenn der mit Null gewichtete Datensatz eine Zustandsprüfung beinhaltet:
| | Datensatz 1 | Datensatz 2 | Datensatz 3 |
| --- |--- |--- |--- |
| Gewicht | 1 | 1 | 0 |
| Zustandsprüfung enthalten? | Ja | Ja | Ja |
| |
| --- |
| Status der Zustandsprüfung | Fehlerhaft | Fehlerhaft | Fehlerfrei |
| DNS-Abfrage beantwortet? | Nein | Nein | Ja |
| |
| --- |
| Status der Zustandsprüfung | Fehlerhaft | Fehlerhaft | Fehlerhaft |
| DNS-Abfrage beantwortet? | Ja | Ja | Nein |
| |
| --- |
| Status der Zustandsprüfung | Fehlerhaft | Fehlerfrei | Fehlerhaft |
| DNS-Abfrage beantwortet? | Nein | Ja | Nein |
| |
| --- |
| Status der Zustandsprüfung | Fehlerfrei | Fehlerfrei | Fehlerhaft |
| DNS-Abfrage beantwortet? | Ja | Ja | Nein |
| |
| --- |
| Status der Zustandsprüfung | Fehlerfrei | Fehlerfrei | Fehlerfrei |
| DNS-Abfrage beantwortet? | Ja | Ja | Nein |
In der folgenden Tabelle erfahren Sie, was passiert, wenn der mit Null gewichtete Datensatz keine Zustandsprüfung beinhaltet:
| | Datensatz 1 | Datensatz 2 | Datensatz 3 |
| --- |--- |--- |--- |
| Gewicht | 1 | 1 | 0 |
| Zustandsprüfung enthalten? | Ja | Ja | Nein |
| |
| --- |
| Status der Zustandsprüfung | Fehlerfrei | Fehlerfrei | – |
| DNS-Abfrage beantwortet? | Ja | Ja | Nein |
| |
| --- |
| Status der Zustandsprüfung | Fehlerhaft | Fehlerhaft | – |
| DNS-Abfrage beantwortet? | Nein | Nein | Ja |
| |
| --- |
| Status der Zustandsprüfung | Fehlerhaft | Fehlerfrei | – |
| DNS-Abfrage beantwortet? | Nein | Ja | Nein |
# Wie Amazon Route 53 verwendet EDNS0 , um den Standort eines Benutzers zu schätzen
Um die Genauigkeit von Geolokalisierung, Geoproximität, IP-basiertem Routing und Latenz-Routing zu verbessern, unterstützt Amazon Route 53 die Erweiterung von. edns-client-subnet EDNS0 (EDNS0 fügt dem DNS-Protokoll mehrere optionale Erweiterungen hinzu.) Route 53 kann edns-client-subnet nur verwendet werden, wenn DNS-Resolver sie unterstützen:
+ Wenn ein Browser oder ein anderer Viewer einen DNS-Resolver verwendet, der dies nicht unterstützt edns-client-subnet, verwendet Route 53 die Quell-IP-Adresse des DNS-Resolvers, um den ungefähren Standort des Benutzers zu ermitteln, und beantwortet Geolocation-Abfragen mit dem DNS-Eintrag für den Standort des Resolvers.
+ Wenn ein Browser oder ein anderer Viewer einen DNS-Resolver verwendet, der dies unterstützt edns-client-subnet, sendet der DNS-Resolver Route 53 eine gekürzte Version der IP-Adresse des Benutzers. Route 53 bestimmt den Standort des Benutzers auf Basis der abgeschnittenen IP-Adresse anstelle der Quell-IP-Adresse des DNS-Resolvers. Das führt in der Regel zu einer präziseren Schätzung des Standorts eines Benutzers. Route 53 beantwortet Geolocation-Abfragen dann mit dem DNS-Datensatz für den Standort des Benutzers.
+ EDNS0 gilt nicht für private gehostete Zonen. Für privat gehostete Zonen verwendet Route 53 Daten von den VPC-Resolvern, in denen sich AWS-Region die private gehostete Zone befindet, um Entscheidungen über Geolokalisierung und Latenzrouting zu treffen.
[Weitere Informationen zu finden Sie im EDNS-Client-Subnetz-RFC edns-client-subnet, Client-Subnetz in DNS-Anfragen.](https://www.rfc-editor.org/rfc/rfc7871)
# Wählen zwischen Alias- und Nicht-Alias-Datensätzen
Amazon-Route-53-*Aliasdatensätze* bieten eine Route-53-spezifische Erweiterung der DNS-Funktionalität. Mit Alias-Datensätzen können Sie Traffic an ausgewählte AWS Ressourcen weiterleiten, einschließlich, aber nicht beschränkt auf CloudFront Distributionen und Amazon S3 S3-Buckets. Außerdem können Sie Datenverkehr von einem Datensatz in einer gehosteten Zone an einen anderen Datensatz weiterleiten.
Im Gegensatz zu einem CNAME-Datensatz können Sie einen Aliasdatensatz am obersten Knoten eines DNS-Namespace erstellen, auch bekannt als *Zone Apex*. Wenn Sie beispielsweise den DNS-Namen example.com registriert haben, lautet der Zone Apex example.com. Sie können keinen CNAME-Datensatz für example.com erstellen, aber Sie können einen Alias-Datensatz für example.com erstellen, der den Datenverkehr an www.example.com weiterleitet (solange www.example.com nicht des Typs CNAME ist).
Wenn Route 53 eine DNS-Abfrage für einen Alias-Datensatz erhält, beantwortet Route 53 sie mit dem entsprechenden Wert für diese Ressource:
+ **Eine Amazon-API-Gateway benutzerdefinierte regionale API oder Edge-optimierte API ** – Route 53 antwortet mit einer oder mehreren IP-Adressen für Ihre API.
+ **Ein Amazon-VPC-Schnittstellendpunkt** – Route 53 antwortet mit einer oder mehreren IP-Adressen für Ihren Schnittstellenendpunkt.
+ **Eine CloudFront Verteilung** — Route 53 antwortet mit einer oder mehreren IP-Adressen für CloudFront Edge-Server, die Ihre Inhalte bereitstellen können.
+ **App Runner-Dienst** — Route 53 antwortet mit einer oder mehreren IP-Adressen.
+ **Eine Elastic-Beanstalk-Umgebung** – Route 53 antwortet mit einer oder mehreren IP-Adressen für die Umgebung.
+ **Ein Elastic Load Balancing Load Balancer**: Route 53 antwortet mit einer oder mehreren IP-Adressen für den Load Balancer. Dazu gehören Application Load Balancer, Classic Load Balancer und Network Load Balancer.
+ **Ein AWS Global Accelerator Beschleuniger** — Route 53 antwortet mit den IP-Adressen für den Beschleuniger.
+ **Ein OpenSearch Dienst** — Route 53 antwortet mit einer oder mehreren IP-Adressen für die benutzerdefinierte OpenSearch Dienstdomäne.
+ **Ein Amazon-S3-Bucket, das als statische Website konfiguriert ist** – Route 53 antwortet mit einer IP-Adresse für den Amazon-S3-Bucket.
+ **Ein anderer Route-53-Datensatz desselben Typs in derselbenen gehosteten Zone** – Route 53 antwortet, als ob die Abfrage nach dem Datensatz gefragt hätte, auf den der Alias-Datensatz verweist (siehe [Vergleich von Alias- und CNAME-Datensätzen](#resource-record-sets-choosing-alias-non-alias-comparison)).
+ **AWS AppSync Domainname** — Route 53 antwortet mit einer oder mehreren IP-Adressen für Ihren Schnittstellenendpunkt.
Weitere Informationen finden Sie unter [Weiterleitung des Internetverkehrs zu Ihren AWS Ressourcen](routing-to-aws-resources.md).
Wenn Sie einen Aliaseintrag verwenden, um den Verkehr an eine AWS Ressource weiterzuleiten, erkennt Route 53 automatisch Änderungen an der Ressource. Angenommen, ein Alias-Datensatz für example.com verweist auf einen Elastic Load Balancing Load Balancer unter „lb1-1234.us-east-2.elb.amazonaws.com“. Wenn sich die IP-Adresse des Load Balancers ändert, beginnt Route 53 automatisch, DNS-Abfragen unter Verwendung der neuen IP-Adresse zu beantworten.
Wenn ein Aliaseintrag auf eine AWS Ressource verweist, können Sie die Gültigkeitsdauer (Time to Live, TTL) nicht festlegen. Route 53 verwendet die Standard-TTL für die Ressource. Wenn ein Alias-Datensatz auf einen anderen Datensatz in derselben gehosteten Zone verweist, verwendet Route 53 die TTL des Datensatzes, auf den der Alias-Datensatz verweist. Weitere Informationen zum aktuellen TTL-Wert für Elastic Load Balancing finden Sie unter [Anforderungs-Routing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#request-routing) im *Elastic-Load-Balancing-Benutzerhandbuch* und suchen Sie nach „ttl“.
Informationen zur Erstellung von Datensätzen mit der Route-53-Konsole finden Sie unter [Erstellen von Datensätzen mithilfe der Amazon-Route-53-Konsole](resource-record-sets-creating.md). Informationen über die Werte, die Sie für Alias-Datensätze festlegen, finden Sie unter dem entsprechenden Thema in [Werte, die Sie beim Erstellen oder Bearbeiten von Amazon Route 53-Datensätzen angeben](resource-record-sets-values.md):
+ [Spezifische Werte für einfache Aliasdatensätze](resource-record-sets-values-alias.md)
+ [Spezifische Werte für gewichtete Aliasdatensätze](resource-record-sets-values-weighted-alias.md)
+ [Spezifische Werte für Latenz-Aliasdatensätze](resource-record-sets-values-latency-alias.md)
+ [Spezifische Werte für Failover-Aliasdatensätze](resource-record-sets-values-failover-alias.md)
+ [Spezifische Werte für Geolocation-Aliasdatensätze](resource-record-sets-values-geo-alias.md)
+ [Spezifische Werte für Geoproximitäts-Aliasdatensätze](resource-record-sets-values-geoprox-alias.md)
+ [Werte, die für Aliasdatensätze für alle Routing-Richtlinien typisch sind](resource-record-sets-values-alias-common.md)
## Vergleich von Alias- und CNAME-Datensätzen
Alias-Datensätze ähneln CNAME-Datensätzen. Es gibt jedoch einige wichtige Unterschiede. Die folgende Liste vergleicht Alias- und CNAME-Datensätze.
**Ressourcen, an die Sie Abfragen umleiten können**
**Alias-Datensätze**
Ein Aliaseintrag kann Abfragen nur an ausgewählte AWS Ressourcen weiterleiten, einschließlich, aber nicht beschränkt auf die folgenden:
+ Amazon-S3-Buckets
+ CloudFront Verteilungen
+ Ein weiterer Datensatz in derselben gehosteten Route-53-Zone
Beispielsweise können Sie einen Alias-Datensatz mit dem Namen acme.example.com erstellen, der Abfragen an einen Amazon-S3-Bucket mit dem Namen acme.example.com weiterleitet. Sie können auch einen Alias-Datensatz acme.example.com erstellen, der Abfragen an einen Datensatz mit dem Namen zenith.example.com in der gehosteten Zone "example.com" weiterleitet.
**CNAME-Datensätze**
Ein CNAME-Datensatz kann DNS-Abfragen an einen beliebigen DNS-Datensatz weiterleiten. Sie können beispielsweise einen CNAME-Datensatz erstellen, der Abfragen von acme.example.com zu zenith.example.com bzw. zu acme.example.org weiterleitet. Sie müssen Route 53 nicht als DNS-Service für die Domain verwenden, an die Sie Abfragen weiterleiten.
**Erstellen von Datensätzen mit demselben Namen wie die Domain (Datensätze am Zone Apex)**
**Alias-Datensätze**
In den meisten Konfigurationen können Sie einen Alias-Datensatz erstellen, der denselben Namen wie die gehostete Zone hat (die Zone Apex). Die einzige Ausnahme ist, wenn Sie Abfragen aus der Zone Apex (z. B. example.com) an einen Datensatz in der gleichen gehosteten Zone weiterleiten, die einen Typ CNAME hat (z. B. zenith.example.com). Der Typ des Alias-Datensatzes muss mit dem Typ des Datensatzes übereinstimmen, zu dem Sie Datenverkehr weiterleiten, und die Erstellung eines CNAME-Datensatzes für den Zone Apex auch für einen Alias-Datensatz nicht unterstützt wird.
**CNAME-Datensätze**
Es ist nicht möglich, einen CNAME-Datensatz zu erstellen, der denselben Namen wie die gehostete Zone (den Zone Apex) hat. Dies gilt sowohl für gehostete Zonen für Domainnamen (example.com) als auch für gehostete Zonen für Subdomains (zenith.example.com).
**Preise für DNS-Abfragen**
**Alias-Datensätze**
Route 53 erhebt keine Gebühren für Aliasabfragen an AWS Ressourcen. Weitere Informationen dazu finden Sie unter [Amazon Route 53 – Preise](https://aws.amazon.com/route53/pricing/).
**CNAME-Datensätze**
Route 53 berechnet Gebühren für CNAME-Abfragen.
Wenn Sie einen CNAME-Datensatz erstellen, der an den Namen eines anderen Datensatzes in einer gehosteten Route-53-Zone (dieselbe gehostete Zone oder eine andere gehostete Zone) umleitet, wird jede DNS-Abfrage als zwei Abfragen berechnet:
+ Route 53 antwortet auf die erste DNS-Abfrage mit dem Namen des Datensatzes, an den Sie umleiten möchten.
+ Dann muss der DNS-Resolver eine weitere Abfrage für den Datensatz in der ersten Antwort senden, um Informationen darüber zu erhalten, wohin der Datenverkehr umgeleitet werden soll, z. B. die IP-Adresse eines Webservers.
Wenn der CNAME-Datensatz an den Namen eines Datensatzes umgeleitet wird, der mit einem anderen DNS-Dienst gehostet wird, berechnet Route 53 eine Abfrage. Der andere DNS-Dienst stellt möglicherweise die zweite Abfrage in Rechnung.
**In der DNS-Abfrage angegebener Datensatztyp**
**Alias-Datensätze**
Route 53 antwortet auf eine DNS-Abfrage nur dann, wenn der Name des Alias-Datensatzes (z. B. acme.example.com) und der Typ des Alias-Datensatzes (z. B. A oder AAAA) mit dem Namen und Typ in der DNS-Abfrage übereinstimmt.
**CNAME-Datensätze**
Ein CNAME-Datensatz leitet DNS-Abfragen für einen Datensatznamen unabhängig von dem in der DNS-Abfrage angegebenen Datensatztyp (z. B. A oder AAAA) um.
**Wie Datensätze in dig oder nslookup Abfragen aufgelistet werden**
**Alias-Datensätze**
In der Antwort auf eine dig- oder nslookup-Abfrage wird ein Aliasdatensatz als der beim Erstellen des Datensatzes angegeben Datensatztyp aufgeführt, z. B. A oder AAAA. (Der Datensatztyp, den Sie für einen Alias-Datensatz angeben, hängt von der Ressource ab, an die Sie den Datenverkehr weiterleiten. Um Datenverkehr beispielsweise an einen S3 Bucket weiterzuleiten, geben Sie A als Typ an.) Die Alias-Eigenschaft ist nur in der Route 53-Konsole oder in der Antwort auf eine programmatische Anfrage, z. B. einen AWS `list-resource-record-sets` CLI-Befehl, sichtbar.
**CNAME-Datensätze**
Ein CNAME-Datensatz wird als CNAME-Datensatz in der Antwort auf dig- oder nslookup-Abfragen aufgeführt.
# Unterstützte DNS-Datensatztypen
Amazon Route 53 unterstützt die in diesem Abschnitt aufgelisteten DNS-Datensatztypen. Jeder Datensatztyp umfasst außerdem ein Beispiel dafür, wie das `Value`-Element formatiert wird, wenn Sie auf Route 53 mithilfe der API zugreifen.
**Anmerkung**
Geben Sie für Datensatztypen, die einen Domänennamen enthalten, einen vollständig qualifizierten Domänennamen ein, beispielsweise *www.example.com*. Der Punkt am Ende ist optional. Route 53 nimmt an, dass der Domänenname vollständig qualifiziert ist. Das bedeutet, dass *www.example.com* (ohne Punkt am Ende) und *www.example.com.* (mit Punkt am Ende) von Route 53 identisch gehandhabt werden.
Route 53 bietet eine Erweiterung der DNS-Funktionalität, die als Alias-Datensätze bezeichnet wird. Ähnlich wie bei CNAME-Einträgen können Sie mit Alias-Datensätzen Traffic an ausgewählte AWS Ressourcen wie CloudFront Distributionen und Amazon S3 S3-Buckets weiterleiten. Weitere Hinweise, einschließlich eines Vergleichs von Alias- und CNAME-Datensätzen, finden Sie unter [Wählen zwischen Alias- und Nicht-Alias-Datensätzen](resource-record-sets-choosing-alias-non-alias.md).
**Topics**
+ [A-Datensatztyp](#AFormat)
+ [AAAA-Datensatztyp](#AAAAFormat)
+ [CAA-Datensatztyp](#CAAFormat)
+ [CNAME-Datensatztyp](#CNAMEFormat)
+ [DS-Datensatztyp](#DSFormat)
+ [HTTPS-Datensatztyp](#HTTPSFormat)
+ [MX-Datensatztyp](#MXFormat)
+ [NAPTR-Datensatztyp](#NAPTRFormat)
+ [NS-Datensatztyp](#NSFormat)
+ [PTR-Datensatztyp](#PTRFormat)
+ [SOA-Datensatztyp](#SOAFormat)
+ [SPF-Datensatztyp](#SPFFormat)
+ [SRV-Datensatztyp](#SRVFormat)
+ [Typ des SSHFP-Eintrags](#SSHFPFormat)
+ [SVCB-Eintragstyp](#SVCBFormat)
+ [TLSA-Eintragstyp](#TLSAFormat)
+ [TXT-Datensatztyp](#TXTFormat)
## A-Datensatztyp
Sie verwenden einen A-Eintrag, um den Datenverkehr mithilfe einer IPv4 Adresse in punktierter Dezimalschreibweise an eine Ressource, z. B. einen Webserver, weiterzuleiten.
**Beispiel für die Amazon-Route-53-Konsole**
```
192.0.2.1
```
**Beispiel für die Route-53-API**
```
192.0.2.1
```
## AAAA-Datensatztyp
Sie verwenden einen AAAA-Eintrag, um den Datenverkehr mithilfe einer IPv6 Adresse im durch Doppelpunkte getrennten Hexadezimalformat an eine Ressource, z. B. einen Webserver, weiterzuleiten.
**Beispiel für die Amazon-Route-53-Konsole**
```
2001:0db8:85a3:0:0:8a2e:0370:7334
```
**Beispiel für die Route-53-API**
```
2001:0db8:85a3:0:0:8a2e:0370:7334
```
## CAA-Datensatztyp
Ein CAA-Eintrag gibt an, welche Zertifizierungsstellen (CAs) Zertifikate für eine Domain oder Subdomain ausstellen dürfen. Durch die Erstellung eines CAA-Eintrags können Sie verhindern, dass falsche Personen Zertifikate für CAs Ihre Domains ausstellen. Ein CAA Datensatz ist kein Ersatz für die Sicherheitsanforderungen, die von Ihrer Zertifizierungsstelle angegeben werden, beispielsweise die Notwendigkeit, zu bestätigen, dass Sie der Besitzer einer Domäne sind.
Sie können mit CAA-Datensätzen Folgendes angeben:
+ Welche Zertifizierungsstellen (CAs) können gegebenenfalls SSL/TLS Zertifikate ausstellen
+ Die E-Mail-Adresse oder URL, die zu kontaktieren ist, wenn eine CA ein Zertifikat für die Domäne oder Subdomäne ausstellt.
Wenn Sie Ihrer gehosteten Zone einen CAA-Datensatz hinzufügen, geben Sie drei durch Leerzeichen getrennte Einstellungen an:
`flags tag "value"`
Beachten Sie im Hinblick auf das Format der CAA-Datensätze Folgendes:
+ Der Wert von `tag` darf nur alphanumerische Zeichen (A-Z, a-z, 0-9) enthalten.
+ Schließen Sie `value` in Anführungszeichen ("") ein.
+ Einige CAs erlauben oder erfordern zusätzliche Werte für`value`. Geben Sie zusätzliche Werte als Name-Wert-Paare an und trennen Sie sie durch Semikolons (;), z. B.:
`0 issue "ca.example.net; account=123456"`
+ Wenn eine Zertifizierungsstelle eine Anforderung für ein Zertifikat für eine Subdomäne (z. B. www.example.com) erhält und kein CAA-Datensatz für die Subdomäne vorhanden ist, sendet die Zertifizierungsstelle eine DNS-Abfrage für einen CAA-Datensatz für die übergeordnete Domäne (z. B. example.com). Wenn ein Datensatz für die übergeordnete Domäne vorhanden und die Zertifikatsanforderung gültig ist, stellt die Zertifizierungsstelle das Zertifikat für die Subdomäne aus.
+ Es wird empfohlen, sich an Ihre CA zu wenden, um die Werte zu ermitteln, die Sie für einen CAA-Datensatz angeben sollten.
+ Es ist nicht möglich, einen CAA-Datensatz und einen CNAME-Datensatz mit demselben Namen zu erstellen, weil es DNS nicht zulässt, denselben Namen für einen CNAME-Datensatz und einen beliebigen anderen Datensatz zu verwenden.
**Topics**
+ [Autorisieren einer Zertifizierungsstelle zum Ausstellen eines Zertifikats für eine Domäne oder Subdomäne](#CAAFormat-issue)
+ [Autorisieren einer Zertifizierungsstelle zum Ausstellen eines Platzhalterzertifikats für eine Domäne oder Subdomäne](#CAAFormat-issue-wild)
+ [Verhindern des Ausstellens eines Zertifikats für eine Domäne oder eine Subdomäne durch eine Zertifizierungsstelle](#CAAFormat-prevent-issue)
+ [Anfordern, dass eine Zertifizierungsstelle Kontakt mit Ihnen aufnimmt, wenn sie eine ungültige Zertifikatanforderung erhält](#CAAFormat-contact)
+ [Verwenden einer anderen Einstellung, die von der Zertifizierungsstelle unterstützt wird](#CAAFormat-custom-setting)
+ [Beispiele](#CAAFormat-examples)
### Autorisieren einer Zertifizierungsstelle zum Ausstellen eines Zertifikats für eine Domäne oder Subdomäne
Um eine Zertifizierungsstelle zum Ausstellen eines Zertifikats für eine Domäne oder Subdomäne zu autorisieren, erstellen Sie einen Datensatz mit demselben Namen wie die Domäne oder Subdomäne und geben Sie die folgenden Einstellungen an:
+ **Flags** – `0`
+ **Tag** — `issue`
+ **value** – Der Code für die Zertifizierungsstelle, die Sie zum Ausstellen eines Zertifikats für die Domäne oder Subdomäne autorisieren
Angenommen, Sie möchten ca.example.net autorisieren, ein Zertifikat für example.com auszustellen. Sie erstellen einen CAA-Datensatz für example.com mit den folgenden Einstellungen:
```
0 issue "ca.example.net"
```
Informationen zur Autorisierung AWS Certificate Manager zur Ausstellung eines Zertifikats finden [Sie unter Konfigurieren eines CAA-Eintrags](https://docs.aws.amazon.com/acm/latest/userguide/setup-caa.html) im *AWS Certificate Manager Benutzerhandbuch*.
### Autorisieren einer Zertifizierungsstelle zum Ausstellen eines Platzhalterzertifikats für eine Domäne oder Subdomäne
Um eine Zertifizierungsstelle zum Ausstellen eines Platzhalterzertifikats für eine Domäne oder Subdomäne zu autorisieren, erstellen Sie einen Datensatz mit demselben Namen wie die Domäne oder Subdomäne und geben Sie die folgenden Einstellungen an. Ein Platzhalterzertifikat gilt für die Domain oder Unterdomain und alle ihre Unterdomains.
+ **Flags** – `0`
+ **Tag —** `issuewild`
+ **value** – Der Code für die Zertifizierungsstelle, die Sie zum Ausstellen eines Zertifikats für die Domäne oder Subdomäne und die entsprechenden Subdomänen autorisieren
Angenommen, Sie möchten ca.example.net zum Ausstellen eines Platzhalterzertifikats für example.com autorisieren, das für example.com und alle entsprechenden Subdomänen gilt. Sie erstellen einen CAA-Datensatz für example.com mit den folgenden Einstellungen:
```
0 issuewild "ca.example.net"
```
Wenn Sie eine Zertifizierungsstelle zum Ausstellen eines Platzhalterzertifikats für eine Domäne oder Subdomäne autorisieren möchten, erstellen Sie einen Datensatz mit demselben Namen wie die Domäne oder Subdomäne und geben Sie die folgenden Einstellungen an. Ein Platzhalterzertifikat gilt für die Domain oder Unterdomain und alle ihre Unterdomains.
### Verhindern des Ausstellens eines Zertifikats für eine Domäne oder eine Subdomäne durch eine Zertifizierungsstelle
Um zu verhindern, dass eine Zertifizierungsstelle ein Zertifikat für eine Domäne oder Subdomäne ausstellt, erstellen Sie einen Datensatz mit demselben Namen wie die Domäne oder Subdomäne und geben Sie die folgenden Einstellungen an.
+ **Flags** – `0`
+ **Etikett** — `issue`
+ **Wert** – `";"`
Angenommen, Sie möchten nicht, dass eine Zertifizierungsstelle ein Zertifikat für example.com ausstellt. Sie erstellen einen CAA-Datensatz für example.com mit den folgenden Einstellungen:
`0 issue ";"`
Wenn Sie nicht möchten, dass eine Zertifizierungsstelle ein Zertifikat für example.com oder die entsprechenden Subdomänen ausstellt, erstellen Sie einen CAA-Datensatz für example.com mit den folgenden Einstellungen:
`0 issuewild ";"`
**Anmerkung**
Wenn Sie einen CAA-Datensatz für example.com erstellen und die folgenden Werte beide angeben, kann eine Zertifizierungsstelle, die den Wert ca.example.net verwendet, das Zertifikat für example.com ausstellen:
```
0 issue ";"
0 issue "ca.example.net"
```
### Anfordern, dass eine Zertifizierungsstelle Kontakt mit Ihnen aufnimmt, wenn sie eine ungültige Zertifikatanforderung erhält
Wenn Sie möchten, dass eine Zertifizierungsstelle, die eine ungültige Anforderung für ein Zertifikat erhält, Kontakt mit Ihnen aufnimmt, geben Sie die folgenden Einstellungen an:
+ **Flags** – `0`
+ **Etikett** — `iodef`
+ **value** – Die URL oder E-Mail-Adresse, die die Zertifizierungsstelle benachrichtigen soll, wenn sie eine ungültige Anforderung für ein Zertifikat erhält Verwenden Sie das entsprechende Format:
`"mailto:email-address"`
`"http://URL"`
`"https://URL"`
Beispiel: Wenn Sie möchten, dass eine Zertifizierungsstelle, die eine ungültige Anforderung für ein Zertifikat erhält, eine E-Mail an admin@example.com sendet, erstellen Sie einen CAA-Datensatz mit den folgenden Einstellungen:
```
0 iodef "mailto:admin@example.com"
```
### Verwenden einer anderen Einstellung, die von der Zertifizierungsstelle unterstützt wird
Wenn Ihre Zertifizierungsstelle eine Funktion unterstützt, die nicht gemäß RFC für CAA-Datensätzen definiert ist, geben Sie die folgenden Einstellungen an:
+ **Flags** – 128 (Dieser Wert verhindert, dass die Zertifizierungsstelle ein Zertifikat ausstellt, wenn sie das angegebene Feature nicht unterstützt.)
+ **Tag** – Das Tag, zu dessen Verwendung Sie die Zertifizierungsstelle autorisieren
+ **value** – Der Wert, der dem Wert von „tag“ entspricht
Angenommen, Ihre Zertifizierungsstelle unterstützt das Senden einer Textnachricht, wenn sie eine ungültige Zertifikatanforderung erhält. (Uns sind keine bekannt CAs , die diese Option unterstützen.) Die Einstellungen für den Datensatz können wie folgt lauten:
```
128 exampletag "15555551212"
```
### Beispiele
**Beispiel für die Route-53-Konsole**
```
0 issue "ca.example.net"
0 iodef "mailto:admin@example.com"
```
**Beispiel für die Route-53-API**
```
0 issue "ca.example.net"
0 iodef "mailto:admin@example.com"
```
## CNAME-Datensatztyp
Ein CNAME-Datensatz ordnet DNS-Abfragen für den Namen des aktuellen Datensatzes wie „acme.example.com“ einer anderen Domäne („example.com“ oder „example.net“) oder Subdomäne („acme.example.com“ oder „zenith.example.org“) zu.
**Wichtig**
Das DNS-Protokoll lässt nicht zu, einen CNAME-Datensatz für den obersten Knoten eines DNS-Namespace zu erstellen, auch als Zone Apex bezeichnet. Wenn Sie beispielsweise den DNS-Namen example.com registriert haben, lautet der Zone Apex example.com. Sie können keinen CNAME-Datensatz für example.com erstellen, Sie können jedoch CNAME-Datensätze für www.example.com, newproduct.example.com und so weiter erstellen.
Darüber hinaus gilt: Wenn Sie einen CNAME-Datensatz für eine Subdomäne erstellen, können Sie keine weiteren Datensätze für diese Subdomäne erstellen. Wenn Sie beispielsweise einen CNAME für „www.example.com“ erstellen, können Sie keine weiteren Datensätze erstellen, bei denen der Wert für das Feld **Name (Name)** „www.example.com“ lautet.
Amazon Route 53 unterstützt auch Alias-Datensätze, mit denen Sie Abfragen an ausgewählte AWS Ressourcen wie CloudFront Distributionen und Amazon S3 S3-Buckets weiterleiten können. Aliasse sind in mancher Hinsicht dem CNAME-Datensatztyp ähnlich; Sie können jedoch einen Alias für den Zone Apex erstellen. Weitere Informationen finden Sie unter [Wählen zwischen Alias- und Nicht-Alias-Datensätzen](resource-record-sets-choosing-alias-non-alias.md).
**Beispiel für die Route-53-Konsole**
```
hostname.example.com
```
**Beispiel für die Route-53-API**
```
hostname.example.com
```
## DS-Datensatztyp
Ein Delegierungssignierer-(DS)-Datensatz verweist auf einen Zonenschlüssel für eine delegierte Subdomänenzone. Sie können einen DS-Datensatz erstellen, wenn Sie beim Konfigurieren der DNSSEC-Signatur eine Vertrauenskette einrichten. Weitere Informationen zur Konfiguration von DNSSEC in Route 53 finden Sie unter [Konfigurieren der DNSSEC-Signatur in Amazon Route 53](dns-configuring-dnssec.md).
Die ersten drei Werte sind Dezimalzahlen, die den Schlüsseltag, den Algorithmus und den Digesttyp darstellen. Der vierte Wert ist der Digest des Zonenschlüssels. Weitere Informationen zum DS-Datensatz-Format finden Sie unter [RFC 4034](https://www.ietf.org/rfc/rfc4034.txt).
**Beispiel für die Route-53-Konsole**
```
123 4 5 1234567890abcdef1234567890absdef
```
**Beispiel für die Route-53-API**
```
123 4 5 1234567890abcdef1234567890absdef
```
## HTTPS-Datensatztyp
Ein HTTPS-Ressourceneintrag ist eine Form des Service Binding (SVCB) -DNS-Eintrags, der erweiterte Konfigurationsinformationen bereitstellt, sodass ein Client einfach und sicher eine Verbindung zu einem Dienst über ein HTTP-Protokoll herstellen kann. Die Konfigurationsinformationen werden in Parametern bereitgestellt, die die Verbindung in einer DNS-Abfrage ermöglichen, anstatt dass mehrere DNS-Abfragen erforderlich sind.
Das Format für einen HTTPS-Ressourceneintrag ist:
`SvcPriority TargetName SvcParams(optional)`
Die folgenden Parameter werden in [RFC 9460, Abschnitt](https://www.rfc-editor.org/rfc/rfc9460.html#section-9.1) 9.1 beschrieben.
**SvcPriority**
Eine Ganzzahl, die die Priorität darstellt. Priorität 0 bedeutet Aliasmodus und ist im Allgemeinen für Aliasing am Zonen-Apex vorgesehen. Dieser Wert ist eine Ganzzahl 0-32767 für Route 53, wobei 1-32767 Datensätze im Servicemodus sind. Je niedriger die Priorität, desto höher die Präferenz.
**TargetName**
Der Domainname entweder des Alias-Ziels (für den Alias-Modus) oder des alternativen Endpunkts (fürServiceMode).
**SvcParams (Optional)**
Eine durch Leerzeichen getrennte Liste, wobei jeder Parameter aus einem Schlüssel=Wert-Paar oder einem eigenständigen Schlüssel besteht. Wenn es mehr als einen Wert gibt, werden sie als kommagetrennte Liste dargestellt. Die folgenden sind definiert: SvcParams
+ `1:alpn`— Protokoll auf Anwendungsebene — Verhandlungsprotokoll IDs. Die Standardeinstellung ist HTTP/1.1, `h2` ist HTTP/2 über TLS und `h3` ist HTTP/3 (HTTP über QUIC-Protokoll).
+ `2:no-default-alpn`— Die Standardeinstellung wird nicht unterstützt und Sie müssen einen Parameter angeben. `alpn`
+ `3:port`— der alternative Endpunkt oder der Port, über den der Dienst erreicht werden kann.
+ `4:ipv4hint`— Hinweise zur IPv4 Adresse.
+ `5:ech`— Verschlüsselter Client Hallo.
+ `6:ipv6hint`— Hinweise zur IPv6 Adresse.
+ `7:dohpath`— DNS-über-HTTPS-Vorlage
+ `8:ohttp`— Der Dienst betreibt ein Oblivious-HTTP-Ziel
**Beispiel für die Amazon Route 53-Konsole für den Alias-Modus**
```
0 example.com
```
**Beispiel für die Amazon Route 53-Konsole für den Servicemodus**
```
16 example.com alpn="h2,h3" port=808
```
**Beispiel für die Amazon Route 53-API für den Alias-Modus**
```
0 example.com
```
**Beispiel für die Route 53-API für den Servicemodus**
```
16 example.com alpn="h2,h3" port=808
```
Weitere Informationen finden Sie unter [RFC 9460, Service Binding and Parameter Specification via DNS (SVCB und HTTPS Resource](https://datatracker.ietf.org/doc/html/rfc9460) Records).
**Anmerkung**
Route 53 unterstützt das beliebige Darstellungsformat mit unbekannten Schlüsseln nicht `keyNNNNN`
## MX-Datensatztyp
Ein MX-Datensatz gibt die Namen Ihrer Mail-Server und im Fall mehrerer vorhandener Mail-Server die Prioritätsreihenfolge an. Jeder Wert für einen MX-Datensatz enthält zwei Werte, die Priorität und den Domänennamen.
**Priorität**
Eine Ganzzahl, die die Priorität für einen E-Mail-Server angibt. Wenn Sie nur einen Server angeben, kann die Priorität eine beliebige Zahl zwischen 0 und 65535 sein. Wenn Sie mehrere Server angeben, kennzeichnet der Wert, den Sie für die Priorität angeben, an welchen E-Mail-Server die E-Mails als Erstes, Zweites usw. geleitet werden sollen. Der Server mit dem niedrigsten Wert für die Priorität erhält den Vorrang. Wenn Sie beispielsweise zwei E-Mail-Server haben und die Werte 10 und 20 für die Priorität angeben, gehen E-Mails immer an den Server mit der Priorität 10, es sei denn, dieser ist nicht verfügbar. Wenn Sie die Werte 10 und 10 angeben, werden E-Mails etwa gleich oft an beide Server geleitet.
**Domainname**
Der Domänenname des E-Mail-Servers. Geben Sie den Namen (z. B. mail.example.com) eines A- oder AAAA-Datensatzes an. In [RFC 2181, Erläuterungen zur DNS-Spezifikation](https://tools.ietf.org/html/rfc2181), wird Abschnitt 10.3 verboten, den Namen eines CNAME-Datensatzes für den Domänennamenwert anzugeben. (Wenn im RFC von „Alias” die Rede ist, geht es um einen CNAME-Datensatz, nicht um einen Route-53-Alias-Datensatz.)
**Beispiel für die Amazon-Route-53-Konsole**
```
10 mail.example.com
```
**Beispiel für die Route-53-API**
```
10 mail.example.com
```
## NAPTR-Datensatztyp
Ein Namensvergebungsstellen-Zeiger (NAPTR) ist ein Datensatztyp, der von DDDS-Anwendungen (Dynamic Delegation Discovery System) genutzt wird, um einen Wert in einen anderen zu konvertieren oder einen Wert durch einen anderen zu ersetzen. Eine gängige Anwendung ist beispielsweise die Konvertierung von Telefonnummern in SIP. URIs
Das `Value`-Element für einen NAPTR-Datensatz besteht aus sechs durch Leerzeichen getrennten Werten:
**Order**
Wenn Sie mehr als einen Datensatz angeben, ist dies die Reihenfolge, in der die DDDS-Anwendung Datensätze auswerten soll. Zulässige Werte: 0 bis 65535.
**Präferenz**
Wenn Sie zwei oder mehr Datensätze mit derselben **Reihenfolge** angeben, gibt die Präferenz die Sequenz an, in der die entsprechenden Datensätze ausgewertet werden. Wenn beispielsweise zwei Datensätze die **Reihenfolge** 1 haben, wertet die DDDS-Anwendung zuerst den Datensatz mit der niedrigeren **Präferenz** aus. Zulässige Werte: 0 bis 65535.
**Flags**
Eine Einstellung speziell für DDDS-Anwendungen. Werte, die derzeit in [RFC 3404](https://www.ietf.org/rfc/rfc3404.txt) definiert sind, sind Groß- und Kleinbuchstaben **"A"**, **"P"**, **"S"** und **"U"** sowie eine leere Zeichenfolge **""**. Schließen Sie **Flags** in Anführungszeichen ein.
**Service**
Eine Einstellung speziell für DDDS-Anwendungen. Schließen Sie **Service** in Anführungszeichen ein.
Weitere Informationen finden Sie in den entsprechenden Dokumenten RFCs:
+ **URI DDDS-Anwendung** — [https://tools.ietf.org/html/rfc3404](https://tools.ietf.org/html/rfc3404#section-4.4) \$1section -4.4
+ **S-NAPTR DDDS-Anwendung** [— /rfc3958 \$1section -6.5 https://tools.ietf.org/html](https://tools.ietf.org/html/rfc3958#section-6.5)
+ **U-NAPTR DDDS-Anwendung** — [https://tools.ietf.org/html/rfc4848 \$1section -4.5](https://tools.ietf.org/html/rfc4848#section-4.5)
**Regexp**
Ein regulärer Ausdruck, den die DDDS-Anwendung nutzt, um einen Eingabewert in einen Ausgabewert zu konvertieren. Beispielsweise kann ein IP-Telefonsystem eine regulären Ausdruck verwenden, um eine Telefonnummer, die von einem Benutzer eingegeben wird, in ein SIP-URI umzuwandeln. Schließen Sie **Regexp** in Anführungszeichen ein. Geben Sie einen Wert für **Regexp** oder für **Ersatz** an. Geben Sie aber nicht beide Werte an.
Der reguläre Ausdruck kann folgende druckbaren ASCII-Zeichen enthalten:
+ a-z
+ 0-9
+ - (Bindestrich)
+ (Leerzeichen)
+ \$1 \$1 \$1 % & ' ( ) \$1 \$1 , - / : ; < = > ? @ [ ] ^ \$1 ` \$1 \$1 \$1 \$1 .
+ " (Anführungszeichen). Um ein Anführungszeichen in eine Zeichenfolge einzufügen, stellen Sie ein \$1-Zeichen voran: \$1".
+ \$1 (Backslash). Um einen Backslash in eine Zeichenfolge einzufügen, stellen Sie ein \$1-Zeichen voran: \$1\$1.
Geben Sie alle anderen Werte, z. B. internationalisierte Domänennamen, im oktalen Format an.
Die Syntax für **Regexp** finden Sie in [RFC 3402, Abschnitt 3.2, Substitution Expression Syntax](https://tools.ietf.org/html/rfc3402#section-3.2)
**Ersatz**
Der vollständig qualifizierte Domänenname (FQDN) des nächsten Domänennamens, an den die DDDS-Anwendung eine DNS-Abfrage senden soll. Die DDDS-Anwendung ersetzt den Eingabewert mit dem von Ihnen angegebenen Wert für **Ersatz**, falls vorhanden. Geben Sie einen Wert für **Regexp** oder für **Ersatz** an. Geben Sie aber nicht beide Werte an. Wenn Sie einen Wert für **Regexp** angeben, tragen Sie einen Punkt (**.**) bei **Ersatz** ein.
Der Domänenname kann a-z, 0-9 und Bindestriche (-) enthalten.
Weitere Informationen zu DDDS-Anwendungen und zu NAPTR-Einträgen finden Sie im Folgenden: RFCs
+ [RFC 3401](https://www.ietf.org/rfc/rfc3401.txt)
+ [RFC 3402](https://www.ietf.org/rfc/rfc3402.txt)
+ [RFC 3403](https://www.ietf.org/rfc/rfc3403.txt)
+ [RFC 3404](https://www.ietf.org/rfc/rfc3404.txt)
**Beispiel für die Amazon-Route-53-Konsole**
```
100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" .
100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" .
100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" .
```
**Beispiel für die Route-53-API**
```
100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\1@example.com!" .
100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:operator@example.com!" .
100 52 "u" "E2U+email:mailto" "!^.*$!mailto:info@example.com!" .
```
## NS-Datensatztyp
Ein NS-Eintrag identifiziert die Namensserver für die gehostete Zone. Beachten Sie Folgendes:
+ Am häufigsten werden NS-Datensätze verwendet, um zu steuern, wie Internetverkehr für eine Domäne weitergeleitet wird. Damit Sie die Datensätze in einer gehosteten Zone zum Weiterleiten von Datenverkehr für eine Domäne verwenden können, aktualisieren Sie die Domänenregistrierungseinstellungen so, dass die vier Nameserver im Standard-NS-Datensatz verwendet werden. (Dies ist der NS-Datensatz, der denselben Namen wie die gehostete Zone hat.)
+ Sie können eine separate gehostete Zone für eine Subdomäne (acme.example.com) erstellen und diese gehostete Zone verwenden, um den Internetverkehr für die Subdomäne und deren Subdomänen (subdomain.acme.example.com) weiterzuleiten. Richten Sie diese Konfiguration ein, die bekannt ist als „Delegieren der Zuständigkeit für eine Subdomäne an eine gehostete Zone“, indem Sie einen anderen NS-Datensatz in der gehosteten Zone für die Stammdomäne (example.com) erstellen. Weitere Informationen finden Sie unter [Weiterleiten von Datenverkehr für Subdomänen](dns-routing-traffic-for-subdomains.md).
+ NS-Datensätze werden auch verwendet, um White-Label-Name-Server zu konfigurieren. Weitere Informationen finden Sie unter [Konfigurieren von White-Label-Nameservern](white-label-name-servers.md).
+ Ein NS-Eintrag kann auch für privat gehostete Zonen verwendet werden, wenn Sie eine Delegiertregel erstellen, um die Autorität für eine Subdomain an Ihren lokalen Resolver zu delegieren. Sie müssen diesen NS-Eintrag erstellen, bevor Sie eine Delegiertenregel erstellen. Weitere Informationen finden Sie unter [Wie Resolver-Endpunkte DNS-Anfragen von Ihrem an Ihr Netzwerk weiterleiten VPCs](resolver-overview-forward-vpc-to-network.md).
Weitere Informationen über NS- und SOA-Einträge finden Sie unter [NS- und SOA-Datensätze, die Amazon Route 53 für eine öffentliche gehostete Zone erstellt](SOA-NSrecords.md).
**Beispiel für die Amazon-Route-53-Konsole**
```
ns-1.example.com
```
**Beispiel für die Route-53-API**
```
ns-1.example.com
```
## PTR-Datensatztyp
Ein PTR-Datensatz ordnet eine IP-Adresse dem entsprechenden Domänennamen zu.
**Beispiel für die Amazon-Route-53-Konsole**
```
hostname.example.com
```
**Beispiel für die Route-53-API**
```
hostname.example.com
```
## SOA-Datensatztyp
Ein SOA-Datensatz enthält Informationen zu einer Domäne und der entsprechenden gehosteten Amazon-Route-53-Zone. Weitere Informationen über die einzelnen Felder in einem SOA-Datensatz finden Sie unter [NS- und SOA-Datensätze, die Amazon Route 53 für eine öffentliche gehostete Zone erstellt](SOA-NSrecords.md).
**Beispiel für die Route-53-Konsole**
```
ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60
```
**Beispiel für die Route-53-API**
```
ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60
```
## SPF-Datensatztyp
SPF-Datensätze wurden früher verwendet, um die Identität des Absenders von E-Mail-Nachrichten zu überprüfen. Wir empfehlen jedoch nicht mehr, Datensätze mit dem Datensatztyp SPF zu erstellen. RFC 7208, *Sender Policy Framework (SPF) für die Autorisierung der Verwendung von Domänen in E-Mail, Version 1,* wurde aktualisiert und besagt nun: „... [Seine] Existenz und sein in [RFC4408] definierter Mechanismus haben zu einigen Interoperabilitätsproblemen geführt. Daher ist die Anwendung nicht mehr für SPF-Version 1 geeignet; Implementierungen sollten dies nicht mehr verwenden." Lesen Sie in RFC 7208 Abschnitt 14.1 über [SPF DNS-Datensatztypen](http://tools.ietf.org/html/rfc7208#section-14.1).
Anstatt einen SPF-Eintrag zu erstellen, empfehlen wir, dass Sie einen TXT-Eintrag mit dem entsprechenden Wert erstellen. Weitere Informationen zu gültigen Werten finden Sie im Wikipedia-Artikel [Sender Policy Framework](https://en.wikipedia.org/wiki/Sender_Policy_Framework).
**Beispiel für die Amazon-Route-53-Konsole**
```
"v=spf1 ip4:192.168.0.1/16 -all"
```
**Beispiel für die Route-53-API**
```
"v=spf1 ip4:192.168.0.1/16 -all"
```
## SRV-Datensatztyp
Ein `Value`-Element eines SRV-Eintrags besteht aus vier durch Leerzeichen getrennten Werten. Die ersten drei Werte sind Dezimalzahlen, die für Priorität, Gewichtung und den Port stehen. Der vierte Wert ist ein Domänenname. SRV-Einträge werden für den Zugriff auf Services verwendet, z. B. einen Service für E-Mail oder Kommunikation. Weitere Informationen zum SRV-Eintragsformat finden Sie in der Dokumentation des Service, mit dem Sie eine Verbindung herstellen möchten.
**Beispiel für die Amazon-Route-53-Konsole**
```
10 5 80 hostname.example.com
```
**Beispiel für die Route-53-API**
```
10 5 80 hostname.example.com
```
## Typ des SSHFP-Eintrags
Ein Secure Shell-Fingerabdruckeintrag (SSHFP) identifiziert SSH-Schlüssel, die dem Domainnamen zugeordnet sind. SSHFP-Datensätze müssen mit DNSSEC gesichert werden, damit eine Vertrauenskette aufgebaut werden kann. Weitere Informationen zu DNSSEC finden Sie unter [Konfigurieren der DNSSEC-Signatur in Amazon Route 53](dns-configuring-dnssec.md)
Das Format für einen SSHFP-Ressourceneintrag ist:
`[Key Algorithm] [Hash Type] Fingerprint`
Die folgenden Parameter sind in [RFC](https://datatracker.ietf.org/doc/html/rfc4255) 4255 definiert.
**Schlüsselalgorithmus**
Typ des Algorithmus:
+ `0`— Reserviert und nicht verwendet.
+ `1: RSA`— Der Rivest-Shamir-Adleman-Algorithmus ist eines der ersten Kryptosysteme mit öffentlichen Schlüsseln und wird immer noch für die sichere Datenübertragung verwendet.
+ `2: DSA`— Der Algorithmus für digitale Signaturen ist ein Bundesstandard zur Informationsverarbeitung für digitale Signaturen. DSA basiert auf modularer Potenzierung und mathematischen Modellen mit diskretem Logarithmus.
+ `3: ECDSA`— Der Elliptic Curve Digital Signature Algorithm ist eine Variante des DSA, die Kryptografie mit elliptischen Kurven verwendet.
+ `4: Ed25519`— Der Ed25519-Algorithmus ist das EdDSA-Signaturschema, das SHA-512 (SHA-2) und Curve25519 verwendet.
+ `6: Ed448`— Ed448 ist das EddSA-Signaturschema, das Curve448 verwendet. SHAKE256
**Hash-Typ**
Algorithmus, der zur Erstellung des öffentlichen Schlüssels verwendet wurde:
+ `0`— Reserviert und nicht verwendet.
+ `1: SHA-1`
+ `2: SHA-256`
**Fingerabdruck**
Hexadezimale Darstellung des Hashs.
**Beispiel für die Amazon-Route-53-Konsole**
```
1 1 09F6A01D2175742B257C6B98B7C72C44C4040683
```
**Beispiel für die Route-53-API**
```
1 1 09F6A01D2175742B257C6B98B7C72C44C4040683
```
Weitere Informationen finden Sie unter [RFC 4255: Verwenden von DNS zur sicheren Veröffentlichung von Secure Shell (SSH](https://datatracker.ietf.org/doc/html/rfc4255)) -Schlüsselfingerabdrücken.
## SVCB-Eintragstyp
Sie verwenden einen SVCB-Eintrag, um Konfigurationsinformationen für den Zugriff auf Dienstendpunkte bereitzustellen. Der SVCB ist ein generischer DNS-Eintrag und kann verwendet werden, um Parameter für eine Vielzahl von Anwendungsprotokollen auszuhandeln.
Das Format für einen SVCB-Ressourceneintrag ist:
`SvcPriority TargetName SvcParams(optional)`
Die folgenden Parameter werden in [RFC 9460,](https://www.rfc-editor.org/rfc/rfc9460.html#section-2.3) Abschnitt 2.3 beschrieben.
**SvcPriority**
Eine Ganzzahl, die die Priorität darstellt. Priorität 0 steht für Alias-Modus und ist im Allgemeinen für Aliasing am Zonen-Apex vorgesehen. Je niedriger die Priorität, desto höher die Präferenz.
**TargetName**
Der Domainname entweder des Alias-Ziels (für den Alias-Modus) oder des alternativen Endpunkts (fürServiceMode).
**SvcParams (Optional)**
Eine durch Leerzeichen getrennte Liste, wobei jeder Parameter aus einem Schlüssel=Wert-Paar oder einem eigenständigen Schlüssel besteht. Wenn es mehr als einen Wert gibt, werden sie als kommagetrennte Liste dargestellt. Dieser Wert ist eine Ganzzahl 0-32767 für Route 53, wobei 1-32767 Datensätze im Servicemodus sind. Die folgenden sind definiert: SvcParams
+ `1:alpn`— Protokoll auf Anwendungsebene — Verhandlungsprotokoll IDs. Die Standardeinstellung ist HTTP/1.1, `h2` ist HTTP/2 über TLS und `h3` ist HTTP/3 (HTTP über QUIC-Protokoll).
+ `2:no-default-alpn`— Die Standardeinstellung wird nicht unterstützt und Sie müssen einen Parameter angeben. `alpn`
+ `3:port`— der Port für den alternativen Endpunkt, über den der Dienst erreicht werden kann.
+ `4:ipv4hint`— IPv4 Adressenhinweise.
+ `5:ech`— Verschlüsselter Client Hallo.
+ `6:ipv6hint`— Hinweise zur IPv6 Adresse.
+ `7:dohpath`— DNS-über-HTTPS-Vorlage
+ `8:ohttp`— Der Dienst betreibt ein Oblivious-HTTP-Ziel
**Beispiel für die Amazon Route 53-Konsole für den Alias-Modus**
```
0 example.com
```
**Beispiel für die Amazon Route 53-Konsole für den Servicemodus**
```
16 example.com alpn="h2,h3" port=808
```
**Beispiel für die Amazon Route 53-API für den Alias-Modus**
```
0 example.com
```
**Beispiel für die Route 53-API für den Servicemodus**
```
16 example.com alpn="h2,h3" port=808
```
Weitere Informationen finden Sie unter [RFC 9460, Service Binding and Parameter Specification via DNS (SVCB und HTTPS Resource](https://datatracker.ietf.org/doc/html/rfc9460) Records).
**Anmerkung**
Route 53 unterstützt das beliebige Darstellungsformat mit unbekannten Schlüsseln nicht `keyNNNNN`
## TLSA-Eintragstyp
Sie verwenden einen TLSA-Datensatz, um die DNS-basierte Authentifizierung benannter Entitäten (DANE) zu verwenden. Ein TLSA-Eintrag ordnet einen certificate/public Schlüssel einem TLS-Endpunkt (Transport Layer Security) zu, und Clients können den certificate/public Schlüssel mithilfe eines mit DNSSEC signierten TLSA-Datensatzes validieren.
TLSA-Einträge können nur als vertrauenswürdig eingestuft werden, wenn DNSSEC in Ihrer Domain aktiviert ist. Weitere Informationen zu DNSSEC finden Sie unter [Konfigurieren der DNSSEC-Signatur in Amazon Route 53](dns-configuring-dnssec.md)
Das Format für einen TLSA-Ressourceneintrag ist:
`[Certificate usage] Selector [Matching type] [Certificate association data]`
Die folgenden Parameter sind in [RFC 6698](https://datatracker.ietf.org/doc/html/rfc6698#section-3), Abschnitt 3, spezifiziert.
**Verwendung des Zertifikats**
Gibt die angegebene Zuordnung an, die für den Abgleich mit dem im TLS-Handshake angegebenen Zertifikat verwendet wird:
+ 0: CA Constraint — Das Zertifikat oder der öffentliche Schlüssel muss sich in einem der PKIX-Zertifizierungspfade (Public Key Infrastructure) für das vom Server in TLS bereitgestellte Entity-Zertifikat befinden. Diese Einschränkung schränkt ein, CAs welche Zertifikate für einen bestimmten Dienst ausgestellt werden können.
+ 1: Service Certificate Constraint — Gibt ein Endentitätszertifikat (oder den öffentlichen Schlüssel) an, das mit dem vom Server in TLS ausgegebenen Endentitätszertifikat übereinstimmen muss. Diese Zertifizierung schränkt ein, welches Entity-Zertifikat von einem bestimmten Dienst auf einem Host verwendet werden kann.
+ 2: Eine Vertrauensanker-Assertion — Gibt ein Zertifikat (oder den öffentlichen Schlüssel) an, das als „Vertrauensanker“ verwendet werden muss, wenn das vom Server in TLS ausgegebene Entity-Zertifikat validiert wird. Ermöglicht einem Domänenadministrator die Angabe eines Vertrauensankers.
+ 3: Von einer Domain ausgestellte Zertifizierung — Gibt ein Zertifikat (oder den öffentlichen Schlüssel) an, das mit dem vom Server in TLS ausgestellten Entity-Zertifikat übereinstimmen muss. Diese Zertifizierung ermöglicht es einem Domainadministrator, Zertifikate für eine Domain auszustellen, ohne dass eine Zertifizierungsstelle eines Drittanbieters hinzugezogen werden muss. Dieses Zertifikat muss die PKIX-Validierung nicht bestehen.
**Selector**
Gibt an, welcher Teil des vom Server im Handshake vorgelegten Zertifikats mit dem Zuordnungswert abgeglichen wird:
+ 0: Das gesamte Zertifikat muss abgeglichen werden.
+ 1: Der öffentliche Subject-Schlüssel oder die DER-kodierte Binärstruktur müssen übereinstimmen.
**Passender Typ**
Gibt die Präsentation (wie im Feld Selector festgelegt) des Zertifikatsabgleichs an:
+ 0: Exakte Übereinstimmung mit dem Inhalt.
+ 1: SHA-256-Hash.
+ 2: SHA-512-Hash.
**Daten zur Zertifikatsvereinigung**
Die abzugleichenden Daten basieren auf den Einstellungen der anderen Felder.
**Beispiel für die Amazon-Route-53-Konsole**
```
0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971
```
**Beispiel für die Route-53-API**
```
0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971
```
Weitere Informationen finden Sie unter [RFC 6698, Das DNS-based Authentication of Named Entities (DANE) Transport Layer Security (TLS)](https://datatracker.ietf.org/doc/html/rfc6698) -Protokoll: TLSA.
## TXT-Datensatztyp
Ein TXT-Datensatz enthält eine oder mehrere Zeichenfolgen, die in Anführungszeichen eingeschlossen sind (`"`). Wenn Sie die einfache [Routing-Richtlinie](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) verwenden, nehmen Sie alle Werte für eine Domäne (example.com) oder Subdomäne (www.example.com) in den gleichen TXT-Datensatz auf.
**Topics**
+ [Eingeben von TXT-Datensatzwerten](#TXTformat-limits)
+ [Sonderzeichen in einem TXT-Datensatzwert](#TXTformat-special-characters)
+ [Groß- und Kleinbuchstaben in einem TXT-Datensatzwert](#TXTformat-case)
+ [Beispiele](#TXTformat-examples)
### Eingeben von TXT-Datensatzwerten
Eine einzelne Zeichenfolge kann bis zu 255 Zeichen umfassen, einschließlich der folgenden:
+ a-z
+ A-Z
+ 0-9
+ Leerzeichen
+ - (Bindestrich)
+ \$1 " \$1 \$1 % & ' ( ) \$1 \$1 , - / : ; < = > ? @ [ \$1 ] ^ \$1 ` \$1 \$1 \$1 \$1 .
Wenn Sie einen Wert eingeben müssen, der länger als 255 Zeichen ist, teilen Sie den Wert in Zeichenfolgen mit höchstens 255 Zeichen auf und schließen Sie jede Zeichenfolge in doppelte Anführungszeichen ein (`"`). Führen Sie in der Konsole alle Zeichenfolgen in derselben Zeile auf:
```
"String 1" "String 2" "String 3"
```
Fügen Sie für die API alle Zeichenfolgen in demselben `Value`-Element ein:
```
"String 1" "String 2" "String 3"
```
Die maximale Länge eines Wertes in einem TXT-Datensatz beträgt 4.000 Zeichen.
Um mehr als einen TXT-Wert einzugeben, geben Sie einen Wert pro Zeile ein.
### Sonderzeichen in einem TXT-Datensatzwert
Wenn Ihr TXT-Eintrag eines der folgenden Zeichen enthält, müssen Sie die Zeichen mithilfe von Escape-Codes im folgenden Format angeben: `\` *three-digit octal code*
+ Zeichen 000 bis 040 oktal (0 bis 32 dezimal, 0x00 bis 0x20 hexadezimal)
+ Zeichen 177 bis 377 oktal (127 bis 255 dezimal, 0x7F bis 0xFF hexadezimal)
Wenn der Wert Ihres TXT-Datensatzes z. B. `"exämple.com"` ist, geben Sie `"ex\344mple.com"` an.
Für eine Zuordnung zwischen ASCII-Zeichen und Oktalcodes führen Sie eine Internetsuche nach „ASCII-Oktalcodes“ durch. Eine nützliche Referenz ist [ASCII Code - The extended ASCII table](https://www.ascii-code.com/).
Um ein Anführungszeichen (`"`) in eine Zeichenfolge aufzunehmen, setzen Sie einen umgekehrten Schrägstrich (`\`) vor das Anführungszeichen: `\"`.
### Groß- und Kleinbuchstaben in einem TXT-Datensatzwert
Die Groß-/Kleinschreibung wird berücksichtigt, sodass `"Ab"` und `"aB"` verschiedene Werte darstellen.
### Beispiele
**Beispiel für die Amazon-Route-53-Konsole**
Geben Sie jeden Wert in einer separaten Zeile ein:
```
"This string includes \"quotation marks\"."
"The last character in this string is an accented e specified in octal format: \351"
"v=spf1 ip4:192.168.0.1/16 -all"
```
**Beispiel für die Route-53-API**
Geben Sie jeden Wert in einem `Value`-Element ein:
```
"This string includes \"quotation marks\"."
"The last character in this string is an accented e specified in octal format: \351"
"v=spf1 ip4:192.168.0.1/16 -all"
```
# Erstellen von Datensätzen mithilfe der Amazon-Route-53-Konsole
Im folgenden Verfahren wird das Erstellen von Datensätzen mit der Amazon-Route-53-Konsole erläutert. Informationen zum Erstellen von Datensätzen mithilfe der Route 53-API finden Sie [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)in der *Amazon Route 53-API-Referenz*.
**Anmerkung**
Um Datensätze für komplexe Routing-Konfigurationen zu erstellen, können Sie auch den visuellen Traffic Flow Editor verwenden und die Konfiguration als Verkehrsrichtlinie speichern. Sie können dann die Datenverkehrsrichtlinie mit einem oder mehreren Domainnamen (z. B. example.com) oder Subdomainnamen (z. B. www.example.com) in derselben gehosteten Zone oder in mehreren gehosteten Zonen verknüpfen. Außerdem können Sie ein Rollback der Aktualisierungen durchführen, wenn die neue Konfiguration sich nicht wie erwartet verhält. Weitere Informationen finden Sie unter [Verwenden von Traffic Flow zum Weiterleiten von DNS-Verkehr](traffic-flow.md).
**So erstellen Sie einen Datensatz mit der Route-53-Konsole:**
1. Wenn Sie keinen Alias-Datensatz erstellen, fahren Sie mit Schritt 2 fort.
Fahren Sie auch mit Schritt 2 fort, wenn Sie einen Aliaseintrag erstellen, der DNS-Verkehr an eine andere AWS Ressource als einen Elastic Load Balancing Load Balancer oder einen anderen Route 53-Datensatz weiterleitet.
Wenn Sie einen Alias-Datensatz erstellen, der Datenverkehr an einen Elastic Load Balancing Load Balancer weiterleitet, und Sie Ihre gehostete Zone und Ihren Load Balancer mit verschiedenen Konten erstellt haben, befolgen Sie die Schritte im Verfahren [Abrufen des DNS-Namens für einen Elastic Load Balancing Load Balancer](#resource-record-sets-elb-dns-name-procedure), um den DNS-Namen für den Load Balancer abzurufen.
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Klicken Sie im Navigationsbereich auf **Hosted Zones (Gehostete Zonen)**.
1. Wenn Sie bereits über eine gehostete Zone für Ihre Domain verfügen, fahren Sie mit Schritt 5 fort. Wenn Sie dies nicht tun, führen Sie die entsprechenden Schritte aus, um eine gehostete Zone zu erstellen:
+ Informationen zum Weiterleiten des Internetdatenverkehrs an Ihre Ressourcen, wie z. B. Amazon-S3-Buckets oder Amazon-EC2-Instances, finden Sie unter [Erstellen einer öffentlichen gehosteten Zone](CreatingHostedZone.md).
+ Informationen zum Weiterleiten von Datenverkehr in Ihrer VPC finden Sie unter [Erstellen einer privat gehosteten Zone](hosted-zone-private-creating.md).
1. Wählen Sie auf der Seite **Hosted Zones (Gehostete Zonen)** den Namen der gehosteten Zone aus, in der Sie Datensätze erstellen möchten.
1. Wählen Sie **Create record (Datensatz erstellen)**.
1. Wählen und definieren Sie die anwendbare Routingrichtlinie und -werte. Weitere Informationen finden Sie im Thema zu der Art des Datensatzes, die Sie erstellen möchten:
+ [Typische Werte für alle Routing-Richtlinien](resource-record-sets-values-shared.md)
+ [Werte, die für Aliasdatensätze für alle Routing-Richtlinien typisch sind](resource-record-sets-values-alias-common.md)
+ [Spezifische Werte für einfache Datensätze](resource-record-sets-values-basic.md)
+ [Spezifische Werte für einfache Aliasdatensätze](resource-record-sets-values-alias.md)
+ [Spezifische Werte für Failover-Datensätze](resource-record-sets-values-failover.md)
+ [Spezifische Werte für Failover-Aliasdatensätze](resource-record-sets-values-failover-alias.md)
+ [Spezifische Werte für Geolocation-Datensätze](resource-record-sets-values-geo.md)
+ [Spezifische Werte für Geolocation-Aliasdatensätze](resource-record-sets-values-geo-alias.md)
+ [Spezifische Werte für Geoproximitätsdatensätze](resource-record-sets-values-geoprox.md)
+ [Spezifische Werte für Geoproximitäts-Aliasdatensätze](resource-record-sets-values-geoprox-alias.md)
+ [Spezifische Werte für Latenz-Datensätze](resource-record-sets-values-latency.md)
+ [Spezifische Werte für Latenz-Aliasdatensätze](resource-record-sets-values-latency-alias.md)
+ [Spezifische Werte für IP-basierte Datensätze](resource-record-sets-values-ipbased.md)
+ [Spezifische Werte für IP-basierte Aliasdatensätze](resource-record-sets-values-ipbased-alias.md)
+ [Werte für spezifische mehrwertige Antwort-Datensätze](resource-record-sets-values-multivalue.md)
+ [Spezifische Werte für gewichtete Datensätze](resource-record-sets-values-weighted.md)
+ [Spezifische Werte für gewichtete Aliasdatensätze](resource-record-sets-values-weighted-alias.md)
1. Wählen Sie **Create records** (Datensätze erstellen).
**Anmerkung**
Die Verteilung Ihrer neuen Datensätze auf die Route-53-DNS-Server nimmt etwas Zeit in Anspruch. Derzeit besteht die einzige Möglichkeit, um zu überprüfen, ob Änderungen übernommen wurden, darin, die [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API-Aktion zu verwenden. Änderungen werden im Allgemeinen innerhalb von 60 Sekunden an alle Route 53-Name-Server übertragen.
1. Wenn Sie mehrere Datensätze erstellen, wiederholen Sie die Schritte 7 bis 8.
**Abrufen des DNS-Namens für einen Elastic Load Balancing Load Balancer**
1. Melden Sie sich AWS-Managementkonsole mit dem AWS Konto an, mit dem Sie den Classic-, Application- oder Network Load Balancer erstellt haben, für den Sie einen Aliaseintrag erstellen möchten.
1. Öffnen Sie die Amazon-EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Klicken Sie im Navigationsbereich auf **Load Balancers**.
1. Wählen Sie in der Liste der Load Balancer den Load Balancer aus, für den Sie einen Alias-Datensatz erstellen möchten.
1. Ermitteln Sie auf der Registerkarte **Description** den Wert bei **DNS name**.
1. Wiederholen Sie die Schritte 4 und 5, wenn Sie Alias-Datensätze für andere Elastic Load Balancing Load Balancer erstellen möchten.
1. Melden Sie sich von der AWS-Managementkonsole ab.
1. Melden Sie sich AWS-Managementkonsole erneut mit dem AWS Konto an, mit dem Sie die gehostete Route 53-Zone erstellt haben.
1. Gehen Sie zurück zu Schritt 3 des Verfahrens [Erstellen von Datensätzen mithilfe der Amazon-Route-53-Konsole](#resource-record-sets-creating).
# Berechtigungen für Ressourcendatensätze
Berechtigungen für Ressourcendatensätze verwenden die Richtlinienbedingungen für Identity and Access Management (IAM), damit Sie detaillierte Berechtigungen für Aktionen auf der Route 53-Konsole oder für die Verwendung der [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)API festlegen können.
Ein Ressourcendatensatz ist definiert als mehrere Ressourceneinträge mit demselben Namen und Typ (und derselben Klasse, aber für die meisten Zwecke ist die Klasse immer IN oder Internet), die jedoch unterschiedliche Daten enthalten. Wenn Sie beispielsweise Geolocation-Routing wählen, können Sie mehrere A- oder AAAA-Datensätze haben, die auf verschiedene Endpunkte für dieselbe Domain verweisen. Alle diese A- oder AAAA-Datensätze bilden zusammen einen Ressourcendatensatz. Weitere Informationen zur DNS-Terminologie finden Sie unter [RFC 7719](https://datatracker.ietf.org/doc/html/rfc7719).
Mit den IAM-Richtlinienbedingungen, `route53:ChangeResourceRecordSetsNormalizedRecordNames` `route53:ChangeResourceRecordSetsRecordTypes``route53:ChangeResourceRecordSetsActions`, und können Sie anderen AWS Benutzern in jedem anderen Konto detaillierte Administratorrechte gewähren. AWS Auf diese Weise können Sie jemandem Berechtigungen erteilen für:
+ Einen einzelnen Ressourcendatensatz.
+ Alle Ressourceneintragssätze eines bestimmten DNS-Eintragstyps.
+ Ressourcendatensätze, bei denen die Namen eine bestimmte Zeichenfolge enthalten.
+ Führen Sie einige oder alle `CREATE | UPSERT | DELETE ` Aktionen aus, wenn Sie die [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)API oder die Route 53-Konsole verwenden.
Sie können auch Zugriffsberechtigungen erstellen, die eine der Route 53-Richtlinienbedingungen kombinieren. Sie können beispielsweise jemandem die Berechtigung erteilen, die A-Datensatzdaten für marketing-example.com zu ändern, diesem Benutzer jedoch nicht erlauben, Datensätze zu löschen.
Weitere Informationen zu Berechtigungen für Ressourcendatensätze und Beispiele für deren Verwendung finden Sie unter[Verwenden von IAM-Richtlinienbedingungen für die differenzierte Zugriffskontrolle](specifying-conditions-route53.md).
Informationen zur Authentifizierung von AWS Benutzern finden Sie unter[Authentifizierung mit Identitäten](security-iam.md#security_iam_authentication). Informationen zum Steuern des Zugriffs auf Route 53-Ressourcen finden Sie unter[Zugriffskontrolle](security-iam.md#access-control).
# Werte, die Sie beim Erstellen oder Bearbeiten von Amazon Route 53-Datensätzen angeben
Wenn Sie Datensätze mit der Amazon Route 53-Konsole erstellen, hängen die von Ihnen angegebenen Werte von der Routing-Richtlinie ab, die Sie verwenden möchten, und davon, ob Sie Alias-Datensätze erstellen, die den Verkehr zu AWS Ressourcen weiterleiten.
Alias-Datensätze, die Traffic an bestimmte AWS Ressourcen weiterleiten, für die Sie die Zielressource angeben (z. B. Elastic Load Balancing, CloudFront Distribution, Amazon S3 S3-Bucket). Sie können optional auch Zustandsprüfungen verknüpfen und die Zielzustandsprüfung konfigurieren. Die folgenden Themen enthalten detaillierte Informationen zu den Werten, die für jede Routing-Richtlinie und jeden Datensatztyp erforderlich sind, sodass Sie Ihre Route 53-Datensätze effektiv konfigurieren können.
**Topics**
+ [Typische Werte für alle Routing-Richtlinien](resource-record-sets-values-shared.md)
+ [Werte, die für Aliasdatensätze für alle Routing-Richtlinien typisch sind](resource-record-sets-values-alias-common.md)
+ [Spezifische Werte für einfache Datensätze](resource-record-sets-values-basic.md)
+ [Spezifische Werte für einfache Aliasdatensätze](resource-record-sets-values-alias.md)
+ [Spezifische Werte für Failover-Datensätze](resource-record-sets-values-failover.md)
+ [Spezifische Werte für Failover-Aliasdatensätze](resource-record-sets-values-failover-alias.md)
+ [Spezifische Werte für Geolocation-Datensätze](resource-record-sets-values-geo.md)
+ [Spezifische Werte für Geolocation-Aliasdatensätze](resource-record-sets-values-geo-alias.md)
+ [Spezifische Werte für Geoproximitätsdatensätze](resource-record-sets-values-geoprox.md)
+ [Spezifische Werte für Geoproximitäts-Aliasdatensätze](resource-record-sets-values-geoprox-alias.md)
+ [Spezifische Werte für Latenz-Datensätze](resource-record-sets-values-latency.md)
+ [Spezifische Werte für Latenz-Aliasdatensätze](resource-record-sets-values-latency-alias.md)
+ [Spezifische Werte für IP-basierte Datensätze](resource-record-sets-values-ipbased.md)
+ [Spezifische Werte für IP-basierte Aliasdatensätze](resource-record-sets-values-ipbased-alias.md)
+ [Werte für spezifische mehrwertige Antwort-Datensätze](resource-record-sets-values-multivalue.md)
+ [Spezifische Werte für gewichtete Datensätze](resource-record-sets-values-weighted.md)
+ [Spezifische Werte für gewichtete Aliasdatensätze](resource-record-sets-values-weighted-alias.md)
# Typische Werte für alle Routing-Richtlinien
Das sind die Werte, die Sie bei der Erstellung oder Bearbeitung von Amazon Route 53-Datensätzen angeben. Diese Werte werden von allen Routing-Richtlinien verwendet.
**Topics**
+ [Datensatzname](#rrsets-values-common-name)
+ [Bewerten/Weiterleiten des Datenverkehrs an](#rrsets-values-common-value)
+ [TTL (Sekunden)](#rrsets-values-common-ttl)
## Datensatzname
Geben Sie den Namen der Domäne oder Subdomäne ein, für die Sie Verkehr weiterleiten wollen. Der Standardwert ist der Name der gehosteten Zone.
**Anmerkung**
Wenn Sie einen Datensatz erstellen, der denselben Namen wie die gehostete Zone hat, geben Sie im Feld **Name** keinen Wert ein (zum Beispiel ein @-Symbol).
**CNAME-Datensätze**
Wenn Sie einen Datensatz erstellen, der den Wert **CNAME** für **Datensatztyp** hat, darf der Name für den Datensatz nicht gleich dem Namen der gehosteten Zone sein.
**Sonderzeichen**
Erläuterungen dazu, wie Sie andere Zeichen als a-z, 0-9 und - (Bindestrich) eingeben und wie internationale Domainnamen angegeben werden, erhalten Sie unter [Format für DNS-Domänennamen](DomainNameFormat.md).
**Platzhalterzeichen**
Sie können im Namen ein Sternchenzeichen (\$1) verwenden. Abhängig von seiner Position im Namen wird das \$1-Zeichen vom DNS entweder als Platzhalter oder als das \$1-Zeichen (ASCII 42) behandelt. Weitere Informationen finden Sie unter [Verwendung eines Sternchens (\$1) im Namen von gehosteten Zonen und Datensätzen](DomainNameFormat.md#domain-name-format-asterisk).
Sie können den Platzhalter \$1 nicht für Ressourcendatensätze mit dem Typ **NS** verwenden.
## Bewerten/Weiterleiten des Datenverkehrs an
Klicken Sie auf **IP-Adresse oder ein anderer Wert, abhängig vom Datensatztyp**. Geben Sie einen gültigen Wert für **Datensatztyp** ein. Sie können für alle Typen außer **CNAME** mehr als einen Wert eingeben. Fügen Sie jeden Wert in einer separaten Zeile hinzu.
**A — IPv4 Adresse**
Eine IP-Adresse im IPv4 Format, zum Beispiel **192.0.2.235**.
**AAAA — Adresse IPv6 **
Eine IP-Adresse im IPv6 Format, zum Beispiel **2001:0 db 8:85 a 3:0:0:0:8** a2e: 0370:7334.
**CAA – Autorisierung der Zertifizierungsstelle**
Drei durch Leerzeichen voneinander getrennte Werte, die festlegen, welche Zertifizierungsstellen Zertifikate oder Platzhalterzertifikate für die in **Datensatzname** angegebene Domäne oder Subdomäne ausstellen dürfen. Sie können mit CAA-Datensätzen Folgendes angeben:
+ Welche CAs SSL/TLS Zertifizierungsstellen () können gegebenenfalls Zertifikate ausstellen
+ Die E-Mail-Adresse oder URL, die zu kontaktieren ist, wenn eine CA ein Zertifikat für die Domäne oder Subdomäne ausstellt.
**CNAME – kanonischer Name**
Der vollständig qualifizierte Domänenname (zum Beispiel *www.example.com*), an den Route 53 die Antworten auf DNS-Abfragen für diesen Datensatz zurückgeben soll. Ein abschließender Punkt ist optional. Route 53 nimmt an, dass der Domänenname vollständig qualifiziert ist. Das bedeutet, dass *www.example.com* (ohne Punkt am Ende) und *www.example.com.* (mit Punkt am Ende) von Route 53 identisch gehandhabt werden.
**MX – Mail-Austausch**
Eine Priorität und ein Domänenname, der einen Mail-Server angibt, zum Beispiel **10 mailserver.example.com**. Der abschließende Punkt wird als optional behandelt.
**NAPTR – Name Authority Pointer (Namensautorisierungszeiger)**
Sechs durch Leerzeichen getrennte Einstellungen, die von DDDS-Anwendungen (Dynamic Delegation Discovery System) verwendet werden, um einen Wert in einen anderen zu konvertieren oder einen Wert durch einen anderen zu ersetzen. Weitere Informationen finden Sie unter [NAPTR-Datensatztyp](ResourceRecordTypes.md#NAPTRFormat).
**PTR – Pointer (Zeiger)**
Der Domänenname, den Route 53 zurückgeben soll.
**NS – Namenserver**
Der Domänenname eines Namens-Servers wie **ns1.example.com**.
Sie können einen NS-Datensatz nur mit einfacher Routing-Richtlinie angeben.
**SPF – Sender Policy Framework.**
Ein SPF-Datensatz in Anführungszeichen, zum Beispiel **"v=spf1 ip4:192.168.0.1/16-all"**. SPF-Einträge werden nicht empfohlen. Weitere Informationen finden Sie unter [Unterstützte DNS-Datensatztypen](ResourceRecordTypes.md).
**SRV – Service-Locator**
Ein SRV-Eintrag. SRV-Einträge werden für den Zugriff auf Services verwendet, z. B. einen Service für E-Mail oder Kommunikation. Weitere Informationen zum SRV-Eintragsformat finden Sie in der Dokumentation des Service, mit dem Sie eine Verbindung herstellen möchten. Ein abschließender Punkt wird als optional behandelt.
Das Format eines SRV-Eintrags ist folgendermaßen:
**[Priorität] [Gewichtung] [Port] [Server-Host-Name]**
Beispiel:
**1 10 5269 xmpp-server.example.com.**
**TXT – Text**
Ein Texteintrag. Schließen Sie den Text in Anführungszeichen ein, z. B. **„Beispieltexteintrag“**.
## TTL (Sekunden)
Der Zeitraum (in Sekunden), für den Informationen über diesen Datensatz von rekursiven DNS-Resolvern zwischengespeichert werden sollen. Durch Angabe eines längeren Wertes (z. B. 172 800 Sekunden oder zwei Tage) verringern Sie die Anzahl der Aufrufe, die rekursive DNS-Resolver an Route 53 senden müssen, um die neuesten Informationen in diesem Datensatz zu erhalten. Dies führt zu einer Verringerung der Latenz und Kosten für den Route-53-Service. Weitere Informationen finden Sie unter [So leitet Amazon Route 53 Datenverkehr an Ihre Domain weiter](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Wenn Sie einen längeren Wert als TTL angeben, dauert es allerdings länger, bis Änderungen an dem Datensatz (z. B. eine neue IP-Adresse) wirksam werden. Dies liegt daran, dass die rekursiven Resolver die Werte in ihrem Zwischenspeicher für einen längeren Zeitraum verwenden, anstatt aktuelle Informationen von Route 53 anzufordern. Wenn Sie Einstellungen für eine Domäne oder Subdomäne ändern, die bereits verwendet wird, wird empfohlen, anfänglich einen kürzeren Wert, wie z. B. 300 Sekunden anzugeben und den Wert zu erhöhen, nachdem Sie bestätigt haben, dass die neuen Einstellungen korrekt sind.
Wenn Sie diesen Datensatz mit einer Zustandsprüfung verknüpfen, empfehlen wir Ihnen eine Time to Live (TTL) von 60 Sekunden oder weniger einzugeben, damit Clients schnell auf Änderungen im Zustandsstatus reagieren.
# Werte, die für Aliasdatensätze für alle Routing-Richtlinien typisch sind
Das sind die Werte, die Sie bei der Erstellung oder Bearbeitung von Amazon Route 53-Datensätzen angeben. Diese Werte werden von allen Routing-Richtlinien verwendet.
**Topics**
+ [Datensatzname](#rrsets-values-common-alias-name)
+ [Wert/Weiterleiten von Datenverkehr an](#rrsets-values-alias-common-target)
## Datensatzname
Geben Sie den Namen der Domäne oder Subdomäne ein, für die Sie Verkehr weiterleiten wollen. Der Standardwert ist der Name der gehosteten Zone.
**Anmerkung**
Wenn Sie einen Datensatz erstellen, der denselben Namen wie die gehostete Zone hat, geben Sie im Feld **Name** keinen Wert ein (zum Beispiel ein @-Symbol).
**CNAME-Datensätze**
Wenn Sie einen Datensatz erstellen, der den Wert **CNAME** für **Type (Typ)** hat, darf der Name für den Datensatz nicht gleich dem Namen der gehosteten Zone sein.
**Aliase für CloudFront Distributionen und Amazon S3 S3-Buckets**
Der Wert, den Sie angeben, hängt zum Teil von der AWS Ressource ab, an die Sie den Datenverkehr weiterleiten:
+ **CloudFront Verteilung** — Ihre Distribution muss einen alternativen Domainnamen enthalten, der dem Namen des Eintrags entspricht. Wenn der Name des Datensatzes beispielsweise **acme.example.com** ist, muss Ihre CloudFront-Verteilung **acme.example.com** als einen alternativen Domänennamen enthalten. Weitere Informationen finden Sie unter [Verwenden alternativer Domainnamen (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) im *Amazon CloudFront Developer Guide*.
+ **Amazon-S3-Bucket** – Der Name des Datensatzes muss mit dem Namen Ihres Amazon-S3-Buckets übereinstimmen. Wenn der Name des Buckets beispielsweise **acme.example.com** lautet, muss der Name dieses Datensatzes ebenfalls **acme.example.com** lauten.
Außerdem müssen Sie den Bucket für das Website-Hosting konfigurieren. Weitere Informationen finden Sie unter [Konfigurieren eines Buckets für Website-Hosting](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html) im *Benutzerhandbuch für Amazon Simple Storage Service*.
**Sonderzeichen**
Erläuterungen dazu, wie Sie andere Zeichen als a-z, 0-9 und - (Bindestrich) eingeben und wie internationale Domainnamen angegeben werden, erhalten Sie unter [Format für DNS-Domänennamen](DomainNameFormat.md).
**Platzhalterzeichen**
Sie können im Namen ein Sternchenzeichen (\$1) verwenden. Abhängig von seiner Position im Namen wird das \$1-Zeichen vom DNS entweder als Platzhalter oder als das \$1-Zeichen (ASCII 42) behandelt. Weitere Informationen finden Sie unter [Verwendung eines Sternchens (\$1) im Namen von gehosteten Zonen und Datensätzen](DomainNameFormat.md#domain-name-format-asterisk).
## Wert/Weiterleiten von Datenverkehr an
Der Wert, den Sie aus der Liste auswählen oder den Sie in das Feld eingeben, hängt von der AWS Ressource ab, an die Sie den Datenverkehr weiterleiten.
Weitere Informationen zur Konfiguration von Route 53 zur Weiterleitung von Verkehr zu bestimmten AWS Ressourcen finden Sie unter[Weiterleitung des Internetverkehrs zu Ihren AWS Ressourcen](routing-to-aws-resources.md).
**Wichtig**
Wenn Sie dasselbe AWS Konto verwendet haben, um Ihre Hosting-Zone und die Ressource zu erstellen, zu der Sie den Datenverkehr weiterleiten, und wenn Ihre Ressource nicht in der **Endpunktliste** erscheint, überprüfen Sie Folgendes:
Sie müssen einen unterstützten Wert für **Datensatztyp** auswählen. Unterstützte Werte sind spezifisch für die Ressource, auf die Sie den Datenverkehr leiten. Um beispielsweise Traffic an einen S3-Bucket weiterzuleiten, müssen Sie **A — IPv4 address als** **Datensatztyp** auswählen.
Das Konto muss über die IAM-Berechtigungen verfügen, die zum Auflisten der entsprechenden Ressourcen erforderlich sind. Damit beispielsweise CloudFront-Verteilungen in der Liste **Endpoint (Endpunkt)** angezeigt werden, muss das Konto über die Berechtigung zum Ausführen der folgenden Aktion verfügen: `cloudfront:ListDistributions`.
Eine IAM-Beispielrichtlinie finden Sie unter [Erforderliche Berechtigungen zur Verwendung der Amazon-Route-53-Konsole](access-control-managing-permissions.md#console-required-permissions).
Wenn Sie verschiedene AWS Konten verwendet haben, um die gehostete Zone und die Ressource zu erstellen, wird Ihre Ressource in der **Endpunktliste** nicht angezeigt. In der folgenden Dokumentation zu Ihrem Ressourcentyp erfahren Sie, welchen Wert Sie unter **Endpunkt** eingeben müssen.
**API Gateway, kundenspezifisch, regional APIs und Edge-optimiert APIs**
Führen Sie für API Gateway Custom Regional APIs und Edge-Optimized APIs einen der folgenden Schritte aus:
+ **Wenn Sie für die Erstellung Ihrer gehosteten Route-53-Zone und Ihrer API dasselbe Konto verwenden** – Wählen Sie **Endpunkt** und anschließend eine API aus der Liste aus. Wenn Sie viele haben APIs, können Sie die ersten Zeichen des API-Endpunkts eingeben, um die Liste zu filtern.
**Anmerkung**
Der Name dieses Datensatzes muss mit einem benutzerdefinierten Domänennamen für Ihre API übereinstimmen, z. B. **api.example.com**.
+ **Wenn Sie für die Erstellung Ihrer gehosteten Route-53-Zone und Ihrer API verschiedene Konten verwenden** – Geben Sie den API-Endpunkt für die API ein, z. B. **api.example.com**.
Wenn Sie ein AWS Konto zum Erstellen der aktuellen Hosting-Zone und ein anderes Konto zum Erstellen einer API verwendet haben, wird die API nicht in der Liste **Endpoints** unter **API Gateway APIs** angezeigt.
Wenn Sie ein Konto verwendet haben, um die aktuelle Hosting-Zone zu erstellen, und ein oder mehrere verschiedene Konten, um all Ihre Konten zu erstellen APIs, wird in der Liste **Endpoints** unter **API Gateway APIs** **Keine Ziele verfügbar** angezeigt. Weitere Informationen finden Sie unter [Weiterleiten des Datenverkehrs zu einer Amazon-API-Gateway-API mithilfe des Domainnamens](routing-to-api-gateway.md).
**CloudFront Distributionen**
Führen Sie für CloudFront Verteilungen einen der folgenden Schritte aus:
+ **Wenn Sie dasselbe Konto verwendet haben, um Ihre Route 53-Hosting-Zone und Ihre CloudFront Distribution zu erstellen**, wählen Sie **Endpoint** und wählen Sie eine Distribution aus der Liste aus. Bei einer großen Anzahl von Verteilungen können Sie die ersten Zeichen des Domänennamens der Verteilung eingeben, um die Liste zu filtern.
Beachten Sie Folgendes, wenn Ihre Verteilung nicht in der Liste angezeigt wird:
+ Der Name dieses Datensatzes muss mit einem alternativen Domänennamen in Ihrer Verteilung übereinstimmen.
+ Wenn Sie Ihrer Distribution gerade einen alternativen Domainnamen hinzugefügt haben, kann es 15 Minuten dauern, bis Ihre Änderungen an allen CloudFront Edge-Standorten wirksam werden. Erst wenn die Änderungen propagiert wurden, kann Route 53 den neuen alternativen Domänennamen kennen.
+ **Wenn Sie verschiedene Konten verwendet haben, um Ihre Route 53-Hosting-Zone und Ihre Distribution zu erstellen, geben Sie den CloudFront Domainnamen für die Verteilung** ein, z. B. **d111111abcdef8.cloudfront.net**.
**Wenn Sie ein AWS Konto zum Erstellen der aktuellen Hosting-Zone und ein anderes Konto zum Erstellen einer Verteilung verwendet haben, wird die Verteilung nicht in der Liste der Endpoints angezeigt.**
**Wenn Sie ein Konto zum Erstellen der aktuellen Hostzone und ein oder mehrere verschiedene Konten zum Erstellen all Ihrer Verteilungen verwendet haben, wird in der Liste **Endpunkte** unter Verteilungen der Eintrag **Keine Ziele verfügbar** angezeigt. CloudFront **
Leiten Sie Abfragen nicht an eine CloudFront Verteilung weiter, die nicht an allen Edge-Standorten verbreitet wurde, da Ihre Benutzer sonst nicht auf die entsprechenden Inhalte zugreifen können.
Ihre CloudFront Distribution muss einen alternativen Domainnamen enthalten, der dem Namen des Eintrags entspricht. Wenn der Name des Eintrags beispielsweise acme.example.com lautet, muss Ihre CloudFront Distribution **acme.example.com** als einen der **alternativen Domainnamen enthalten.** Weitere Informationen finden Sie unter [Verwenden alternativer Domainnamen (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) im *Amazon CloudFront Developer Guide*.
Wenn für die Verteilung aktiviert IPv6 ist, erstellen Sie zwei Datensätze, einen mit dem Wert **A — IPv4 Adresse** für **Datensatztyp** und einen mit dem Wert **AAAA — IPv6 Adresse**. Weitere Informationen finden Sie unter [Weiterleitung von Traffic an eine CloudFront Amazon-Distribution mithilfe Ihres Domainnamens](routing-to-cloudfront-distribution.md).
**App-Runner-Dienst**
Führen Sie für den App Runner-Dienst einen der folgenden Schritte aus:
+ **Wenn Sie dasselbe Konto verwendet haben, um Ihre Route 53-Hosting-Zone und Ihren App Runner-Dienst zu erstellen** AWS-Region, wählen Sie den und dann den Domainnamen der Umgebung, in die Sie den Verkehr weiterleiten möchten, aus der Liste aus.
+ **Wenn Sie verschiedene Konten verwendet haben, um Ihre von Route 53 gehostete Zone und Ihren App Runner zu erstellen**, geben Sie den benutzerdefinierten Domainnamen ein. Weitere Informationen finden Sie unter [Verwalten benutzerdefinierter Domainnamen für App Runner](https://docs.aws.amazon.com/apprunner/latest/dg/manage-custom-domains.html).
Wenn Sie ein AWS Konto zum Erstellen der aktuellen Hosting-Zone und ein anderes Konto zum Erstellen eines App Runners verwendet haben, wird der App Runner nicht in der Liste der **Endpoints** angezeigt.
Weitere Informationen finden Sie unter [Konfigurieren von Amazon Route 53 zur Weiterleitung des Datenverkehrs an einen App-Runner-Dienst](routing-to-app-runner.md#routing-to-app-runner-configuring).
**Elastic Beanstalk-Umgebungen, die über regionale Subdomänen verfügen**
Wenn der Domänenname für Ihre Elastic Beanstalk-Umgebung die Region enthält, in der Sie die Umgebung bereitgestellt haben, können Sie einen Aliasdatensatz erstellen, der Datenverkehr an die Umgebung weiterleitet. Der Domänenname `my-environment.us-west-2.elasticbeanstalk.com` ist beispielsweise ein regionalisierter Domänenname.
Für Umgebungen, die vor Anfang 2016 erstellt wurden, enthält der Domänenname die Region nicht. Um Datenverkehr an diese Umgebungen zu leiten, müssen Sie einen CNAME-Datensatz anstelle eines Alias-Datensatzes erstellen. Beachten Sie, dass es nicht möglich ist, einen CNAME-Datensatz für den Stammdomänennamen zu erstellen. Wenn der Domainname beispielsweise example.com ist, können Sie einen Datensatz erstellen, der den Datenverkehr für acme.example.com an Ihre Elastic Beanstalk-Umgebung leitet. Sie können jedoch keinen Datensatz erstellen, der den Datenverkehr für example.com an Ihre Elastic Beanstalk-Umgebung leitet.
Im Fall von Elastic-Beanstalk-Umgebungen mit regionalisierten Subdomänen führen Sie einen der folgenden Schritte aus:
+ **Wenn Sie für die Erstellung Ihrer gehosteten Route-53-Zone und Ihrer Elastic-Beanstalk-Umgebung dasselbe Konto verwendet haben** – Wählen Sie **Endpunkt** und anschließend eine Umgebung aus der Liste aus. Bei einer großen Anzahl von Umgebungen können Sie die ersten Zeichen des CNAME-Attributs für die Umgebung eingeben, um die Liste zu filtern.
+ **Wenn Sie unterschiedliche Konten verwendet haben, um Ihre Route-53-gehostete Zone und Ihre Elastic-Beanstalk-Umgebung zu erstellen** – Geben Sie das CNAME-Attribut für die Elastic-Beanstalk-Umgebung ein.
Weitere Informationen finden Sie unter [Weiterleiten des Datenverkehrs an eine AWS Elastic Beanstalk Umgebung](routing-to-beanstalk-environment.md).
**ELB-Load Balancer**
Führen Sie im Fall von ELB-Load Balancern einen der folgenden Schritte aus:
+ **Wenn Sie für die Erstellung der gehostete Route-53-Zone und Ihres Load Balancer dasselbe Konto verwendet haben** – Wählen Sie **Endpunkt** und anschließend einen Load Balancer aus der Liste aus. Bei einer großen Anzahl von Load Balancern können Sie die ersten Zeichen des DNS-Namens eingeben, um die Liste zu filtern.
+ **Wenn Sie für die Erstellung Ihrer gehosteten Route-53-Zone und Ihres Load Balancer verschiedene Konten verwendet haben** – Geben Sie den Wert ein, den Sie im Verfahren [Abrufen des DNS-Namens für einen Elastic Load Balancing Load Balancer](resource-record-sets-creating.md#resource-record-sets-elb-dns-name-procedure) erhalten haben.
**Wenn Sie ein AWS Konto zum Erstellen der aktuellen Hosting-Zone und ein anderes Konto zum Erstellen eines Load Balancers verwendet haben, wird der Load Balancer nicht in der Liste der Endpoints angezeigt.**
Wenn Sie für die Erstellung der aktuellen gehosteten Zone ein Konto und für die Erstellung all Ihrer Load Balancer ein oder mehrere andere Konten verwendet haben, wird in der Liste **Endpunkte** **Keine Ziele verfügbar** unter **Elastic Load Balancer** angezeigt.
Sie müssen **dualstack.** für Anwendung und Classic Load Balancer aus einem anderen Konto voranstellen. Wenn ein Client, z. B. ein Webbrowser, die IP-Adresse für Ihren Domainnamen (example.com) oder Ihren Subdomainnamen (www.example.com) anfordert, kann der Client eine IPv4 Adresse (einen A-Datensatz), eine IPv6 Adresse (einen AAAA-Eintrag) oder beides IPv4 und IPv6 Adressen (in separaten Anfragen) anfordern. Die Qualifizierung **dualstack.** ermöglicht Route 53, mit der jeweiligen IP-Adresse für Ihren Load Balancer zu antworten, abhängig vom IP-Adressenformat, das der Client angefordert hat.
Weitere Informationen finden Sie unter [Weiterleiten von Datenverkehr an einen ELB Load Balancer](routing-to-elb-load-balancer.md).
**AWS Beschleuniger von Global Accelerator**
Geben Sie für AWS Global Accelerator-Beschleuniger den DNS-Namen für den Accelerator ein. Sie können den DNS-Namen eines Accelerators eingeben, den Sie mit dem aktuellen AWS Konto oder mit einem anderen AWS Konto erstellt haben.
**Amazon-S3-Buckets**
Im Fall von Amazon-S3-Buckets, die als Website-Endpunkte konfiguriert sind, führen Sie einen der folgenden Schritte aus:
+ **Wenn Sie für die Erstellung Ihrer gehosteten Route-53-Zone und Ihres Amazon-S3-Buckets dasselbe Konto verwendet haben** – Wählen Sie Alias **Endpunkt** und anschließend einen Bucket aus der Liste aus. Bei einer großen Anzahl von Buckets können Sie die ersten Zeichen des DNS-Namens eingeben, um die Liste zu filtern.
Der Wert von **Endpunkt** ändert sich für Ihren Bucket in den Amazon-S3-Website-Endpunkt.
+ **Wenn Sie für die Erstellung Ihrer gehosteten Route-53-Zone und Ihres Amazon-S3-Buckets verschiedene Konten verwendet haben** – Geben Sie den Namen der Region ein, in der Sie Ihren S3 Bucket erstellt haben. Verwenden Sie den entsprechenden Wert aus der Spalte **Website-Endpunkt** in der Tabelle [Amazon-S3-Website-Endpunkte](https://docs.aws.amazon.com/general/latest/gr/s3.html#s3_website_region_endpoints) im *Allgemeine Amazon Web Services-Referenz*.
Wenn Sie für die Erstellung Ihrer Amazon S3 S3-Buckets andere AWS Konten als das aktuelle Konto verwendet haben, wird der Bucket nicht in der Liste der **Endpoints** angezeigt.
Sie müssen den Bucket für Website-Hosting konfigurieren. Weitere Informationen finden Sie unter [Konfigurieren eines Buckets für Website-Hosting](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html) im *Benutzerhandbuch für Amazon Simple Storage Service*.
Der Name des Datensatzes muss mit dem Namen Ihres Amazon-S3-Buckets übereinstimmen. Wenn der Name des Amazon-S3-Buckets beispielsweise **acme.example.com** lautet, muss der Name dieses Datensatzes ebenfalls **acme.example.com** lauten.
In einer Gruppe mit gewichteten Alias-, Latenz-Alias-, Failover-Alias- oder Geolocation-Alias-Datensätzen können Sie nur einen Datensatz erstellen, der Abfragen an einen Amazon-S3-Bucket weiterleitet. Der Grund hierfür ist, dass der Name des Datensatzes mit dem Namen des Buckets übereinstimmen muss und Bucketnamen global eindeutig sein müssen.
** OpenSearch Amazon-Dienst**
Führen Sie für OpenSearch Service einen der folgenden Schritte aus:
+ **OpenSearch Benutzerdefinierte Dienstdomäne**: Der Name des Eintrags muss mit der benutzerdefinierten Domäne übereinstimmen. Wenn der Name Ihrer benutzerdefinierten Domain beispielsweise test.example.com lautet, muss der Name dieses Datensatzes auch test.example.com lauten.
+ **Wenn Sie dasselbe Konto verwendet haben, um Ihre Route 53-Hosting-Zone und Ihre OpenSearch Service-Domain zu erstellen AWS-Region, wählen Sie die und dann den Domainnamen** aus.
+ **Wenn Sie unterschiedliche Konten verwendet haben, um Ihre Route 53-Hosting-Zone und Ihre OpenSearch Service-Domain zu erstellen**, geben Sie den benutzerdefinierten Domainnamen ein. Weitere Informationen finden Sie unter [Benutzerdefinierten Endpunkt erstellen](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/customendpoint.html).
Wenn Sie ein AWS Konto zum Erstellen der aktuellen Hosting-Zone und ein anderes Konto zum Erstellen einer OpenSearch Dienstdomäne verwendet haben, wird die Domain nicht in der Liste der **Endpoints** angezeigt.
**Wenn Sie ein Konto verwendet haben, um die aktuelle Hosting-Zone zu erstellen, und ein oder mehrere verschiedene Konten, um all Ihre OpenSearch Service-Domains zu erstellen, wird in der Liste **Endpoints** unter OpenSearch Service die Option **Keine Ziele verfügbar** angezeigt.**
Weitere Informationen finden Sie unter [Konfiguration von Amazon Route 53 zur Weiterleitung von Datenverkehr an einen Amazon OpenSearch Service-Domain-Endpunkt](routing-to-open-search-service.md#routing-to-open-search-service-configuring).
**Amazon-VPC-Schnittstellenendpunkte**
Im Fall von Amazon-VPC-Schnittstellenendpunkten führen Sie einen der folgenden Schritte aus:
+ **Wenn Sie für die Erstellung Ihrer gehosteten Route-53-Zone und Ihres Schnittstellenendpunkts dasselbe Konto verwendet haben** – Wählen Sie **Endpunkt** und anschließend einen Schnittstellenendpunkt aus der Liste aus. Bei einer großen Anzahl von Schnittstellenendpunkten können Sie die ersten Zeichen des DNS-Namens eingeben, um die Liste zu filtern.
+ **Wenn Sie verschiedene Konten verwendet haben, um Ihre Route 53-Hosting-Zone und Ihren Schnittstellenendpunkt zu erstellen**, geben Sie den DNS-Hostnamen für den Schnittstellenendpunkt ein, z. B. **vpce-123456789abcdef01- example-us-east -1a.elasticloadbalancing.us-east-1.vpce.amazonaws.com**.
Wenn Sie ein AWS Konto zum Erstellen der aktuellen Hosting-Zone und ein anderes Konto zum Erstellen eines Schnittstellenendpunkts verwendet haben, wird der Schnittstellenendpunkt nicht in der **Endpunktliste** unter **VPC-Endpoints** angezeigt.
Wenn Sie für die Erstellung der aktuellen gehosteten Zone ein Konto und für die Erstellung all Ihrer Schnittstellenendpunkte ein oder mehrere Konten verwendet haben, wird in der Liste **Endpunkte** **Keine Ziele verfügbar** unter **VPC-Endpunkte** angezeigt.
Weitere Informationen finden Sie unter [Weiterleiten des Datenverkehrs an einen Amazon-Virtual-Private Cloud-Schnittstellenendpunkt unter Verwendung Ihres Domainnamens](routing-to-vpc-interface-endpoint.md).
**Datensätze in dieser gehosteten Zone**
Wählen Sie für Datensätze in dieser gehosteten Zone **Endpunkt** und anschließend den jeweiligen Datensatz aus. Bei einer großen Anzahl von Datensätzen können Sie die ersten Zeichen des Namens eingeben, um die Liste zu filtern.
Wenn die gehostete Zone nur die NS- und SOA-Standarddatensätze enthält, wird in der Liste **Endpunkte** **Keine Ziele verfügbar** angezeigt.
Wenn Sie einen Aliasdatensatz erstellen, der denselben Namen wie die gehostete Zone hat (*Zonen-Apex*), können Sie keinen Datensatz auswählen, dessen Wert für **Datensatztyp** **CNAME** ist. Der Grund hierfür ist, dass der Aliasdatensatz denselben Typ wie der Datensatz haben muss, zu dem Sie den Datenverkehr weiterleiten, und die Erstellung eines CNAME-Datensatzes für den Zonen-Apex wird für einen Aliasdatensatz nicht unterstützt.
# Spezifische Werte für einfache Datensätze
Beim Erstellen einfacher Datensätze geben Sie die folgenden Werte an.
**Topics**
+ [Routing-Richtlinie](#rrsets-values-basic-routing-policy)
+ [Datensatzname](#rrsets-values-basic-name)
+ [Bewerten/Weiterleiten des Datenverkehrs an](#rrsets-values-basic-value)
+ [Datensatztyp](#rrsets-values-basic-type)
+ [TTL (Sekunden)](#rrsets-values-basic-ttl)
## Routing-Richtlinie
Klicken Sie auf **Einfaches Routing**.
## Datensatzname
Geben Sie den Namen der Domäne oder Subdomäne ein, für die Sie Verkehr weiterleiten wollen. Der Standardwert ist der Name der gehosteten Zone.
**Anmerkung**
Wenn Sie einen Datensatz erstellen, der denselben Namen wie die gehostete Zone hat, geben Sie im Feld **Name** keinen Wert ein (zum Beispiel ein @-Symbol).
Weitere Informationen über Datensatznamen finden Sie unter [Datensatzname](resource-record-sets-values-shared.md#rrsets-values-common-name).
## Bewerten/Weiterleiten des Datenverkehrs an
Klicken Sie auf **IP-Adresse oder ein anderer Wert, abhängig vom Datensatztyp**. Geben Sie einen gültigen Wert für **Datensatztyp** ein. Sie können für alle Typen außer **CNAME** mehr als einen Wert eingeben. Fügen Sie jeden Wert in einer separaten Zeile hinzu.
Sie können weiterleiten oder die folgenden Werte angeben:
+ **A — IPv4 Adresse**
+ **AAAA — Adresse IPv6 **
+ **CAA – Certificate Authority Authorization** (Autorisierung der Zertifizierungsstelle)
+ **CNAME – kanonischer Name**
+ **MX – Mail-Austausch**
+ **NAPTR – Name Authority Pointer** (Namensautorisierungszeiger)
+ **NS – Namenserver**
Der Domänenname eines Namens-Servers wie **ns1.example.com**.
**Anmerkung**
Sie können einen NS-Datensatz nur mit einfacher Routing-Richtlinie angeben.
+ **PTR – Pointer** (Zeiger)
+ **SPF – Sender Policy Framework** (Richtlinien-Framework des Senders)
+ **SRV – Service-Locator**
+ **TXT – Text**
Weitere Informationen zu den oben genannten Werten finden Sie unter [Allgemeine Werte für den Value/Route Verkehr nach](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Datensatztyp
Der DNS-Datensatztyp. Weitere Informationen finden Sie unter [Unterstützte DNS-Datensatztypen](ResourceRecordTypes.md).
Wählen Sie den Wert für **Datensatztyp** danach aus, wie Route 53 auf DNS-Abfragen antworten soll.
## TTL (Sekunden)
Der Zeitraum (in Sekunden), für den Informationen über diesen Datensatz von rekursiven DNS-Resolvern zwischengespeichert werden sollen. Durch Angabe eines längeren Wertes (z. B. 172 800 Sekunden oder zwei Tage) verringern Sie die Anzahl der Aufrufe, die rekursive DNS-Resolver an Route 53 senden müssen, um die neuesten Informationen in diesem Datensatz zu erhalten. Dies führt zu einer Verringerung der Latenz und Kosten für den Route-53-Service. Weitere Informationen finden Sie unter [So leitet Amazon Route 53 Datenverkehr an Ihre Domain weiter](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Wenn Sie einen längeren Wert als TTL angeben, dauert es allerdings länger, bis Änderungen an dem Datensatz (z. B. eine neue IP-Adresse) wirksam werden. Dies liegt daran, dass die rekursiven Resolver die Werte in ihrem Zwischenspeicher für einen längeren Zeitraum verwenden, anstatt aktuelle Informationen von Route 53 anzufordern. Wenn Sie Einstellungen für eine Domäne oder Subdomäne ändern, die bereits verwendet wird, wird empfohlen, anfänglich einen kürzeren Wert, wie z. B. 300 Sekunden anzugeben und den Wert zu erhöhen, nachdem Sie bestätigt haben, dass die neuen Einstellungen korrekt sind.
# Spezifische Werte für einfache Aliasdatensätze
Beim Erstellen von Aliasdatensätzen geben Sie die folgenden Werte an. Weitere Informationen finden Sie unter [Wählen zwischen Alias- und Nicht-Alias-Datensätzen](resource-record-sets-choosing-alias-non-alias.md).
**Anmerkung**
Wenn Sie Route 53 in der verwenden AWS GovCloud (US) Region, hat diese Funktion einige Einschränkungen. Weitere Informationen finden Sie auf der [Amazon-Route-53-Seite](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-r53.html) im *AWS GovCloud (US) -Benutzerhandbuch*.
**Topics**
+ [Routing-Richtlinie](#rrsets-values-alias-routing-policy)
+ [Datensatzname](#rrsets-values-alias-name)
+ [Wert/Weiterleiten von Datenverkehr an](#rrsets-values-alias-alias-target)
+ [Datensatztyp](#rrsets-values-alias-type)
+ [Evaluate Target Health](#rrsets-values-alias-evaluate-target-health)
## Routing-Richtlinie
Klicken Sie auf **Einfaches Routing**.
## Datensatzname
Geben Sie den Namen der Domäne oder Subdomäne ein, für die Sie Verkehr weiterleiten wollen. Der Standardwert ist der Name der gehosteten Zone.
**Anmerkung**
Wenn Sie einen Datensatz erstellen, der denselben Namen wie die gehostete Zone hat, geben Sie im Feld **Name** keinen Wert ein (zum Beispiel ein @-Symbol).
Weitere Informationen über Datensatznamen finden Sie unter [Datensatzname](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).
## Wert/Weiterleiten von Datenverkehr an
Der Wert, den Sie aus der Liste auswählen oder den Sie in das Feld eingeben, hängt von der AWS Ressource ab, zu der Sie den Verkehr weiterleiten.
Informationen darüber, auf welche AWS Ressourcen Sie abzielen können, finden Sie unter [Allgemeine Werte für Aliasdatensätze für den value/route Datenverkehr](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
Weitere Informationen zur Konfiguration von Route 53 zur Weiterleitung von Datenverkehr an bestimmte AWS Ressourcen finden Sie unter[Weiterleitung des Internetverkehrs zu Ihren AWS Ressourcen](routing-to-aws-resources.md).
## Datensatztyp
Der DNS-Datensatztyp. Weitere Informationen finden Sie unter [Unterstützte DNS-Datensatztypen](ResourceRecordTypes.md).
Wählen Sie den entsprechenden Wert basierend auf der AWS Ressource aus, an die Sie den Verkehr weiterleiten:
**Benutzerdefinierte regionale API-Gateway-API oder Edge-optimierte API**
Wählen Sie **A — IPv4 Adresse** aus.
**Amazon-VPC-Schnittstellenendpunkte**
Wählen Sie **A — IPv4 Adresse** aus.
**CloudFront Vertrieb**
Wählen Sie **A — IPv4 Adresse** aus.
Wenn für die Verteilung aktiviert IPv6 ist, erstellen Sie zwei Datensätze, einen mit dem Wert **A — IPv4 Adresse** für **Typ** und einen mit dem Wert **AAAA — IPv6 Adresse**.
**App-Runner-Dienst**
Wählen Sie **A — Adresse IPv4 **
**Elastic-Beanstalk-Umgebung, die über regionale Subdomänen verfügt**
Wählen Sie **A — IPv4 Adresse**
**ELB-Load Balancer**
Wählen **Sie IPv4 A-Adresse** oder **AAAA-Adresse IPv6 **
**Amazon-S3-Bucket**
Wählen Sie **A — Adresse IPv4 **
**OpenSearch Dienst**
Wählen **Sie IPv4 A-Adresse** oder **AAAA-Adresse IPv6 **
**Weiterer Datensatz in dieser gehosteten Zone**
Wählen Sie den Typ des Datensatzes aus, für den Sie den Alias erstellen. Es werden alle Typen außer **NS** und **SOA** unterstützt.
Wenn Sie einen Aliasdatensatz mit demselben Namen wie die gehostete Zone (*Zonen-Apex*) erstellen, können Sie den Datenverkehr nicht zu einem Datensatz weiterleiten, dessen Wert in **Type (Typ)** **CNAME** ist. Der Grund hierfür ist, dass der Aliasdatensatz denselben Typ wie der Datensatz haben muss, zu dem Sie den Datenverkehr weiterleiten, und die Erstellung eines CNAME-Datensatzes für den Zonen-Apex wird für einen Aliasdatensatz nicht unterstützt.
## Evaluate Target Health
Wenn der Wert der **Routing policy (Routing-Richtlinie)** **Simple (Einfach)** ist, können Sie entweder **No (Nein)** oder den Standardwert **Ja** auswählen, da **Evaluate target health (Zielzustand bewerten)** keine Auswirkung auf **einfaches** Routing hat. Wenn es nur einen Datensatz mit einem bestimmten Namen und Typ gibt, antwortet Route 53 auf DNS-Abfragen mittels der Werte in diesem Datensatz, unabhängig davon, ob die Ressource fehlerfrei ist.
Bei anderen Routing-Richtlinien bestimmt **Evaluate target health**, ob Route 53 den Zustand der Ressource überprüft, auf die sich der Aliaseintrag bezieht:
+ **Dienste, bei denen die Option Zielintegrität bewerten betriebliche Vorteile bietet**: Bei Load Balancers (ELB) und AWS Elastic Beanstalk Umgebungen mit Load Balancers kann Route 53 den Verkehr von fehlerhaften Ressourcen wegleiten, wenn die Option **Zielintegrität auswerten** auf **Ja** gesetzt wird.
+ **Hochverfügbare Services**: Für Services wie Amazon S3 S3-Buckets, VPC-Schnittstellenendpunkte, Amazon API Gateway AWS Global Accelerator, Amazon OpenSearch Service und Amazon VPC Lattice bietet **Evaluate Target Health** keinen betrieblichen Vorteil, da diese Services auf Hochverfügbarkeit ausgelegt sind. Verwenden Sie für Failover-Szenarien mit diesen Diensten stattdessen [Route 53 53-Zustandsprüfungen](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html).
Ausführliche Informationen darüber, wie **Evaluate Target Health** mit verschiedenen AWS Diensten funktioniert, finden Sie in der [ EvaluateTargetHealth](https://docs.aws.amazon.com/Route53/latest/APIReference/API_AliasTarget.html#Route53-Type-AliasTarget-EvaluateTargetHealth)Dokumentation in der API-Referenz.
# Spezifische Werte für Failover-Datensätze
Beim Erstellen von Failover-Datensätzen geben Sie die folgenden Werte an.
**Anmerkung**
Weitere Informationen zum Erstellen von Failover-Datensätzen in einer privaten gehosteten Zone finden Sie unter [Konfigurieren von Failover in einer privaten gehosteten Zone](dns-failover-private-hosted-zones.md).
**Topics**
+ [Routing-Richtlinie](#rrsets-values-failover-routing-policy)
+ [Datensatzname](#rrsets-values-failover-name)
+ [Datensatztyp](#rrsets-values-failover-type)
+ [TTL (Sekunden)](#rrsets-values-failover-ttl)
+ [Bewerten/Weiterleiten des Datenverkehrs an](#rrsets-values-failover-value)
+ [Failover-Datensatztyp](#rrsets-values-failover-record-type)
+ [Gesundheitscheck](#rrsets-values-failover-associate-with-health-check)
+ [Datensatz-ID](#rrsets-values-failover-set-id)
## Routing-Richtlinie
Klicken Sie auf **Failover**.
## Datensatzname
Geben Sie den Namen der Domäne oder Subdomäne ein, für die Sie Verkehr weiterleiten wollen. Der Standardwert ist der Name der gehosteten Zone.
**Anmerkung**
Wenn Sie einen Datensatz erstellen, der denselben Namen wie die gehostete Zone hat, geben Sie im Feld **Datensatzname** keinen Wert ein (zum Beispiel ein @-Symbol).
Geben Sie für beide Datensätze in der Gruppe von Failover-Datensätzen denselben Namen ein.
Weitere Informationen über Datensatznamen finden Sie unter [Datensatzname](resource-record-sets-values-shared.md#rrsets-values-common-name).
## Datensatztyp
Der DNS-Datensatztyp. Weitere Informationen finden Sie unter [Unterstützte DNS-Datensatztypen](ResourceRecordTypes.md).
Wählen Sie für die primären und sekundären Failover-Datensätze denselben Wert aus.
## TTL (Sekunden)
Der Zeitraum (in Sekunden), für den Informationen über diesen Datensatz von rekursiven DNS-Resolvern zwischengespeichert werden sollen. Durch Angabe eines längeren Wertes (z. B. 172 800 Sekunden oder zwei Tage) verringern Sie die Anzahl der Aufrufe, die rekursive DNS-Resolver an Route 53 senden müssen, um die neuesten Informationen in diesem Datensatz zu erhalten. Dies führt zu einer Verringerung der Latenz und Kosten für den Route-53-Service. Weitere Informationen finden Sie unter [So leitet Amazon Route 53 Datenverkehr an Ihre Domain weiter](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Wenn Sie einen längeren Wert als TTL angeben, dauert es allerdings länger, bis Änderungen an dem Datensatz (z. B. eine neue IP-Adresse) wirksam werden. Dies liegt daran, dass die rekursiven Resolver die Werte in ihrem Zwischenspeicher für einen längeren Zeitraum verwenden, anstatt aktuelle Informationen von Route 53 anzufordern. Wenn Sie Einstellungen für eine Domäne oder Subdomäne ändern, die bereits verwendet wird, wird empfohlen, anfänglich einen kürzeren Wert, wie z. B. 300 Sekunden anzugeben und den Wert zu erhöhen, nachdem Sie bestätigt haben, dass die neuen Einstellungen korrekt sind.
Wenn Sie diesen Datensatz mit einer Zustandsprüfung verknüpfen, empfehlen wir Ihnen eine Time to Live (TTL) von 60 Sekunden oder weniger einzugeben, damit Clients schnell auf Änderungen im Zustandsstatus reagieren.
## Bewerten/Weiterleiten des Datenverkehrs an
Klicken Sie auf **IP-Adresse oder ein anderer Wert, abhängig vom Datensatztyp**. Geben Sie einen gültigen Wert für **Datensatztyp** ein. Sie können für alle Typen außer **CNAME** mehr als einen Wert eingeben. Fügen Sie jeden Wert in einer separaten Zeile hinzu.
Sie können weiterleiten oder die folgenden Werte angeben:
+ **A — IPv4 Adresse**
+ **AAAA — Adresse IPv6 **
+ **CAA – Certificate Authority Authorization** (Autorisierung der Zertifizierungsstelle)
+ **CNAME – kanonischer Name**
+ **MX – Mail-Austausch**
+ **NAPTR – Name Authority Pointer** (Namensautorisierungszeiger)
+ **PTR – Pointer** (Zeiger)
+ **SPF – Sender Policy Framework** (Richtlinien-Framework des Senders)
+ **SRV – Service-Locator**
+ **TXT – Text**
Weitere Informationen zu den oben genannten Werten finden Sie unter [Allgemeine Werte für den Value/Route Verkehr nach](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Failover-Datensatztyp
Wählen Sie den passenden Wert für diesen Datensatz aus. Damit der Failover-Prozess ordnungsgemäß funktionieren kann, müssen Sie einen primären und einen sekundären Failover-Datensatz erstellen.
Sie können keine Nicht-Failover-Datensätze erstellen, die über die gleichen Werte wie Failover-Datensätze für **Datensatzname** und **Datensatztyp** verfügen.
## Gesundheitscheck
Wählen Sie eine Zustandsprüfung aus, wenn Route 53 den Status eines angegebenen Endpunkts überprüfen und DNS-Abfragen mit diesem Eintrag nur beantworten soll, wenn der Endpunkt fehlerfrei ist.
Route 53 prüft den Zustand des im Datensatz angegebenen Endpunkts nicht, z. B. des durch die IP-Adresse im Feld **Wert** definierten Endpunkts. Wenn Sie eine Zustandsprüfung für einen Datensatz auswählen, überprüft Route 53 den Zustand des Endpunkts, den Sie in der Zustandsprüfung angegeben haben. Informationen dazu, wie Route 53 ermittelt, ob ein Endpunkt fehlerfrei ist, finden Sie unter [So ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei istSo ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei ist](dns-failover-determining-health-of-endpoints.md).
Die Verknüpfung einer Zustandsprüfung mit einem Datensatz ist nur nützlich, wenn Route 53 zwischen mindestens zwei Datensätzen auswählt, um auf eine DNS-Abfrage zu antworten, und Route 53 die Auswahl zum Teil anhand des Status einer Zustandsprüfung treffen soll. Verwenden Sie Zustandsprüfungen nur in den folgenden Konfigurationen:
+ Sie überprüfen den Zustand aller Datensätze in einer Gruppe von Datensätzen, die denselben Namen, denselben Typ und dieselbe Routing-Richtlinie haben (z. B. Failover oder gewichtete Datensätze), und Sie geben eine Integritätsprüfung IDs für alle Datensätze an. Wenn die Zustandsprüfung für einen Datensatz einen Endpunkt angibt, der nicht fehlerfrei ist, antwortet Route 53 nicht mehr auf Abfragen, die den Wert für diesen Datensatz verwenden.
+ Sie wählen **Yes** (Ja) für **Evaluate Target Health** (Zustand des Ziels bewerten) für einen Alias-Datensatz oder die Datensätze in einer Gruppe aus Failover-Alias-, Geolocation-Alias-, Latenz-Alias-, IP-basierten Alias- oder gewichteten Alias-Datensätzen aus. Wenn die Alias-Datensätze andere als Alias-Datensätze in derselben gehosteten Zone referenzieren, müssen Sie auch Zustandsprüfungen für die referenzierten Datensätze angeben. Wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen und **Yes** (Ja) für **Evaluate Target Health** (Zustand des Ziels bewerten) auswählen, müssen beide mit „True“ ausgewertet werden. Weitere Informationen finden Sie unter [Was geschieht, wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Wenn Ihre Zustandsprüfungen den Endpunkt nur nach Domainname angeben, sollten Sie für jeden Endpunkt eine eigene Zustandsprüfung erstellen. Sie sollten beispielsweise eine Zustandsprüfung für jeden HTTP-Server erstellen, der Inhalte für www.example.com bereitstellt. Sie müssen in **Domain Name (Domänenname)** als Wert den Domänennamen des Servers angeben (z. B. us-east-2-www.example.com), nicht den Namen der Datensätze (example.com).
**Wichtig**
Wenn Sie in dieser Konfiguration eine Zustandsprüfung erstellen, für die der Wert von **Domain Name (Domänenname)** mit dem Namen der Datensätze übereinstimmt, und anschließend die Zustandsprüfung mit diesen Datensätzen verknüpfen, sind die Ergebnisse der Zustandsprüfung nicht planbar.
## Datensatz-ID
Geben Sie einen Wert ein, der die primären und sekundären Datensätze eindeutig identifiziert.
# Spezifische Werte für Failover-Aliasdatensätze
Beim Erstellen von Failover-Aliasdatensätzen geben Sie die folgenden Werte an.
Weitere Informationen finden Sie unter den folgenden Themen:
+ Weitere Informationen zum Erstellen von Failover-Datensätzen in einer privaten gehosteten Zone finden Sie unter [Konfigurieren von Failover in einer privaten gehosteten Zone](dns-failover-private-hosted-zones.md).
+ Weitere Informationen über Alias-Datensätze finden Sie unter [Wählen zwischen Alias- und Nicht-Alias-Datensätzen](resource-record-sets-choosing-alias-non-alias.md).
**Topics**
+ [Routing-Richtlinie](#rrsets-values-failover-alias-routing-policy)
+ [Datensatzname](#rrsets-values-failover-alias-name)
+ [Datensatztyp](#rrsets-values-failover-alias-type)
+ [Bewerten/Weiterleiten des Datenverkehrs an](#rrsets-values-failover-alias-alias-target)
+ [Failover-Datensatztyp](#rrsets-values-failover-alias-failover-record-type)
+ [Gesundheitscheck](#rrsets-values-failover-alias-associate-with-health-check)
+ [Evaluate Target Health](#rrsets-values-failover-alias-evaluate-target-health)
+ [Datensatz-ID](#rrsets-values-failover-alias-set-id)
## Routing-Richtlinie
Klicken Sie auf **Failover**.
## Datensatzname
Geben Sie den Namen der Domäne oder Subdomäne ein, für die Sie Verkehr weiterleiten wollen. Der Standardwert ist der Name der gehosteten Zone.
**Anmerkung**
Wenn Sie einen Datensatz erstellen, der denselben Namen wie die gehostete Zone hat, geben Sie im Feld **Datensatzname** keinen Wert ein (zum Beispiel ein @-Symbol).
Geben Sie für beide Datensätze in der Gruppe von Failover-Datensätzen denselben Namen ein.
Weitere Informationen über Datensatznamen finden Sie unter [Datensatzname](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).
## Datensatztyp
Der DNS-Datensatztyp. Weitere Informationen finden Sie unter [Unterstützte DNS-Datensatztypen](ResourceRecordTypes.md).
Wählen Sie den entsprechenden Wert basierend auf der AWS Ressource aus, zu der Sie den Verkehr weiterleiten. Wählen Sie für die primären und sekundären Failover-Datensätze denselben Wert aus:
**Benutzerdefinierte regionale API-Gateway-API oder Edge-optimierte API**
Wählen Sie **A — IPv4 Adresse** aus.
**Amazon-VPC-Schnittstellenendpunkte**
Wählen Sie **A — IPv4 Adresse**.
**CloudFront Vertrieb**
Wählen Sie **A — IPv4 Adresse** aus.
Wenn für die Verteilung aktiviert IPv6 ist, erstellen Sie zwei Datensätze, einen mit dem Wert **A — IPv4 Adresse** für **Typ** und einen mit dem Wert **AAAA — IPv6 Adresse**.
**App-Runner-Dienst**
Wählen Sie **A — Adresse IPv4 **
**Elastic-Beanstalk-Umgebung, die über regionale Subdomänen verfügt**
Wählen Sie **A — IPv4 Adresse**
**ELB-Load Balancer**
Wählen **Sie IPv4 A-Adresse** oder **AAAA-Adresse IPv6 **
**Amazon-S3-Bucket**
Wählen Sie **A — Adresse IPv4 **
**OpenSearch Dienst**
Wählen **Sie IPv4 A-Adresse** oder **AAAA-Adresse IPv6 **
**Weiterer Datensatz in dieser gehosteten Zone**
Wählen Sie den Typ des Datensatzes aus, für den Sie den Alias erstellen. Es werden alle Typen außer **NS** und **SOA** unterstützt.
Wenn Sie einen Aliasdatensatz mit demselben Namen wie die gehostete Zone (*Zonen-Apex*) erstellen, können Sie den Datenverkehr nicht zu einem Datensatz weiterleiten, dessen Wert in **Type (Typ)** **CNAME** ist. Der Grund hierfür ist, dass der Aliasdatensatz denselben Typ wie der Datensatz haben muss, zu dem Sie den Datenverkehr weiterleiten, und die Erstellung eines CNAME-Datensatzes für den Zonen-Apex wird für einen Aliasdatensatz nicht unterstützt.
## Bewerten/Weiterleiten des Datenverkehrs an
Der Wert, den Sie aus der Liste auswählen oder den Sie in das Feld eingeben, hängt von der AWS Ressource ab, an die Sie den Verkehr weiterleiten.
Informationen darüber, auf welche AWS Ressourcen Sie abzielen können, finden Sie unter [Allgemeine Werte für Aliasdatensätze für den value/route Datenverkehr](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
Weitere Informationen zur Konfiguration von Route 53 zur Weiterleitung von Datenverkehr an bestimmte AWS Ressourcen finden Sie unter[Weiterleitung des Internetverkehrs zu Ihren AWS Ressourcen](routing-to-aws-resources.md).
**Anmerkung**
Bei der Erstellung von primären und sekundären Failover-Datensätzen können Sie optional einen Failover- und einen Failover-*Alias*-Datensatz erstellen, die dieselben Werte für **Name** und **Datensatztyp** haben. Wenn Sie Failover- und Failover-Alias-Datensätze mischen, kann jeder davon der primäre Datensatz sein.
## Failover-Datensatztyp
Wählen Sie den passenden Wert für diesen Datensatz aus. Damit der Failover-Prozess ordnungsgemäß funktionieren kann, müssen Sie einen primären und einen sekundären Failover-Datensatz erstellen.
Sie können keine Nicht-Failover-Datensätze erstellen, die über die gleichen Werte wie Failover-Datensätze für **Datensatzname** und **Datensatztyp** verfügen.
## Gesundheitscheck
Wählen Sie eine Zustandsprüfung aus, wenn Route 53 den Status eines angegebenen Endpunkts überprüfen und DNS-Abfragen mit diesem Eintrag nur beantworten soll, wenn der Endpunkt fehlerfrei ist.
Route 53 prüft den Zustand des im Datensatz angegebenen Endpunkts nicht, z. B. des durch die IP-Adresse im Feld **Wert** definierten Endpunkts. Wenn Sie eine Zustandsprüfung für einen Datensatz auswählen, überprüft Route 53 den Zustand des Endpunkts, den Sie in der Zustandsprüfung angegeben haben. Informationen dazu, wie Route 53 ermittelt, ob ein Endpunkt fehlerfrei ist, finden Sie unter [So ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei istSo ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei ist](dns-failover-determining-health-of-endpoints.md).
Die Verknüpfung einer Zustandsprüfung mit einem Datensatz ist nur nützlich, wenn Route 53 zwischen mindestens zwei Datensätzen auswählt, um auf eine DNS-Abfrage zu antworten, und Route 53 die Auswahl zum Teil anhand des Status einer Zustandsprüfung treffen soll. Verwenden Sie Zustandsprüfungen nur in den folgenden Konfigurationen:
+ Sie überprüfen den Zustand aller Datensätze in einer Gruppe von Datensätzen, die denselben Namen, denselben Typ und dieselbe Routing-Richtlinie haben (z. B. Failover oder gewichtete Datensätze), und Sie geben eine Integritätsprüfung IDs für alle Datensätze an. Wenn die Zustandsprüfung für einen Datensatz einen Endpunkt angibt, der nicht fehlerfrei ist, antwortet Route 53 nicht mehr auf Abfragen, die den Wert für diesen Datensatz verwenden.
+ Sie wählen **Yes** (Ja) für **Evaluate Target Health** (Zustand des Ziels bewerten) für einen Alias-Datensatz oder die Datensätze in einer Gruppe aus Failover-Alias-, Geolocation-Alias-, Latenz-Alias-, IP-basierten Alias- oder gewichteten Alias-Datensätzen aus. Wenn die Alias-Datensätze andere als Alias-Datensätze in derselben gehosteten Zone referenzieren, müssen Sie auch Zustandsprüfungen für die referenzierten Datensätze angeben. Wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen und **Yes** (Ja) für **Evaluate Target Health** (Zustand des Ziels bewerten) auswählen, müssen beide mit „True“ ausgewertet werden. Weitere Informationen finden Sie unter [Was geschieht, wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Wenn Ihre Zustandsprüfungen den Endpunkt nur nach Domainname angeben, sollten Sie für jeden Endpunkt eine eigene Zustandsprüfung erstellen. Sie sollten beispielsweise eine Zustandsprüfung für jeden HTTP-Server erstellen, der Inhalte für www.example.com bereitstellt. Sie müssen in **Domain Name (Domänenname)** als Wert den Domänennamen des Servers angeben (z. B. us-east-2-www.example.com), nicht den Namen der Datensätze (example.com).
**Wichtig**
Wenn Sie in dieser Konfiguration eine Zustandsprüfung erstellen, für die der Wert von **Domain Name (Domänenname)** mit dem Namen der Datensätze übereinstimmt, und anschließend die Zustandsprüfung mit diesen Datensätzen verknüpfen, sind die Ergebnisse der Zustandsprüfung nicht planbar.
## Evaluate Target Health
Wählen Sie **Ja** aus, wenn Route 53 ermitteln soll, ob auf DNS-Abfragen, die diesen Datensatz verwenden, geantwortet werden soll, indem der Zustand der in **Endpunkt** angegebenen Ressource geprüft wird.
Beachten Sie Folgendes:
**API Gateway, kundenspezifisch, regional APIs und Edge-optimiert APIs**
Es gibt keine besonderen Anforderungen für das Festlegen von **Zielzustand bewerten** auf **Ja**, wenn der Endpunkt eine benutzerdefinierte regionale API-Gateway-API oder eine Edge-optimierte API ist.
**CloudFront Verteilungen**
Sie können die Option **Zielintegrität bewerten** nicht auf **Ja setzen, wenn es** sich bei dem Endpunkt um eine CloudFront Verteilung handelt.
**Elastic Beanstalk-Umgebungen, die über regionale Subdomänen verfügen**
Wenn Sie in **Endpunkt** eine Elastic-Beanstalk-Umgebung angeben und diese einen ELB-Load-Balancer enthält, leitet Elastic Load Balancing Abfragen nur an die fehlerfreien Amazon-EC2-Instances weiter, die beim Load Balancer registriert sind. (Eine Umgebung enthält automatisch einen ELB-Load Balancer, wenn sie mehr als eine Amazon EC2-Instance umfasst.) Wenn Sie **Zielzustand bewerten** auf **Ja** setzen und entweder keine fehlerfreien Amazon-EC2-Instances zur Verfügung stehen oder der Load Balancer selbst fehlerhaft ist, leitet Route 53 Abfragen an andere fehlerfreie Ressourcen weiter, sofern vorhanden.
Bei einer Umgebung, die nur eine einzelne Amazon EC2-Instance enthält, gibt es keine besonderen Anforderungen.
**ELB-Load Balancer**
Das Verhalten der Zustandsprüfung ist abhängig vom Typ des Load Balancers:
+ **Classic Load Balancer** – Wenn Sie in **Endpunkt** einen ELB-Classic-Load-Balancer angeben, leitet Elastic Load Balancing Abfragen nur an die fehlerfreien Amazon-EC2-Instances weiter, die beim Load Balancer registriert sind. Wenn Sie **Zielzustand bewerten** auf **Ja** festlegen und es entweder keine fehlerfreien EC2-Instances gibt oder der Load Balancer selbst fehlerhaft ist, leitet Route 53 Abfragen an andere Ressourcen weiter.
+ **Anwendung und Network Load Balancer** – Wenn Sie eine ELB-Anwendung oder einen Network Load Balancer angeben und **Zielzustand bewerten** auf **Ja** festlegen, leitet Route 53 Abfragen basierend auf dem Zustand der mit dem Load Balancer verknüpften Zielgruppen an den Load Balancer weiter:
+ Damit ein Application oder Network Load Balancer als fehlerfrei gilt, muss eine Zielgruppe mit Zielen mindestens ein fehlerfreies Ziel enthalten. Falls eine Zielgruppe nur fehlerhafte Ziele enthält, gilt der Load Balancer als fehlerhaft und Route 53 leitet Abfragen an andere Ressourcen weiter.
+ Eine Zielgruppe ohne registrierte Ziele gilt als fehlerhaft.
Beim Erstellen eines Load Balancers konfigurieren Sie Einstellungen für Elastic Load Balancing-Zustandsprüfungen. Dies sind keine Route 53-Zustandsprüfungen. Sie erfüllen aber eine ähnliche Funktion. Erstellen Sie keine Route 53-Zustandsprüfungen für die EC2-Instances, die Sie bei einem ELB-Load Balancer registrieren.
**S3-Buckets**
Es gibt keine speziellen Anforderungen, nach denen **Evaluate Target Health (Zielzustand bewerten)** auf **Yes (Ja)** festgelegt werden muss, wenn es sich beim Endpunkt um einen S3-Bucket handelt.
**Amazon-VPC-Schnittstellenendpunkte**
Es gibt keine besonderen Anforderungen für das Festlegen der **Zielzustand bewerten** auf **Ja**, wenn der Endpunkt ein Amazon-VPC-Schnittstellenendpunkt ist.
**Andere Datensätze innerhalb derselben gehosteten Zone**
Wenn es sich bei der AWS Ressource, die Sie in **Endpoint** angeben, um einen Datensatz oder eine Gruppe von Datensätzen handelt (z. B. um eine Gruppe gewichteter Datensätze), es sich jedoch nicht um einen weiteren Aliasdatensatz handelt, empfehlen wir, allen Datensätzen im Endpunkt eine Integritätsprüfung zuzuordnen. Weitere Informationen finden Sie unter [Was geschieht, wenn Sie Zustandsprüfungen überspringen?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).
## Datensatz-ID
Geben Sie einen Wert ein, der die primären und sekundären Datensätze eindeutig identifiziert.
# Spezifische Werte für Geolocation-Datensätze
Beim Erstellen von Geolocation-Datensätzen geben Sie die folgenden Werte an.
**Topics**
+ [Routing-Richtlinie](#rrsets-values-geo-routing-policy)
+ [Datensatzname](#rrsets-values-geo-name)
+ [Datensatztyp](#rrsets-values-geo-type)
+ [TTL (Sekunden)](#rrsets-values-geo-ttl)
+ [Bewerten/Weiterleiten des Datenverkehrs an](#rrsets-values-geo-value)
+ [Speicherort](#rrsets-values-geo-location)
+ [US-Staaten](#rrsets-values-geo-sublocation)
+ [Gesundheitscheck](#rrsets-values-geo-associate-with-health-check)
+ [Datensatz-ID](#rrsets-values-geo-set-id)
## Routing-Richtlinie
Wählen Sie **Geolocation** aus.
## Datensatzname
Geben Sie den Namen der Domäne oder Subdomäne ein, für die Sie Verkehr weiterleiten wollen. Der Standardwert ist der Name der gehosteten Zone.
**Anmerkung**
Wenn Sie einen Datensatz erstellen, der denselben Namen wie die gehostete Zone hat, geben Sie im Feld **Name** keinen Wert ein (zum Beispiel ein @-Symbol).
Geben Sie für alle Datensätze in der Gruppe von Geolocation-Datensätzen denselben Namen ein.
Weitere Informationen über Datensatznamen finden Sie unter [Datensatzname](resource-record-sets-values-shared.md#rrsets-values-common-name).
## Datensatztyp
Der DNS-Datensatztyp. Weitere Informationen finden Sie unter [Unterstützte DNS-Datensatztypen](ResourceRecordTypes.md).
Wählen Sie für alle Datensätze in der Gruppe von Geolocation-Datensätzen denselben Namen aus:
## TTL (Sekunden)
Der Zeitraum (in Sekunden), für den Informationen über diesen Datensatz von rekursiven DNS-Resolvern zwischengespeichert werden sollen. Durch Angabe eines längeren Wertes (z. B. 172 800 Sekunden oder zwei Tage) verringern Sie die Anzahl der Aufrufe, die rekursive DNS-Resolver an Route 53 senden müssen, um die neuesten Informationen in diesem Datensatz zu erhalten. Dies führt zu einer Verringerung der Latenz und Kosten für den Route-53-Service. Weitere Informationen finden Sie unter [So leitet Amazon Route 53 Datenverkehr an Ihre Domain weiter](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Wenn Sie einen längeren Wert als TTL angeben, dauert es allerdings länger, bis Änderungen an dem Datensatz (z. B. eine neue IP-Adresse) wirksam werden. Dies liegt daran, dass die rekursiven Resolver die Werte in ihrem Zwischenspeicher für einen längeren Zeitraum verwenden, anstatt aktuelle Informationen von Route 53 anzufordern. Wenn Sie Einstellungen für eine Domäne oder Subdomäne ändern, die bereits verwendet wird, wird empfohlen, anfänglich einen kürzeren Wert, wie z. B. 300 Sekunden anzugeben und den Wert zu erhöhen, nachdem Sie bestätigt haben, dass die neuen Einstellungen korrekt sind.
Wenn Sie diesen Datensatz mit einer Zustandsprüfung verknüpfen, empfehlen wir Ihnen eine Time to Live (TTL) von 60 Sekunden oder weniger einzugeben, damit Clients schnell auf Änderungen im Zustandsstatus reagieren.
## Bewerten/Weiterleiten des Datenverkehrs an
Klicken Sie auf **IP-Adresse oder ein anderer Wert, abhängig vom Datensatztyp**. Geben Sie einen gültigen Wert für **Datensatztyp** ein. Sie können für alle Typen außer **CNAME** mehr als einen Wert eingeben. Fügen Sie jeden Wert in einer separaten Zeile hinzu.
Sie können weiterleiten oder die folgenden Werte angeben:
+ **A — IPv4 Adresse**
+ **AAAA — Adresse IPv6 **
+ **CAA – Certificate Authority Authorization** (Autorisierung der Zertifizierungsstelle)
+ **CNAME – kanonischer Name**
+ **MX – Mail-Austausch**
+ **NAPTR – Name Authority Pointer** (Namensautorisierungszeiger)
+ **PTR – Pointer** (Zeiger)
+ **SPF – Sender Policy Framework** (Richtlinien-Framework des Senders)
+ **SRV – Service-Locator**
+ **TXT – Text**
Weitere Informationen zu den oben genannten Werten finden Sie unter [Allgemeine Werte für den Value/Route Verkehr nach](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Speicherort
Bei der Konfiguration von Route 53 für Antworten auf DNS-Abfragen auf Basis des Standorts, von dem die Abfragen stammen, wählen Sie den Kontinent oder das Land aus, für den bzw. das Route 53 mit den Einstellungen in diesem Datensatz antworten soll. Wenn Route 53 auf DNS-Abfragen für einzelne Bundesstaaten in den Vereinigten Staaten antworten soll, wählen Sie **United States (USA)** in der Liste **Location (Ort)** und den Bundesstaat in der Liste **Sublocation (Standort)** aus.
Wählen Sie für eine private gehostete Zone den Kontinent, das Land oder die Unterteilung aus, die dem, in dem sich Ihre Ressource befindet AWS-Region , am nächsten liegt. Wenn sich Ihre Ressource beispielsweise in us-east-1 befindet, können Sie Nordamerika, USA oder Virginia angeben.
**Wichtig**
Es wird empfohlen, einen Geolocation-Datensatz mit dem Wert **Standard** für **Standort** zu erstellen. Dies deckt geographische Standorte ab, für die Sie keine Datensätze erstellt haben, sowie IP-Adressen, für die Route 53 keinen Standort identifizieren kann.
Sie können keine Nicht-Geolocation-Datensätze erstellen, die für **Datensatzname** und **Datensatztyp** die gleichen Werte wie Geolocation-Datensätze aufweisen.
Weitere Informationen finden Sie unter [Geolocation-Routing](routing-policy-geo.md).
Dies sind die Länder, die Amazon Route 53 dem jeweiligen Kontinent zuordnet. Die Ländercodes entsprechen ISO 3166. Weitere Informationen finden Sie im Wikipedia-Artikel zu [ISO 3166-1 Alpha-2](http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2):
**Afrika (AF)**
AO, BF, BI, BJ, BW, CD, CF, CG, CI, CM, CV, DJ, DZ, EG, ER, ET, GA, GH, GM, GN, GQ, GW, KE, KM, LR, LS, LY, MA, MG, ML, MR, MU, MW, MZ, NA, NE, NG, RE, RW, SC, SD, SH, SL, SN, SO, SS, ST, SZ, TD, TG, TN, TZ, UG, YT, ZA, ZM, ZW
**Antarktika (AN)**
AQ, GS, TF
**Asien (AS)**
AE, AF, AM, AZ, BD, BH, BN, BT, CC, CN, GE, HK, ID, IL, IN, IO, IQ, IR, JO, JP, KG, KH, KP, KR, KW, KZ, LA, LB, LK, MM, MN, MO, MV, MY, NP, OM, PH, PK, PS, QA, SA, SG, SY, TH, TJ, TM, TW, UZ, VN, YE
**Europa (EU)**
AD, AL, AT, AX, BA, BE, BG, BY, CH, CY, CZ, DE, DK, EE, ES, FI, FO, FR, GB, GG, GI, GR, HR, HU, IE, IM, IS, IT, JE, LI, LT, LU, LV, MC, MD, ME, MK, MT, NL, NO, PL, PT, RO, RS, RU, SE, SI, SJ, SK, SM, TR, UA, VA, XK
Einige Anbieter gehen davon aus, dass TR in Asien angesiedelt ist, und die IP-Adressen werden dies widerspiegeln.
**Nordamerika (NA)**
AG, AI, AW, BB, BL, BM, BQ, BS, BZ, CA, CR, CU, CW, DM, DO, GD, GL, GP, GT, HN, HT, JM, KN, KY, LC, MF, MQ, MS, MX, NI, PA, PM, PR, SV, SX, TC, TT, US, VC, VG, VI
**Ozeanien (OC)**
AS, AU, CK, FJ, FM, GU, KI, MH, MP, NC, NF, NR, NU, NZ, PF, PG, PN, PW, SB, TK, TL, TO, TV, UM, VU, WF, WS
**Südamerika (SA)**
AR, BO, BR, CL, CO, EC, FK, GF, GY, PE, PY, SR, UY, VE
**Anmerkung**
Route 53 unterstützt nicht die Erstellung von Geolokalisierungsdatensätzen für die folgenden Länder: Bouvetinsel (BV), Weihnachtsinsel (CX), Westsahara (EH) und Heard Island and McDonald Islands (HM). Für diese Länder stehen keine Daten zu IP-Adressen zur Verfügung.
## US-Staaten
Wenn Route 53 auf DNS-Abfragen auf Basis des Bundesstaats in den Vereinigten Staaten, aus dem die Abfragen stammen, antworten soll, wählen Sie den Bundesstaat in der Liste **USA-Staaten** aus. US-Territorien (zum Beispiel Puerto Rico) werden in der Liste **Location (Ort)** als Länder aufgeführt.
**Wichtig**
Einige IP-Adressen sind mit den Vereinigten Staaten verknüpft, aber nicht mit einem einzelnen Bundesstaat. Wenn Sie Datensätze für sämtliche Bundesstaaten der Vereinigten Staaten erstellen, empfehlen wir, auch einen Datensatz für die Vereinigten Staaten zu erstellen, um diese nicht verknüpften IP-Adressen weiterzuleiten. Wenn Sie keinen Datensatz für die Vereinigten Staaten erstellen, antwortet Route 53 auf DNS-Abfragen von nicht verknüpften IP-Adressen der Vereinigten Staaten mit den Einstellungen aus dem standardmäßigen Geolocation-Datensatz (sofern von Ihnen erstellt) oder mit der Information, dass keine Antwort erfolgt.
## Gesundheitscheck
Wählen Sie eine Zustandsprüfung aus, wenn Route 53 den Status eines angegebenen Endpunkts überprüfen und DNS-Abfragen mit diesem Eintrag nur beantworten soll, wenn der Endpunkt fehlerfrei ist.
Route 53 prüft den Zustand des im Datensatz angegebenen Endpunkts nicht, z. B. des durch die IP-Adresse im Feld **Wert** definierten Endpunkts. Wenn Sie eine Zustandsprüfung für einen Datensatz auswählen, überprüft Route 53 den Zustand des Endpunkts, den Sie in der Zustandsprüfung angegeben haben. Informationen dazu, wie Route 53 ermittelt, ob ein Endpunkt fehlerfrei ist, finden Sie unter [So ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei istSo ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei ist](dns-failover-determining-health-of-endpoints.md).
Die Verknüpfung einer Zustandsprüfung mit einem Datensatz ist nur nützlich, wenn Route 53 zwischen mindestens zwei Datensätzen auswählt, um auf eine DNS-Abfrage zu antworten, und Route 53 die Auswahl zum Teil anhand des Status einer Zustandsprüfung treffen soll. Verwenden Sie Zustandsprüfungen nur in den folgenden Konfigurationen:
+ Sie überprüfen den Zustand aller Datensätze in einer Gruppe von Datensätzen, die denselben Namen, denselben Typ und dieselbe Routing-Richtlinie haben (z. B. Failover oder gewichtete Datensätze), und Sie geben eine Integritätsprüfung IDs für alle Datensätze an. Wenn die Zustandsprüfung für einen Datensatz einen Endpunkt angibt, der nicht fehlerfrei ist, antwortet Route 53 nicht mehr auf Abfragen, die den Wert für diesen Datensatz verwenden.
+ Sie wählen **Yes** (Ja) für **Evaluate Target Health** (Zustand des Ziels bewerten) für einen Alias-Datensatz oder die Datensätze in einer Gruppe aus Failover-Alias-, Geolocation-Alias-, Latenz-Alias-, IP-basierten Alias- oder gewichteten Alias-Datensätzen aus. Wenn die Alias-Datensätze andere als Alias-Datensätze in derselben gehosteten Zone referenzieren, müssen Sie auch Zustandsprüfungen für die referenzierten Datensätze angeben. Wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen und **Yes** (Ja) für **Evaluate Target Health** (Zustand des Ziels bewerten) auswählen, müssen beide mit „True“ ausgewertet werden. Weitere Informationen finden Sie unter [Was geschieht, wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Wenn Ihre Zustandsprüfungen den Endpunkt nur nach Domainname angeben, sollten Sie für jeden Endpunkt eine eigene Zustandsprüfung erstellen. Sie sollten beispielsweise eine Zustandsprüfung für jeden HTTP-Server erstellen, der Inhalte für www.example.com bereitstellt. Sie müssen in **Domain Name (Domänenname)** als Wert den Domänennamen des Servers angeben (z. B. us-east-2-www.example.com), nicht den Namen der Datensätze (example.com).
**Wichtig**
Wenn Sie in dieser Konfiguration eine Zustandsprüfung erstellen, für die der Wert von **Domain Name (Domänenname)** mit dem Namen der Datensätze übereinstimmt, und anschließend die Zustandsprüfung mit diesen Datensätzen verknüpfen, sind die Ergebnisse der Zustandsprüfung nicht planbar.
Wenn es einen fehlerhaften Endpunkt in Geolocation-Datensätzen gibt, sucht Route 53 nach einem Datensatz für die größere verknüpfte geografische Region. Angenommen, Sie besitzen Datensätze für einen Bundesstaat der Vereinigten Staaten, für die Vereinigten Staaten, für Nordamerika und für alle Standorte (**Location (Standort)** ist **Default (Standard)**). Wenn der Endpunkt für den Bundesstaatdatensatz fehlerhaft ist, prüft Route 53 der Reihe nach die Datensätze für die Vereinigten Staaten, für Nordamerika und für alle Standorte, bis ein Datensatz mit einem fehlerfreien Endpunkt gefunden wird. Wenn alle Datensätze einschließlich des Datensatzes für alle Standorte fehlerhaft sind, antwortet Route 53 auf die DNS-Abfrage mittels des Werts für den Datensatz für die kleinste geografische Region.
## Datensatz-ID
Geben Sie einen Wert ein, der diesen Datensatz in der Gruppe von Geolocation-Datensätzen eindeutig identifiziert.
# Spezifische Werte für Geolocation-Aliasdatensätze
Beim Erstellen von Geolocation-Aliasdatensätzen geben Sie die folgenden Werte an.
Weitere Informationen finden Sie unter [Wählen zwischen Alias- und Nicht-Alias-Datensätzen](resource-record-sets-choosing-alias-non-alias.md).
**Topics**
+ [Routing-Richtlinie](#rrsets-values-geo-alias-routing-policy)
+ [Datensatzname](#rrsets-values-geo-alias-name)
+ [Datensatztyp](#rrsets-values-geo-alias-type)
+ [Bewerten/Weiterleiten des Datenverkehrs an](#rrsets-values-geo-alias-alias-target)
+ [Speicherort](#rrsets-values-geo-alias-location)
+ [US-Staaten](#rrsets-values-geo-alias-sublocation)
+ [Gesundheitscheck](#rrsets-values-geo-alias-associate-with-health-check)
+ [Evaluate Target Health](#rrsets-values-geo-alias-evaluate-target-health)
+ [Datensatz-ID](#rrsets-values-geo-alias-set-id)
## Routing-Richtlinie
Wählen Sie **Geolocation** aus.
## Datensatzname
Geben Sie den Namen der Domäne oder Subdomäne ein, für die Sie Verkehr weiterleiten wollen. Der Standardwert ist der Name der gehosteten Zone.
**Anmerkung**
Wenn Sie einen Datensatz erstellen, der denselben Namen wie die gehostete Zone hat, geben Sie im Feld **Datensatzname** keinen Wert ein (zum Beispiel ein @-Symbol).
Geben Sie für alle Datensätze in der Gruppe von Geolocation-Datensätzen denselben Namen ein.
Weitere Informationen über Datensatznamen finden Sie unter [Datensatzname](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).
## Datensatztyp
Der DNS-Datensatztyp. Weitere Informationen finden Sie unter [Unterstützte DNS-Datensatztypen](ResourceRecordTypes.md).
Wählen Sie den entsprechenden Wert basierend auf der AWS Ressource aus, zu der Sie den Verkehr weiterleiten. Wählen Sie für alle Datensätze in der Gruppe von Geolocation-Datensätzen denselben Namen aus:
**Benutzerdefinierte regionale API-Gateway-API oder Edge-optimierte API**
Wählen Sie **A — IPv4 Adresse** aus.
**Amazon-VPC-Schnittstellenendpunkte**
Wählen Sie **A — IPv4 Adresse** aus.
**CloudFront Vertrieb**
Wählen Sie **A — IPv4 Adresse** aus.
Wenn für die Verteilung aktiviert IPv6 ist, erstellen Sie zwei Datensätze, einen mit dem Wert **A — IPv4 Adresse** für **Typ** und einen mit dem Wert **AAAA — IPv6 Adresse**.
**App-Runner-Dienst**
Wählen Sie **A — Adresse IPv4 **
**Elastic-Beanstalk-Umgebung, die über regionale Subdomänen verfügt**
Wählen Sie **A — IPv4 Adresse**
**ELB-Load Balancer**
Wählen **Sie IPv4 A-Adresse** oder **AAAA-Adresse IPv6 **
**Amazon-S3-Bucket**
Wählen Sie **A — Adresse IPv4 **
**OpenSearch Dienst**
Wählen Sie **A — IPv4 Adresse** oder **AAAA — IPv6 ** Adresse
**Weiterer Datensatz in dieser gehosteten Zone**
Wählen Sie den Typ des Datensatzes aus, für den Sie den Alias erstellen. Es werden alle Typen außer **NS** und **SOA** unterstützt.
Wenn Sie einen Aliasdatensatz mit demselben Namen wie die gehostete Zone (*Zonen-Apex*) erstellen, können Sie den Datenverkehr nicht zu einem Datensatz weiterleiten, dessen Wert in **Type (Typ)** **CNAME** ist. Der Grund hierfür ist, dass der Aliasdatensatz denselben Typ wie der Datensatz haben muss, zu dem Sie den Datenverkehr weiterleiten, und die Erstellung eines CNAME-Datensatzes für den Zonen-Apex wird für einen Aliasdatensatz nicht unterstützt.
## Bewerten/Weiterleiten des Datenverkehrs an
Der Wert, den Sie aus der Liste auswählen oder den Sie in das Feld eingeben, hängt von der AWS Ressource ab, an die Sie den Verkehr weiterleiten.
Informationen darüber, auf welche AWS Ressourcen Sie abzielen können, finden Sie unter[Wert/Weiterleiten von Datenverkehr an](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
Weitere Informationen zur Konfiguration von Route 53 zur Weiterleitung von Datenverkehr zu bestimmten AWS Ressourcen finden Sie unter[Weiterleitung des Internetverkehrs zu Ihren AWS Ressourcen](routing-to-aws-resources.md).
## Speicherort
Bei der Konfiguration von Route 53 für Antworten auf DNS-Abfragen auf Basis des Standorts, von dem die Abfragen stammen, wählen Sie den Kontinent oder das Land aus, für den bzw. das Route 53 mit den Einstellungen in diesem Datensatz antworten soll. Wenn Route 53 auf DNS-Abfragen für einzelne Bundesstaaten in den Vereinigten Staaten antworten soll, wählen Sie **United States (USA)** in der Liste **Location (Ort)** und den Bundesstaat in der Liste **U.S. States (USA)** aus.
Wählen Sie für eine private gehostete Zone den Kontinent, das Land oder die Unterteilung aus, die dem, in dem sich Ihre Ressource befindet AWS-Region , am nächsten liegt. Wenn sich Ihre Ressource beispielsweise in us-east-1 befindet, können Sie Nordamerika, USA oder Virginia angeben.
**Wichtig**
Es wird empfohlen, einen Geolocation-Datensatz mit dem Wert **Standard** für **Standort** zu erstellen. Dies deckt geographische Standorte ab, für die Sie keine Datensätze erstellt haben, sowie IP-Adressen, für die Route 53 keinen Standort identifizieren kann.
Sie können keine Nicht-Geolocation-Datensätze erstellen, die für **Datensatzname** und **Datensatztyp** die gleichen Werte wie Geolocation-Datensätze aufweisen.
Weitere Informationen finden Sie unter [Geolocation-Routing](routing-policy-geo.md).
Dies sind die Länder, die Amazon Route 53 dem jeweiligen Kontinent zuordnet. Die Ländercodes entsprechen ISO 3166. Weitere Informationen finden Sie im Wikipedia-Artikel zu [ISO 3166-1 Alpha-2](http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2):
**Afrika (AF)**
AO, BF, BI, BJ, BW, CD, CF, CG, CI, CM, CV, DJ, DZ, EG, ER, ET, GA, GH, GM, GN, GQ, GW, KE, KM, LR, LS, LY, MA, MG, ML, MR, MU, MW, MZ, NA, NE, NG, RE, RW, SC, SD, SH, SL, SN, SO, SS, ST, SZ, TD, TG, TN, TZ, UG, YT, ZA, ZM, ZW
**Antarktika (AN)**
AQ, GS, TF
**Asien (AS)**
AE, AF, AM, AZ, BD, BH, BN, BT, CC, CN, GE, HK, ID, IL, IN, IO, IQ, IR, JO, JP, KG, KH, KP, KR, KW, KZ, LA, LB, LK, MM, MN, MO, MV, MY, NP, OM, PH, PK, PS, QA, SA, SG, SY, TH, TJ, TM, TW, UZ, VN, YE
**Europa (EU)**
AD, AL, AT, AX, BA, BE, BG, BY, CH, CY, CZ, DE, DK, EE, ES, FI, FO, FR, GB, GG, GI, GR, HR, HU, IE, IM, IS, IT, JE, LI, LT, LU, LV, MC, MD, ME, MK, MT, NL, NO, PL, PT, RO, RS, RU, SE, SI, SJ, SK, SM, TR, UA, VA, XK
Einige Anbieter gehen davon aus, dass TR in Asien angesiedelt ist, und die IP-Adressen werden dies widerspiegeln.
**Nordamerika (NA)**
AG, AI, AW, BB, BL, BM, BQ, BS, BZ, CA, CR, CU, CW, DM, DO, GD, GL, GP, GT, HN, HT, JM, KN, KY, LC, MF, MQ, MS, MX, NI, PA, PM, PR, SV, SX, TC, TT, US, VC, VG, VI
**Ozeanien (OC)**
AS, AU, CK, FJ, FM, GU, KI, MH, MP, NC, NF, NR, NU, NZ, PF, PG, PN, PW, SB, TK, TL, TO, TV, UM, VU, WF, WS
**Südamerika (SA)**
AR, BO, BR, CL, CO, EC, FK, GF, GY, PE, PY, SR, UY, VE
**Anmerkung**
Route 53 unterstützt nicht die Erstellung von Geolokalisierungsdatensätzen für die folgenden Länder: Bouvetinsel (BV), Weihnachtsinsel (CX), Westsahara (EH) und Heard Island and McDonald Islands (HM). Für diese Länder stehen keine Daten zu IP-Adressen zur Verfügung.
## US-Staaten
Wenn Route 53 auf DNS-Abfragen auf Basis des Bundesstaats in den Vereinigten Staaten, aus dem die Abfragen stammen, antworten soll, wählen Sie den Bundesstaat in der Liste **USA-Staaten** aus. US-Territorien (zum Beispiel Puerto Rico) werden in der Liste **Location (Ort)** als Länder aufgeführt.
**Wichtig**
Einige IP-Adressen sind mit den Vereinigten Staaten verknüpft, aber nicht mit einem einzelnen Bundesstaat. Wenn Sie Datensätze für sämtliche Bundesstaaten der Vereinigten Staaten erstellen, empfehlen wir, auch einen Datensatz für die Vereinigten Staaten zu erstellen, um diese nicht verknüpften IP-Adressen weiterzuleiten. Wenn Sie keinen Datensatz für die Vereinigten Staaten erstellen, antwortet Route 53 auf DNS-Abfragen von nicht verknüpften IP-Adressen der Vereinigten Staaten mit den Einstellungen aus dem standardmäßigen Geolocation-Datensatz (sofern von Ihnen erstellt) oder mit der Information, dass keine Antwort erfolgt.
## Gesundheitscheck
Wählen Sie eine Zustandsprüfung aus, wenn Route 53 den Status eines angegebenen Endpunkts überprüfen und DNS-Abfragen mit diesem Eintrag nur beantworten soll, wenn der Endpunkt fehlerfrei ist.
Route 53 prüft den Zustand des im Datensatz angegebenen Endpunkts nicht, z. B. des durch die IP-Adresse im Feld **Wert** definierten Endpunkts. Wenn Sie eine Zustandsprüfung für einen Datensatz auswählen, überprüft Route 53 den Zustand des Endpunkts, den Sie in der Zustandsprüfung angegeben haben. Informationen dazu, wie Route 53 ermittelt, ob ein Endpunkt fehlerfrei ist, finden Sie unter [So ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei istSo ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei ist](dns-failover-determining-health-of-endpoints.md).
Die Verknüpfung einer Zustandsprüfung mit einem Datensatz ist nur nützlich, wenn Route 53 zwischen mindestens zwei Datensätzen auswählt, um auf eine DNS-Abfrage zu antworten, und Route 53 die Auswahl zum Teil anhand des Status einer Zustandsprüfung treffen soll. Verwenden Sie Zustandsprüfungen nur in den folgenden Konfigurationen:
+ Sie überprüfen den Zustand aller Datensätze in einer Gruppe von Datensätzen, die denselben Namen, denselben Typ und dieselbe Routing-Richtlinie haben (z. B. Failover oder gewichtete Datensätze), und Sie geben eine Integritätsprüfung IDs für alle Datensätze an. Wenn die Zustandsprüfung für einen Datensatz einen Endpunkt angibt, der nicht fehlerfrei ist, antwortet Route 53 nicht mehr auf Abfragen, die den Wert für diesen Datensatz verwenden.
+ Sie wählen **Yes** (Ja) für **Evaluate Target Health** (Zustand des Ziels bewerten) für einen Alias-Datensatz oder die Datensätze in einer Gruppe aus Failover-Alias-, Geolocation-Alias-, Latenz-Alias-, IP-basierten Alias- oder gewichteten Alias-Datensätzen aus. Wenn die Alias-Datensätze andere als Alias-Datensätze in derselben gehosteten Zone referenzieren, müssen Sie auch Zustandsprüfungen für die referenzierten Datensätze angeben. Wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen und **Yes** (Ja) für **Evaluate Target Health** (Zustand des Ziels bewerten) auswählen, müssen beide mit „True“ ausgewertet werden. Weitere Informationen finden Sie unter [Was geschieht, wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Wenn Ihre Zustandsprüfungen den Endpunkt nur nach Domainname angeben, sollten Sie für jeden Endpunkt eine eigene Zustandsprüfung erstellen. Sie sollten beispielsweise eine Zustandsprüfung für jeden HTTP-Server erstellen, der Inhalte für www.example.com bereitstellt. Sie müssen in **Domain Name (Domänenname)** als Wert den Domänennamen des Servers angeben (z. B. us-east-2-www.example.com), nicht den Namen der Datensätze (example.com).
**Wichtig**
Wenn Sie in dieser Konfiguration eine Zustandsprüfung erstellen, für die der Wert von **Domain name** dem Namen des Datensatzes entspricht, und anschließend die Zustandsprüfung mit diesen Datensätzen verknüpfen, sind die Ergebnisse der Zustandsprüfung unvorhersehbar.
Wenn es einen fehlerhaften Endpunkt in Geolocation-Datensätzen gibt, sucht Route 53 nach einem Datensatz für die größere verknüpfte geografische Region. Angenommen, Sie besitzen Datensätze für einen Bundesstaat der Vereinigten Staaten, für die Vereinigten Staaten, für Nordamerika und für alle Standorte (**Location (Standort)** ist **Default (Standard)**). Wenn der Endpunkt für den Bundesstaatdatensatz fehlerhaft ist, prüft Route 53 der Reihe nach die Datensätze für die Vereinigten Staaten, für Nordamerika und für alle Standorte, bis ein Datensatz mit einem fehlerfreien Endpunkt gefunden wird. Wenn alle Datensätze einschließlich des Datensatzes für alle Standorte fehlerhaft sind, antwortet Route 53 auf die DNS-Abfrage mittels des Werts für den Datensatz für die kleinste geografische Region.
## Evaluate Target Health
Wählen Sie **Ja** aus, wenn Route 53 ermitteln soll, ob auf DNS-Abfragen, die diesen Datensatz verwenden, geantwortet werden soll, indem der Zustand der in **Endpunkt** angegebenen Ressource geprüft wird.
Beachten Sie Folgendes:
**API Gateway, kundenspezifisch, regional APIs und Edge-optimiert APIs**
Es gibt keine besonderen Anforderungen für das Festlegen von **Evaluate target health (Zielzustand bewerten)** auf **Yes (Ja)**, wenn der Endpunkt eine benutzerdefinierte regionale API-Gateway-API oder eine Edge-optimierte API ist.
**CloudFront Verteilungen**
Sie können die Option **Zielintegrität bewerten** nicht auf **Ja setzen, wenn es** sich bei dem Endpunkt um eine CloudFront Verteilung handelt.
**Elastic Beanstalk-Umgebungen, die über regionale Subdomänen verfügen**
Wenn Sie in **Endpunkt** eine Elastic-Beanstalk-Umgebung angeben und diese einen ELB-Load-Balancer enthält, leitet Elastic Load Balancing Abfragen nur an die fehlerfreien Amazon-EC2-Instances weiter, die beim Load Balancer registriert sind. (Eine Umgebung enthält automatisch einen ELB-Load Balancer, wenn sie mehr als eine Amazon EC2-Instance umfasst.) Wenn Sie **Zielzustand bewerten** auf **Ja** setzen und entweder keine fehlerfreien Amazon-EC2-Instances zur Verfügung stehen oder der Load Balancer selbst fehlerhaft ist, leitet Route 53 Abfragen an andere fehlerfreie Ressourcen weiter, sofern vorhanden.
Bei einer Umgebung, die nur eine einzelne Amazon EC2-Instance enthält, gibt es keine besonderen Anforderungen.
**ELB-Load Balancer**
Das Verhalten der Zustandsprüfung ist abhängig vom Typ des Load Balancers:
+ **Classic Load Balancer** – Wenn Sie in **Endpunkt** einen ELB-Classic-Load-Balancer angeben, leitet Elastic Load Balancing Abfragen nur an die fehlerfreien Amazon-EC2-Instances weiter, die beim Load Balancer registriert sind. Wenn Sie **Zielzustand bewerten** auf **Ja** festlegen und es entweder keine fehlerfreien EC2-Instances gibt oder der Load Balancer selbst fehlerhaft ist, leitet Route 53 Abfragen an andere Ressourcen weiter.
+ **Anwendungs- und Network Load Balancer** – Wenn Sie einen ELB-Anwendungs- oder -Network Load Balancer angeben und **Zielzustand bewerten** auf **Ja** festlegen, leitet Route 53 Abfragen basierend auf dem Zustand der mit dem Load Balancer verknüpften Zielgruppen an den Load Balancer weiter:
+ Damit ein Application oder Network Load Balancer als fehlerfrei gilt, muss jede Zielgruppe mit Zielen mindestens ein fehlerfreies Ziel enthalten. Falls eine Zielgruppe nur fehlerhafte Ziele enthält, gilt der Load Balancer als fehlerhaft und Route 53 leitet Abfragen an andere Ressourcen weiter.
+ Eine Zielgruppe ohne registrierte Ziele gilt als fehlerhaft.
Beim Erstellen eines Load Balancers konfigurieren Sie Einstellungen für Elastic Load Balancing-Zustandsprüfungen. Dies sind keine Route 53-Zustandsprüfungen. Sie erfüllen aber eine ähnliche Funktion. Erstellen Sie keine Route 53-Zustandsprüfungen für die EC2-Instances, die Sie bei einem ELB-Load Balancer registrieren.
**S3-Buckets**
Es gibt keine speziellen Anforderungen, nach denen **Evaluate Target Health (Zielzustand bewerten)** auf **Yes (Ja)** festgelegt werden muss, wenn es sich beim Endpunkt um einen S3-Bucket handelt.
**Amazon-VPC-Schnittstellenendpunkte**
Es gibt keine besonderen Anforderungen für das Festlegen der **Zielzustand bewerten** auf **Ja**, wenn der Endpunkt ein Amazon-VPC-Schnittstellenendpunkt ist.
**Andere Datensätze innerhalb derselben gehosteten Zone**
Wenn es sich bei der AWS Ressource, die Sie in **Endpoint** angeben, um einen Datensatz oder eine Gruppe von Datensätzen handelt (z. B. um eine Gruppe gewichteter Datensätze), es sich jedoch nicht um einen weiteren Aliasdatensatz handelt, empfehlen wir, allen Datensätzen im Endpunkt eine Integritätsprüfung zuzuordnen. Weitere Informationen finden Sie unter [Was geschieht, wenn Sie Zustandsprüfungen überspringen?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).
## Datensatz-ID
Geben Sie einen Wert ein, der diesen Datensatz in der Gruppe von Geolocation-Datensätzen eindeutig identifiziert.
# Spezifische Werte für Geoproximitätsdatensätze
Wenn Sie Geoproximitätsdatensätze erstellen, geben Sie die folgenden Werte an.
**Topics**
+ [Routing-Richtlinie](#rrsets-values-geoprox-routing-policy)
+ [Datensatzname](#rrsets-values-geoprox-name)
+ [Datensatztyp](#rrsets-values-geoprox-type)
+ [TTL (Sekunden)](#rrsets-values-geoprox-ttl)
+ [Bewerten/Weiterleiten des Datenverkehrs an](#rrsets-values-geoprox-value)
+ [Endpunktstandort](#rrsets-values-geoprox-endpoint-location)
+ [Bias](#rrsets-values-geoprox-bias)
+ [Gesundheitscheck](#rrsets-values-geoprox-associate-with-health-check)
+ [Datensatz-ID](#rrsets-values-geoprox-set-id)
## Routing-Richtlinie
Wählen Sie **Geoproximity**.
## Datensatzname
Geben Sie den Namen der Domäne oder Subdomäne ein, für die Sie Verkehr weiterleiten wollen. Der Standardwert ist der Name der gehosteten Zone.
**Anmerkung**
Wenn Sie einen Datensatz erstellen, der denselben Namen wie die gehostete Zone hat, geben Sie im Feld **Name** keinen Wert ein (zum Beispiel ein @-Symbol).
Geben Sie denselben Namen für alle Datensätze in der Gruppe der Geoproximitätsdatensätze ein.
Weitere Informationen über Datensatznamen finden Sie unter [Datensatzname](resource-record-sets-values-shared.md#rrsets-values-common-name).
## Datensatztyp
Der DNS-Datensatztyp. Weitere Informationen finden Sie unter [Unterstützte DNS-Datensatztypen](ResourceRecordTypes.md).
Wählen Sie denselben Wert für alle Datensätze in der Gruppe der Geoproximitätsdatensätze aus.
## TTL (Sekunden)
Der Zeitraum (in Sekunden), für den Informationen über diesen Datensatz von rekursiven DNS-Resolvern zwischengespeichert werden sollen. Durch Angabe eines längeren Wertes (z. B. 172 800 Sekunden oder zwei Tage) verringern Sie die Anzahl der Aufrufe, die rekursive DNS-Resolver an Route 53 senden müssen, um die neuesten Informationen in diesem Datensatz zu erhalten. Dies führt zu einer Verringerung der Latenz und Kosten für den Route-53-Service. Weitere Informationen finden Sie unter [So leitet Amazon Route 53 Datenverkehr an Ihre Domain weiter](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Wenn Sie einen längeren Wert als TTL angeben, dauert es allerdings länger, bis Änderungen an dem Datensatz (z. B. eine neue IP-Adresse) wirksam werden. Dies liegt daran, dass die rekursiven Resolver die Werte in ihrem Zwischenspeicher für einen längeren Zeitraum verwenden, anstatt aktuelle Informationen von Route 53 anzufordern. Wenn Sie Einstellungen für eine Domäne oder Subdomäne ändern, die bereits verwendet wird, wird empfohlen, anfänglich einen kürzeren Wert, wie z. B. 300 Sekunden anzugeben und den Wert zu erhöhen, nachdem Sie bestätigt haben, dass die neuen Einstellungen korrekt sind.
Wenn Sie diesen Datensatz mit einer Zustandsprüfung verknüpfen, empfehlen wir Ihnen eine Time to Live (TTL) von 60 Sekunden oder weniger einzugeben, damit Clients schnell auf Änderungen im Zustandsstatus reagieren.
## Bewerten/Weiterleiten des Datenverkehrs an
Klicken Sie auf **IP-Adresse oder ein anderer Wert, abhängig vom Datensatztyp**. Geben Sie einen gültigen Wert für **Datensatztyp** ein. Sie können für alle Typen außer **CNAME** mehr als einen Wert eingeben. Fügen Sie jeden Wert in einer separaten Zeile hinzu.
Sie können weiterleiten oder die folgenden Werte angeben:
+ **A — Adresse IPv4 **
+ **AAAA — Adresse IPv6 **
+ **CAA – Certificate Authority Authorization** (Autorisierung der Zertifizierungsstelle)
+ **CNAME – kanonischer Name**
+ **MX – Mail-Austausch**
+ **NAPTR – Name Authority Pointer** (Namensautorisierungszeiger)
+ **PTR – Pointer** (Zeiger)
+ **SPF – Sender Policy Framework** (Richtlinien-Framework des Senders)
+ **SRV – Service-Locator**
+ **TXT – Text**
Weitere Informationen zu den oben genannten Werten finden Sie unter [Allgemeine Werte für den Value/Route Verkehr nach](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Endpunktstandort
Sie können den Standort des Ressourcenendpunkts mit einer der folgenden Methoden angeben:
**Benutzerdefinierte Koordinaten**
Geben Sie den Längen- und Breitengrad für ein geografisches Gebiet an.
**AWS-Region**
Wählen Sie eine verfügbare Region aus der **Standortliste** aus.
Weitere Informationen zu den Regionen finden Sie unter [AWS Globale Infrastruktur](https://aws.amazon.com/about-aws/global-infrastructure/).
**AWS Lokale Zonengruppe**
Wählen Sie eine verfügbare lokale Zonengruppe aus der **Standortliste** aus.
Weitere Informationen zu Local Zones finden Sie unter [Available Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/available-local-zones.html) im *AWS Local Zones User Guide*. Eine lokale Zonengruppe ist normalerweise die lokale Zone ohne das Endzeichen. Wenn die lokale Zone beispielsweise die lokale Zone ist, ist es `us-east-1-bue-1a` die lokale Zonengruppe`us-east-1-bue-1`.
Sie können die Local Zones Group für eine bestimmte Local Zone auch mit dem [describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html)CLI-Befehl identifizieren:
```
aws ec2 describe-availability-zones --region us-west-2 --all-availability-zones --query "AvailabilityZones[?ZoneName=='us-west-2-den-1a']" | grep "GroupName"
```
Dieser Befehl gibt: zurück und gibt an`"GroupName": "us-west-2-den-1"`, dass die Local Zone `us-west-2-den-1a` zur Local Zone Group gehört`us-west-2-den-1`.
Sie können keine Geoproximitätsdatensätze erstellen, die dieselben Werte für **Datensatzname und **Datensatztyp**** wie Geoproximitätsdatensätze haben.
Sie können auch nicht zwei Geoproximity-Ressourcendatensätze erstellen, die denselben Standort für denselben Datensatznamen und Datensatztyp angeben.
## Bias
Durch eine Abweichung wird ein geografisches Gebiet, von dem aus die Route 53 den Verkehr zu einer Ressource weiterleitet, entweder vergrößert oder verkleinert. Eine positive Tendenz erweitert den Bereich, und eine negative Tendenz verkleinert ihn. Weitere Informationen finden Sie unter [So verwendet Amazon Route 53 Bias-Werte](routing-policy-geoproximity.md#routing-policy-geoproximity-bias).
## Gesundheitscheck
Wählen Sie eine Zustandsprüfung aus, wenn Route 53 den Status eines angegebenen Endpunkts überprüfen und DNS-Abfragen mit diesem Eintrag nur beantworten soll, wenn der Endpunkt fehlerfrei ist.
Route 53 prüft den Zustand des im Datensatz angegebenen Endpunkts nicht, z. B. des durch die IP-Adresse im Feld **Wert** definierten Endpunkts. Wenn Sie eine Zustandsprüfung für einen Datensatz auswählen, überprüft Route 53 den Zustand des Endpunkts, den Sie in der Zustandsprüfung angegeben haben. Informationen dazu, wie Route 53 ermittelt, ob ein Endpunkt fehlerfrei ist, finden Sie unter [So ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei istSo ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei ist](dns-failover-determining-health-of-endpoints.md).
Die Verknüpfung einer Zustandsprüfung mit einem Datensatz ist nur nützlich, wenn Route 53 zwischen mindestens zwei Datensätzen auswählt, um auf eine DNS-Abfrage zu antworten, und Route 53 die Auswahl zum Teil anhand des Status einer Zustandsprüfung treffen soll. Verwenden Sie Zustandsprüfungen nur in den folgenden Konfigurationen:
+ Sie überprüfen den Zustand aller Datensätze in einer Gruppe von Datensätzen, die denselben Namen, denselben Typ und dieselbe Routing-Richtlinie haben (z. B. Failover oder gewichtete Datensätze), und Sie geben eine Integritätsprüfung IDs für alle Datensätze an. Wenn die Zustandsprüfung für einen Datensatz einen Endpunkt angibt, der nicht fehlerfrei ist, antwortet Route 53 nicht mehr auf Abfragen, die den Wert für diesen Datensatz verwenden.
+ Sie wählen **Ja** für **Evaluate Target Health** für einen Aliasdatensatz oder die Datensätze in einer Gruppe von Failover-Alias, Geolocation-Alias, Geoproximity-Alias, Latenzalias, IP-basiertem Alias oder gewichtetem Aliasdatensatz. Wenn die Alias-Datensätze andere als Alias-Datensätze in derselben gehosteten Zone referenzieren, müssen Sie auch Zustandsprüfungen für die referenzierten Datensätze angeben. Wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen und **Yes** (Ja) für **Evaluate Target Health** (Zustand des Ziels bewerten) auswählen, müssen beide mit „True“ ausgewertet werden. Weitere Informationen finden Sie unter [Was geschieht, wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Wenn Ihre Zustandsprüfungen den Endpunkt nur nach Domainname angeben, sollten Sie für jeden Endpunkt eine eigene Zustandsprüfung erstellen. Sie sollten beispielsweise eine Zustandsprüfung für jeden HTTP-Server erstellen, der Inhalte für www.example.com bereitstellt. Sie müssen in **Domain Name (Domänenname)** als Wert den Domänennamen des Servers angeben (z. B. us-east-2-www.example.com), nicht den Namen der Datensätze (example.com).
**Wichtig**
Wenn Sie in dieser Konfiguration eine Zustandsprüfung erstellen, für die der Wert von **Domain Name (Domänenname)** mit dem Namen der Datensätze übereinstimmt, und anschließend die Zustandsprüfung mit diesen Datensätzen verknüpfen, sind die Ergebnisse der Zustandsprüfung nicht planbar.
Wenn ein Endpunkt fehlerhaft ist, sucht Route 53 bei Geoproximitätsdatensätzen nach einem Endpunkt, der sich am nächsten befindet und noch fehlerfrei ist.
## Datensatz-ID
Geben Sie einen Wert ein, der diesen Datensatz in der Gruppe der Geoproximitätsdatensätze eindeutig identifiziert.
# Spezifische Werte für Geoproximitäts-Aliasdatensätze
Wenn Sie Geoproximity-Aliasdatensätze erstellen, geben Sie die folgenden Werte an.
Weitere Informationen finden Sie unter [Wählen zwischen Alias- und Nicht-Alias-Datensätzen](resource-record-sets-choosing-alias-non-alias.md).
**Topics**
+ [Routing-Richtlinie](#rrsets-values-geoprox-alias-routing-policy)
+ [Datensatzname](#rrsets-values-geoprox-alias-name)
+ [Datensatztyp](#rrsets-values-geoprox-alias-type)
+ [Bewerten/Weiterleiten des Datenverkehrs an](#rrsets-values-geoprox-alias-alias-target)
+ [Endpunktstandort](#rrsets-values-geoprox-alias-endpoint-location)
+ [Bias](#rrsets-values-geoprox-alias-bias)
+ [Gesundheitscheck](#rrsets-values-geoprox-alias-associate-with-health-check)
+ [Evaluate Target Health](#rrsets-values-geoprox-alias-evaluate-target-health)
+ [Datensatz-ID](#rrsets-values-geoprox-alias-set-id)
## Routing-Richtlinie
Wählen Sie **Geoproximity**.
## Datensatzname
Geben Sie den Namen der Domäne oder Subdomäne ein, für die Sie Verkehr weiterleiten wollen. Der Standardwert ist der Name der gehosteten Zone.
**Anmerkung**
Wenn Sie einen Datensatz erstellen, der denselben Namen wie die gehostete Zone hat, geben Sie im Feld **Datensatzname** keinen Wert ein (zum Beispiel ein @-Symbol).
Geben Sie denselben Namen für alle Datensätze in der Gruppe der Geoproximitätsdatensätze ein.
Weitere Informationen über Datensatznamen finden Sie unter [Datensatzname](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).
## Datensatztyp
Der DNS-Datensatztyp. Weitere Informationen finden Sie unter [Unterstützte DNS-Datensatztypen](ResourceRecordTypes.md).
Wählen Sie den entsprechenden Wert basierend auf der AWS Ressource aus, zu der Sie den Verkehr weiterleiten. Wählen Sie denselben Wert für alle Datensätze in der Gruppe der Geoproximitätsdatensätze aus:
**Benutzerdefinierte regionale API-Gateway-API oder Edge-optimierte API**
Wählen Sie **A — IPv4 Adresse** aus.
**Amazon-VPC-Schnittstellenendpunkte**
Wählen Sie **A — IPv4 Adresse**.
**CloudFront Vertrieb**
Wählen Sie **A — IPv4 Adresse** aus.
Wenn für die Verteilung aktiviert IPv6 ist, erstellen Sie zwei Datensätze, einen mit dem Wert **A — IPv4 Adresse** für **Typ** und einen mit dem Wert **AAAA — IPv6 Adresse**.
**App-Runner-Dienst**
Wählen Sie **A — Adresse IPv4 **
**Elastic-Beanstalk-Umgebung, die über regionale Subdomänen verfügt**
Wählen Sie **A — IPv4 Adresse**
**ELB-Load Balancer**
Wählen **Sie IPv4 A-Adresse** oder **AAAA-Adresse IPv6 **
**Amazon-S3-Bucket**
Wählen Sie **A — Adresse IPv4 **
**OpenSearch Dienst**
Wählen **Sie IPv4 A-Adresse** oder **AAAA-Adresse IPv6 **
**Weiterer Datensatz in dieser gehosteten Zone**
Wählen Sie den Typ des Datensatzes aus, für den Sie den Alias erstellen. Es werden alle Typen außer **NS** und **SOA** unterstützt.
Wenn Sie einen Aliasdatensatz mit demselben Namen wie die gehostete Zone (*Zonen-Apex*) erstellen, können Sie den Datenverkehr nicht zu einem Datensatz weiterleiten, dessen Wert in **Type (Typ)** **CNAME** ist. Der Grund hierfür ist, dass der Aliasdatensatz denselben Typ wie der Datensatz haben muss, zu dem Sie den Datenverkehr weiterleiten, und die Erstellung eines CNAME-Datensatzes für den Zonen-Apex wird für einen Aliasdatensatz nicht unterstützt.
## Bewerten/Weiterleiten des Datenverkehrs an
Der Wert, den Sie aus der Liste auswählen oder den Sie in das Feld eingeben, hängt von der AWS Ressource ab, an die Sie den Verkehr weiterleiten.
Informationen darüber, auf welche AWS Ressourcen Sie abzielen können, finden Sie unter[Wert/Weiterleiten von Datenverkehr an](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
Weitere Informationen zur Konfiguration von Route 53 zur Weiterleitung von Datenverkehr zu bestimmten AWS Ressourcen finden Sie unter[Weiterleitung des Internetverkehrs zu Ihren AWS Ressourcen](routing-to-aws-resources.md).
## Endpunktstandort
Sie können den Standort des Ressourcenendpunkts mit einer der folgenden Methoden angeben:
**Benutzerdefinierte Koordinaten**
Geben Sie den Längen- und Breitengrad für ein geografisches Gebiet an.
**AWS-Region**
Wählen Sie eine verfügbare Region aus der **Standortliste** aus.
Weitere Informationen zu den Regionen finden Sie unter [AWS Globale Infrastruktur](https://aws.amazon.com/about-aws/global-infrastructure/).
**AWS Lokale Zonengruppe**
Wählen Sie eine verfügbare lokale Zonenregion aus der **Standortliste** aus.
Weitere Informationen zu Local Zones finden Sie unter [Available Local Zones](https://docs.aws.amazon.com/local-zones/latest/ug/available-local-zones.html) im *AWS Local Zones User Guide*. Eine lokale Zonengruppe ist normalerweise die lokale Zone ohne das Endzeichen. Wenn die lokale Zone beispielsweise die lokale Zone ist, ist es `us-east-1-bue-1a` die lokale Zonengruppe`us-east-1-bue-1`.
Sie können die Local Zones Group auch für eine bestimmte Local Zone identifizieren, indem Sie den [describe-availability-zones](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-availability-zones.html)CLI-Befehl verwenden:
```
aws ec2 describe-availability-zones --region us-west-2 --all-availability-zones --query "AvailabilityZones[?ZoneName=='us-west-2-den-1a']" | grep "GroupName"
```
Dieser Befehl gibt: zurück und gibt an`"GroupName": "us-west-2-den-1"`, dass die Local Zone `us-west-2-den-1a` zur Local Zone Group gehört`us-west-2-den-1`.
Sie können keine Geoproximitätsdatensätze erstellen, die dieselben Werte für **Datensatzname und **Datensatztyp**** wie Geoproximitätsdatensätze haben.
Sie können auch nicht zwei Geoproximity-Ressourcendatensätze erstellen, die denselben Standort für denselben Datensatznamen und Datensatztyp angeben.
Weitere Informationen finden Sie unter .html available-local-zones
## Bias
Durch eine Verzerrung wird ein geografisches Gebiet, von dem aus die Route 53 den Verkehr zu einer Ressource weiterleitet, entweder vergrößert oder verkleinert. Eine positive Tendenz erweitert den Bereich, und eine negative Tendenz verkleinert ihn. Weitere Informationen finden Sie unter [So verwendet Amazon Route 53 Bias-Werte](routing-policy-geoproximity.md#routing-policy-geoproximity-bias).
## Gesundheitscheck
Wählen Sie eine Zustandsprüfung aus, wenn Route 53 den Status eines angegebenen Endpunkts überprüfen und DNS-Abfragen mit diesem Eintrag nur beantworten soll, wenn der Endpunkt fehlerfrei ist.
Route 53 prüft den Zustand des im Datensatz angegebenen Endpunkts nicht, z. B. des durch die IP-Adresse im Feld **Wert** definierten Endpunkts. Wenn Sie eine Zustandsprüfung für einen Datensatz auswählen, überprüft Route 53 den Zustand des Endpunkts, den Sie in der Zustandsprüfung angegeben haben. Informationen dazu, wie Route 53 ermittelt, ob ein Endpunkt fehlerfrei ist, finden Sie unter [So ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei istSo ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei ist](dns-failover-determining-health-of-endpoints.md).
Die Verknüpfung einer Zustandsprüfung mit einem Datensatz ist nur nützlich, wenn Route 53 zwischen mindestens zwei Datensätzen auswählt, um auf eine DNS-Abfrage zu antworten, und Route 53 die Auswahl zum Teil anhand des Status einer Zustandsprüfung treffen soll. Verwenden Sie Zustandsprüfungen nur in den folgenden Konfigurationen:
+ Sie überprüfen den Zustand aller Datensätze in einer Gruppe von Datensätzen, die denselben Namen, denselben Typ und dieselbe Routing-Richtlinie haben (z. B. Failover oder gewichtete Datensätze), und Sie geben eine Integritätsprüfung IDs für alle Datensätze an. Wenn die Zustandsprüfung für einen Datensatz einen Endpunkt angibt, der nicht fehlerfrei ist, antwortet Route 53 nicht mehr auf Abfragen, die den Wert für diesen Datensatz verwenden.
+ Sie wählen **Ja** für **Zielintegrität für einen Aliasdatensatz oder die Datensätze in einer Gruppe von Failover-Alias, Geolocation-Alias, Geoproximity-Alias, Latenz-Alias, IP-basiertem Alias oder gewichtetem Aliasdatensatz auswerten**. Wenn die Alias-Datensätze andere als Alias-Datensätze in derselben gehosteten Zone referenzieren, müssen Sie auch Zustandsprüfungen für die referenzierten Datensätze angeben. Wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen und **Yes** (Ja) für **Evaluate Target Health** (Zustand des Ziels bewerten) auswählen, müssen beide mit „True“ ausgewertet werden. Weitere Informationen finden Sie unter [Was geschieht, wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Wenn Ihre Zustandsprüfungen den Endpunkt nur nach Domainname angeben, sollten Sie für jeden Endpunkt eine eigene Zustandsprüfung erstellen. Sie sollten beispielsweise eine Zustandsprüfung für jeden HTTP-Server erstellen, der Inhalte für www.example.com bereitstellt. Sie müssen in **Domain Name (Domänenname)** als Wert den Domänennamen des Servers angeben (z. B. us-east-2-www.example.com), nicht den Namen der Datensätze (example.com).
**Wichtig**
Wenn Sie in dieser Konfiguration eine Zustandsprüfung erstellen, für die der Wert von **Domain name** dem Namen des Datensatzes entspricht, und anschließend die Zustandsprüfung mit diesen Datensätzen verknüpfen, sind die Ergebnisse der Zustandsprüfung unvorhersehbar.
Wenn ein Endpunkt fehlerhaft ist, sucht Route 53 bei Geoproximitätsdatensätzen nach einem Endpunkt, der sich am nächsten befindet und noch fehlerfrei ist.
## Evaluate Target Health
Wählen Sie **Ja** aus, wenn Route 53 ermitteln soll, ob auf DNS-Abfragen, die diesen Datensatz verwenden, geantwortet werden soll, indem der Zustand der in **Endpunkt** angegebenen Ressource geprüft wird.
Beachten Sie Folgendes:
**API Gateway, kundenspezifisch, regional APIs und Edge-optimiert APIs**
Es gibt keine besonderen Anforderungen für das Festlegen von **Evaluate target health (Zielzustand bewerten)** auf **Yes (Ja)**, wenn der Endpunkt eine benutzerdefinierte regionale API-Gateway-API oder eine Edge-optimierte API ist.
**CloudFront Verteilungen**
Sie können die Option **Zielintegrität bewerten** nicht auf **Ja setzen, wenn es** sich bei dem Endpunkt um eine CloudFront Verteilung handelt.
**Elastic Beanstalk-Umgebungen, die über regionale Subdomänen verfügen**
Wenn Sie in **Endpunkt** eine Elastic-Beanstalk-Umgebung angeben und diese einen ELB-Load-Balancer enthält, leitet Elastic Load Balancing Abfragen nur an die fehlerfreien Amazon-EC2-Instances weiter, die beim Load Balancer registriert sind. (Eine Umgebung enthält automatisch einen ELB-Load Balancer, wenn sie mehr als eine Amazon EC2-Instance umfasst.) Wenn Sie **Zielzustand bewerten** auf **Ja** setzen und entweder keine fehlerfreien Amazon-EC2-Instances zur Verfügung stehen oder der Load Balancer selbst fehlerhaft ist, leitet Route 53 Abfragen an andere fehlerfreie Ressourcen weiter, sofern vorhanden.
Bei einer Umgebung, die nur eine einzelne Amazon EC2-Instance enthält, gibt es keine besonderen Anforderungen.
**ELB-Load Balancer**
Das Verhalten der Zustandsprüfung ist abhängig vom Typ des Load Balancers:
+ **Classic Load Balancer** – Wenn Sie in **Endpunkt** einen ELB-Classic-Load-Balancer angeben, leitet Elastic Load Balancing Abfragen nur an die fehlerfreien Amazon-EC2-Instances weiter, die beim Load Balancer registriert sind. Wenn Sie **Zielzustand bewerten** auf **Ja** festlegen und es entweder keine fehlerfreien EC2-Instances gibt oder der Load Balancer selbst fehlerhaft ist, leitet Route 53 Abfragen an andere Ressourcen weiter.
+ **Anwendungs- und Network Load Balancer** – Wenn Sie einen ELB-Anwendungs- oder -Network Load Balancer angeben und **Zielzustand bewerten** auf **Ja** festlegen, leitet Route 53 Abfragen basierend auf dem Zustand der mit dem Load Balancer verknüpften Zielgruppen an den Load Balancer weiter:
+ Damit ein Application oder Network Load Balancer als fehlerfrei gilt, muss jede Zielgruppe mit Zielen mindestens ein fehlerfreies Ziel enthalten. Falls eine Zielgruppe nur fehlerhafte Ziele enthält, gilt der Load Balancer als fehlerhaft und Route 53 leitet Abfragen an andere Ressourcen weiter.
+ Eine Zielgruppe ohne registrierte Ziele gilt als fehlerhaft.
Beim Erstellen eines Load Balancers konfigurieren Sie Einstellungen für Elastic Load Balancing-Zustandsprüfungen. Dies sind keine Route 53-Zustandsprüfungen. Sie erfüllen aber eine ähnliche Funktion. Erstellen Sie keine Route 53-Zustandsprüfungen für die EC2-Instances, die Sie bei einem ELB-Load Balancer registrieren.
**S3-Buckets**
Es gibt keine speziellen Anforderungen, nach denen **Evaluate Target Health (Zielzustand bewerten)** auf **Yes (Ja)** festgelegt werden muss, wenn es sich beim Endpunkt um einen S3-Bucket handelt.
**Amazon-VPC-Schnittstellenendpunkte**
Es gibt keine besonderen Anforderungen für das Festlegen der **Zielzustand bewerten** auf **Ja**, wenn der Endpunkt ein Amazon-VPC-Schnittstellenendpunkt ist.
**Andere Datensätze innerhalb derselben gehosteten Zone**
Wenn es sich bei der AWS Ressource, die Sie in **Endpoint** angeben, um einen Datensatz oder eine Gruppe von Datensätzen handelt (z. B. um eine Gruppe gewichteter Datensätze), es sich jedoch nicht um einen weiteren Aliasdatensatz handelt, empfehlen wir, allen Datensätzen im Endpunkt eine Integritätsprüfung zuzuordnen. Weitere Informationen finden Sie unter [Was geschieht, wenn Sie Zustandsprüfungen überspringen?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).
## Datensatz-ID
Geben Sie einen Wert ein, der diesen Datensatz in der Gruppe der Geoproximitätsdatensätze eindeutig identifiziert.
# Spezifische Werte für Latenz-Datensätze
Beim Erstellen von Latenz-Datensätzen geben Sie die folgenden Werte an.
**Topics**
+ [Routing-Richtlinie](#rrsets-values-latency-routing-policy)
+ [Datensatzname](#rrsets-values-latency-name)
+ [Datensatztyp](#rrsets-values-latency-type)
+ [TTL (Sekunden)](#rrsets-values-latency-ttl)
+ [Bewerten/Weiterleiten des Datenverkehrs an](#rrsets-values-latency-value)
+ [Region](#rrsets-values-latency-region)
+ [Gesundheitscheck](#rrsets-values-latency-associate-with-health-check)
+ [Datensatz-ID](#rrsets-values-latency-set-id)
## Routing-Richtlinie
Klicken Sie auf **Latenz**.
## Datensatzname
Geben Sie den Namen der Domäne oder Subdomäne ein, für die Sie Verkehr weiterleiten wollen. Der Standardwert ist der Name der gehosteten Zone.
**Anmerkung**
Wenn Sie einen Datensatz erstellen, der denselben Namen wie die gehostete Zone hat, geben Sie im Feld **Datensatzname** keinen Wert ein (zum Beispiel ein @-Symbol).
Geben Sie für alle Datensätze in der Gruppe von Latenz-Datensätzen denselben Namen ein.
Weitere Informationen über Datensatznamen finden Sie unter [Datensatzname](resource-record-sets-values-shared.md#rrsets-values-common-name).
## Datensatztyp
Der DNS-Datensatztyp. Weitere Informationen finden Sie unter [Unterstützte DNS-Datensatztypen](ResourceRecordTypes.md).
Wählen Sie den Wert für **Typ** danach aus, wie Route 53 auf DNS-Abfragen antworten soll.
Wählen Sie für alle Datensätze in der Gruppe von Latenz-Datensätzen denselben Namen aus.
## TTL (Sekunden)
Der Zeitraum (in Sekunden), für den Informationen über diesen Datensatz von rekursiven DNS-Resolvern zwischengespeichert werden sollen. Durch Angabe eines längeren Wertes (z. B. 172 800 Sekunden oder zwei Tage) verringern Sie die Anzahl der Aufrufe, die rekursive DNS-Resolver an Route 53 senden müssen, um die neuesten Informationen in diesem Datensatz zu erhalten. Dies führt zu einer Verringerung der Latenz und Kosten für den Route-53-Service. Weitere Informationen finden Sie unter [So leitet Amazon Route 53 Datenverkehr an Ihre Domain weiter](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Wenn Sie einen längeren Wert als TTL angeben, dauert es allerdings länger, bis Änderungen an dem Datensatz (z. B. eine neue IP-Adresse) wirksam werden. Dies liegt daran, dass die rekursiven Resolver die Werte in ihrem Zwischenspeicher für einen längeren Zeitraum verwenden, anstatt aktuelle Informationen von Route 53 anzufordern. Wenn Sie Einstellungen für eine Domäne oder Subdomäne ändern, die bereits verwendet wird, wird empfohlen, anfänglich einen kürzeren Wert, wie z. B. 300 Sekunden anzugeben und den Wert zu erhöhen, nachdem Sie bestätigt haben, dass die neuen Einstellungen korrekt sind.
Wenn Sie diesen Datensatz mit einer Zustandsprüfung verknüpfen, empfehlen wir Ihnen eine Time to Live (TTL) von 60 Sekunden oder weniger einzugeben, damit Clients schnell auf Änderungen im Zustandsstatus reagieren.
## Bewerten/Weiterleiten des Datenverkehrs an
Klicken Sie auf **IP-Adresse oder ein anderer Wert, abhängig vom Datensatztyp**. Geben Sie einen gültigen Wert für **Datensatztyp** ein. Sie können für alle Typen außer **CNAME** mehr als einen Wert eingeben. Fügen Sie jeden Wert in einer separaten Zeile hinzu.
Sie können weiterleiten oder die folgenden Werte angeben:
+ **A — IPv4 Adresse**
+ **AAAA — Adresse IPv6 **
+ **CAA – Certificate Authority Authorization** (Autorisierung der Zertifizierungsstelle)
+ **CNAME – kanonischer Name**
+ **MX – Mail-Austausch**
+ **NAPTR – Name Authority Pointer** (Namensautorisierungszeiger)
+ **PTR – Pointer** (Zeiger)
+ **SPF – Sender Policy Framework** (Richtlinien-Framework des Senders)
+ **SRV – Service-Locator**
+ **TXT – Text**
Weitere Informationen zu den oben genannten Werten finden Sie unter [Allgemeine Werte für den Value/Route Verkehr nach](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Region
Die Amazon-EC2-Region, in der sich die Ressource befindet, die Sie in diesem Datensatz angegeben haben. Route 53 empfiehlt basierend auf anderen von Ihnen angegebenen Werten eine Amazon-EC2-Region. Dies gilt auch für privat gehostete Zonen. Wir empfehlen, diesen Wert nicht zu ändern.
Beachten Sie Folgendes:
+ Sie können für jede Amazon-EC2-Region nur einen Latenzdatensatz erstellen.
+ Es ist nicht notwendig, für alle Amazon-EC2-Regionen Latenzdatensätze zu erstellen. Route 53 wählt aus den Regionen, für die Sie Latenzdatensätze erstellen, die Region mit der besten Latenz aus.
+ Sie können keine Datensätze ohne Latenz erstellen, die über dieselben Werte wie Latenzdatensätze für **Datensatzname** und **Datensatztyp** verfügen.
+ Wenn Sie einen Datensatz erstellen, der mit der Region **cn-north-1** markiert ist, antwortet Route 53 unabhängig von der Latenz immer auf Abfragen aus China mit diesem Datensatz.
Weitere Informationen zum Verwenden von Latenz-Datensätzen finden Sie unter [Latenzbasiertes Routing](routing-policy-latency.md).
## Gesundheitscheck
Wählen Sie eine Zustandsprüfung aus, wenn Route 53 den Status eines angegebenen Endpunkts überprüfen und DNS-Abfragen mit diesem Eintrag nur beantworten soll, wenn der Endpunkt fehlerfrei ist.
Route 53 prüft den Zustand des im Datensatz angegebenen Endpunkts nicht, z. B. des durch die IP-Adresse im Feld **Wert** definierten Endpunkts. Wenn Sie eine Zustandsprüfung für einen Datensatz auswählen, überprüft Route 53 den Zustand des Endpunkts, den Sie in der Zustandsprüfung angegeben haben. Informationen dazu, wie Route 53 ermittelt, ob ein Endpunkt fehlerfrei ist, finden Sie unter [So ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei istSo ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei ist](dns-failover-determining-health-of-endpoints.md).
Die Verknüpfung einer Zustandsprüfung mit einem Datensatz ist nur nützlich, wenn Route 53 zwischen mindestens zwei Datensätzen auswählt, um auf eine DNS-Abfrage zu antworten, und Route 53 die Auswahl zum Teil anhand des Status einer Zustandsprüfung treffen soll. Verwenden Sie Zustandsprüfungen nur in den folgenden Konfigurationen:
+ Sie überprüfen den Zustand aller Datensätze in einer Gruppe von Datensätzen, die denselben Namen, denselben Typ und dieselbe Routing-Richtlinie haben (z. B. Failover oder gewichtete Datensätze), und Sie geben eine Integritätsprüfung IDs für alle Datensätze an. Wenn die Zustandsprüfung für einen Datensatz einen Endpunkt angibt, der nicht fehlerfrei ist, antwortet Route 53 nicht mehr auf Abfragen, die den Wert für diesen Datensatz verwenden.
+ Sie wählen **Yes** (Ja) für **Evaluate Target Health** (Zustand des Ziels bewerten) für einen Alias-Datensatz oder die Datensätze in einer Gruppe aus Failover-Alias-, Geolocation-Alias-, Latenz-Alias-, IP-basierten Alias- oder gewichteten Alias-Datensätzen aus. Wenn die Alias-Datensätze andere als Alias-Datensätze in derselben gehosteten Zone referenzieren, müssen Sie auch Zustandsprüfungen für die referenzierten Datensätze angeben. Wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen und **Yes** (Ja) für **Evaluate Target Health** (Zustand des Ziels bewerten) auswählen, müssen beide mit „True“ ausgewertet werden. Weitere Informationen finden Sie unter [Was geschieht, wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Wenn Ihre Zustandsprüfungen den Endpunkt nur nach Domainname angeben, sollten Sie für jeden Endpunkt eine eigene Zustandsprüfung erstellen. Sie sollten beispielsweise eine Zustandsprüfung für jeden HTTP-Server erstellen, der Inhalte für www.example.com bereitstellt. Sie müssen in **Domain Name (Domänenname)** als Wert den Domänennamen des Servers angeben (z. B. us-east-2-www.example.com), nicht den Namen der Datensätze (example.com).
**Wichtig**
Wenn Sie in dieser Konfiguration eine Zustandsprüfung erstellen, für die der Wert von **Domain name** dem Namen des Datensatzes entspricht, und anschließend die Zustandsprüfung mit diesen Datensätzen verknüpfen, sind die Ergebnisse der Zustandsprüfung unvorhersehbar.
## Datensatz-ID
Geben Sie einen Wert ein, der diesen Datensatz in der Gruppe von Latenz-Datensätzen eindeutig identifiziert.
# Spezifische Werte für Latenz-Aliasdatensätze
Beim Erstellen von Latenz-Aliasdatensätzen geben Sie die folgenden Werte an.
Weitere Informationen finden Sie unter [Wählen zwischen Alias- und Nicht-Alias-Datensätzen](resource-record-sets-choosing-alias-non-alias.md).
**Topics**
+ [Routing-Richtlinie](#rrsets-values-latency-alias-routing-policy)
+ [Datensatzname](#rrsets-values-latency-alias-name)
+ [Datensatztyp](#rrsets-values-latency-alias-type)
+ [Bewerten/Weiterleiten des Datenverkehrs an](#rrsets-values-latency-alias-alias-target)
+ [Region](#rrsets-values-latency-alias-region)
+ [Gesundheitscheck](#rrsets-values-latency-alias-associate-with-health-check)
+ [Evaluate Target Health](#rrsets-values-latency-alias-evaluate-target-health)
+ [Datensatz-ID](#rrsets-values-latency-alias-set-id)
## Routing-Richtlinie
Klicken Sie auf **Latenz**.
## Datensatzname
Geben Sie den Namen der Domäne oder Subdomäne ein, für die Sie Verkehr weiterleiten wollen. Der Standardwert ist der Name der gehosteten Zone.
**Anmerkung**
Wenn Sie einen Datensatz erstellen, der denselben Namen wie die gehostete Zone hat, geben Sie im Feld **Datensatzname** keinen Wert ein (zum Beispiel ein @-Symbol).
Geben Sie für alle Datensätze in der Gruppe von Latenz-Datensätzen denselben Namen ein.
Weitere Informationen über Datensatznamen finden Sie unter [Datensatzname](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).
## Datensatztyp
Der DNS-Datensatztyp. Weitere Informationen finden Sie unter [Unterstützte DNS-Datensatztypen](ResourceRecordTypes.md).
Wählen Sie den entsprechenden Wert basierend auf der AWS Ressource aus, an die Sie den Verkehr weiterleiten:
**Benutzerdefinierte regionale API-Gateway-API oder Edge-optimierte API**
Wählen Sie **A — IPv4 Adresse** aus.
**Amazon-VPC-Schnittstellenendpunkte**
Wählen Sie **A — IPv4 Adresse** aus.
**CloudFront Vertrieb**
Wählen Sie **A — IPv4 Adresse** aus.
Wenn für die Verteilung aktiviert IPv6 ist, erstellen Sie zwei Datensätze, einen mit dem Wert **A — IPv4 Adresse** für **Typ** und einen mit dem Wert **AAAA — IPv6 Adresse**.
**App-Runner-Dienst**
Wählen Sie **A — Adresse IPv4 **
**Elastic-Beanstalk-Umgebung, die über regionale Subdomänen verfügt**
Wählen Sie **A — IPv4 Adresse**
**ELB-Load Balancer**
Wählen **Sie IPv4 A-Adresse** oder **AAAA-Adresse IPv6 **
**Amazon-S3-Bucket**
Wählen Sie **A — Adresse IPv4 **
**OpenSearch Dienst**
Wählen Sie **A — IPv4 Adresse** oder **AAAA — IPv6 ** Adresse
**Weiterer Datensatz in dieser gehosteten Zone**
Wählen Sie den Typ des Datensatzes aus, für den Sie den Alias erstellen. Es werden alle Typen außer **NS** und **SOA** unterstützt.
Wenn Sie einen Aliasdatensatz mit demselben Namen wie die gehostete Zone (*Zonen-Apex*) erstellen, können Sie den Datenverkehr nicht zu einem Datensatz weiterleiten, dessen Wert in **Type (Typ)** **CNAME** ist. Der Grund hierfür ist, dass der Aliasdatensatz denselben Typ wie der Datensatz haben muss, zu dem Sie den Datenverkehr weiterleiten, und die Erstellung eines CNAME-Datensatzes für den Zonen-Apex wird für einen Aliasdatensatz nicht unterstützt.
Wählen Sie für alle Datensätze in der Gruppe von Latenz-Datensätzen denselben Namen aus.
## Bewerten/Weiterleiten des Datenverkehrs an
Der Wert, den Sie aus der Liste auswählen oder den Sie in das Feld eingeben, hängt von der AWS Ressource ab, an die Sie den Verkehr weiterleiten.
Informationen darüber, auf welche AWS Ressourcen Sie abzielen können, finden Sie unter [Allgemeine Werte für Aliasdatensätze für den value/route Datenverkehr](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
Weitere Informationen zur Konfiguration von Route 53 zur Weiterleitung von Datenverkehr an bestimmte AWS Ressourcen finden Sie unter[Weiterleitung des Internetverkehrs zu Ihren AWS Ressourcen](routing-to-aws-resources.md).
## Region
Die Amazon-EC2-Region, in der sich die von Ihnen in diesem Datensatz angegebene Ressource befindet. Route 53 empfiehlt basierend auf anderen von Ihnen angegebenen Werten eine Amazon-EC2-Region. Dies gilt auch für privat gehostete Zonen. Wir empfehlen, diesen Wert nicht zu ändern.
Beachten Sie Folgendes:
+ Sie können für jede Amazon-EC2-Region nur einen Latenzdatensatz erstellen.
+ Es ist nicht notwendig, für alle Amazon-EC2-Regionen Latenzdatensätze zu erstellen. Route 53 wählt aus den Regionen, für die Sie Latenzdatensätze erstellen, die Region mit der besten Latenz aus.
+ Sie können keine Datensätze ohne Latenz erstellen, die über dieselben Werte wie Latenzdatensätze für **Datensatzname** und **Datensatztyp** verfügen.
+ Wenn Sie einen Datensatz erstellen, der mit der Region **cn-north-1** markiert ist, antwortet Route 53 unabhängig von der Latenz immer auf Abfragen aus China mit diesem Datensatz.
Weitere Informationen zum Verwenden von Latenz-Datensätzen finden Sie unter [Latenzbasiertes Routing](routing-policy-latency.md).
## Gesundheitscheck
Wählen Sie eine Zustandsprüfung aus, wenn Route 53 den Status eines angegebenen Endpunkts überprüfen und DNS-Abfragen mit diesem Eintrag nur beantworten soll, wenn der Endpunkt fehlerfrei ist.
Route 53 prüft den Zustand des im Datensatz angegebenen Endpunkts nicht, z. B. des durch die IP-Adresse im Feld **Wert** definierten Endpunkts. Wenn Sie eine Zustandsprüfung für einen Datensatz auswählen, überprüft Route 53 den Zustand des Endpunkts, den Sie in der Zustandsprüfung angegeben haben. Informationen dazu, wie Route 53 ermittelt, ob ein Endpunkt fehlerfrei ist, finden Sie unter [So ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei istSo ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei ist](dns-failover-determining-health-of-endpoints.md).
Die Verknüpfung einer Zustandsprüfung mit einem Datensatz ist nur nützlich, wenn Route 53 zwischen mindestens zwei Datensätzen auswählt, um auf eine DNS-Abfrage zu antworten, und Route 53 die Auswahl zum Teil anhand des Status einer Zustandsprüfung treffen soll. Verwenden Sie Zustandsprüfungen nur in den folgenden Konfigurationen:
+ Sie überprüfen den Zustand aller Datensätze in einer Gruppe von Datensätzen, die denselben Namen, denselben Typ und dieselbe Routing-Richtlinie haben (z. B. Failover oder gewichtete Datensätze), und Sie geben eine Integritätsprüfung IDs für alle Datensätze an. Wenn die Zustandsprüfung für einen Datensatz einen Endpunkt angibt, der nicht fehlerfrei ist, antwortet Route 53 nicht mehr auf Abfragen, die den Wert für diesen Datensatz verwenden.
+ Sie wählen **Yes** (Ja) für **Evaluate Target Health** (Zustand des Ziels bewerten) für einen Alias-Datensatz oder die Datensätze in einer Gruppe aus Failover-Alias-, Geolocation-Alias-, Latenz-Alias-, IP-basierten Alias- oder gewichteten Alias-Datensätzen aus. Wenn die Alias-Datensätze andere als Alias-Datensätze in derselben gehosteten Zone referenzieren, müssen Sie auch Zustandsprüfungen für die referenzierten Datensätze angeben. Wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen und **Yes** (Ja) für **Evaluate Target Health** (Zustand des Ziels bewerten) auswählen, müssen beide mit „True“ ausgewertet werden. Weitere Informationen finden Sie unter [Was geschieht, wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Wenn Ihre Zustandsprüfungen den Endpunkt nur nach Domainname angeben, sollten Sie für jeden Endpunkt eine eigene Zustandsprüfung erstellen. Sie sollten beispielsweise eine Zustandsprüfung für jeden HTTP-Server erstellen, der Inhalte für www.example.com bereitstellt. Sie müssen in **Domain Name (Domänenname)** als Wert den Domänennamen des Servers angeben (z. B. us-east-2-www.example.com), nicht den Namen der Datensätze (example.com).
**Wichtig**
Wenn Sie in dieser Konfiguration eine Zustandsprüfung erstellen, für die der Wert von **Domain Name (Domänenname)** mit dem Namen der Datensätze übereinstimmt, und anschließend die Zustandsprüfung mit diesen Datensätzen verknüpfen, sind die Ergebnisse der Zustandsprüfung nicht planbar.
## Evaluate Target Health
Wählen Sie **Ja** aus, wenn Route 53 ermitteln soll, ob auf DNS-Abfragen, die diesen Datensatz verwenden, geantwortet werden soll, indem der Zustand der in **Endpunkt** angegebenen Ressource geprüft wird.
Beachten Sie Folgendes:
**API Gateway, kundenspezifisch, regional APIs und Edge-optimiert APIs**
Es gibt keine besonderen Anforderungen für das Festlegen von **Zielzustand bewerten** auf **Ja**, wenn der Endpunkt eine benutzerdefinierte regionale API-Gateway-API oder eine Edge-optimierte API ist.
**CloudFront Verteilungen**
Sie können **Evaluate Target Health** nicht auf **Ja setzen, wenn es** sich bei dem Endpunkt um eine CloudFront Verteilung handelt.
**Elastic Beanstalk-Umgebungen, die über regionale Subdomänen verfügen**
Wenn Sie in **Endpunkt** eine Elastic-Beanstalk-Umgebung angeben und diese einen ELB-Load-Balancer enthält, leitet Elastic Load Balancing Abfragen nur an die fehlerfreien Amazon-EC2-Instances weiter, die beim Load Balancer registriert sind. (Eine Umgebung enthält automatisch einen ELB-Load Balancer, wenn sie mehr als eine Amazon EC2-Instance umfasst.) Wenn Sie **Zielzustand bewerten** auf **Ja** setzen und entweder keine fehlerfreien Amazon-EC2-Instances zur Verfügung stehen oder der Load Balancer selbst fehlerhaft ist, leitet Route 53 Abfragen an andere fehlerfreie Ressourcen weiter, sofern vorhanden.
Bei einer Umgebung, die nur eine einzelne Amazon EC2-Instance enthält, gibt es keine besonderen Anforderungen.
**ELB-Load Balancer**
Das Verhalten der Zustandsprüfung ist abhängig vom Typ des Load Balancers:
+ **Classic Load Balancer** – Wenn Sie in **Endpunkt** einen ELB-Classic-Load-Balancer angeben, leitet Elastic Load Balancing Abfragen nur an die fehlerfreien Amazon-EC2-Instances weiter, die beim Load Balancer registriert sind. Wenn Sie **Zielzustand bewerten** auf **Ja** festlegen und es entweder keine fehlerfreien EC2-Instances gibt oder der Load Balancer selbst fehlerhaft ist, leitet Route 53 Abfragen an andere Ressourcen weiter.
+ **Anwendungs- und Network Load Balancer** – Wenn Sie einen ELB-Anwendungs- oder -Network Load Balancer angeben und **Zielzustand bewerten** auf **Ja** festlegen, leitet Route 53 Abfragen basierend auf dem Zustand der mit dem Load Balancer verknüpften Zielgruppen an den Load Balancer weiter:
+ Damit ein Application oder Network Load Balancer als fehlerfrei gilt, muss jede Zielgruppe mit Zielen mindestens ein fehlerfreies Ziel enthalten. Falls eine Zielgruppe nur fehlerhafte Ziele enthält, gilt der Load Balancer als fehlerhaft und Route 53 leitet Abfragen an andere Ressourcen weiter.
+ Eine Zielgruppe ohne registrierte Ziele gilt als fehlerhaft.
Beim Erstellen eines Load Balancers konfigurieren Sie Einstellungen für Elastic Load Balancing-Zustandsprüfungen. Dies sind keine Route 53-Zustandsprüfungen. Sie erfüllen aber eine ähnliche Funktion. Erstellen Sie keine Route 53-Zustandsprüfungen für die EC2-Instances, die Sie bei einem ELB-Load Balancer registrieren.
**S3-Buckets**
Es gibt keine speziellen Anforderungen, nach denen **Evaluate Target Health (Zielzustand bewerten)** auf **Yes (Ja)** festgelegt werden muss, wenn es sich beim Endpunkt um einen S3-Bucket handelt.
**Amazon-VPC-Schnittstellenendpunkte**
Es gibt keine besonderen Anforderungen für das Festlegen der **Zielzustand bewerten** auf **Ja**, wenn der Endpunkt ein Amazon-VPC-Schnittstellenendpunkt ist.
**Andere Datensätze innerhalb derselben gehosteten Zone**
Wenn es sich bei der AWS Ressource, die Sie in **Endpoint** angeben, um einen Datensatz oder eine Gruppe von Datensätzen handelt (z. B. um eine Gruppe gewichteter Datensätze), es sich jedoch nicht um einen weiteren Aliasdatensatz handelt, empfehlen wir, allen Datensätzen im Endpunkt eine Integritätsprüfung zuzuordnen. Weitere Informationen finden Sie unter [Was geschieht, wenn Sie Zustandsprüfungen überspringen?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).
## Datensatz-ID
Geben Sie einen Wert ein, der diesen Datensatz in der Gruppe von Latenz-Datensätzen eindeutig identifiziert.
# Spezifische Werte für IP-basierte Datensätze
Beim Erstellen IP-basierter Datensätze geben Sie die folgenden Werte an.
**Anmerkung**
Das Erstellen von IP-basierten Datensätzen in einer privat gehosteten Zone ist zwar erlaubt, wird aber nicht unterstützt.
**Topics**
+ [Routing-Richtlinie](#rrsets-values-ipbased-routing-policy)
+ [Datensatzname](#rrsets-values-ibased-name)
+ [Datensatztyp](#rrsets-values-ibased-type)
+ [TTL (Sekunden)](#rrsets-values-ibased-ttl)
+ [Bewerten/Weiterleiten des Datenverkehrs an](#rrsets-values-ibased-value)
+ [Ort](#rrsets-values-ibased-location)
+ [Zustandsprüfung](#rrsets-values-ibased-associate-with-health-check)
+ [Datensatz-ID](#rrsets-values-ipbased-set-id)
## Routing-Richtlinie
Wählen Sie **IP-based** (IP-basiert) aus.
## Datensatzname
Geben Sie den Namen der Domäne oder Subdomäne ein, für die Sie Verkehr weiterleiten wollen. Der Standardwert ist der Name der gehosteten Zone.
**Anmerkung**
Wenn Sie einen Datensatz erstellen, der denselben Namen wie die gehostete Zone hat, geben Sie im Feld **Datensatzname** keinen Wert ein (zum Beispiel ein @-Symbol).
Geben Sie den gleichen Namen für alle Datensätze in der Gruppe von IP-basierten Datensätzen ein.
**CNAME-Datensätze**
Wenn Sie einen Datensatz erstellen, der den Wert **CNAME** für **Datensatztyp** hat, darf der Name für den Datensatz nicht gleich dem Namen der gehosteten Zone sein.
**Sonderzeichen**
Erläuterungen dazu, wie Sie andere Zeichen als a-z, 0-9 und - (Bindestrich) eingeben und wie internationale Domainnamen angegeben werden, erhalten Sie unter [Format für DNS-Domänennamen](DomainNameFormat.md).
**Platzhalterzeichen**
Sie können im Namen ein Sternchenzeichen (\$1) verwenden. Abhängig von seiner Position im Namen wird das \$1-Zeichen vom DNS entweder als Platzhalter oder als das \$1-Zeichen (ASCII 42) behandelt. Weitere Informationen finden Sie unter [Verwendung eines Sternchens (\$1) im Namen von gehosteten Zonen und Datensätzen](DomainNameFormat.md#domain-name-format-asterisk).
## Datensatztyp
Der DNS-Datensatztyp. Weitere Informationen finden Sie unter [Unterstützte DNS-Datensatztypen](ResourceRecordTypes.md).
Wählen Sie den Wert für **Typ** danach aus, wie Route 53 auf DNS-Abfragen antworten soll.
Wählen Sie denselben Wert für alle Datensätze in der Gruppe der IP-basierten Datensätze aus.
## TTL (Sekunden)
Der Zeitraum (in Sekunden), für den Informationen über diesen Datensatz von rekursiven DNS-Resolvern zwischengespeichert werden sollen. Durch Angabe eines längeren Wertes (z. B. 172800 Sekunden, oder zwei Tage) verringern Sie die Anzahl der Aufrufe, die rekursive DNS-Resolver an Route 53 senden müssen, um die neuesten Informationen in diesem Datensatz zu erhalten. Dies führt zu einer Verringerung der Latenz und Ihrer Rechnung für den Route 53-Service. Weitere Informationen finden Sie unter [So leitet Amazon Route 53 Datenverkehr an Ihre Domain weiter](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Wenn Sie einen längeren Wert als TTL angeben, dauert es allerdings länger, bis Änderungen an dem Datensatz (z. B. eine neue IP-Adresse) wirksam werden. Dies liegt daran, dass die rekursiven Resolver die Werte in ihrem Zwischenspeicher für einen längeren Zeitraum verwenden, anstatt aktuelle Informationen von Route 53 anzufordern. Wenn Sie Einstellungen für eine Domäne oder Subdomäne ändern, die bereits verwendet wird, wird empfohlen, anfänglich einen kürzeren Wert, wie z. B. 300 Sekunden anzugeben und den Wert zu erhöhen, nachdem Sie bestätigt haben, dass die neuen Einstellungen korrekt sind.
Wenn Sie diesen Datensatz mit einer Zustandsprüfung verknüpfen, empfehlen wir Ihnen eine Time to Live (TTL, Gültigkeitsdauer) von 60 Sekunden oder weniger einzugeben, damit Clients schnell auf Änderungen im Zustandsstatus reagieren.
## Bewerten/Weiterleiten des Datenverkehrs an
Klicken Sie auf **IP-Adresse oder ein anderer Wert, abhängig vom Datensatztyp**. Geben Sie einen gültigen Wert für **Datensatztyp** ein. Sie können für alle Typen außer **CNAME** mehr als einen Wert eingeben. Fügen Sie jeden Wert in einer separaten Zeile hinzu.
Sie können weiterleiten oder die folgenden Werte angeben:
+ **A — Adresse IPv4 **
+ **AAAA — Adresse IPv6 **
+ **CAA – Certificate Authority Authorization** (Autorisierung der Zertifizierungsstelle)
+ **CNAME – kanonischer Name**
+ **MX – Mail-Austausch**
+ **NAPTR – Name Authority Pointer** (Namensautorisierungszeiger)
+ **PTR – Pointer** (Zeiger)
+ **SPF – Sender Policy Framework** (Richtlinien-Framework des Senders)
+ **SRV – Service-Locator**
+ **TXT – Text**
Weitere Informationen zu diesen Werten finden Sie unter [Bewerten/Weiterleiten des Datenverkehrs an](resource-record-sets-values-shared.md#rrsets-values-common-value) [Gemeinsame Werte für Bewerten/Weiterleiten des Datenverkehrs an](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Ort
Der Name des CIDR-Standorts, an dem die Ressource, die Sie in diesem Datensatz angegeben haben, durch die CIDR-Blockwerte innerhalb des CIDR-Standorts angegeben wird.
Weitere Informationen zum Verwenden von IP-basierten Datensätzen finden Sie unter [IP-basiertes Routing](routing-policy-ipbased.md).
## Zustandsprüfung
Wählen Sie eine Zustandsprüfung aus, wenn Route 53 den Status eines angegebenen Endpunkts überprüfen und DNS-Abfragen mit diesem Eintrag nur beantworten soll, wenn der Endpunkt fehlerfrei ist.
Route 53 prüft den Zustand des im Datensatz angegebenen Endpunkts nicht, z. B. des durch die IP-Adresse im Feld **Wert** definierten Endpunkts. Wenn Sie eine Zustandsprüfung für einen Datensatz auswählen, überprüft Route 53 den Zustand des Endpunkts, den Sie in der Zustandsprüfung angegeben haben. Informationen dazu, wie Route 53 ermittelt, ob ein Endpunkt fehlerfrei ist, finden Sie unter [So ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei istSo ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei ist](dns-failover-determining-health-of-endpoints.md).
Die Verknüpfung einer Zustandsprüfung mit einem Datensatz ist nur nützlich, wenn Route 53 zwischen mindestens zwei Datensätzen auswählt, um auf eine DNS-Abfrage zu antworten, und Route 53 die Auswahl zum Teil anhand des Status einer Zustandsprüfung treffen soll. Verwenden Sie Zustandsprüfungen nur in den folgenden Konfigurationen:
+ Sie überprüfen den Zustand aller Datensätze in einer Gruppe von Datensätzen, die denselben Namen, denselben Typ und dieselbe Routing-Richtlinie haben (z. B. Failover oder gewichtete Datensätze), und Sie geben die Integritätsprüfung IDs für alle Datensätze an. Wenn die Zustandsprüfung für einen Datensatz einen Endpunkt angibt, der nicht fehlerfrei ist, antwortet Route 53 nicht mehr auf Abfragen, die den Wert für diesen Datensatz verwenden.
+ Sie wählen **Yes** (Ja) für **Evaluate Target Health** (Zustand des Ziels bewerten) für einen Alias-Datensatz oder die Datensätze in einer Gruppe aus Failover-Alias-, Geolocation-Alias-, Latenz-Alias-, IP-basiertem Alias oder gewichteten Alias-Datensätzen aus. Wenn die Alias-Datensätze andere als Alias-Datensätze in derselben gehosteten Zone referenzieren, müssen Sie auch Zustandsprüfungen für die referenzierten Datensätze angeben. Wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen und **Yes** (Ja) für **Evaluate Target Health** (Zustand des Ziels bewerten) auswählen, müssen beide mit „True“ ausgewertet werden. Weitere Informationen finden Sie unter [Was geschieht, wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Wenn Ihre Zustandsprüfungen den Endpunkt nur nach Domainname angeben, sollten Sie für jeden Endpunkt eine eigene Zustandsprüfung erstellen. Sie sollten beispielsweise eine Zustandsprüfung für jeden HTTP-Server erstellen, der Inhalte für www.example.com bereitstellt. Sie müssen in **Domain Name (Domänenname)** als Wert den Domänennamen des Servers angeben (z. B. us-east-2-www.example.com), nicht den Namen der Datensätze (example.com).
**Wichtig**
Wenn Sie in dieser Konfiguration eine Zustandsprüfung erstellen, für die der Wert von **Domain name** dem Namen des Datensatzes entspricht, und anschließend die Zustandsprüfung mit diesen Datensätzen verknüpfen, sind die Ergebnisse der Zustandsprüfung unvorhersehbar.
## Datensatz-ID
Geben Sie einen Wert ein, der diesen Datensatz in der Gruppe von IP-basierten Datensätzen eindeutig identifiziert.
# Spezifische Werte für IP-basierte Aliasdatensätze
Beim Erstellen von IP-basierten Aliasdatensätzen geben Sie die folgenden Werte an.
**Anmerkung**
Das Erstellen von IP-basierten Aliasdatensätzen in einer privat gehosteten Zone ist zwar erlaubt, wird aber nicht unterstützt.
Weitere Informationen finden Sie unter [Wählen zwischen Alias- und Nicht-Alias-Datensätzen](resource-record-sets-choosing-alias-non-alias.md).
**Topics**
+ [Routing-Richtlinie](#rrsets-values-ipbased-alias-routing-policy)
+ [Datensatzname](#rrsets-values-ipbased-alias-name)
+ [Datensatztyp](#rrsets-values-ipbased-alias-type)
+ [Bewerten/Weiterleiten des Datenverkehrs an](#rrsets-values-ipbased-alias-alias-target)
+ [Speicherort](#rrsets-values-ipbased-alias-location)
+ [Gesundheitscheck](#rrsets-values-ipbased-alias-associate-with-health-check)
+ [Evaluate Target Health](#rrsets-values-ipbased-alias-evaluate-target-health)
+ [Datensatz-ID](#rrsets-values-ipbased-alias-set-id)
## Routing-Richtlinie
Wählen Sie **IP-based** (IP-basiert) aus.
**Anmerkung**
Das Erstellen von IP-basierten Aliasdatensätzen in einer privat gehosteten Zone ist zwar erlaubt, wird aber nicht unterstützt.
## Datensatzname
Geben Sie den Namen der Domäne oder Subdomäne ein, für die Sie Verkehr weiterleiten wollen. Der Standardwert ist der Name der gehosteten Zone.
**Anmerkung**
Wenn Sie einen Datensatz erstellen, der denselben Namen wie die gehostete Zone hat, geben Sie im Feld **Datensatzname** keinen Wert ein (zum Beispiel ein @-Symbol).
Geben Sie den gleichen Namen für alle Datensätze in der Gruppe von IP-basierten Datensätzen ein.
**CNAME-Datensätze**
Wenn Sie einen Datensatz erstellen, der den Wert **CNAME** für **Datensatztyp** hat, darf der Name für den Datensatz nicht gleich dem Namen der gehosteten Zone sein.
**Aliase für CloudFront Distributionen und Amazon S3 S3-Buckets**
Der Wert, den Sie angeben, hängt zum Teil von der AWS Ressource ab, an die Sie den Datenverkehr weiterleiten:
+ **CloudFront Verteilung** — Ihre Distribution muss einen alternativen Domainnamen enthalten, der dem Namen des Eintrags entspricht. Wenn der Name des Datensatzes beispielsweise **acme.example.com** ist, muss Ihre CloudFront-Verteilung **acme.example.com** als einen alternativen Domänennamen enthalten. Weitere Informationen finden Sie unter [Verwenden alternativer Domainnamen (CNAMEs)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) im *Amazon CloudFront Developer Guide*.
+ **Amazon-S3-Bucket** – Der Name des Datensatzes muss mit dem Namen Ihres Amazon-S3-Buckets übereinstimmen. Wenn der Name des Buckets beispielsweise **acme.example.com** lautet, muss der Name dieses Datensatzes ebenfalls **acme.example.com** lauten.
Außerdem müssen Sie den Bucket für das Website-Hosting konfigurieren. Weitere Informationen finden Sie unter [Konfigurieren eines Buckets für Website-Hosting](https://docs.aws.amazon.com/AmazonS3/latest/userguide/HowDoIWebsiteConfiguration.html) im *Benutzerhandbuch für Amazon Simple Storage Service*.
**Sonderzeichen**
Erläuterungen dazu, wie Sie andere Zeichen als a-z, 0-9 und - (Bindestrich) eingeben und wie internationale Domainnamen angegeben werden, erhalten Sie unter [Format für DNS-Domänennamen](DomainNameFormat.md).
**Platzhalterzeichen**
Sie können im Namen ein Sternchenzeichen (\$1) verwenden. Abhängig von seiner Position im Namen wird das \$1-Zeichen vom DNS entweder als Platzhalter oder als das \$1-Zeichen (ASCII 42) behandelt. Weitere Informationen finden Sie unter [Verwendung eines Sternchens (\$1) im Namen von gehosteten Zonen und Datensätzen](DomainNameFormat.md#domain-name-format-asterisk).
## Datensatztyp
Der DNS-Datensatztyp. Weitere Informationen finden Sie unter [Unterstützte DNS-Datensatztypen](ResourceRecordTypes.md).
Wählen Sie den entsprechenden Wert basierend auf der AWS Ressource aus, an die Sie den Datenverkehr weiterleiten. Wählen Sie für alle Datensätze in der Gruppe IP-basierter Datensätzen denselben Wert aus.
**Benutzerdefinierte regionale API-Gateway-API oder Edge-optimierte API**
Wählen Sie **A — IPv4 Adresse** aus.
**Amazon-VPC-Schnittstellenendpunkte**
Wählen Sie **A — IPv4 Adresse** aus.
**CloudFront Vertrieb**
Wählen Sie **A — IPv4 Adresse** aus.
Wenn für die Verteilung aktiviert IPv6 ist, erstellen Sie zwei Datensätze, einen mit dem Wert **A — IPv4 Adresse** für **Typ** und einen mit dem Wert **AAAA — IPv6 Adresse**.
**App-Runner-Dienst**
Wählen Sie **A — Adresse IPv4 **
**Elastic-Beanstalk-Umgebung, die über regionale Subdomänen verfügt**
Wählen Sie **A — IPv4 Adresse**
**ELB-Load Balancer**
Wählen **Sie IPv4 A-Adresse** oder **AAAA-Adresse IPv6 **
**Amazon-S3-Bucket**
Wählen Sie **A — Adresse IPv4 **
**OpenSearch Dienst**
Wählen Sie **A — IPv4 Adresse** oder **AAAA — IPv6 ** Adresse
**Weiterer Datensatz in dieser gehosteten Zone**
Wählen Sie den Typ des Datensatzes aus, für den Sie den Alias erstellen. Es werden alle Typen außer **NS** und **SOA** unterstützt.
Wenn Sie einen Aliasdatensatz mit demselben Namen wie die gehostete Zone (*Zonen-Apex*) erstellen, können Sie den Datenverkehr nicht zu einem Datensatz weiterleiten, dessen Wert in **Type (Typ)** **CNAME** ist. Der Grund hierfür ist, dass der Aliasdatensatz denselben Typ wie der Datensatz haben muss, zu dem Sie den Datenverkehr weiterleiten, und die Erstellung eines CNAME-Datensatzes für den Zonen-Apex wird für einen Aliasdatensatz nicht unterstützt.
## Bewerten/Weiterleiten des Datenverkehrs an
Der Wert, den Sie aus der Liste auswählen oder den Sie in das Feld eingeben, hängt von der AWS Ressource ab, an die Sie den Verkehr weiterleiten.
Informationen darüber, auf welche AWS Ressourcen Sie abzielen können, finden Sie unter [Allgemeine Werte für Aliasdatensätze für den value/route Datenverkehr](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
Weitere Informationen zur Konfiguration von Route 53 zur Weiterleitung von Datenverkehr an bestimmte AWS Ressourcen finden Sie unter[Weiterleitung des Internetverkehrs zu Ihren AWS Ressourcen](routing-to-aws-resources.md).
## Speicherort
Bei der Konfiguration von Route 53 für Antworten auf DNS-Abfragen auf Basis des Standorts, von dem die Abfragen stammen, wählen Sie den CIDR-Standort aus, für den bzw. das Route 53 mit den Einstellungen in diesem Datensatz antworten soll.
**Wichtig**
Es wird empfohlen, einen IP-basierten Datensatz mit dem Wert **Standard** für **Standort** zu erstellen. Dies deckt Standorte ab, für die Sie keine Datensätze erstellt haben, sowie IP-Adressen, für die Route 53 keinen Standort identifizieren kann.
Sie können keine non-IP-based Datensätze erstellen, die dieselben Werte für **Datensatzname und **Datensatztyp**** haben wie IP-basierte Datensätze.
Weitere Informationen finden Sie unter [IP-basiertes Routing](routing-policy-ipbased.md).
## Gesundheitscheck
Wählen Sie eine Zustandsprüfung aus, wenn Route 53 den Status eines angegebenen Endpunkts überprüfen und DNS-Abfragen mit diesem Eintrag nur beantworten soll, wenn der Endpunkt fehlerfrei ist.
Route 53 prüft den Zustand des im Datensatz angegebenen Endpunkts nicht, z. B. des durch die IP-Adresse im Feld **Wert** definierten Endpunkts. Wenn Sie eine Zustandsprüfung für einen Datensatz auswählen, überprüft Route 53 den Zustand des Endpunkts, den Sie in der Zustandsprüfung angegeben haben. Informationen dazu, wie Route 53 ermittelt, ob ein Endpunkt fehlerfrei ist, finden Sie unter [So ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei istSo ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei ist](dns-failover-determining-health-of-endpoints.md).
Die Verknüpfung einer Zustandsprüfung mit einem Datensatz ist nur nützlich, wenn Route 53 zwischen mindestens zwei Datensätzen auswählt, um auf eine DNS-Abfrage zu antworten, und Route 53 die Auswahl zum Teil anhand des Status einer Zustandsprüfung treffen soll. Verwenden Sie Zustandsprüfungen nur in den folgenden Konfigurationen:
+ Sie überprüfen den Zustand aller Datensätze in einer Gruppe von Datensätzen, die denselben Namen, denselben Typ und dieselbe Routing-Richtlinie haben (z. B. Failover oder gewichtete Datensätze), und Sie geben eine Integritätsprüfung IDs für alle Datensätze an. Wenn die Zustandsprüfung für einen Datensatz einen Endpunkt angibt, der nicht fehlerfrei ist, antwortet Route 53 nicht mehr auf Abfragen, die den Wert für diesen Datensatz verwenden.
+ Sie wählen **Yes** (Ja) für **Evaluate Target Health** (Zustand des Ziels bewerten) für einen Alias-Datensatz oder die Datensätze in einer Gruppe aus Failover-Alias-, Geolocation-Alias-, IP-basiertem Alias-, Latenz-Alias oder gewichteten Alias-Datensätzen aus. Wenn die Alias-Datensätze andere als Alias-Datensätze in derselben gehosteten Zone referenzieren, müssen Sie auch Zustandsprüfungen für die referenzierten Datensätze angeben. Wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen und **Yes** (Ja) für **Evaluate Target Health** (Zustand des Ziels bewerten) auswählen, müssen beide mit „True“ ausgewertet werden. Weitere Informationen finden Sie unter [Was geschieht, wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Wenn Ihre Zustandsprüfungen den Endpunkt nur nach Domainname angeben, sollten Sie für jeden Endpunkt eine eigene Zustandsprüfung erstellen. Sie sollten beispielsweise eine Zustandsprüfung für jeden HTTP-Server erstellen, der Inhalte für www.example.com bereitstellt. Sie müssen in **Domain Name (Domänenname)** als Wert den Domänennamen des Servers angeben (z. B. us-east-2-www.example.com), nicht den Namen der Datensätze (example.com).
**Wichtig**
Wenn Sie in dieser Konfiguration eine Zustandsprüfung erstellen, für die der Wert von **Domain name** dem Namen des Datensatzes entspricht, und anschließend die Zustandsprüfung mit diesen Datensätzen verknüpfen, sind die Ergebnisse der Zustandsprüfung unvorhersehbar.
Wenn es einen ungesunden Endpunkt in IP-basierten Aliasdatensätzen gibt, sucht Route 53 nach einem Datensatz im größeren verbundenen Standort. Angenommen, Sie besitzen Datensätze für einen Bundesstaat der Vereinigten Staaten, für die Vereinigten Staaten, für Nordamerika und für alle Standorte (**Location (Standort)** ist **Default (Standard)**). Wenn der Endpunkt für den Bundesstaatdatensatz fehlerhaft ist, prüft Route 53 der Reihe nach die Datensätze für die Vereinigten Staaten, für Nordamerika und für alle Standorte, bis ein Datensatz mit einem fehlerfreien Endpunkt gefunden wird. Wenn alle Datensätze einschließlich des Datensatzes für alle Standorte fehlerhaft sind, antwortet Route 53 auf die DNS-Abfrage mittels des Werts für den Datensatz für die kleinste geografische Region.
## Evaluate Target Health
Wählen Sie **Ja** aus, wenn Route 53 ermitteln soll, ob auf DNS-Abfragen, die diesen Datensatz verwenden, geantwortet werden soll, indem der Zustand der in **Endpunkt** angegebenen Ressource geprüft wird.
Beachten Sie Folgendes:
**API Gateway, kundenspezifisch, regional APIs und Edge-optimiert APIs**
Es gibt keine besonderen Anforderungen für das Festlegen von **Zielzustand bewerten** auf **Ja**, wenn der Endpunkt eine benutzerdefinierte regionale API-Gateway-API oder eine Edge-optimierte API ist.
**CloudFront Verteilungen**
Sie können die Option **Zielintegrität bewerten** nicht auf **Ja setzen, wenn es** sich bei dem Endpunkt um eine CloudFront Verteilung handelt.
**Elastic Beanstalk-Umgebungen, die über regionale Subdomänen verfügen**
Wenn Sie in **Endpoint** eine Elastic Beanstalk Beanstalk-Umgebung angeben und die Umgebung einen ELB-Load Balancer enthält, leitet Elastic Load Balancing Abfragen nur an die fehlerfreien EC2 Amazon-Instances weiter, die beim Load Balancer registriert sind. (Eine Umgebung enthält automatisch einen ELB-Load Balancer, wenn sie mehr als eine EC2 Amazon-Instance umfasst.) Wenn Sie **Evaluate target health** auf **Ja** setzen und entweder keine EC2 Amazon-Instances fehlerfrei sind oder der Load Balancer selbst fehlerhaft ist, leitet Route 53 Abfragen an andere verfügbare Ressourcen weiter, die fehlerfrei sind, falls vorhanden.
Wenn die Umgebung eine einzelne EC2 Amazon-Instance enthält, gibt es keine besonderen Anforderungen.
**ELB-Load Balancer**
Das Verhalten der Zustandsprüfung ist abhängig vom Typ des Load Balancers:
+ **Classic Load Balancers** — Wenn Sie einen ELB Classic Load Balancer in **Endpoint** angeben, leitet Elastic Load Balancing Abfragen nur an die fehlerfreien EC2 Amazon-Instances weiter, die beim Load Balancer registriert sind. Wenn Sie „**Zielstatus bewerten**“ auf **Ja** setzen und entweder keine EC2 Instances fehlerfrei sind oder der Load Balancer selbst fehlerhaft ist, leitet Route 53 Abfragen an andere Ressourcen weiter.
+ **Anwendungs- und Network Load Balancer** – Wenn Sie einen ELB-Anwendungs- oder -Network Load Balancer angeben und **Zielzustand bewerten** auf **Ja** festlegen, leitet Route 53 Abfragen basierend auf dem Zustand der mit dem Load Balancer verknüpften Zielgruppen an den Load Balancer weiter:
+ Damit ein Application oder Network Load Balancer als fehlerfrei gilt, muss jede Zielgruppe mit Zielen mindestens ein fehlerfreies Ziel enthalten. Falls eine Zielgruppe nur fehlerhafte Ziele enthält, gilt der Load Balancer als fehlerhaft und Route 53 leitet Abfragen an andere Ressourcen weiter.
+ Eine Zielgruppe ohne registrierte Ziele gilt als fehlerhaft.
Beim Erstellen eines Load Balancers konfigurieren Sie Einstellungen für Elastic Load Balancing-Zustandsprüfungen. Dies sind keine Route 53-Zustandsprüfungen. Sie erfüllen aber eine ähnliche Funktion. Erstellen Sie keine Route 53-Zustandsprüfungen für die EC2 Instances, die Sie bei einem ELB-Load Balancer registrieren.
**S3-Buckets**
Es gibt keine speziellen Anforderungen, nach denen **Evaluate Target Health (Zielzustand bewerten)** auf **Yes (Ja)** festgelegt werden muss, wenn es sich beim Endpunkt um einen S3-Bucket handelt.
**Amazon-VPC-Schnittstellenendpunkte**
Es gibt keine besonderen Anforderungen für das Festlegen der **Zielzustand bewerten** auf **Ja**, wenn der Endpunkt ein Amazon-VPC-Schnittstellenendpunkt ist.
**Andere Datensätze innerhalb derselben gehosteten Zone**
Wenn es sich bei der AWS Ressource, die Sie in **Endpoint** angeben, um einen Datensatz oder eine Gruppe von Datensätzen (z. B. um eine Gruppe gewichteter Datensätze) handelt, es sich jedoch nicht um einen weiteren Alias-Datensatz handelt, empfehlen wir, allen Datensätzen im Endpunkt eine Integritätsprüfung zuzuordnen. Weitere Informationen finden Sie unter [Was geschieht, wenn Sie Zustandsprüfungen überspringen?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).
## Datensatz-ID
Geben Sie einen Wert ein, der diesen Datensatz in der Gruppe von IP-basierten Datensätzen eindeutig identifiziert.
# Werte für spezifische mehrwertige Antwort-Datensätze
Beim Erstellen mehrwertiger Antwort-Datensätze geben Sie folgende Werte an.
**Anmerkung**
Das Erstellen von mehrwertigen Antwort-Aliasdatensätzen wird nicht unterstützt.
**Topics**
+ [Routing-Richtlinie](#rrsets-values-multivalue-routing-policy)
+ [Datensatzname](#rrsets-values-multivalue-name)
+ [Datensatztyp](#rrsets-values-multivalue-type)
+ [TTL (Sekunden)](#rrsets-values-multivalue-ttl)
+ [Bewerten/Weiterleiten des Datenverkehrs an](#rrsets-values-multivalue-value)
+ [Gesundheitscheck](#rrsets-values-multivalue-associate-with-health-check)
+ [Datensatz-ID](#rrsets-values-multivalue-set-identifier)
## Routing-Richtlinie
Klicken Sie auf **Mehrwertige Antwort**.
## Datensatzname
Geben Sie den Namen der Domäne oder Subdomäne ein, für die Sie Verkehr weiterleiten wollen. Der Standardwert ist der Name der gehosteten Zone.
**Anmerkung**
Wenn Sie einen Datensatz erstellen, der denselben Namen wie die gehostete Zone hat, geben Sie im Feld **Datensatzname** keinen Wert ein (zum Beispiel ein @-Symbol).
Geben Sie für alle Datensätze in der Gruppe von mehrwertigen Datensätzen denselben Namen ein.
Weitere Informationen über Datensatznamen finden Sie unter [Datensatzname](resource-record-sets-values-shared.md#rrsets-values-common-name).
## Datensatztyp
Der DNS-Datensatztyp. Weitere Informationen finden Sie unter [Unterstützte DNS-Datensatztypen](ResourceRecordTypes.md).
Wählen Sie einen beliebigen Wert außer **NS** und **CNAME** aus.
Wählen Sie für alle Datensätze in der Gruppe von mehrwertigen Antwort-Datensätzen denselben Namen aus.
## TTL (Sekunden)
Der Zeitraum (in Sekunden), für den Informationen über diesen Datensatz von rekursiven DNS-Resolvern zwischengespeichert werden sollen. Durch Angabe eines längeren Wertes (z. B. 172 800 Sekunden oder zwei Tage) verringern Sie die Anzahl der Aufrufe, die rekursive DNS-Resolver an Route 53 senden müssen, um die neuesten Informationen in diesem Datensatz zu erhalten. Dies führt zu einer Verringerung der Latenz und Kosten für den Route-53-Service. Weitere Informationen finden Sie unter [So leitet Amazon Route 53 Datenverkehr an Ihre Domain weiter](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Wenn Sie einen längeren Wert als TTL angeben, dauert es allerdings länger, bis Änderungen an dem Datensatz (z. B. eine neue IP-Adresse) wirksam werden. Dies liegt daran, dass die rekursiven Resolver die Werte in ihrem Zwischenspeicher für einen längeren Zeitraum verwenden, anstatt aktuelle Informationen von Route 53 anzufordern. Wenn Sie Einstellungen für eine Domäne oder Subdomäne ändern, die bereits verwendet wird, wird empfohlen, anfänglich einen kürzeren Wert, wie z. B. 300 Sekunden anzugeben und den Wert zu erhöhen, nachdem Sie bestätigt haben, dass die neuen Einstellungen korrekt sind.
Wenn Sie diesen Datensatz mit einer Zustandsprüfung verknüpfen, empfehlen wir Ihnen eine Time to Live (TTL) von 60 Sekunden oder weniger einzugeben, damit Clients schnell auf Änderungen im Zustandsstatus reagieren.
**Anmerkung**
Wenn Sie zwei oder mehr mehrwertige Antwortdatensätze mit demselben Namen und Typ erstellen, verwenden Sie die Konsole und legen unterschiedliche Werte für **TTL** fest. Route 53 ändert den Wert von **TTL** für alle Datensätze auf den letzten angegebenen Wert.
## Bewerten/Weiterleiten des Datenverkehrs an
Klicken Sie auf **IP-Adresse oder ein anderer Wert, abhängig vom Datensatztyp**. Geben Sie einen gültigen Wert für **Datensatztyp** ein. Wenn Sie mehr als einen Wert eingeben, geben Sie jeden Wert in einer separaten Zeile ein.
Sie können den Datenverkehr weiterleiten oder die folgenden Werte angeben:
+ **A — IPv4 Adresse**
+ **AAAA — Adresse IPv6 **
+ **CAA – Certificate Authority Authorization** (Autorisierung der Zertifizierungsstelle)
+ **MX – Mail-Austausch**
+ **NAPTR – Name Authority Pointer** (Namensautorisierungszeiger)
+ **PTR – Pointer** (Zeiger)
+ **SPF – Sender Policy Framework** (Richtlinien-Framework des Senders)
+ **SRV – Service-Locator**
+ **TXT – Text**
Weitere Informationen zu den oben genannten Werten finden Sie unter [Allgemeine Werte für den Value/Route Verkehr nach](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Gesundheitscheck
Wählen Sie eine Zustandsprüfung aus, wenn Route 53 den Status eines angegebenen Endpunkts überprüfen und DNS-Abfragen mit diesem Eintrag nur beantworten soll, wenn der Endpunkt fehlerfrei ist.
Route 53 prüft den Zustand des im Datensatz angegebenen Endpunkts nicht, z. B. des durch die IP-Adresse im Feld **Wert** definierten Endpunkts. Wenn Sie eine Zustandsprüfung für einen Datensatz auswählen, überprüft Route 53 den Zustand des Endpunkts, den Sie in der Zustandsprüfung angegeben haben. Informationen dazu, wie Route 53 ermittelt, ob ein Endpunkt fehlerfrei ist, finden Sie unter [So ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei istSo ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei ist](dns-failover-determining-health-of-endpoints.md).
Die Verknüpfung einer Zustandsprüfung mit einem Datensatz ist nur nützlich, wenn Route 53 zwischen mindestens zwei Datensätzen auswählt, um auf eine DNS-Abfrage zu antworten, und Route 53 die Auswahl zum Teil anhand des Status einer Zustandsprüfung treffen soll. Verwenden Sie Zustandsprüfungen nur in den folgenden Konfigurationen:
+ Sie überprüfen den Zustand aller Datensätze in einer Gruppe von Datensätzen, die denselben Namen, denselben Typ und dieselbe Routing-Richtlinie haben (z. B. Failover oder gewichtete Datensätze), und Sie geben eine Integritätsprüfung IDs für alle Datensätze an. Wenn die Zustandsprüfung für einen Datensatz einen Endpunkt angibt, der nicht fehlerfrei ist, antwortet Route 53 nicht mehr auf Abfragen, die den Wert für diesen Datensatz verwenden.
+ Sie wählen **Yes (Ja)** für **Evaluate Target Health (Zustand des Ziels bewerten)** für einen Alias-Datensatz oder die Datensätze in einer Gruppe aus Failover-Alias-, Geolocation-Alias-, Latenz-Alias- oder gewichteten Alias-Datensätzen aus. Wenn die Alias-Datensätze andere als Alias-Datensätze in derselben gehosteten Zone referenzieren, müssen Sie auch Zustandsprüfungen für die referenzierten Datensätze angeben. Wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen und **Yes** (Ja) für **Evaluate Target Health** (Zustand des Ziels bewerten) auswählen, müssen beide mit „True“ ausgewertet werden. Weitere Informationen finden Sie unter [Was geschieht, wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Wenn Ihre Zustandsprüfungen den Endpunkt nur nach Domainname angeben, sollten Sie für jeden Endpunkt eine eigene Zustandsprüfung erstellen. Sie sollten beispielsweise eine Zustandsprüfung für jeden HTTP-Server erstellen, der Inhalte für www.example.com bereitstellt. Sie müssen in **Domain Name (Domänenname)** als Wert den Domänennamen des Servers angeben (z. B. us-east-2-www.example.com), nicht den Namen der Datensätze (example.com).
**Wichtig**
Wenn Sie in dieser Konfiguration eine Zustandsprüfung erstellen, für die der Wert von **Domain name** dem Namen des Datensatzes entspricht, und anschließend die Zustandsprüfung mit diesen Datensätzen verknüpfen, sind die Ergebnisse der Zustandsprüfung unvorhersehbar.
## Datensatz-ID
Geben Sie einen Wert ein, der diesen Datensatz in der Gruppe von mehrwertigen Antwort-Datensätzen eindeutig identifiziert.
# Spezifische Werte für gewichtete Datensätze
Beim Erstellen von gewichteten Datensätzen geben Sie die folgenden Werte an.
**Topics**
+ [Routing-Richtlinie](#rrsets-values-weighted-routing-policy)
+ [Datensatzname](#rrsets-values-weighted-name)
+ [Datensatztyp](#rrsets-values-weighted-type)
+ [TTL (Sekunden)](#rrsets-values-weighted-ttl)
+ [Bewerten/Weiterleiten des Datenverkehrs an](#rrsets-values-weighted-value)
+ [Gewicht](#rrsets-values-weighted-weight)
+ [Gesundheitscheck](#rrsets-values-weighted-associate-with-health-check)
+ [Datensatz-ID](#rrsets-values-weighted-set-identifier)
## Routing-Richtlinie
Wählen Sie **Weighted (Gewichtet)** aus.
## Datensatzname
Geben Sie den Namen der Domäne oder Subdomäne ein, für die Sie Verkehr weiterleiten wollen. Der Standardwert ist der Name der gehosteten Zone.
**Anmerkung**
Wenn Sie einen Datensatz erstellen, der denselben Namen wie die gehostete Zone hat, geben Sie im Feld **Datensatzname** keinen Wert ein (zum Beispiel ein @-Symbol).
Geben Sie für alle Datensätze in der Gruppe von gewichteten Datensätzen denselben Namen ein.
Weitere Informationen über Datensatznamen finden Sie unter [Datensatzname](resource-record-sets-values-shared.md#rrsets-values-common-name).
## Datensatztyp
Der DNS-Datensatztyp. Weitere Informationen finden Sie unter [Unterstützte DNS-Datensatztypen](ResourceRecordTypes.md).
Wählen Sie für alle Datensätze in der Gruppe von gewichteten Datensätzen denselben Namen aus.
## TTL (Sekunden)
Der Zeitraum (in Sekunden), für den Informationen über diesen Datensatz von rekursiven DNS-Resolvern zwischengespeichert werden sollen. Durch Angabe eines längeren Wertes (z. B. 172 800 Sekunden oder zwei Tage) verringern Sie die Anzahl der Aufrufe, die rekursive DNS-Resolver an Route 53 senden müssen, um die neuesten Informationen in diesem Datensatz zu erhalten. Dies führt zu einer Verringerung der Latenz und Kosten für den Route-53-Service. Weitere Informationen finden Sie unter [So leitet Amazon Route 53 Datenverkehr an Ihre Domain weiter](welcome-dns-service.md#welcome-dns-service-how-route-53-routes-traffic).
Wenn Sie einen längeren Wert als TTL angeben, dauert es allerdings länger, bis Änderungen an dem Datensatz (z. B. eine neue IP-Adresse) wirksam werden. Dies liegt daran, dass die rekursiven Resolver die Werte in ihrem Zwischenspeicher für einen längeren Zeitraum verwenden, anstatt aktuelle Informationen von Route 53 anzufordern. Wenn Sie Einstellungen für eine Domäne oder Subdomäne ändern, die bereits verwendet wird, wird empfohlen, anfänglich einen kürzeren Wert, wie z. B. 300 Sekunden anzugeben und den Wert zu erhöhen, nachdem Sie bestätigt haben, dass die neuen Einstellungen korrekt sind.
Wenn Sie diesen Datensatz mit einer Zustandsprüfung verknüpfen, empfehlen wir Ihnen eine Time to Live (TTL) von 60 Sekunden oder weniger einzugeben, damit Clients schnell auf Änderungen im Zustandsstatus reagieren.
Sie müssen für alle Datensätze in dieser Gruppe von gewichteten Datensätzen denselben Wert für **TTL** angeben.
**Anmerkung**
Wenn Sie zwei oder mehr gewichtete Datensätze mit demselben Namen und Typ erstellen und unterschiedliche Werte für **TTL** festlegen, ändert Route 53 den Wert von **TTL** für alle Datensätze auf den letzten angegebenen Wert.
Wenn eine Gruppe von gewichteten Datensätzen einen oder mehrere gewichtete Alias-Datensätze enthält, die Datenverkehr an einen ELB-Load Balancer weiterleiten, wird empfohlen, eine TTL von 60 Sekunden für sämtliche gewichteten Nicht-Alias-Datensätze anzugeben, die denselben Namen und Typ haben. Andere Werte als 60 Sekunden (die TTL für Load Balancer) ändern die Auswirkungen der Werte, die Sie für **Weight (Gewichtung)** angeben.
## Bewerten/Weiterleiten des Datenverkehrs an
Klicken Sie auf **IP-Adresse oder ein anderer Wert, abhängig vom Datensatztyp**. Geben Sie einen gültigen Wert für **Datensatztyp** ein. Sie können für alle Typen außer **CNAME** mehr als einen Wert eingeben. Fügen Sie jeden Wert in einer separaten Zeile hinzu.
Sie können weiterleiten oder die folgenden Werte angeben:
+ **A — IPv4 Adresse**
+ **AAAA — Adresse IPv6 **
+ **CAA – Certificate Authority Authorization** (Autorisierung der Zertifizierungsstelle)
+ **CNAME – kanonischer Name**
+ **MX – Mail-Austausch**
+ **NAPTR – Name Authority Pointer** (Namensautorisierungszeiger)
+ **PTR – Pointer** (Zeiger)
+ **SPF – Sender Policy Framework** (Richtlinien-Framework des Senders)
+ **SRV – Service-Locator**
+ **TXT – Text**
Weitere Informationen zu den oben genannten Werten finden Sie unter [Allgemeine Werte für den Value/Route Verkehr nach](resource-record-sets-values-shared.md#rrsets-values-common-value).
## Gewicht
Ein Wert, der das Verhältnis von DNS-Abfragen, auf die Route 53 antwortet, anhand des aktuellen Datensatzes bestimmt. Route 53 berechnet die Summe der Gewichtungen für die Datensätze, die dieselbe Kombination von DNS-Namen und -Typ aufweisen. Route 53 beantwortet dann Abfragen, die auf dem Verhältnis der Gewichtung einer Ressource zur Gesamtmenge basieren.
Sie können keine nicht gewichteten Datensätze erstellen, die über dieselben Werte wie gewichtete Datensätze für **Datensatzname** und **Datensatztyp** verfügen.
Geben Sie eine Ganzzahl zwischen 0 und 255 ein. Zum Deaktivieren der Weiterleitung an eine Ressource setzen Sie für **Weight (Gewichtung)** den Wert 0 fest. Wenn Sie **Weight (Gewichtung)** für alle Datensätze in der Gruppe auf 0 setzen, wird der Datenverkehr mit gleicher Wahrscheinlichkeit zu allen Ressourcen weitergeleitet. Auf diese Weise wird verhindert, dass Sie die Weiterleitung für eine Gruppe von gewichteten Datensätzen versehentlich deaktivieren.
Wenn Sie Zustandsprüfungen mit gewichteten Datensätzen verknüpfen und **Weight (Gewichtung)** auf 0 setzen, unterscheidet sich das Resultat. Weitere Informationen finden Sie unter [So wählt Amazon Route 53 Datensätze, wenn Zustandsprüfungen konfiguriert sindSo wählt Route 53 Datensätze, wenn Zustandsprüfungen konfiguriert sind](health-checks-how-route-53-chooses-records.md).
## Gesundheitscheck
Wählen Sie eine Zustandsprüfung aus, wenn Route 53 den Status eines angegebenen Endpunkts überprüfen und DNS-Abfragen mit diesem Eintrag nur beantworten soll, wenn der Endpunkt fehlerfrei ist.
Route 53 prüft den Zustand des im Datensatz angegebenen Endpunkts nicht, z. B. des durch die IP-Adresse im Feld **Wert** definierten Endpunkts. Wenn Sie eine Zustandsprüfung für einen Datensatz auswählen, überprüft Route 53 den Zustand des Endpunkts, den Sie in der Zustandsprüfung angegeben haben. Informationen dazu, wie Route 53 ermittelt, ob ein Endpunkt fehlerfrei ist, finden Sie unter [So ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei istSo ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei ist](dns-failover-determining-health-of-endpoints.md).
Die Verknüpfung einer Zustandsprüfung mit einem Datensatz ist nur nützlich, wenn Route 53 zwischen mindestens zwei Datensätzen auswählt, um auf eine DNS-Abfrage zu antworten, und Route 53 die Auswahl zum Teil anhand des Status einer Zustandsprüfung treffen soll. Verwenden Sie Zustandsprüfungen nur in den folgenden Konfigurationen:
+ Sie überprüfen den Zustand aller Datensätze in einer Gruppe von Datensätzen, die denselben Namen, denselben Typ und dieselbe Routing-Richtlinie haben (z. B. Failover oder gewichtete Datensätze), und Sie geben eine Integritätsprüfung IDs für alle Datensätze an. Wenn die Zustandsprüfung für einen Datensatz einen Endpunkt angibt, der nicht fehlerfrei ist, antwortet Route 53 nicht mehr auf Abfragen, die den Wert für diesen Datensatz verwenden.
+ Sie wählen **Yes** (Ja) für **Evaluate Target Health** (Zustand des Ziels bewerten) für einen Alias-Datensatz oder die Datensätze in einer Gruppe aus Failover-Alias-, Geolocation-Alias-, Latenz-Alias-, IP-basierten Alias- oder gewichteten Alias-Datensätzen aus. Wenn die Alias-Datensätze andere als Alias-Datensätze in derselben gehosteten Zone referenzieren, müssen Sie auch Zustandsprüfungen für die referenzierten Datensätze angeben. Wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen und **Yes** (Ja) für **Evaluate Target Health** (Zustand des Ziels bewerten) auswählen, müssen beide mit „True“ ausgewertet werden. Weitere Informationen finden Sie unter [Was geschieht, wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Wenn Ihre Zustandsprüfungen den Endpunkt nur nach Domainname angeben, sollten Sie für jeden Endpunkt eine eigene Zustandsprüfung erstellen. Sie sollten beispielsweise eine Zustandsprüfung für jeden HTTP-Server erstellen, der Inhalte für www.example.com bereitstellt. Sie müssen in **Domain Name (Domänenname)** als Wert den Domänennamen des Servers angeben (z. B. us-east-2-www.example.com), nicht den Namen der Datensätze (example.com).
**Wichtig**
Wenn Sie in dieser Konfiguration eine Zustandsprüfung erstellen, für die der Wert von **Domain name** dem Namen des Datensatzes entspricht, und anschließend die Zustandsprüfung mit diesen Datensätzen verknüpfen, sind die Ergebnisse der Zustandsprüfung unvorhersehbar.
## Datensatz-ID
Geben Sie einen Wert ein, der diesen Datensatz in der Gruppe von gewichteten Datensätzen eindeutig identifiziert.
# Spezifische Werte für gewichtete Aliasdatensätze
Beim Erstellen von gewichteten Aliasdatensätzen geben Sie die folgenden Werte an. Weitere Informationen finden Sie unter [Wählen zwischen Alias- und Nicht-Alias-Datensätzen](resource-record-sets-choosing-alias-non-alias.md).
**Topics**
+ [Routing-Richtlinie](#rrsets-values-weighted-alias-routing-policy)
+ [Datensatzname](#rrsets-values-weighted-alias-name)
+ [Datensatztyp](#rrsets-values-weighted-alias-type)
+ [Bewerten/Weiterleiten des Datenverkehrs an](#rrsets-values-weighted-alias-alias-target)
+ [Gewicht](#rrsets-values-weighted-alias-weight)
+ [Gesundheitscheck](#rrsets-values-weighted-alias-associate-with-health-check)
+ [Evaluate Target Health](#rrsets-values-weighted-alias-evaluate-target-health)
+ [Datensatz-ID](#rrsets-values-weighted-alias-set-identifier)
## Routing-Richtlinie
Klicken Sie auf **Gewichtet**.
## Datensatzname
Geben Sie den Namen der Domäne oder Subdomäne ein, für die Sie Verkehr weiterleiten wollen. Der Standardwert ist der Name der gehosteten Zone.
**Anmerkung**
Wenn Sie einen Datensatz erstellen, der denselben Namen wie die gehostete Zone hat, geben Sie im Feld **Name** keinen Wert ein (zum Beispiel ein @-Symbol).
Geben Sie für alle Datensätze in der Gruppe von gewichteten Datensätzen denselben Namen ein.
Weitere Informationen über Datensatznamen finden Sie unter [Datensatzname](resource-record-sets-values-alias-common.md#rrsets-values-common-alias-name).
## Datensatztyp
Der DNS-Datensatztyp. Weitere Informationen finden Sie unter [Unterstützte DNS-Datensatztypen](ResourceRecordTypes.md).
Wählen Sie den entsprechenden Wert basierend auf der AWS Ressource aus, an die Sie den Verkehr weiterleiten:
**Benutzerdefinierte regionale API-Gateway-API oder Edge-optimierte API**
Wählen Sie **A — IPv4 Adresse** aus.
**Amazon-VPC-Schnittstellenendpunkte**
Wählen Sie **A — IPv4 Adresse** aus.
**CloudFront Vertrieb**
Wählen Sie **A — IPv4 Adresse** aus.
Wenn für die Verteilung aktiviert IPv6 ist, erstellen Sie zwei Datensätze, einen mit dem Wert **A — IPv4 Adresse** für **Typ** und einen mit dem Wert **AAAA — IPv6 Adresse**.
**App-Runner-Dienst**
Wählen Sie **A — Adresse IPv4 **
**Elastic-Beanstalk-Umgebung, die über regionale Subdomänen verfügt**
Wählen Sie **A — IPv4 Adresse**
**ELB-Load Balancer**
Wählen **Sie IPv4 A-Adresse** oder **AAAA-Adresse IPv6 **
**Amazon-S3-Bucket**
Wählen Sie **A — Adresse IPv4 **
**OpenSearch Dienst**
Wählen Sie **A — IPv4 Adresse** oder **AAAA — IPv6 ** Adresse
**Weiterer Datensatz in dieser gehosteten Zone**
Wählen Sie den Typ des Datensatzes aus, für den Sie den Alias erstellen. Es werden alle Typen außer **NS** und **SOA** unterstützt.
Wenn Sie einen Aliasdatensatz mit demselben Namen wie die gehostete Zone (*Zonen-Apex*) erstellen, können Sie den Datenverkehr nicht zu einem Datensatz weiterleiten, dessen Wert in **Type (Typ)** **CNAME** ist. Der Grund hierfür ist, dass der Aliasdatensatz denselben Typ wie der Datensatz haben muss, zu dem Sie den Datenverkehr weiterleiten, und die Erstellung eines CNAME-Datensatzes für den Zonen-Apex wird für einen Aliasdatensatz nicht unterstützt.
Wählen Sie für alle Datensätze in der Gruppe von gewichteten Datensätzen denselben Namen aus.
## Bewerten/Weiterleiten des Datenverkehrs an
Der Wert, den Sie aus der Liste auswählen oder den Sie in das Feld eingeben, hängt von der AWS Ressource ab, an die Sie den Verkehr weiterleiten.
Informationen darüber, auf welche AWS Ressourcen Sie abzielen können, finden Sie unter [Allgemeine Werte für Aliasdatensätze für den value/route Datenverkehr](resource-record-sets-values-alias-common.md#rrsets-values-alias-common-target).
Weitere Informationen zur Konfiguration von Route 53 zur Weiterleitung von Datenverkehr an bestimmte AWS Ressourcen finden Sie unter[Weiterleitung des Internetverkehrs zu Ihren AWS Ressourcen](routing-to-aws-resources.md).
## Gewicht
Ein Wert, der das Verhältnis von DNS-Abfragen, auf die Route 53 antwortet, anhand des aktuellen Datensatzes bestimmt. Route 53 berechnet die Summe der Gewichtungen für die Datensätze, die dieselbe Kombination von DNS-Namen und -Typ aufweisen. Route 53 beantwortet dann Abfragen, die auf dem Verhältnis der Gewichtung einer Ressource zur Gesamtmenge basieren.
Sie können keine nicht gewichteten Datensätze erstellen, die über dieselben Werte wie gewichtete Datensätze für **Datensatzname** und **Datensatztyp** verfügen.
Geben Sie eine Ganzzahl zwischen 0 und 255 ein. Zum Deaktivieren der Weiterleitung an eine Ressource setzen Sie für **Weight (Gewichtung)** den Wert 0 fest. Wenn Sie **Weight (Gewichtung)** für alle Datensätze in der Gruppe auf 0 setzen, wird der Datenverkehr mit gleicher Wahrscheinlichkeit zu allen Ressourcen weitergeleitet. Auf diese Weise wird verhindert, dass Sie die Weiterleitung für eine Gruppe von gewichteten Datensätzen versehentlich deaktivieren.
Wenn Sie Zustandsprüfungen mit gewichteten Datensätzen verknüpfen und **Weight (Gewichtung)** auf 0 setzen, unterscheidet sich das Resultat. Weitere Informationen finden Sie unter [So wählt Amazon Route 53 Datensätze, wenn Zustandsprüfungen konfiguriert sindSo wählt Route 53 Datensätze, wenn Zustandsprüfungen konfiguriert sind](health-checks-how-route-53-chooses-records.md).
## Gesundheitscheck
Wählen Sie eine Zustandsprüfung aus, wenn Route 53 den Status eines angegebenen Endpunkts überprüfen und DNS-Abfragen mit diesem Eintrag nur beantworten soll, wenn der Endpunkt fehlerfrei ist.
Route 53 prüft den Zustand des im Datensatz angegebenen Endpunkts nicht, z. B. des durch die IP-Adresse im Feld **Wert** definierten Endpunkts. Wenn Sie eine Zustandsprüfung für einen Datensatz auswählen, überprüft Route 53 den Zustand des Endpunkts, den Sie in der Zustandsprüfung angegeben haben. Informationen dazu, wie Route 53 ermittelt, ob ein Endpunkt fehlerfrei ist, finden Sie unter [So ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei istSo ermittelt Amazon Route 53, ob eine Zustandsprüfung fehlerfrei ist](dns-failover-determining-health-of-endpoints.md).
Die Verknüpfung einer Zustandsprüfung mit einem Datensatz ist nur nützlich, wenn Route 53 zwischen mindestens zwei Datensätzen auswählt, um auf eine DNS-Abfrage zu antworten, und Route 53 die Auswahl zum Teil anhand des Status einer Zustandsprüfung treffen soll. Verwenden Sie Zustandsprüfungen nur in den folgenden Konfigurationen:
+ Sie überprüfen den Zustand aller Datensätze in einer Gruppe von Datensätzen, die denselben Namen, denselben Typ und dieselbe Routing-Richtlinie haben (z. B. Failover oder gewichtete Datensätze), und Sie geben eine Integritätsprüfung IDs für alle Datensätze an. Wenn die Zustandsprüfung für einen Datensatz einen Endpunkt angibt, der nicht fehlerfrei ist, antwortet Route 53 nicht mehr auf Abfragen, die den Wert für diesen Datensatz verwenden.
+ Sie wählen **Yes** (Ja) für **Evaluate Target Health** (Zustand des Ziels bewerten) für einen Alias-Datensatz oder die Datensätze in einer Gruppe aus Failover-Alias-, Geolocation-Alias-, Latenz-Alias-, IP-basierten Alias- oder gewichteten Alias-Datensätzen aus. Wenn die Alias-Datensätze andere als Alias-Datensätze in derselben gehosteten Zone referenzieren, müssen Sie auch Zustandsprüfungen für die referenzierten Datensätze angeben. Wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen und **Yes** (Ja) für **Evaluate Target Health** (Zustand des Ziels bewerten) auswählen, müssen beide mit „True“ ausgewertet werden. Weitere Informationen finden Sie unter [Was geschieht, wenn Sie eine Zustandsprüfung mit einem Aliasdatensatz verknüpfen?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
Wenn Ihre Zustandsprüfungen den Endpunkt nur nach Domainname angeben, sollten Sie für jeden Endpunkt eine eigene Zustandsprüfung erstellen. Sie sollten beispielsweise eine Zustandsprüfung für jeden HTTP-Server erstellen, der Inhalte für www.example.com bereitstellt. Sie müssen in **Domain Name (Domänenname)** als Wert den Domänennamen des Servers angeben (z. B. us-east-2-www.example.com), nicht den Namen der Datensätze (example.com).
**Wichtig**
Wenn Sie in dieser Konfiguration eine Zustandsprüfung erstellen, für die der Wert von **Domain name** dem Namen des Datensatzes entspricht, und anschließend die Zustandsprüfung mit diesen Datensätzen verknüpfen, sind die Ergebnisse der Zustandsprüfung unvorhersehbar.
## Evaluate Target Health
Wählen Sie **Ja** aus, wenn Route 53 ermitteln soll, ob auf DNS-Abfragen, die diesen Datensatz verwenden, geantwortet werden soll, indem der Zustand der in **Endpunkt** angegebenen Ressource geprüft wird.
Beachten Sie Folgendes:
**API Gateway, kundenspezifisch, regional APIs und Edge-optimiert APIs**
Es gibt keine besonderen Anforderungen für das Festlegen von **Evaluate target health (Zielzustand bewerten)** auf **Yes (Ja)**, wenn der Endpunkt eine benutzerdefinierte regionale API-Gateway-API oder eine Edge-optimierte API ist.
**CloudFront Verteilungen**
Sie können die Option **Zielintegrität bewerten** nicht auf **Ja setzen, wenn es** sich bei dem Endpunkt um eine CloudFront Verteilung handelt.
**Elastic Beanstalk-Umgebungen, die über regionale Subdomänen verfügen**
Wenn Sie in **Endpunkt** eine Elastic-Beanstalk-Umgebung angeben und diese einen ELB-Load-Balancer enthält, leitet Elastic Load Balancing Abfragen nur an die fehlerfreien Amazon-EC2-Instances weiter, die beim Load Balancer registriert sind. (Eine Umgebung enthält automatisch einen ELB-Load Balancer, wenn sie mehr als eine Amazon EC2-Instance umfasst.) Wenn Sie **Zielzustand bewerten** auf **Ja** setzen und entweder keine fehlerfreien Amazon-EC2-Instances zur Verfügung stehen oder der Load Balancer selbst fehlerhaft ist, leitet Route 53 Abfragen an andere fehlerfreie Ressourcen weiter, sofern vorhanden.
Bei einer Umgebung, die nur eine einzelne Amazon EC2-Instance enthält, gibt es keine besonderen Anforderungen.
**ELB-Load Balancer**
Das Verhalten der Zustandsprüfung ist abhängig vom Typ des Load Balancers:
+ **Classic Load Balancer** – Wenn Sie in **Endpunkt** einen ELB-Classic-Load-Balancer angeben, leitet Elastic Load Balancing Abfragen nur an die fehlerfreien Amazon-EC2-Instances weiter, die beim Load Balancer registriert sind. Wenn Sie **Zielzustand bewerten** auf **Ja** festlegen und es entweder keine fehlerfreien EC2-Instances gibt oder der Load Balancer selbst fehlerhaft ist, leitet Route 53 Abfragen an andere Ressourcen weiter.
+ **Anwendung und Network Load Balancer** – Wenn Sie eine ELB-Anwendung oder einen Network Load Balancer angeben und **Zielzustand bewerten** auf **Ja** festlegen, leitet Route 53 Abfragen basierend auf dem Zustand der mit dem Load Balancer verknüpften Zielgruppen an den Load Balancer weiter:
+ Damit ein Application oder Network Load Balancer als fehlerfrei gilt, muss jede Zielgruppe mit Zielen mindestens ein fehlerfreies Ziel enthalten. Falls eine Zielgruppe nur fehlerhafte Ziele enthält, gilt der Load Balancer als fehlerhaft und Route 53 leitet Abfragen an andere Ressourcen weiter.
+ Eine Zielgruppe ohne registrierte Ziele gilt als fehlerhaft.
Beim Erstellen eines Load Balancers konfigurieren Sie Einstellungen für Elastic Load Balancing-Zustandsprüfungen. Dies sind keine Route 53-Zustandsprüfungen. Sie erfüllen aber eine ähnliche Funktion. Erstellen Sie keine Route 53-Zustandsprüfungen für die EC2-Instances, die Sie bei einem ELB-Load Balancer registrieren.
**S3-Buckets**
Es gibt keine speziellen Anforderungen, nach denen **Evaluate Target Health (Zielzustand bewerten)** auf **Yes (Ja)** festgelegt werden muss, wenn es sich beim Endpunkt um einen S3-Bucket handelt.
**Amazon-VPC-Schnittstellenendpunkte**
Es gibt keine besonderen Anforderungen für das Festlegen der **Zielzustand bewerten** auf **Ja**, wenn der Endpunkt ein Amazon-VPC-Schnittstellenendpunkt ist.
**Andere Datensätze innerhalb derselben gehosteten Zone**
Wenn es sich bei der AWS Ressource, die Sie in **Endpoint** angeben, um einen Datensatz oder eine Gruppe von Datensätzen handelt (z. B. um eine Gruppe gewichteter Datensätze), es sich jedoch nicht um einen weiteren Aliasdatensatz handelt, empfehlen wir, allen Datensätzen im Endpunkt eine Integritätsprüfung zuzuordnen. Weitere Informationen finden Sie unter [Was geschieht, wenn Sie Zustandsprüfungen überspringen?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting).
## Datensatz-ID
Geben Sie einen Wert ein, der diesen Datensatz in der Gruppe von gewichteten Datensätzen eindeutig identifiziert.
# Erstellen von Datensätzen durch Importieren einer Zonendatei
Wenn Sie eine Migration von einem anderen DNS-Serviceanbieter durchführen und dieser DNS-Serviceanbieter Sie die aktuellen DNS-Einstellungen in eine Zonendatei exportieren lässt, können Sie schnell alle Datensätze für eine gehostete Amazon-Route-53-Zone erstellen, indem Sie eine Zonendatei importieren.
**Anmerkung**
Eine Zonendatei verwendet ein Standardformat namens BIND zur Darstellung von Datensätzen in einem Textformat. Informationen zum Format einer Zonendatei finden Sie im Wikipedia-Eintrag [Zonendatei](https://en.wikipedia.org/wiki/Zone_file). Weitere Informationen finden Sie in Abschnitt 3.6.1 von [RFC 1034, Domain Names—Concepts and Facilities](https://datatracker.ietf.org/doc/html/rfc1034) und in Abschnitt 5 von [RFC 1035, Domain Names—Implementation and Specification](https://datatracker.ietf.org/doc/html/rfc1035).
Beachten Sie Folgendes, wenn Sie Datensätze durch Importieren einer Zonendatei erstellen möchten:
+ Die Zonendatei muss in einem RFC-konformen Format sein.
+ Der Domainname jedes Datensatzes in einer gehosteten Zone muss mit dem Namen der gehosteten Zone enden.
+ Route 53 unterstützt die `$ORIGIN`- und `$TTL`-Schlüsselwörter. Wenn die Zonendatei `$GENERATE` oder `$INCLUDE`-Schlüsselwörter enthält, schlägt der Import fehl und Route 53 gibt einen Fehler zurück.
+ Wenn Sie die Zonendatei importieren, ignoriert Route 53 den SOA-Datensatz in der Zonendatei. Route 53 ignoriert auch alle NS-Datensätze, die denselben Namen haben wie die gehostete Zone.
+ Sie können maximal 1000 Datensätze importieren.
+ Wenn die gehostete Zone bereits Datensätze enthält, die in der Zonendatei angezeigt werden, schlägt der Importvorgang fehl und es werden keine Datensätze erstellt.
+ Bei TXT-Datensätzen, die Backslash-Zeichen enthalten, interpretiert der Import der Zonendatei bestimmte Backslash-Sequenzen als Steuerzeichen. Um wörtliche Backslash-Zeichen in TXT-Datensatzwerte aufzunehmen:
+ Verwenden Sie doppelte Backslashes (`\\\\`) in der Zonendatei, um einen einzelnen buchstäblichen Backslash im endgültigen TXT-Datensatz darzustellen.
+ Wenn Ihr TXT-Eintrag beispielsweise `\\jYTDWqH...` (mit einem buchstäblichen Backslash und j) enthalten soll, geben Sie dies in der Zonendatei an. `\\\\jYTDWqH...`
Dies ist besonders wichtig für ACME-Challenge-Datensätze und andere TXT-Datensätze, die buchstäbliche Backslash-Zeichen enthalten.
+ Bei langen TXT-Datensätzen (wie DKIM-Datensätzen) unterstützt der Importvorgang für Zonendateien die Aufteilung des Inhalts in mehrere Zeichenfolgen. Um TXT-Einträge mit mehreren Zeichenketten zu erstellen:
+ Verwenden Sie separate Zeilen in Ihrer Zonendatei mit demselben Datensatznamen und -typ.
**Example**
```
example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC"
example.com. 300 IN TXT "7fCC6C13dM9tXuJmUBH7D4Vw8y1ByJ8z9QX2fvLm3pN4sR5tU6vW7xY8zA9bC0dE1f"
example.com. 300 IN TXT "G2hI3jK4lM5nO6pQ7rS8tU9vW0xY1zA2bC3dE4fG5hI6jK7lM8nO9pQ0rS1tU2vW3x"
```
Der Importvorgang kombiniert diese automatisch zu einem einzigen TXT-Datensatz mit mehreren Zeichenfolgen. Jede einzelne Zeichenfolge kann bis zu 65.535 Zeichen enthalten. Verketten Sie lange Zeichenketten nicht zu einem einzigen Wert in Anführungszeichen.
+ Wir empfehlen, dass Sie den Inhalt der Zonendatei überprüfen, um zu bestätigen, dass Datensatznamen gegebenenfalls einen abschließenden Punkt enthalten oder ausschließen:
+ Wenn der Name eines Datensatzes in der Zonendatei einen abschließenden Punkt enthält (`example.com.`), interpretiert der Importprozess den Namen als voll qualifizierten Domainnamen und erstellt einen Route-53-Datensatz mit diesem Namen.
+ Wenn der Name eines Datensatz in der Zonendatei keinen abschließenden Punkt enthält (`www`), verbindet der Importprozess diesen Namen mit dem Domainnamen in der Zonendatei (`example.com`) und erstellt einen Route-53-Datensatz mit diesem zusammengefügten Namen (`www.example.com`).
Wenn der Exportprozess keinen abschließenden Punkt zu den vollqualifizierten Domainnamen eines Datensatzes hinzufügt, fügt der Route-53-Importprozess den Domainnamen zum Namen des Datensatzes hinzu. Nehmen wir beispielsweise an, dass Sie Datensätze in die gehostete Zone `example.com` importieren und der Name eines MX-Datensatzes in dieser Zonendatei `mail.example.com` (ohne abschließenden Punkt) ist. Der Route-53-Importprozess erstellt einen MX-Datensatz mit dem Namen `mail.example.com.example.com`.
**Wichtig**
Für CNAME-, MX-, PTR- und SRV-Datensätze gilt dieses Verhalten auch für den Domainnamen, der im RDATA-Wert enthalten ist. Nehmen wir beispielsweise an, dass Sie eine Zonendatei für `example.com` haben. Wenn ein CNAME-Datensatz in der Zonendatei (`support`, ohne abschließenden Punkt) den RDATA-Wert `www.example.com` (auch ohne abschließenden Punkt) hat, erstellt der Importprozess einen Route-53-Datensatz mit dem Namen `support.example.com`, der Datenverkehr an `www.example.com.example.com` weiterleitet. Überprüfen Sie die RDATA-Werte und aktualisieren Sie sie entsprechend, bevor Sie Ihre Zonendatei importieren. Verwenden Sie bei TXT-Datensätzen, die Backslash-Zeichen enthalten, doppelte Backslashes (`\\\\`) in der Zonendatei, um wörtliche Backslashes darzustellen.
Route 53 unterstützt das Exportieren von Datensätzen in eine Zonendatei nicht.
**Anmerkung**
Wenn Sie einen Datensatz erstellen, der denselben Namen wie die gehostete Zone hat, geben Sie im Feld Name keinen Wert ein (zum Beispiel ein @-Symbol).
**So erstellen Sie Datensätze durch den Import einer Zonendatei:**
1. Sichern Sie sich eine Zonendatei vom DNS-Serviceanbieter, der aktuell den Service für die Domain bereitstellt. Der Prozess und die Terminologie unterscheiden sich von einem Anbieter zum nächsten. Sehen Sie sich die Schnittstelle und Dokumentation Ihres Anbieters an, um Informationen zum Exportieren und Speichern Ihrer Datensätze in einer Zonendatei oder BIND-Datei zu erhalten.
Wenn der Prozess komplizierter ist, bitten Sie den Kundendienst Ihres aktuellen DNS-Anbieters um Ihre *Datensatzliste* oder *Zonendatei*-Informationen.
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. Klicken Sie im Navigationsbereich auf **Hosted Zones (Gehostete Zonen)**.
1. Erstellen Sie auf der Seite **Hosted Zones (Gehostete Zonen)** eine neue gehostete Zone:
1. Wählen Sie **Create hosted zone (Erstellte gehostete Zone)**.
1. Geben Sie den Namen Ihrer Domain und optional eine Anmerkung ein.
1. Wählen Sie **Erstellen** aus.
1. Wählen Sie **Import Zone File (Zonendatei importieren)**.
1. Fügen Sie im Bereich **Import Zone File (Zonen-Datei importieren)** die Inhalte Ihrer Zonendatei in das Textfeld **Zone File (Zonendatei)** ein.
1. Wählen Sie **Importieren** aus.
**Anmerkung**
Abhängig von der Anzahl der Datensätze in Ihrer Zonendatei müssen Sie möglicherweise einige Minuten warten, bis die Datensätze erstellt sind.
1. Wenn Sie einen anderen DNS-Service für die Domain verwenden (was üblich ist, wenn Sie Ihre Domain bei einer anderen Vergabestelle registriert haben), können Sie den DNS-Service zu Route 53 migrieren. Wenn dieser Schritt abgeschlossen ist, erkennt Ihre Vergabestelle Route 53 als Ihren DNS-Service bei DNS-Abfragen für Ihre Domain und die Abfragen werden an Route-53-DNS-Server gesendet. (In der Regel dauert es ein oder zwei Tage, bis DNS-Abfragen zu Route 53 geleitet werden, weil die Informationen zu Ihrem vorherigen DNS-Service so lange im Cache von DNS-Resolvern abgelegt sind.) Weitere Informationen finden Sie unter [Amazon Route 53 zum DNS-Dienst für eine vorhandene Domäne machenRoute 53 zum DNS-Dienst für eine vorhandene Domäne machen](MigratingDNS.md).
# Bearbeiten von Datensätzen
Im folgenden Verfahren wird das Bearbeiten von Datensätzen mit der Amazon-Route-53-Konsole erläutert. Informationen zum Bearbeiten von Datensätzen mithilfe der Route 53-API finden Sie [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)in der *Amazon Route 53-API-Referenz*.
**Anmerkung**
Die Verteilung der Änderungen an Ihren neuen Datensätzen auf die Route 53-DNS-Server nimmt etwas Zeit in Anspruch. Derzeit besteht die einzige Möglichkeit, um zu überprüfen, ob Änderungen weitergegeben wurden, darin, die [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API-Aktion zu verwenden. Änderungen werden im Allgemeinen innerhalb von 60 Sekunden an alle Route 53-Name-Server übertragen.
**So bearbeiten Sie Datensätze mithilfe der Route-53-Konsole:**
1. Wenn Sie keine Alias-Datensätze bearbeiten, fahren Sie mit Schritt 2 fort.
Wenn Sie Alias-Datensätze bearbeiten, die Datenverkehr an einen Classic Load Balancer mit Elastic Load Balancing, an einen Application Load Balancer oder an einen Network Load Balancer weiterleiten, und Sie Ihre gehostete Route-53-Zone und Ihren Load Balancer mit verschiedenen Konten erstellt haben, befolgen Sie die Schritte im Verfahren [Abrufen des DNS-Namens für einen Elastic Load Balancing Load Balancer](resource-record-sets-creating.md#resource-record-sets-elb-dns-name-procedure), um den DNS-Namen für den Load Balancer abzurufen.
Wenn Sie Aliaseinträge für eine andere AWS Ressource bearbeiten, fahren Sie mit Schritt 2 fort.
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Klicken Sie im Navigationsbereich auf **Hosted Zones (Gehostete Zonen)**.
1. Wählen Sie auf der Seite **Hosted Zones (Gehostete Zonen)** die Zeile der gehosteten Zone, die die zu löschenden Datensätze enthält.
1. Wählen Sie die Zeile für den Datensatz aus, den Sie bearbeiten möchten und geben Sie Ihre Änderungen im Bereich **Edit record (Bearbeiten von Datensätzen)** ein.
1. Geben Sie die entsprechenden Werte ein. Weitere Informationen finden Sie unter [Werte, die Sie beim Erstellen oder Bearbeiten von Amazon Route 53-Datensätzen angeben](resource-record-sets-values.md).
1. Wählen Sie **Änderungen speichern ** aus.
1. Wenn Sie mehrere Datensätze bearbeiten, wiederholen Sie die Schritte 5 bis 7.
# Löschen von Datensätzen
Im folgenden Verfahren wird das Löschen von Datensätzen mit der Route-53-Konsole erläutert. Informationen zum Löschen von Datensätzen mithilfe der Route 53-API finden Sie [ChangeResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ChangeResourceRecordSets.html)in der *Amazon Route 53-API-Referenz*.
**Anmerkung**
Die Verteilung der Änderungen an Ihren neuen Datensätzen auf die Route 53-DNS-Server nimmt etwas Zeit in Anspruch. Derzeit besteht die einzige Möglichkeit, um zu überprüfen, ob Änderungen weitergegeben wurden, darin, die [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API-Aktion zu verwenden. Änderungen werden im Allgemeinen innerhalb von 60 Sekunden an alle Route 53-Name-Server übertragen.
**So löschen Sie Datensätze:**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Wählen Sie auf der Seite „Gehostete Zonen“ die Zeile der gehosteten Zone, die die zu löschenden Datensätze enthält.
1. Wählen Sie in der Liste der Datensatzsätze den Datensatz aus, den Sie löschen möchten.
Um mehrere aufeinander folgende Datensätze auszuwählen, wählen Sie die erste Zeile, halten Sie die **Umschalttaste** gedrückt und klicken Sie dann auf die letzte Zeile. Um mehrere nicht aufeinanderfolgende Datensätze auszuwählen, wählen Sie die erste Zeile, halten Sie die **Steuerungstaste** gedrückt und wählen Sie dann weitere Zeilen.
Sie können keine Datensätze löschen, die über einen Wert von **NS** oder **SOA** für **Type (Typ)** verfügen.
1. Wählen Sie **Löschen** aus.
1. Wählen Sie **Löschen**, um das Dialogfeld zu schließen.
# Auflisten von Datensätzen
Im folgenden Verfahren wird das Auflisten der Datensätze in einer gehosteten Zone mithilfe der Amazon-Route-53-Konsole erläutert. Informationen zum Auflisten von Datensätzen mithilfe der Route 53-API finden Sie [ListResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListResourceRecordSets.html)in der *Amazon Route 53-API-Referenz*.
**So listen Sie Datensätze auf:**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Klicken Sie im Navigationsbereich auf **Hosted Zones (Gehostete Zonen)**.
1. Wählen Sie auf der Seite **Hosted Zones (Gehostete Zonen)** den Namen der gehosteten Zone aus.
1. Um den Suchmodus zu ändern, wählen Sie das Zahnradsymbol oben rechts in der Tabelle **Datensätze**. Wählen Sie eine der folgenden Optionen:
+ **Automatisch**
In diesem Modus verwendet der Service einen Filter auf der Grundlage einer Anzahl von Datensätzen. Voll bei weniger als 2 000 und schnell bei mehr als 2 000 Datensätzen.
+ **Voll**
In diesem Modus sind alle Suchfilter verfügbar, aber die Suchleistung kann langsamer sein.
+ **Schnell**
In diesem Modus sind einige erweiterte Features nicht verfügbar, aber die Suchleistung ist schneller.
Um nur ausgewählte Datensätze anzuzeigen, geben Sie die entsprechenden Suchkriterien über der Liste der Datensätze ein. Im automatischen Modus hängt das Suchverhalten davon ab, ob die gehostete Zone bis zu 2 000 Datensätze oder mehr als 2 000 Datensätze enthält:
**Bis zu 2 000 Datensätze und Vollmodus**
+ Um die Datensätze mit bestimmten Werten anzuzeigen, geben Sie einen Wert in die Suchleiste ein und drücken Sie die **Eingabetaste**. Wenn Sie beispielsweise die Datensätze anzeigen möchten, die eine IP-Adresse haben, die mit **192.0** beginnt, geben Sie diesen Wert in das Feld **Search (Suche)** ein, und drücken Sie **Enter (Eingabetaste)**.
+ Um nur die Datensätze anzuzeigen, die denselben DNS-Datensatztyp aufweisen, wählen Sie **Datensatztyp** in der Dropdown-Liste und geben Sie den Datensatztyp ein.
+ Um nur Alias-Datensätze anzuzeigen, wählen Sie **Aliasnamen** in der Dropdown-Liste und geben Sie **Yes** ein.
+ Um nur gewichtete Datensätze anzuzeigen, wählen Sie **Routing-Richtlinie** in der Dropdown-Liste und geben Sie **WEIGHTED** ein.
**Mehr als 2 000 Datensätze und Schnellmodus**
+ Sie können nun nach Datensatznamen, nicht nach Datensatzwerten suchen lassen. Es ist auch nicht möglich, die Datensätze nach Typ oder nach Alias- oder gewichteten Datensätzen zu filtern.
Platzieren Sie dazu den Cursor im Textfeld **Filter** und wählen Sie **Eigenschaften** > **Datensatzname** aus.
+ Für Datensätze mit drei Bezeichnungen (drei durch Punkte voneinander getrennten Teilen) gilt: Wenn Sie einen Wert in das Suchfeld eingeben und die **Eingabetaste** drücken, führt die Route-53-Konsole automatisch eine Platzhaltersuche für die dritte Bezeichnung von rechts im Datensatznamen durch. Nehmen wir beispielsweise an, die gehostete Zone example.com enthält 100 Datensätze mit der Bezeichnung record1.example.com bis record100.example.com. (Record1 ist die dritte Bezeichnung von rechts.) Dies geschieht, wenn Sie eine Suche nach den folgenden Werten durchführen:
+ **record1** – Die Route-53-Konsole sucht nach **record1\$1.example.com**, wobei **record1.example.com**, **record10.example.com** bis **record19.example.com** und **record100.example.com** zurückgegeben werden.
+ **record1.example.com** – Wie im vorherigen Beispiel sucht die Konsole nach **record1\$1.example.com** und es werden die gleichen Datensätze zurückgegeben.
+ **1** – Die Konsole sucht nach **1\$1.example.com** und es werden keine Datensätze zurückgegeben.
+ **example** – Die Konsole sucht nach **example\$1.example.com** und es werden keine Datensätze zurückgegeben.
+ **example.com** – In diesem Beispiel führt die Konsole keine Platzhaltersuche durch. Es werden alle Datensätze in der gehosteten Zone zurückgegeben.
+ **Automatischer Suchmodus**: Bei Verwendung dieses Suchmodus müssen Sie zuerst eine Eigenschaft wie etwa den Datensatznamen angeben, um suchen zu können.
**Anmerkung**
Wenn die dritte Bezeichnung von rechts mindestens einen Bindestrich enthält (z. B. `third-label.example.com`) und Sie nach dem Teil der dritten Bezeichnung unmittelbar vor dem Bindestrich suchen (`third` in diesem Beispiel), gibt Route 53 keine Datensätze zurück. Stattdessen sollten Sie entweder den Bindestrich einschließen (nach `third-` suchen) oder das Zeichen unmittelbar vor dem Bindestrich weglassen (nach `third` suchen).
+ Bei Datensätzen, die vier oder mehr Bezeichnungen haben, müssen Sie den genauen Namen des Datensatzes angeben. Platzhaltersuchen werden nicht unterstützt. Wenn z. B. die gehostete Zone einen Datensatz mit dem Namen label4.record1.example.com enthält, finden Sie diesen Datensatz nur dann, wenn Sie **label4.record1.example.com** in das Suchfeld eingeben.
# Konfigurieren der DNSSEC-Signatur in Amazon Route 53
DNSSEC-Signatur (Domain Name System Security Extensions) ermöglicht DNS-Resolvern zu überprüfen, ob eine DNS-Antwort von Amazon Route 53 stammt und nicht manipuliert wurde. Wenn Sie die DNSSEC-Signatur verwenden, wird jede Antwort für eine gehostete Zone mithilfe der Kryptografie mit öffentlichen Schlüsseln signiert. Einen Überblick über DNSSEC finden Sie im Abschnitt DNSSEC von [AWS re:Invent 2021 — Amazon Route 53](https://www.youtube.com/watch?v=77V23phAaAE): Ein Jahr im Rückblick.
In diesem Kapitel erklären wir, wie Sie die DNSSEC-Signatur für Route 53 aktivieren, wie Sie mit Schlüsselsignaturschlüsseln () arbeiten und wie Sie Probleme beheben können. KSKs Sie können mit der DNSSEC-Signatur in der oder programmgesteuert mit der AWS-Managementkonsole API arbeiten. Weitere Informationen zur Verwendung der CLI oder SDKs zur Arbeit mit Route 53 finden Sie unter[Amazon Route 53 einrichten](setting-up-route-53.md).
Bevor Sie DNSSEC-Signatur aktivieren, beachten Sie Folgendes:
+ Um einen Zonenausfall zu verhindern und Probleme mit der Nichtverfügbarkeit Ihrer Domäne zu vermeiden, müssen Sie DNSSEC-Fehler schnell beheben und beheben. Es wird dringend empfohlen, einen CloudWatch Alarm einzurichten, der Sie benachrichtigt, wenn ein `DNSSECInternalFailure` `DNSSECKeySigningKeysNeedingAction` Oder-Fehler erkannt wird. Weitere Informationen finden Sie unter [Überwachung von Hosting-Zonen mit Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md).
+ Es gibt zwei Arten von Schlüsseln in DNSSEC: einen Schlüssel-Signaturschlüssel (KSK) und einen Zonen-Signaturschlüssel (ZSK). Bei der DNSSEC-Signierung von Route 53 basiert jede KSK auf einem[Asymmetrische kundenverwaltete Schlüssel](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#asymmetric-keys-concept)in AWS KMS dass Sie besitzen. Sie sind für das Management von KSK verantwortlich, was bei Bedarf auch das Drehen beinhaltet. Das ZSK-Management wird von der Route 53 durchgeführt.
+ Wenn Sie DNSSEC-Signierung für eine gehostete Zone aktivieren, begrenzt Route 53 die TTL auf eine Woche. Wenn Sie eine TTL von mehr als einer Woche für Datensätze in der gehosteten Zone festlegen, wird keine Fehlermeldung angezeigt. Route 53 erzwingt jedoch eine TTL von einer Woche für die Datensätze. Datensätze mit einer TTL von weniger als einer Woche und Datensätze in anderen gehosteten Zonen, für die keine DNSSEC-Signatur aktiviert ist, sind nicht betroffen.
+ Wenn Sie DNSSEC-Signatur verwenden, werden Konfigurationen verschiedener Anbieter nicht unterstützt. Wenn Sie White-Label-Nameserver (auch bekannt als Vanity-Nameserver oder Private-Nameserver) konfiguriert haben, stellen Sie sicher, dass diese Nameserver von einem einzigen DNS-Anbieter bereitgestellt werden.
+ Einige DNS-Anbieter unterstützen keine Delegation Signer (DS) -Einträge in ihrem autorisierenden DNS. Wenn Ihre übergeordnete Zone von einem DNS-Anbieter gehostet wird, der keine DS-Abfragen unterstützt (kein AA-Flag in der DS-Abfrageantwort setzt), kann die untergeordnete Zone nicht mehr aufgelöst werden, wenn Sie DNSSEC in seiner untergeordneten Zone aktivieren. Stellen Sie sicher, dass Ihr DNS-Anbieter DS-Einträge unterstützt.
+ Es kann hilfreich sein, IAM-Berechtigungen einzurichten, damit ein anderer Benutzer neben dem Zonenbesitzer Datensätze in der Zone hinzufügen oder entfernen kann. Ein Zonenbesitzer kann beispielsweise eine KSK hinzufügen und die Signatur aktivieren und möglicherweise auch für die Schlüsselrotation verantwortlich sein. Möglicherweise ist eine andere Person jedoch für die Arbeit mit anderen Datensätzen für die gehostete Zone verantwortlich. Eine IAM-Beispielrichtlinie finden Sie unter [Beispielberechtigungen für einen Domänendatensatzbesitzer](access-control-managing-permissions.md#example-permissions-record-owner).
+ Informationen darüber, ob die TLD DNSSEC-Unterstützung bietet, finden Sie unter. [Domains, die Sie mit Amazon Route 53 registrieren können](registrar-tld-list.md)
**Topics**
+ [Aktivieren der DNSSEC-Signierung und Aufbau einer Vertrauenskette](dns-configuring-dnssec-enable-signing.md)
+ [Deaktivieren der DNSSEC-Signatur](dns-configuring-dnssec-disable.md)
+ [Arbeiten mit vom Kunden verwalteten Schlüsseln für DNSSEC](dns-configuring-dnssec-cmk-requirements.md)
+ [Arbeiten mit Schlüsseln zur Schlüsselsignierung () KSKs](dns-configuring-dnssec-ksk.md)
+ [KMS-Schlüssel- und ZSK-Verwaltung in Route 53](dns-configuring-dnssec-zsk-management.md)
+ [DNSSEC-Nachweise für Nichtvorhandensein in Route 53](dns-configuring-dnssec-proof-of-nonexistence.md)
+ [Fehlerbehebung für DNSSEC](dns-configuring-dnssec-troubleshoot.md)
# Aktivieren der DNSSEC-Signierung und Aufbau einer Vertrauenskette
****
Die inkrementellen Schritte gelten für den Besitzer der gehosteten Zone und den übergeordneten Zonenbetreuer. Dies kann dieselbe Person sein, aber falls nicht, sollte der Zonenbesitzer den übergeordneten Zonenbetreuer benachrichtigen und mit ihm arbeiten.
Wir empfehlen, die Schritte in diesem Artikel zu befolgen, damit Ihre Zone signiert und in die Vertrauenskette aufgenommen wird. Die folgenden Schritte minimieren das Risiko des Onboardings auf DNSSEC.
**Anmerkung**
Stellen Sie sicher, dass Sie die Voraussetzungen lesen, bevor Sie in [Konfigurieren der DNSSEC-Signatur in Amazon Route 53](dns-configuring-dnssec.md) beginnen.
Es müssen drei Schritte durchgeführt werden, um die DNSSEC-Signatur zu aktivieren, indem Sie wie in den folgenden Abschnitten beschrieben vorgehen.
**Topics**
+ [Schritt 1: Vorbereiten der Aktivierung der DNSSEC-Signatur](#dns-configuring-dnssec-enable-signing-step-1)
+ [Schritt 2: Aktivieren der DNSSEC-Signatur und Erstellen einer KSK](#dns-configuring-dnssec-enable)
+ [Schritt 3: Erstellen einer Vertrauenskette](#dns-configuring-dnssec-chain-of-trust)
## Schritt 1: Vorbereiten der Aktivierung der DNSSEC-Signatur
Die Vorbereitungsschritte helfen Ihnen, das Risiko eines Onboardings bei DNSSEC zu minimieren, indem Sie die Zonenverfügbarkeit überwachen und die Wartezeiten zwischen dem Aktivieren der Signierung und dem Einfügen des Delegation Signer (DS)-Datensatzes senken.
**So bereiten Sie sich auf das Aktivieren der DNSSEC-Signierung vor**
1. Überwachen Sie die Verfügbarkeit der Zone.
Sie können die Zone auf die Verfügbarkeit Ihrer Domänennamen überwachen. Dies kann Ihnen helfen, alle Probleme zu beheben, die einen Schritt zurücksetzen könnten, nachdem Sie die DNSSEC-Signatur aktiviert haben. Sie können Ihre Domänennamen mit dem größten Datenverkehr überwachen, indem Sie die Abfrageprotokollierung verwenden. Für weitere Informationen zum Einrichten einer Abfrage-Protokollierung siehe [Amazon Route 53 überwachen](monitoring-overview.md).
Die Überwachung kann über ein Shell-Skript oder über einen Drittanbieterdienst erfolgen. Dies sollte jedoch nicht das einzige Signal sein, um festzustellen, ob ein Rollback erforderlich ist. Möglicherweise erhalten Sie auch Feedback von Ihren Kunden, da eine Domäne nicht verfügbar ist.
1. Senken Sie die maximale TTL der Zone.
Die maximale TTL der Zone ist der längste TTL-Datensatz in der Zone. In der folgenden Beispielzone beträgt die maximale TTL der Zone 1 Tag (86 400 Sekunden).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html)
Die Senkung der maximalen TTL der Zone trägt dazu bei, die Wartezeit zwischen dem Aktivieren der Signatur und dem Einfügen des Delegation Signer (DS)-Datensatzes zu verkürzen. Wir empfehlen, die maximale TTL der Zone auf eine Stunde (3 600 Sekunden) zu senken. Auf diese Weise können Sie sie nach nur einer Stunde zurücksetzen, wenn ein Resolver Probleme beim Zwischenspeichern signierter Datensätze hat.
**Rollback:** Machen Sie die TTL-Änderungen rückgängig.
1. Senken Sie das SOA-TTL- und SOA-Mindestfeld.
Das SOA-Mindestfeld ist das letzte Feld in den SOA-Datensatzdaten. Im folgenden SOA-Beispieldatensatz hat das Mindestfeld den Wert 5 Minuten (300 Sekunden).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html)
Das SOA-TTL- und SOA-Mindestfeld bestimmt, wie lange Resolver sich an negative Antworten erinnern. Nachdem Sie die Signierung aktiviert haben, geben die Nameserver der Route 53 NSEC-Datensätze für negative Antworten zurück. Die NSEC enthält Informationen, die Resolver verwenden könnten, um eine negative Antwort zu synthetisieren. Wenn Sie ein Rollback durchführen müssen, weil die NSEC-Informationen dazu geführt haben, dass ein Resolver eine negative Antwort für einen Namen annimmt, müssen Sie nur auf das Maximum des SOA-TTL- und SOA-Mindestfeldes warten, damit der Resolver die Annahme stoppt.
**Rollback:** Machen Sie die SOA-Änderungen rückgängig.
1. Stellen Sie sicher, dass die Änderungen an den Mindestfeldern TTL und SOA wirksam sind.
Verwenden Sie diese [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)Option, um sicherzustellen, dass Ihre bisherigen Änderungen an alle Route 53-DNS-Server weitergegeben wurden.
## Schritt 2: Aktivieren der DNSSEC-Signatur und Erstellen einer KSK
Sie können die DNSSEC-Signatur aktivieren und einen Schlüsselsignierungsschlüssel (KSK) erstellen, indem Sie AWS CLI oder die Route 53-Konsole verwenden.
+ [CLI](#dnssec_CLI)
+ [Konsole](#dnssec_console)
Wenn Sie einen KMS-Schlüssel bereitstellen oder erstellen, gibt es mehrere Anforderungen. Weitere Informationen finden Sie unter [Arbeiten mit vom Kunden verwalteten Schlüsseln für DNSSEC](dns-configuring-dnssec-cmk-requirements.md).
------
#### [ CLI ]
Sie können einen Schlüssel verwenden, den Sie bereits zur Verfügung haben, oder Sie erstellen einen, indem Sie einen AWS CLI -Befehl wie den folgenden mit eigenen Werten für `hostedzone_id`, `cmk_arn`, `ksk_name`, und `unique_string` (um die Anfrage eindeutig zu machen) verwenden:
```
aws --region us-east-1 route53 create-key-signing-key \
--hosted-zone-id $hostedzone_id \
--key-management-service-arn $cmk_arn --name $ksk_name \
--status ACTIVE \
--caller-reference $unique_string
```
Weitere Informationen zu den vom Kunden verwalteten Schlüsseln finden Sie unter [Arbeiten mit vom Kunden verwalteten Schlüsseln für DNSSEC](dns-configuring-dnssec-cmk-requirements.md). Siehe auch [CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html).
Um die DNSSEC-Signatur zu aktivieren, führen Sie einen AWS CLI Befehl wie den folgenden aus und verwenden Sie dabei Ihren eigenen Wert für: `hostedzone_id`
```
aws --region us-east-1 route53 enable-hosted-zone-dnssec \
--hosted-zone-id $hostedzone_id
```
[Weitere Informationen finden Sie unter [enable-hosted-zone-dnssec](https://docs.aws.amazon.com/cli/latest/reference/route53/enable-hosted-zone-dnssec.html)und EnableHostedZone DNSSEC.](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)
------
#### [ Console ]
**So aktivieren Sie die DNSSEC-Signatur und erstellen eine KSK**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. Wählen Sie im Navigationsbereich**Gehostete Zonen**Wählen Sie dann eine gehostete Zone aus, für die Sie die DNSSEC-Signatur aktivieren möchten.
1. Klicken Sie auf der**DNSSEC**Wählen Sie auf der Registerkarte**DNSSEC-Signatur aktivieren**aus.
**Anmerkung**
Wenn die Option in diesem Abschnitt**DNSSEC-Signatur deaktivieren**Der erste Schritt zur Aktivierung der DNSSEC-Signatur ist bereits abgeschlossen. Stellen Sie sicher, dass Sie eine Vertrauenskette für die gehostete Zone für DNSSEC einrichten oder bereits vorhanden sind, und Sie sind fertig. Weitere Informationen finden Sie unter [Schritt 3: Erstellen einer Vertrauenskette](#dns-configuring-dnssec-chain-of-trust).
1. Wählen Sie im Abschnitt **Schlüsselsignaturschlüsselerstellung (KSK)** **Create new KSK** (Neuen KSK erstellen), aus und geben Sie unter **Provide KSK name** (KSK-Namen angeben) einen Namen für den KSK ein, den Route 53 für Sie erstellen wird. Namen können nur Buchstaben, Zahlen und Unterstriche enthalten. Dieser Wert muss eindeutig sein.
1. UNDER**Kundenverwalteter CMK**den vom Kunden verwalteten Schlüssel für Route 53 aus, der beim Erstellen des KSK für Sie verwendet werden soll. Sie können einen vorhandenen vom Kunden verwalteten Schlüssel verwenden, der für die DNSSEC-Signatur gilt, oder einen neuen, vom Kunden verwalteten Schlüssel erstellen.
Wenn Sie einen vom Kunden verwalteten Schlüssel bereitstellen oder erstellen, gibt es mehrere Anforderungen. Weitere Informationen finden Sie unter [Arbeiten mit vom Kunden verwalteten Schlüsseln für DNSSEC](dns-configuring-dnssec-cmk-requirements.md).
1. Geben Sie den Alias für einen vorhandenen, vom Kunden verwalteten Schlüssel ein. Wenn Sie einen neuen vom Kunden verwalteten Schlüssel verwenden möchten, geben Sie einen Alias für einen vom Kunden verwalteten Schlüssel ein, und Route 53 erstellt einen für Sie.
**Anmerkung**
Wenn Sie sich dafür entscheiden, dass Route 53 einen vom Kunden verwalteten Schlüssel erstellt, beachten Sie, dass für jeden vom Kunden verwalteten Schlüssel separate Gebühren anfallen. Weitere Informationen finden Sie unter [AWS Key Management Service – Preise](https://aws.amazon.com/kms/pricing/).
1. Klicken Sie auf **DNSSEC-Signatur aktivieren**.
------
**Führen Sie nach dem Aktivieren der Zonensignierung die folgenden Schritte aus** (egal, ob Sie die Konsole oder CLI verwendet haben):
1. Stellen Sie sicher, dass die Zonensignatur effektiv ist.
Falls Sie dies getan haben AWS CLI, können Sie die Vorgangs-ID aus der Ausgabe des `EnableHostedZoneDNSSEC()` Aufrufs verwenden, um [get-change](https://docs.aws.amazon.com/cli/latest/reference/route53/get-change.html) auszuführen oder [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)um sicherzustellen, dass alle Route 53-DNS-Server Antworten signieren (Status =`INSYNC`).
1. Warten Sie mindestens auf die maximale TTL der vorherigen Zone.
Warten Sie, bis Resolver alle nicht signierten Datensätze aus ihrem Cache leeren. Um dies zu erreichen, sollten Sie mindestens auf die maximale TTL der vorherigen Zone warten. In der `example.com`-Zone oben beträgt Wartezeit 1 Tag.
1. Überwachen Sie Berichte über Kundenprobleme.
Nachdem Sie die Zonensignierung aktiviert haben, sehen Ihre Kunden möglicherweise Probleme im Zusammenhang mit Netzwerkgeräten und Resolvern. Der empfohlene Überwachungszeitraum beträgt 2 Wochen.
Im Folgenden finden Sie Beispiele für Probleme, die möglicherweise auftreten:
+ Einige Netzwerkgeräte können die DNS-Antwortgröße auf unter 512 Byte beschränken, was für einige signierte Antworten zu klein ist. Diese Netzwerkgeräte sollten neu konfiguriert werden, um größere DNS-Antwortgrößen zu ermöglichen.
+ Einige Netzwerkgeräte führen eine gründliche Untersuchung der DNS-Antworten durch und entfernen bestimmte Datensätze, die sie nicht verstehen, wie die für DNSSEC verwendeten. Diese Geräte sollten neu konfiguriert werden.
+ Die Resolver einiger Kunden behaupten, dass sie eine größere UDP-Antwort akzeptieren können, als ihr Netzwerk unterstützt. Sie können Ihre Netzwerkfähigkeit testen und Ihre Resolver entsprechend konfigurieren. Weitere Informationen finden Sie unter [DNS-Antwortgröße-Testserver](https://www.dns-oarc.net/oarc/services/replysizetest/).
**Rollback:** Rufen Sie [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) auf und führen Sie dann ein Rollback der Schritte unter durch. [Schritt 1: Vorbereiten der Aktivierung der DNSSEC-Signatur](#dns-configuring-dnssec-enable-signing-step-1)
## Schritt 3: Erstellen einer Vertrauenskette
Nachdem Sie die DNSSEC-Signatur für eine gehostete Zone in Route 53 aktiviert haben, richten Sie eine Vertrauenskette für die gehostete Zone ein, um die DNSSEC-Signatureinrichtung abzuschließen. Dazu erstellen Sie einen Delegation Signer (DS) -Datensatz im*parent*-gehostete Zone für Ihre gehostete Zone mit den Informationen, die Route 53 zur Verfügung stellt. Je nachdem, wo Ihre Domain registriert ist, fügen Sie den Datensatz der übergeordneten gehosteten Zone in Route 53 oder bei einer anderen Domänenregistrierungsstelle hinzu.
**So richten Sie eine Vertrauenskette für die DNSSEC-Signatur ein**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. Wählen Sie im Navigationsbereich**Gehostete Zonen**, und wählen Sie dann eine gehostete Zone aus, für die Sie eine DNSSEC-Vertrauenskette einrichten möchten. *Sie müssen zuerst die DNSSEC-Signatur aktivieren.*
1. Klicken Sie auf der **DNSSEC** unter **DNSSEC**, wählen Sie **Anzeigen von Informationen zum Erstellen von DS-Datensätzen** aus.
**Anmerkung**
Wenn Sie nicht sehen**Anzeigen von Informationen zum Erstellen von DS-Datensätzen**in diesem Abschnitt müssen Sie die DNSSEC-Signatur aktivieren, bevor Sie die Vertrauenskette einrichten. Wählen Sie **Enable DNSSEC signing** (DNSSEC-Signatur aktivieren) aus, führen Sie die unter beschriebenen Schritte in [Schritt 2: Aktivieren der DNSSEC-Signatur und Erstellen einer KSK](#dns-configuring-dnssec-enable) aus und kehren Sie dann zu diesen Schritten zurück, um die Vertrauenskette einzurichten.
1. UNDER**Erstellen einer Vertrauenskette**, wählen Sie entweder**Registrant Route 53**oder**Eine andere Domänenvergabestelle**, je nachdem, wo Ihre Domain registriert ist.
1. Verwenden Sie die bereitgestellten Werte ab Schritt 3 , um einen DS-Datensatz für die übergeordnete gehostete Zone in Route 53 zu erstellen. Wenn Ihre Domäne nicht bei Route 53 gehostet wird, verwenden Sie die bereitgestellten Werte, um einen DS-Datensatz auf der Website Ihres Domänen-Registrars zu erstellen.
Richten Sie eine Vertrauenskette für die übergeordnete Zone ein:
+ Wenn Ihre Domain über Route 53 verwaltet wird, gehen Sie wie folgt vor:
Stellen Sie sicher, dass Sie den richtigen Signierungsalgorithmus (ECDSAP256SHA256 und Typ 13) und den richtigen Digest-Algorithmus (SHA-256 und Typ 2) konfigurieren.
Wenn Route 53 Ihr Registrar ist, gehen Sie in der Route-53-Konsole wie folgt vor:
1. Beachten Sie die**Schlüsseltyp**,**Signaturalgorithmus**, und**Der öffentliche Schlüssel**-Werte. Klicken Sie im Navigationsbereich auf **Registered domains (Registrierte Domänen)**.
1. **Wählen Sie eine Domain aus und klicken Sie dann auf der Registerkarte **DNSSEC-Schlüssel auf Schlüssel hinzufügen**.**
1. Wählen Sie im Dialogfeld **Manage DNSSEC keys** (DNSSEC-Schlüssel verwalten) den entsprechenden **Key type** (Schlüsseltyp) und **Algorithm** (Algorithmus) für **Route 53 registrar** (Route-53-Registrar) aus den Dropdown-Menüs aus.
1. Kopieren Sie die**Der öffentliche Schlüssel**für den Registrar der Route 53. Wählen Sie in **Manage DNSSEC keys** (DNSSEC-Schlüssel verwalten) den Wert in dem Feld **Public key** (Öffentlicher Schlüssel) aus.
1. Wählen Sie **Hinzufügen** aus.
Route 53 fügt den DS-Datensatz der übergeordneten Zone aus dem öffentlichen Schlüssel hinzu. Beispiel: Wenn Ihre Domäne lautet`example.com`Der DS-Eintrag wird der DNS-Zone .com hinzugefügt.
+ Wenn Ihre Domain in einer anderen Registry verwaltet wird, folgen Sie den Anweisungen im Abschnitt **Ein anderer Domain-Registrar**.
Um sicherzustellen, dass die folgenden Schritte reibungslos verlaufen, führen Sie eine niedrige DS-TTL in die übergeordnete Zone ein. Wir empfehlen, den DS TTL auf 5 Minuten (300 Sekunden) für eine schnellere Wiederherstellung einzustellen, wenn Sie Ihre Änderungen zurücksetzen müssen.
+ Richten Sie eine Vertrauenskette für die untergeordnete Zone ein:
Wenn Ihre übergeordnete Zone von einer anderen Registrierung verwaltet wird, kontaktieren Sie Ihren Registrar, um den DS-Datensatz für Ihre Zone einzuführen. In der Regel können Sie die TTL des DS-Datensatzes nicht anpassen.
+ Wenn Ihre übergeordnete Zone auf Route 53 gehostet wird, kontaktieren Sie den Besitzer der übergeordneten Zone, um den DS-Datensatz für Ihre Zone einzuführen.
Geben Sie die `$ds_record_value` für den Besitzer der übergeordneten Zone an. Sie können sie abrufen, indem Sie in der Konsole auf **Informationen anzeigen klicken, um einen DS-Eintrag zu erstellen**, und das **DS-Datensatzfeld** kopieren, oder indem Sie die [GetDNSSec-API aufrufen](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetDNSSEC.html) und den Wert des Felds '' abrufen: DSRecord
```
aws --region us-east-1 route53 get-dnssec
--hosted-zone-id $hostedzone_id
```
Der Besitzer der übergeordneten Zone kann den Datensatz über die Route-53-Konsole oder CLI einfügen.
+ Um den DS-Eintrag mithilfe von einzufügen AWS CLI, erstellt und benennt der Besitzer der übergeordneten Zone eine JSON-Datei, die dem folgenden Beispiel ähnelt. Der Besitzer der übergeordneten Zone kann die Datei wie folgt benennen: `inserting_ds.json`.
```
{
"HostedZoneId": "$parent_zone_id",
"ChangeBatch": {
"Comment": "Inserting DS for zone $zone_name",
"Changes": [
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "$zone_name",
"Type": "DS",
"TTL": 300,
"ResourceRecords": [
{
"Value": "$ds_record_value"
}
]
}
}
]
}
}
```
Führen Sie anschließend den folgenden Befehl aus:
```
aws --region us-east-1 route53 change-resource-record-sets
--cli-input-json file://inserting_ds.json
```
+ Um den DS-Datensatz über die Konsole einzufügen,
Öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
Wählen Sie im Navigationsbereich **Hosted zones** (Gehostete Zonen) und dann Name Ihrer gehosteten Zone und dann die Schaltfäche **Create record** (Datensatz erstellen) aus. Stellen Sie sicher, dass Sie Einfaches Routing für die **Routing policy** (Routing-Richtlinie) auswählen.
Geben Sie im Feld **Datensatzname** denselben Namen wie der ein`$zone_name`, wählen Sie DS aus der Dropdownliste **Datensatztyp** aus, geben Sie den Wert von `$ds_record_value` in das Feld **Wert** ein und wählen Sie **Datensätze erstellen** aus.
**Rollback:** entfernen Sie das DS aus der übergeordneten Zone, warten Sie auf die DS-TTL und setzen Sie dann die Schritte zum Aufbau von Vertrauen zurück. Wenn die übergeordnete Zone auf Route 53 gehostet wird, kann der Besitzer der übergeordneten Zone die `Action` von `UPSERT` zu `DELETE` in der JSON-Datei ändern und die obige Beispiel-CLI erneut ausführen.
1. Warten Sie, bis die Aktualisierungen basierend auf der TTL für Ihre Domänendatensätze weitergegeben werden.
Wenn sich die übergeordnete Zone auf dem Route 53-DNS-Dienst befindet, kann der Besitzer der übergeordneten Zone die vollständige Weitergabe über die [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API bestätigen.
Andernfalls können Sie die übergeordnete Zone regelmäßig auf den DS-Datensatz untersuchen und danach weitere 10 Minuten warten, um die Wahrscheinlichkeit zu erhöhen, dass die Einfügung des DS-Datensatzes vollständig propagiert wird. Beachten Sie, dass einige Registraren beispielsweise einmal täglich die DS-Einfügung geplant haben.
Wenn Sie den Delegation Signer (DS)-Datensatz in der übergeordneten Zone einführen, starten die validierten Resolver, die den DS aufgenommen haben, mit der Validierung der Antworten aus der Zone.
Um sicherzustellen, dass die Schritte zur Vertrauensbildung reibungslos verlaufen, führen Sie Folgendes aus:
1. Finden Sie das maximale NS TTL.
Es gibt 2 Sätze von NS-Datensätzen, die Ihren Zonen zugeordnet sind:
+ Der NS-Datensatz der Delegation – dies ist der NS-Datensatz für Ihre Zone, die von der übergeordneten Zone gehalten wird. Sie können dies finden, indem Sie die folgenden Unix-Befehle ausführen (wenn Ihre Zone beispiel.com ist, ist die übergeordnete Zone com):
`dig -t NS com`
Wählen Sie einen der NS-Datensätze aus und führen Sie dann Folgendes aus:
`dig @one of the NS records of your parent zone -t NS example.com`
Zum Beispiel:
`dig @b.gtld-servers.net. -t NS example.com`
+ Der NS-Datensatz in der Zone – dies ist der NS-Datensatz in Ihrer Zone. Sie können dies suchen, indem Sie den folgenden Unix-Befehl ausführen:
`dig @one of the NS records of your zone -t NS example.com`
Zum Beispiel:
`dig @ns-0000.awsdns-00.co.uk. -t NS example.com`
Beachten Sie die maximale TTL für beide Zonen.
1. Warten Sie auf den maximalen NS TTL.
Vor der DS-Einfügung erhalten Resolver eine signierte Antwort, validieren die Signatur jedoch nicht. Wenn der DS-Datensatz eingefügt wird, sehen Resolver ihn erst, wenn der NS-Datensatz für die Zone abläuft. Wenn Resolver den NS-Datensatz erneut abrufen, wird der DS-Datensatz dann ebenfalls zurückgegeben.
Wenn Ihr Kunde einen Resolver auf einem Host mit einer nicht synchronisierten Uhr ausführt, stellen Sie sicher, dass sich die Uhr innerhalb 1 Stunde nach der richtigen Zeit befindet.
Nach Abschluss dieses Schritts validieren alle DNSSEC-fähigen Resolver Ihre Zone.
1. Beachten Sie die Namensauflösung.
Sie sollten beachten, dass es keine Probleme mit Resolvern gibt, die Ihre Zone validieren. Stellen Sie sicher, dass Sie auch die Zeit berücksichtigen, die Ihre Kunden benötigen, um Ihnen Probleme zu melden.
Wir empfehlen eine Überwachung für bis zu 2 Wochen.
1. (Optional) Verlängern Sie DS und NS TTLs.
Wenn Sie mit der Einrichtung zufrieden sind, können Sie die von Ihnen vorgenommenen TTL- und SOA-Änderungen speichern. Beachten Sie, dass Route 53 die TTL für signierte Zonen auf 1 Woche beschränkt. Weitere Informationen finden Sie unter [Konfigurieren der DNSSEC-Signatur in Amazon Route 53](dns-configuring-dnssec.md).
Wenn Sie die DS TTL ändern können, empfehlen wir, dass Sie es auf 1 Stunde einstellen.
# Deaktivieren der DNSSEC-Signatur
Die Schritte zum Deaktivieren der DNSSEC-Signierung in Route 53 variieren je nach Vertrauenskette, zu der Ihre gehostete Zone gehört.
Beispielsweise kann Ihre gehostete Zone eine übergeordnete Zone mit einem DS-Datensatz (Delegation Signer) als Teil einer Vertrauenskette aufweisen. Ihre gehostete Zone kann auch selbst eine übergeordnete Zone für untergeordnete Zonen sein, die die DNSSEC-Signatur aktiviert haben. Dies ist ein weiterer Teil der Vertrauenskette. Untersuchen und ermitteln Sie die vollständige Vertrauenskette für Ihre gehostete Zone, bevor Sie die DNSSEC-Signatur deaktivieren.
Die Vertrauenskette für Ihre gehostete Zone, die die DNSSEC-Signatur aktiviert, muss beim Deaktivieren der Signatur sorgfältig rückgängig gemacht werden. Um die gehostete Zone aus der Vertrauenskette zu entfernen, entfernen Sie alle DS-Datensätze, die für die Vertrauenskette vorhanden sind, die diese gehostete Zone enthält. Dies bedeutet, dass Sie Folgendes tun müssen, um:
1. Entfernen Sie alle DS-Datensätze, die diese gehostete Zone für untergeordnete Zonen enthält, die Teil einer Vertrauenskette sind.
1. Entfernen Sie den DS-Datensatz aus der übergeordneten Zone. Überspringen Sie diesen Schritt, wennn Sie über eine Vertrauensinsel verfügen (es gibt keine DS-Datensätze in der übergeordneten Zone und keine DS-Datensätze für untergeordnete Zonen in dieser Zone).
1. Wenn Sie DS-Datensätze nicht entfernen können, entfernen Sie NS-Datensätze aus der übergeordneten Zone, um die Zone aus der Vertrauenskette zu entfernen. Weitere Informationen finden Sie unter [Hinzufügen oder Ändern der Nameserver und Glue-Datensätze in einer Domäne](domain-name-servers-glue-records.md).
Mit den folgenden inkrementellen Schritten können Sie die Effektivität der einzelnen Schritte überwachen, um Probleme mit der DNS-Verfügbarkeit in Ihrer Zone zu vermeiden.
**So deaktivieren Sie die DNSSEC-Signatur**
1. Überwachen Sie die Verfügbarkeit der Zone.
Sie können die Zone auf die Verfügbarkeit Ihrer Domänennamen überwachen. Dies kann Ihnen helfen, alle Probleme zu beheben, die einen Schritt zurücksetzen könnten, nachdem Sie die DNSSEC-Signatur aktiviert haben. Sie können Ihre Domänennamen mit dem größten Datenverkehr überwachen, indem Sie die Abfrageprotokollierung verwenden. Für weitere Informationen zum Einrichten einer Abfrage-Protokollierung siehe [Amazon Route 53 überwachen](monitoring-overview.md).
Die Überwachung kann über ein Shell-Skript oder über einen kostenpflichtigen Dienst erfolgen. Dies sollte jedoch nicht das einzige Signal sein, um festzustellen, ob ein Rollback erforderlich ist. Möglicherweise erhalten Sie auch Feedback von Ihren Kunden, da eine Domäne nicht verfügbar ist.
1. Suchen Sie die aktuelle DS TTL.
Sie können die DS TTL finden, indem Sie den folgenden Unix-Befehl ausführen:
`dig -t DS example.com example.com`
1. Suchen Sie die maximale NS TTL.
Es gibt 2 Sätze von NS-Datensätzen, die Ihren Zonen zugeordnet sind:
+ Der NS-Datensatz der Delegation – dies ist der NS-Datensatz für Ihre Zone, die von der übergeordneten Zone gehalten wird. Sie können dies suchen, indem Sie den folgenden Unix-Befehl ausführen:
Suchen Sie zuerst den NS Ihrer übergeordneten Zone (wenn Ihre Zone beispiel.com ist, ist die übergeordnete Zone com):
`dig -t NS com`
Wählen Sie einen der NS-Datensätze aus und führen Sie dann Folgendes aus:
`dig @one of the NS records of your parent zone -t NS example.com`
Zum Beispiel:
`dig @b.gtld-servers.net. -t NS example.com`
+ Der NS-Datensatz in der Zone – dies ist der NS-Datensatz in Ihrer Zone. Sie können dies suchen, indem Sie den folgenden Unix-Befehl ausführen:
`dig @one of the NS records of your zone -t NS example.com`
Zum Beispiel:
`dig @ns-0000.awsdns-00.co.uk. -t NS example.com`
Beachten Sie die maximale TTL für beide Zonen.
1. Entfernen Sie den DS-Eintrag aus der übergeordneten Zone.
Kontaktieren Sie den Besitzer der übergeordneten Zone, um den DS-Datensatz zu entfernen.
**Rollback:** Fügen Sie den DS-Datensatz erneut ein, bestätigen Sie, dass die DS-Einfügung wirksam ist, und warten Sie für die maximale TTL von NS (nicht DS). Danach starten alle Resolver wieder mit der Validierung.
1. Bestätigen Sie, dass die DS-Entfernung wirksam ist.
Wenn sich die übergeordnete Zone auf dem Route 53-DNS-Dienst befindet, kann der Besitzer der übergeordneten Zone die vollständige Weitergabe über die [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html)API bestätigen.
Andernfalls können Sie die übergeordnete Zone regelmäßig auf den DS-Datensatz untersuchen und danach weitere 10 Minuten warten, um die Wahrscheinlichkeit zu erhöhen, dass die Entfernung des DS-Datensatzes vollständig verbreitet wird. Beachten Sie, dass einige Registraren die DS-Entfernung geplant haben, z. B. einmal am Tag.
1. Warten Sie auf die DS TTL.
Warten Sie, bis alle Resolver den DS-Datensatz aus ihren Caches abgelaufen sind.
1. Deaktivieren Sie die DNSSEC-Signatur und deaktivieren Sie den Schlüsselsignierungsschlüssel (KSK).
+ [CLI](#CLI_dnssec_disable)
+ [Konsole](#console_dnssec_disable)
------
#### [ CLI ]
Rufen Sie [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html) und auf. [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html) APIs
Beispiel:
```
aws --region us-east-1 route53 disable-hosted-zone-dnssec \
--hosted-zone-id $hostedzone_id
aws --region us-east-1 route53 deactivate-key-signing-key \
--hosted-zone-id $hostedzone_id --name $ksk_name
```
------
#### [ Console ]
**So deaktivieren Sie die DNSSEC-Signatur**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. Wählen Sie im Navigationsbereich**Gehostete Zonen**Wählen Sie dann eine gehostete Zone aus, für die Sie die DNSSEC-Signatur deaktivieren möchten.
1. Klicken Sie auf der**DNSSEC**Wählen Sie auf der Registerkarte**DNSSEC-Signatur deaktivieren**aus.
1. Klicken Sie auf der**DNSSEC-Signatur deaktivieren**Wählen Sie je nach Szenario für die Zone, für die Sie die DNSSEC-Signatur deaktivieren, eine der folgenden Optionen aus.
+ **Nur übergeordnete Zone**— Diese Zone hat eine übergeordnete Zone mit einem DS-Eintrag. In diesem Szenario müssen Sie den DS-Eintrag der übergeordneten Zone entfernen.
+ **Nur untergeordnete Zonen**— Diese Zone verfügt über einen DS-Eintrag für eine Vertrauenskette mit einer oder mehreren untergeordneten Zonen. In diesem Szenario müssen Sie die DS-Einträge der Zone entfernen.
+ **Übergeordnet und untergeordnet**— Diese Zone verfügt über einen DS-Datensatz für eine Vertrauenskette mit einer oder mehreren untergeordneten Zonen*und*eine übergeordnete Zone mit einem DS-Datensatz. Führen Sie für dieses Szenario die folgenden Schritte in aus:
1. Entfernen Sie die DS-Einträge der Zone.
1. Entfernen Sie den DS-Eintrag der übergeordneten Zone.
Wenn Sie eine Insel des Vertrauens haben, können Sie diesen Schritt überspringen.
1. Bestimmen Sie die TTL für jeden DS-Datensatz, den Sie in Schritt 4 entfernen. Stellen Sie sicher, dass der längste TTL-Zeitraum abgelaufen ist.
1. Wählen Sie das Kontrollkästchen, um zu bestätigen, dass Sie die Schritte der Reihe nach befolgt haben.
1. GebenSie *disable* wie gezeigt in das Feld und wählen Sie **Deaktivieren** aus.
**So deaktivieren Sie den Schlüsselsignierungschlüssel (KSK)**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/).
1. Wählen Sie im Navigationsbereich **Hosted Zones** (Gehostete Zonen) und wählen Sie dann eine gehostete Zone aus, für die Sie den Schlüsselsignierungsschlüssel (KSK) deaktivieren möchten.
1. **Wählen Sie im Abschnitt **Schlüssel zur Schlüsselsignierung (KSKs)** das KSK aus, das Sie deaktivieren möchten, und wählen Sie unter **Aktionen** die Option KSK **bearbeiten aus, setzen Sie den KSK-Status** **auf **Inaktiv** und wählen Sie dann KSK** speichern aus.**
------
**[Rollback: Anruf und DNSSEC. [ActivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html)EnableHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)** APIs
Beispiel:
```
aws --region us-east-1 route53 activate-key-signing-key \
--hosted-zone-id $hostedzone_id --name $ksk_name
aws --region us-east-1 route53 enable-hosted-zone-dnssec \
--hosted-zone-id $hostedzone_id
```
1. Bestätigen Sie, dass das Deaktivieren der Zonensignierung wirksam ist.
Vergewissern Sie sich anhand der ID aus dem `EnableHostedZoneDNSSEC()` Anruf [GetChange](https://docs.aws.amazon.com/Route53/latest/APIReference/API_GetChange.html), dass alle Route 53-DNS-Server keine Antworten mehr signieren (Status =). `INSYNC`
1. Beachten Sie die Namensauflösung.
Sie sollten beachten, dass es keine Probleme gibt, die dazu führen, dass Resolver Ihre Zone validieren. Planen Sie 1-2 Wochen ein, um auch die Zeit zu berücksichtigen, die Ihre Kunden benötigen, um Ihnen Probleme zu melden.
1. (Optional) Bereinigen.
Wenn Sie das Signieren nicht wieder aktivieren möchten, können Sie den KSKs durchgehenden Schlüssel bereinigen [DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html)und den entsprechenden vom Kunden verwalteten Schlüssel löschen, um Kosten zu sparen.
# Arbeiten mit vom Kunden verwalteten Schlüsseln für DNSSEC
Wenn Sie die DNSSEC-Signierung in Amazon Route 53 aktivieren, erstellt Route 53 einen Schlüssel-Signaturschlüssel (KSK). Um ein KSK zu erstellen, muss Route 53 einen vom Kunden verwalteten Schlüssel verwenden AWS Key Management Service , der DNSSEC unterstützt. In diesem Abschnitt werden die Details und Anforderungen für den vom Kunden verwalteten Schlüssel beschrieben, die bei der Arbeit mit DNSSEC hilfreich sind.
Beachten Sie Folgendes, wenn Sie mit kundenverwalteten Schlüsselverwaltete Schlüssel für DNSSEC arbeiten:
+ Der kundenverwaltete Schlüssel, den Sie mit der DNSSEC-Signatur verwenden, muss sich in der Region USA Ost (Nord-Virginia) befinden.
+ Der vom Kunden verwaltete Schlüssel muss ein [Asymmetrische kundenverwaltete Schlüssel](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-concepts.html#asymmetric-cmks) mit einem [Schlüsselspezifikation ECC\$1NIST\$1P256](https://docs.aws.amazon.com//kms/latest/developerguide/asymmetric-key-specs.html#key-spec-ecc) sein. Diese kundenverwalteten Schlüssel werden nur zur Signatur und Verifizierung verwendet. Hilfe bei der Erstellung eines asymmetrischen kundenverwalteten Schlüssels finden Sie unter [Asymmetrische, vom Kunden verwaltete Schlüssel erstellen](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-asymmetric-cmk) im Entwicklerhandbuch. AWS Key Management Service Hilfe bei der Suche nach der kryptografischen Konfiguration eines vorhandenen, vom Kunden verwalteten Schlüssels finden Sie im [Entwicklerhandbuch unter Kryptografiekonfiguration von kundenverwalteten Schlüsseln anzeigen](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-crypto-config.html). AWS Key Management Service
+ Wenn Sie einen vom Kunden verwalteten Schlüssel für die Verwendung mit DNSSEC in Route 53 selbst erstellen, müssen Sie bestimmte Schlüsselrichtlinienanweisungen einschließen, die Route 53 die erforderlichen Berechtigungen erteilen. Route 53 muss auf Ihren vom Kunden verwalteten Schlüssel zugreifen können, damit er eine KSK für Sie erstellen kann. Weitere Informationen finden Sie unter [Route 53 vom Kunden verwaltete Schlüsselberechtigungen für DNSSEC-Signierung erforderlich](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC).
+ Route 53 kann einen vom Kunden verwalteten Schlüssel für Sie erstellen, den Sie mit der AWS KMS DNSSEC-Signatur ohne zusätzliche Berechtigungen verwenden können. AWS KMS Sie müssen jedoch über bestimmte Berechtigungen verfügen, wenn Sie den Schlüssel nach der Erstellung bearbeiten möchten. Die spezifischen Berechtigungen, die Sie haben müssen, sind die folgenden:`kms:UpdateKeyDescription`,`kms:UpdateAlias`, und `kms:PutKeyPolicy`.
+ Beachten Sie, dass für jeden Kunden verwalteten Schlüssel, den Sie haben, separate Gebühren anfallen, unabhängig davon, ob Sie den vom Kunden verwalteten Schlüssel erstellen oder Route 53 ihn für Sie erstellt. Weitere Informationen finden Sie unter [AWS Key Management Service Preise](https://aws.amazon.com/kms/pricing/).
# Arbeiten mit Schlüsseln zur Schlüsselsignierung () KSKs
Wenn Sie DNSSEC-Signaturschlüssel aktivieren, erstellt Route 53 einen Schlüssel-Signaturschlüssel (KSK). In Route 53 können Sie bis zu zwei KSKs pro gehosteter Zone haben. Nachdem Sie die DNSSEC-Signatur aktiviert haben, können Sie Ihre hinzufügen, entfernen oder bearbeiten. KSKs
Beachten Sie Folgendes, wenn Sie mit Ihrem arbeiten: KSKs
+ Bevor Sie eine KSK löschen können, müssen Sie die KSK bearbeiten, um ihren Status auf **Inaktiv** einzustellen.
+ Wenn DNSSEC-Signatur für eine gehostete Zone aktiviert ist, begrenzt Route 53 die TTL auf eine Woche. Wenn Sie eine TTL für Datensätze in der gehosteten Zone auf mehr als eine Woche festlegen, erhalten Sie keinen Fehler, aber Route 53 erzwingt eine TTL von einer Woche.
+ Um einen Zonenausfall zu verhindern und Probleme mit der Nichtverfügbarkeit Ihrer Domäne zu vermeiden, müssen Sie DNSSEC-Fehler schnell beheben und beheben. Wir empfehlen Ihnen dringend, einen CloudWatch Alarm einzurichten, der Sie benachrichtigt, wenn ein `DNSSECInternalFailure` `DNSSECKeySigningKeysNeedingAction` Oder-Fehler erkannt wird. Weitere Informationen finden Sie unter [Überwachung von Hosting-Zonen mit Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md).
+ Die in diesem Abschnitt beschriebenen KSK-Operationen ermöglichen es Ihnen, Ihre Zonen zu wechseln. KSKs Weitere Informationen und ein step-by-step Beispiel finden Sie unter *DNSSEC-Schlüsselrotation* im Blogbeitrag [Konfiguration der DNSSEC-Signierung und -Validierung mit](https://aws.amazon.com/blogs/networking-and-content-delivery/configuring-dnssec-signing-and-validation-with-amazon-route-53/) Amazon Route 53.
Folgen Sie den Anweisungen KSKs in den folgenden AWS-Managementkonsole Abschnitten, um damit zu arbeiten.
## Hinzufügen eines Schlüsselsignaturschlüssels
Wenn Sie DNSSEC-Signatur aktivieren, erstellt Route 53 eine Schlüsselsignierung (KSK) für Sie. Sie können es auch KSKs separat hinzufügen. In Route 53 können Sie bis zu zwei KSKs pro gehosteter Zone haben.
Wenn Sie ein KSK erstellen, müssen Sie Route 53 angeben oder anfordern, um einen vom Kunden verwalteten Schlüssel zur Verwendung mit dem KSK zu erstellen. Wenn Sie einen vom Kunden verwalteten Schlüssel bereitstellen oder erstellen, gibt es mehrere Anforderungen. Weitere Informationen finden Sie unter [Arbeiten mit vom Kunden verwalteten Schlüsseln für DNSSEC](dns-configuring-dnssec-cmk-requirements.md).
Gehen Sie folgendermaßen vor, um eine KSK in der AWS-Managementkonsole hinzuzufügen.
**So fügen Sie eine KSK hinzu**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. Wählen Sie im Navigationsbereich**Gehostete Zonen**, und wählen Sie dann eine gehostete Zone aus.
1. **Wählen Sie auf der Registerkarte **DNSSEC-Signierung unter **Schlüssel zur Schlüsselsignierung (KSKs)** die Option **Zur erweiterten Ansicht wechseln** und dann unter **Aktionen** die Option KSK** hinzufügen aus.**
1. UNDER**KSK**einen Namen für die KSK ein, die Route 53 für Sie erstellt. Namen können nur Buchstaben, Zahlen und Unterstriche enthalten. Dieser Wert muss eindeutig sein.
1. Geben Sie den Alias für einen vom Kunden verwalteten Schlüssel ein, der für die DNSSEC-Signatur gilt, oder geben Sie einen Alias für einen neuen kundenverwalteten Schlüssel ein, den Route 53 für Sie erstellt.
**Anmerkung**
Wenn Sie sich dafür entscheiden, dass Route 53 einen vom Kunden verwalteten Schlüssel erstellt, beachten Sie, dass für jeden vom Kunden verwalteten Schlüssel separate Gebühren anfallen. Weitere Informationen finden Sie unter [AWS Key Management Service Preise](https://aws.amazon.com/kms/pricing/).
1. Wählen Sie **Create stack (Stack erstellen)** aus.
## Bearbeiten eines Schlüsselsignaturschlüssels
Sie können den Status eines KSK so bearbeiten, dass**Aktiv**oder**Inaktiv** ist. Wenn ein KSK aktiv ist, verwendet Route 53 diese KSK für die DNSSEC-Signatur. Bevor Sie eine KSK löschen können, müssen Sie die KSK bearbeiten, um ihren Status auf **Inaktiv**einzustellen.
Gehen Sie folgendermaßen vor, um eine KSK im AWS-Managementkonsole zu editieren.
**So bearbeiten Sie ein Tag**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. Wählen Sie im Navigationsbereich**Gehostete Zonen**, und wählen Sie dann eine gehostete Zone aus.
1. **Wählen Sie auf der Registerkarte **DNSSEC-Signierung unter **Schlüssel zur Schlüsselsignierung (KSKs)** die Option **Zur erweiterten Ansicht wechseln** und dann unter **Aktionen** die Option KSK** bearbeiten aus.**
1. Nehmen Sie die gewünschten Aktualisierungen an der KSK vor und wählen Sie**Save**aus.
## Löschen eines Schlüsselsignaturschlüssels
Bevor Sie eine KSK löschen können, müssen Sie die KSK bearbeiten, um ihren Status auf**Inaktiv**einzustellen.
Ein Grund, warum Sie eine KSK löschen können, ist als Teil der Routine Schlüsselrotation. Es ist eine bewährte Methode, kryptografische Schlüssel regelmäßig zu drehen. Ihre Organisation verfügt möglicherweise über Standardanweisungen für das Drehen von Schlüsseln.
Befolgen Sie diese Schritte, um die AWS-Managementkonsole-Tabelle zu löschen.
**So löschen Sie eine VPC**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Route 53-Konsole unter. [https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/)
1. Wählen Sie im Navigationsbereich**Gehostete Zonen**, und wählen Sie dann eine gehostete Zone aus.
1. **Wählen Sie auf der Registerkarte **DNSSEC-Signierung unter **Schlüssel zur Schlüsselsignierung (KSKs)** die Option **Zur erweiterten Ansicht wechseln** und dann unter **Aktionen** die Option KSK** löschen aus.**
1. Folgen Sie den Anweisungen, um das Löschen des KSK zu bestätigen.
# KMS-Schlüssel- und ZSK-Verwaltung in Route 53
In diesem Abschnitt wird die aktuelle Vorgehensweise beschrieben, die Route 53 für Ihre Zonen mit aktivierter DNSSEC-Signatur verwendet.
**Anmerkung**
Route 53 verwendet die folgende Regel, die sich ändern könnte. Alle zukünftigen Änderungen werden die Sicherheitslage Ihrer Zone oder die von Route 53 nicht beeinträchtigen.
**Wie verwendet Route 53 die mit Ihrem KSK verknüpften AWS KMS **
In DNSSEC wird der KSK verwendet, um die Ressourceneintragssignatur (RRSIG) für den DNSKEY-Ressourcendatensatz zu generieren. Alle `ACTIVE` KSKs werden in der RRSIG-Generation verwendet. Route 53 generiert eine RRSIG, indem sie die `Sign` AWS KMS API für den zugehörigen KMS-Schlüssel aufruft. Weitere Informationen finden Sie unter [Signieren](https://docs.aws.amazon.com/kms/latest/APIReference/API_Sign.html) im *AWS KMS -API-Handbuch*. Diese werden RRSIGs nicht auf das in der Zone festgelegte Limit für Ressourceneinträge angerechnet.
Ein RRSIG läuft ab. Um zu verhindern, dass sie ablaufen, RRSIGs werden sie regelmäßig aktualisiert, indem sie alle ein bis sieben Tage erneuert werden. RRSIGs
Sie RRSIGs werden außerdem jedes Mal aktualisiert, wenn Sie einen der folgenden Befehle aufrufen: APIs
+ [ActivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ActivateKeySigningKey.html)
+ [CreateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_CreateKeySigningKey.html)
+ [DeactivateKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeactivateKeySigningKey.html)
+ [DeleteKeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DeleteKeySigningKey.html)
+ [DisableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html)
+ [EnableHostedZoneDNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)
Jedes Mal, wenn Route 53 eine Aktualisierung durchführt, generieren wir 15 für die nächsten Tage, falls RRSIGs auf den zugehörigen KMS-Schlüssel nicht mehr zugegriffen werden kann. Für die Schätzung der KMS-Schlüsselkosten können Sie von einer regulären Aktualisierung am Tag ausgehen. Ein KMS-Schlüssel könnte durch versehentliche Änderungen der KMS-Schlüsselrichtlinie unzugänglich werden. Der unzugängliche KMS-Schlüssel setzt den Status des zugehörigen KSK auf `ACTION_NEEDED`. Es wird dringend empfohlen, diesen Zustand zu überwachen, indem Sie bei jedem erkannten `DNSSECKeySigningKeysNeedingAction` Fehler einen CloudWatch Alarm einrichten, da bei validierenden Resolvern die Suche nach Ablauf der letzten RRSIG fehlschlägt. Weitere Informationen finden Sie unter [Überwachung von Hosting-Zonen mit Amazon CloudWatch](monitoring-hosted-zones-with-cloudwatch.md).
**Wie Route 53 den ZSK Ihrer Zone verwaltet**
Jede neue gehostete Zone mit aktivierter DNSSEC-Signatur hat einen `ACTIVE` Zonensignaturschlüssel (ZSK). Der ZSK wird für jede gehostete Zone separat generiert und gehört Route 53. Der aktuelle Schlüsselalgorithmus ist. ECDSAP256 SHA256
Wir werden innerhalb von sieben bis 30 Tagen nach Beginn der Signatur eine regelmäßige ZSK-Rotation in der Zone durchführen. Derzeit verwendet Route 53 die Methode „Schlüssel-Rollover vor der Veröffentlichung“. Weitere Informationen finden Sie unter [Zonensignaturschlüssel-Rollover vor der Veröffentlichung](https://datatracker.ietf.org/doc/html/rfc6781#section-4.1.1.1). Diese Methode führt einen anderen ZSK in die Zone ein. Die Rotation wird alle sieben bis 30 Tage wiederholt.
Route 53 unterbricht die ZSK-Rotation, wenn sich ein KSK der Zone im `ACTION_NEEDED` Status befindet, weil Route 53 nicht in der Lage sein wird, die Ressourcendatensätze RRSIGs für DNSKEY neu zu generieren, um den Änderungen im ZSK der Zone Rechnung zu tragen. Die ZSK-Rotation wird automatisch fortgesetzt, nachdem die Bedingung gelöscht wurde.
# DNSSEC-Nachweise für Nichtvorhandensein in Route 53
**Anmerkung**
Route 53 verwendet die folgende Regel, die sich ändern könnte. Alle zukünftigen Änderungen werden die Sicherheitslage Ihrer Zone oder die von Route 53 nicht beeinträchtigen.
Es gibt drei Arten von Nachweisen für das Nichtvorhandensein in DNSSEC:
+ Nachweis des Nichtvorhandenseins eines Datensatzes, der mit dem Abfragenamen übereinstimmt.
+ Nachweis des Nichtvorhandenseins eines Typs, der mit dem Abfragetyp übereinstimmt.
+ Nachweis des Vorhandenseins eines Platzhalterdatensatzes, der zur Erzeugung des Datensatzes als Antwort verwendet wird.
Route 53 implementiert den Nachweis des Nichtvorhandenseins eines Datensatzes, der mit dem Abfragenamen übereinstimmt, mithilfe der BL-Methode. Weitere Informationen finden Sie unter [BL](https://datatracker.ietf.org/doc/html/draft-valsorda-dnsop-black-lies-00). Bei dieser Methode wird eine kompakte Darstellung des Nachweises erzeugt und das Zone Walking verhindert.
In Fällen, in denen es einen Datensatz gibt, der dem Abfragenamen, aber nicht dem Abfragetyp entspricht (z. B. bei der Abfrage nach web.example). com/AAAA but there is only web.example.com/Apresent) geben wir einen minimalen NSEC-Datensatz (Next Secure) zurück, der alle unterstützten Ressourcendatensatztypen enthält.
Wenn Route 53 eine Antwort aus einem Platzhalterdatensatz synthetisiert, umfasst die Antwort keinen nächsten sicheren Datensatz, oder NSEC-Datensatz, für den Platzhalter. Ein solcher NSEC-Datensatz wird in einigen Implementierungen verwendet, für gewöhnlich jenen, die Offline-Signaturen ausführen, um zu verhindern, dass die Ressourceneeintragssignaturen (RRSIG) in der Antwort wiederverwendet werden, um eine andere Antwort zu fälschen. Route 53 verwendet Online-Signierung für Datensätze, die nicht zu DNSKEY gehören, um RRSIGs spezifische Einträge für die Antwort zu generieren, die nicht für eine andere Antwort wiederverwendet werden können.
# Fehlerbehebung für DNSSEC
Die Informationen in diesem Abschnitt können Ihnen helfen, Probleme mit der DNSSEC-Signatur zu lösen, einschließlich der Aktivierung und Deaktivierung sowie mit Ihren Key-Signing-Schlüsseln (). KSKs
Aktivieren der DNSSEC
Stellen Sie sicher, dass Sie die Voraussetzungen in [Konfigurieren der DNSSEC-Signatur in Amazon Route 53](dns-configuring-dnssec.md) gelesen haben, bevor Sie mit der Aktivierung der DNSSEC-Signierung beginnen.
Deaktivieren der DNSSEC
Um DNSSEC sicher zu deaktivieren, überprüft Route 53, ob sich die Zielzone in der Vertrauenskette befindet. Es überprüft, ob das übergeordnete Element der Zielzone über NS-Datensätze der Zielzone und DS-Datensätze der Zielzone verfügt. Wenn die Zielzone nicht öffentlich auflösbar ist, z. B. wenn beim Abfragen nach NS und DS eine SERVFAIL-Antwort erhalten wird, kann Route 53 nicht feststellen, ob DNSSEC sicher deaktiviert werden kann. Sie können sich an Ihre übergeordnete Zone wenden, um diese Probleme zu beheben, und später erneut versuchen, DNSSEC zu deaktivieren.
KSK-Status lautet**Aktion erforderlich**
Ein KSK kann seinen Status in **Aktion erforderlich** (oder `ACTION_NEEDED` in einen [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html)Status) ändern, wenn Route 53 DNSSEC den Zugriff auf ein entsprechendes Objekt verliert AWS KMS key (aufgrund einer Änderung der Berechtigungen oder Löschung). AWS KMS key
Wenn der Status eines KSK **Action needed** (Aktion erforderlich) ist, bedeutet dies, dass es schließlich zu einem Zonenausfall für Clients kommt, die DNSSEC-validierende Resolver verwenden, und Sie müssen schnell handeln, um zu verhindern, dass eine Produktionszone nicht mehr aufgelöst werden kann.
Um das Problem zu beheben, stellen Sie sicher, dass der vom Kunden verwaltete Schlüssel, auf dem Ihre KSK basiert, aktiviert ist und über die richtigen Berechtigungen verfügt. Weitere Informationen zu den erforderlichen Berechtigungen finden Sie unter [Route 53 vom Kunden verwaltete Schlüsselberechtigungen für DNSSEC-Signierung erforderlich](access-control-managing-permissions.md#KMS-key-policy-for-DNSSEC).
Nachdem Sie das KSK repariert haben, aktivieren Sie es erneut mithilfe der Konsole oder der AWS CLI, wie unter beschrieben. [Schritt 2: Aktivieren der DNSSEC-Signatur und Erstellen einer KSK](dns-configuring-dnssec-enable-signing.md#dns-configuring-dnssec-enable)
Um dieses Problem in future zu vermeiden, sollten Sie erwägen, eine Amazon CloudWatch Metrik hinzuzufügen, um den Status des KSK nachzuverfolgen, wie unter vorgeschlagen. [Konfigurieren der DNSSEC-Signatur in Amazon Route 53](dns-configuring-dnssec.md)
KSK-Status lautet**Internal failure (Interner Fehler)**
Wenn ein KSK den Status **Interner Fehler** (oder `INTERNAL_FAILURE` einen [KeySigningKey](https://docs.aws.amazon.com/Route53/latest/APIReference/API_KeySigningKey.html)Status) hat, können Sie nicht mit anderen DNSSEC-Entitäten arbeiten, bis das Problem behoben ist. Sie müssen Maßnahmen ergreifen, bevor Sie mit der DNSSEC-Signatur arbeiten können, einschließlich der Arbeit mit dieser KSK oder Ihrer anderen KSK.
Um das Problem zu beheben, versuchen Sie erneut, KSK zu aktivieren oder zu deaktivieren.
[Um das Problem bei der Arbeit mit dem zu beheben APIs, versuchen Sie, das Signieren zu aktivieren ([EnableHostedZoneDNSSEC) oder das Signieren zu deaktivieren (DNSSEC](https://docs.aws.amazon.com/Route53/latest/APIReference/API_EnableHostedZoneDNSSEC.html)). DisableHostedZone](https://docs.aws.amazon.com/Route53/latest/APIReference/API_DisableHostedZoneDNSSEC.html)
Es ist wichtig, dass Sie**Internal failure (Interner Fehler)**umgehend Probleme. Sie können keine weiteren Änderungen an der gehosteten Zone vornehmen, bis Sie das Problem behoben haben, mit Ausnahme der Vorgänge zum Beheben des **Internal failure (Interner Fehler)**.
# Wird AWS Cloud Map zum Erstellen von Datensätzen und Zustandsprüfungen verwendet
Wenn Sie Internetdatenverkehr oder Datenverkehr innerhalb einer Amazon VPC an Anwendungskomponenten oder Microservices weiterleiten möchten, können Sie AWS Cloud Map zum automatischen Erstellen von Datensätzen und optional zum Erstellen von Zustandsprüfungen verwenden. Weitere Informationen finden Sie im [AWS Cloud Map -Entwicklerhandbuch](https://docs.aws.amazon.com/cloud-map/latest/dg/).
# DNS-Einschränkungen und Verhaltensweisen
DNS-Messaging unterliegt Faktoren, die die Erstellung und Verwendung gehosteter Zonen und Datensätze beeinflussen. In diesem Abschnitt werden diese Faktoren erläutert.
## Maximale Antwortgröße
Um die DNS-Standards einzuhalten, haben über UDP gesendete Antworten eine Größe von höchstens 512 Byte. Antworten mit mehr als 512 Byte werden abgeschnitten, und der Auflösungsdienst muss die Anforderung erneut über TCP senden. Wenn der Auflösungsdienst EDNS0 unterstützt (gemäß [RFC 2671](https://tools.ietf.org/html/rfc2671)) und die EDNS0-Option zu Amazon Route 53 anbietet, genehmigt Route 53 Antworten mit bis zu 4096 Byte über UDP, ohne Kürzung.
## Autoritative Abschnittsverarbeitung
Für erfolgreiche Abfragen hängt Route 53 Namensserver-Datensätze (NS) für die entsprechende gehostete Zone an den Authority-Abschnitt der DNS-Antwort an. Bei Namen, die nicht gefunden werden (NXDOMAIN-Antworten), hängt Route 53 den SOA-Datensatz (Start of Authority, Autoritätsursprung) (gemäß [RFC 1035](https://tools.ietf.org/html/rfc1035)) für die entsprechende gehostete Zone an den Authority-Abschnitt der DNS-Antwort an.
## Zusätzliche Abschnittsverarbeitung
Route 53 hängt Datensätze an den Additional-Abschnitt an. Wenn die Datensätze bekannt und geeignet sind, fügt der Service A- oder AAAA-Datensätze für jedes Ziel eines MX-, CNAME-, NS- oder SRV-Datensatzes in den Answer-Abschnitt ein. Weitere Informationen zu diesen DNS-Datensatztypen finden Sie unter [Unterstützte DNS-Datensatztypen](ResourceRecordTypes.md).
# Verwandte Themen
Informationen zur Übertragung der Domainregistrierung (nicht nur DNS-Hosting) auf Route 53 finden Sie in den folgenden Themen:
+ [Checkliste vor der Übertragung für Domainübertragungen](domain-transfer-checklist.md)— Füllen Sie diese Checkliste aus, bevor Sie die Domainregistrierung übertragen, um häufige Übertragungsfehler zu vermeiden.
+ [Übertragen der Registrierung für eine Domain an Amazon Route 53](domain-transfer-to-route-53.md)— Step-by-step Verfahren zur Übertragung der Domainregistrierung von einem anderen Registrar auf Route 53.
+ [Übertragen von Domänen](domain-transfer.md)— Überblick über alle Optionen für die Domainübertragung, einschließlich Übertragungen zwischen AWS Konten.