Schutz vor hängenden Delegierungsdatensätzen in Route 53 - Amazon Route 53
Beispiele

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.

Schutz vor hängenden Delegierungsdatensätzen in Route 53

Mit Route 53 kann ein Kunde eine gehostete Zone erstellen, um beispielsweise example.com seine DNS-Einträge zu hosten. Jede gehostete Zone verfügt über einen „Delegierungssatz“, der aus vier Nameservern besteht, mit denen ein Kunde NS-Einträge in der übergeordneten Domain konfigurieren kann. Diese NS-Einträge können als „Delegations-NS-Einträge“ oder „Delegierungseinträge“ bezeichnet werden.

Damit die gehostete example.com Route 53 53-Zone autoritativ wird, muss der rechtmäßige Eigentümer der example.com Domain Delegierungseinträge in seiner übergeordneten Domain „.com“ über den Domain-Registrar konfigurieren. In Fällen, in denen ein Kunde den Zugriff auf die vier in der übergeordneten Domain konfigurierten Nameserver verliert, beispielsweise weil die zugehörige Hosting-Zone gelöscht wurde, kann dies ein Risiko darstellen, das ein Angreifer ausnutzen kann. Dieses Risiko wird als „hängengebliebene Delegationsdaten“ bezeichnet.

Route 53 schützt vor dem Risiko eines hängenden Delegierungsdatensatzes für den Fall, dass eine gehostete Zone gelöscht wird. Wenn nach dem Löschen eine neue gehostete Zone mit demselben Domänennamen erstellt wird, überprüft Route 53, ob die Delegierungseinträge, die auf die gelöschte Hosting-Zone verweisen, noch in der übergeordneten Domäne vorhanden sind. Wenn dies der Fall ist, verhindert Route 53, dass sich überschneidende Nameserver zugewiesen werden. Dies ist Szenario 1 in den folgenden Beispielen.

Es gibt jedoch noch andere Risiken im Zusammenhang mit Delegierungsaufzeichnungen, vor denen Route 53 nicht schützen kann, wie in den folgenden Beispielen in den Szenarien 2 bis 6 beschrieben. Um sich vor diesen umfassenderen Risiken zu schützen, stellen Sie sicher, dass die übergeordneten NS-Einträge mit dem Delegierungssatz für die gehostete Route 53-Zone übereinstimmen. Sie finden den Delegierungssatz einer Hosting-Zone über die Route 53-Konsole oder AWS CLI. Für weitere Informationen siehe Auflisten von Datensätzen oder get-hosted-zone.

Darüber hinaus kann die Aktivierung der DNSSEC-Signatur für eine gehostete Route 53 53-Zone als weitere Schutzebene dienen, die über die oben genannten bewährten Methoden hinausgeht. DNSSEC authentifiziert, dass DNS-Antworten von der autoritativen Quelle stammen, und schützt so effektiv vor diesem Risiko. Weitere Informationen finden Sie unter Konfigurieren der DNSSEC-Signatur in Amazon Route 53.

Beispiele

In den folgenden Beispielen gehen wir davon aus, dass Sie über eine Domain und deren untergeordnete Domain example.com verfügen. child.example.com Wir werden erklären, wie in verschiedenen Szenarien fehlerhafte Delegierungsdatensätze erstellt werden können, wie Route 53 Ihre Domain vor Missbrauch schützt und wie Sie die Risiken, die mit unbrauchbaren Delegierungsdatensätzen verbunden sind, wirksam mindern können.

Szenario 1:

<ns3><ns4>Sie erstellen eine gehostete Zone child.example.com mit vier Nameservern:<ns1>,<ns2>, und. Sie richten die Delegierung in der Hosting-Zone example.com ordnungsgemäß ein und erstellen Delegierungs-NS-Einträge für child.example.com vier Nameserver <ns1><ns2>,<ns3>, und<ns4>. Wenn die child.example.com gehostete Zone gelöscht wird, ohne dass die Delegierungs-NS-Einträge entfernt werdenexample.com, schützt Route 53 vor child.example.com dem Risiko der Übertragung von Delegierungseinträgen <ns1><ns2><ns3>, indem verhindert wird,, und dass <ns4>neu erstellten Hosting-Zonen mit demselben Domainnamen zugewiesen werden.

Szenario 2:

Ähnlich wie in Szenario 1, aber dieses Mal löschen Sie die untergeordnete gehostete Zone UND die DNS-Einträge der Delegierung in der Hosting-Zoneexample.com. Sie fügen jedoch die Delegations-NS-Einträge<ns1>,, <ns2><ns3>und wieder hinzu, <ns4>ohne eine untergeordnete gehostete Zone zu erstellen. In diesem Fall <ns1><ns2><ns3><ns4>handelt es sich bei,, und um Delegierungsdatensätze, da Route 53 den Hold aufhebt, der die <ns1><ns2><ns3><ns4>Zuweisung von,, und verhindert hat, und ermöglicht nun neu erstellten Hosting-Zonen die Verwendung der oben genannten Nameserver. Um das Risiko zu minimieren, entfernen Sie, <ns1><ns2><ns3>, und <ns4>aus den Delegierungsdatensätzen und fügen Sie sie erst wieder hinzu, wenn die untergeordnete gehostete Zone erstellt wurde.

Szenario 3:

<ns4>In diesem Szenario erstellen Sie einen wiederverwendbaren Route 53-Delegierungssatz mit den Nameservern <ns1><ns2>,<ns3>, und. Anschließend delegieren Sie die Domäne example.com an diese Nameserver in der übergeordneten Domäne.com. Sie haben die Hosting-Zone für example.com jedoch noch nicht im wiederverwendbaren Delegierungssatz erstellt. Hier, <ns1><ns2><ns3>, und hängen <ns4>die Delegierungsdatensätze. <ns4>Um das Risiko zu minimieren, erstellen Sie die Hosting-Zone mithilfe des wiederverwendbaren Delegierungssatzes mit den Nameservern<ns1>, <ns2><ns3>, und.

Szenario 4:

Sie haben eine gehostete Zone child.example.com mit vier Nameservern: <ns1><ns2>,<ns3>, und<ns4>. Sie fügen eine Delegierung zu<ns1>, <ns2><ns3>, und zum <ns4>übergeordneten Element hinzu. Anschließend löschen Sie die Zone, entfernen jedoch nicht die <ns1><ns2><ns3><ns4>Delegierung,, und. <ns8>Anschließend erstellen Sie eine neue child.example.com Zone mit Nameservern<ns5>,, <ns6><ns7><ns8>, und fügen Delegierung zu<ns5>, <ns6><ns7>, und hinzu. <ns7><ns8>Sie haben jetzt eine übergeordnete Zone mit Delegierungen sowohl an<ns1>,<ns2>, als auch an<ns3>, <ns4><ns5><ns6>, und. <ns4>Dadurch entsteht ein hängendes Delegationsrisiko für<ns1>, <ns2><ns3>, und. <ns5><ns6><ns7><ns8>Um dieses Risiko zu minimieren, entfernen Sie die inaktiven Nameserver<ns1>,,, <ns2><ns3><ns4>aus den Delegierungsdatensätzen, sodass nur die aktiven Nameserver,,,, übrig bleiben. Stellen Sie generell immer sicher, dass es nur eine Subdomänen-Delegierung für gibt child.example.com und dass die NS-Einträge example.com exakt mit den vier Nameservern im Delegierungssatz der aktuellen untergeordneten Zone übereinstimmen.

Szenario 5:

Sie erstellen Hosting-Zonen sowohl child.example.com für Nameserver <ns1><ns2>,<ns3>, <ns4>undgrandchild.child.example.com, als auch für Nameserver <ns5><ns6>,<ns7>, und<ns8>. Sie delegieren jedoch beide direkt in der example.com Zone, wodurch ein gewisses Delegierungsrisiko besteht. Um sicherzustellen, dass Delegierungen der richtigen DNS-Hierarchie folgen, delegieren Sie Subdomänen nur über ihre unmittelbar übergeordneten Zonen. Wenn Sie beispielsweise delegieren möchtengrandchild.child.example.com: Delegieren Sie zuerst child.example.com mit den Nameservern<ns1>,, <ns2><ns3>und <ns4>in der example.com Zone, dann delegieren Sie grandchild.child.example.com mit den Nameservern,<ns5>, <ns6><ns7>, und <ns8>in der child.example.com Zone und entfernen Sie alle direkten Delegierungen für aus der Zone. grandchild.child.example.com example.com

Szenario 6:

Sie delegieren eine Domain oder Subdomain an Route 53 53-Nameserver, bevor Sie eine entsprechende Hosting-Zone erstellen. Dadurch entstehen fehlerhafte Delegierungsdatensätze. Dies ähnelt dem Fall in Szenario 3, das Risiko besteht jedoch auch, wenn kein wiederverwendbarer Delegierungssatz erstellt wird. Beispiel: Sie delegieren die Domäne example.com an die Nameserver<ns1>, <ns2><ns3>, und <ns4>in der übergeordneten Domäne.com, aber keiner dieser Nameserver wurde jemals gehostetexample.com. Route 53 kann davor nicht schützen, da es noch nie eine gehostete Zone gegeben hat, um diese Nameserver für diesen Domainnamen zu sperren. Um das Risiko zu minimieren, delegieren Sie nur an Route 53 53-Nameserver, die zu einer von Ihnen kontrollierten öffentlichen Hosting-Zone gehören.