

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.

# Auswählen einer Routing-Richtlinie
<a name="routing-policy"></a>

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
<a name="routing-policy-simple"></a>

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
<a name="routing-policy-failover"></a>

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
<a name="routing-policy-geo"></a>

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
<a name="routing-policy-geo-phz"></a>

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
<a name="routing-policy-geoproximity"></a>

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
<a name="routing-policy-geoproximity-bias"></a>

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
<a name="routing-policy-latency"></a>

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
<a name="routing-policy-latency-phz"></a>

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
<a name="routing-policy-ipbased"></a>

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
<a name="resource-record-sets-creating-cidr-collection"></a>



Erstellen Sie zunächst eine CIDR-Sammlung und fügen Sie CIDR-Blöcke und -Standorte hinzu.<a name="CIDR-collection-creating-procedure"></a>

**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
<a name="resource-record-sets-working-with-cidr-locations"></a>

<a name="CIDR-locations-work-with-procedure"></a>

**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
<a name="resource-record-sets-delete-cidr-collection"></a>

<a name="CIDR-collection-delete-procedure"></a>

**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
<a name="resource-record-sets-move-geolocation-to-cidr"></a>

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
<a name="routing-policy-multivalue"></a>

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
<a name="routing-policy-weighted"></a>

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
<a name="routing-policy-weighted-healthchecks"></a>

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
<a name="routing-policy-edns0"></a>

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)