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.
# 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.