View a markdown version of this page

Unterstützte DNS-Datensatztypen - Amazon Route 53
A-DatensatztypAAAA-DatensatztypCAA-DatensatztypCNAME-DatensatztypDS-DatensatztypHTTPS-DatensatztypMX-DatensatztypNAPTR-DatensatztypNS-DatensatztypPTR-DatensatztypSOA-DatensatztypSPF-DatensatztypSRV-DatensatztypTyp des SSHFP-EintragsSVCB-EintragstypTLSA-EintragstypTXT-Datensatztyp

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.

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.

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

<Value>192.0.2.1</Value>

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

<Value>2001:0db8:85a3:0:0:8a2e:0370:7334</Value>

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ürvalue. 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.

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 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 [email protected] sendet, erstellen Sie einen CAA-Datensatz mit den folgenden Einstellungen:

0 iodef "mailto:[email protected]"

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:[email protected]"

Beispiel für die Route-53-API

<ResourceRecord>
   <Value>0 issue "ca.example.net"</Value>
   <Value>0 iodef "mailto:[email protected]"</Value>
</ResourceRecord>

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.

Beispiel für die Route-53-Konsole

hostname.example.com

Beispiel für die Route-53-API

<Value>hostname.example.com</Value>

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.

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.

Beispiel für die Route-53-Konsole

123 4 5 1234567890abcdef1234567890absdef

Beispiel für die Route-53-API

<Value>123 4 5 1234567890abcdef1234567890absdef</Value>

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

<Value>0 example.com</Value>

Beispiel für die Route 53-API für den Servicemodus

<Value>16 example.com alpn="h2,h3" port=808</Value>

Weitere Informationen finden Sie unter RFC 9460, Service Binding and Parameter Specification via DNS (SVCB und HTTPS Resource 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, 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

<Value>10 mail.example.com</Value>

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 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:

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)

  • ! # $ % & ' ( ) * + , - / : ; < = > ? @ [ ] ^ _ ` { | } ~ .

  • " (Anführungszeichen). Um ein Anführungszeichen in eine Zeichenfolge einzufügen, stellen Sie ein \-Zeichen voran: \".

  • \ (Backslash). Um einen Backslash in eine Zeichenfolge einzufügen, stellen Sie ein \-Zeichen voran: \\.

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

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

Beispiel für die Amazon-Route-53-Konsole

100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\[email protected]!" .
100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:[email protected]!" .
100 52 "u" "E2U+email:mailto" "!^.*$!mailto:[email protected]!" .

Beispiel für die Route-53-API

<ResourceRecord>
   <Value>100 50 "u" "E2U+sip" "!^(\\+441632960083)$!sip:\\[email protected]!" .</Value>
   <Value>100 51 "u" "E2U+h323" "!^\\+441632960083$!h323:[email protected]!" .</Value>
   <Value>100 52 "u" "E2U+email:mailto" "!^.*$!mailto:[email protected]!" .</Value>
</ResourceRecord>

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.

  • NS-Datensätze werden auch verwendet, um White-Label-Name-Server zu konfigurieren. Weitere Informationen finden Sie unter Konfigurieren von White-Label-Nameservern.

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

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.

Beispiel für die Amazon-Route-53-Konsole

ns-1.example.com

Beispiel für die Route-53-API

<Value>ns-1.example.com</Value>

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

<Value>hostname.example.com</Value>

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.

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

<Value>ns-2048.awsdns-64.net hostmaster.awsdns.com 1 1 1 1 60</Value>

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.

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.

Beispiel für die Amazon-Route-53-Konsole

"v=spf1 ip4:192.168.0.1/16 -all"

Beispiel für die Route-53-API

<Value>"v=spf1 ip4:192.168.0.1/16 -all"</Value>

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

<Value>10 5 80 hostname.example.com</Value>

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

Das Format für einen SSHFP-Ressourceneintrag ist:

[Key Algorithm] [Hash Type] Fingerprint

Die folgenden Parameter sind in RFC 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

<Value>1 1 09F6A01D2175742B257C6B98B7C72C44C4040683</Value>

Weitere Informationen finden Sie unter RFC 4255: Verwenden von DNS zur sicheren Veröffentlichung von Secure Shell (SSH) -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, 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

<Value>0 example.com</Value>

Beispiel für die Route 53-API für den Servicemodus

<Value>16 example.com alpn="h2,h3" port=808</Value>

Weitere Informationen finden Sie unter RFC 9460, Service Binding and Parameter Specification via DNS (SVCB und HTTPS Resource 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

Das Format für einen TLSA-Ressourceneintrag ist:

[Certificate usage] Selector [Matching type] [Certificate association data]

Die folgenden Parameter sind in RFC 6698, 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

<Value>0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971</Value>

Weitere Informationen finden Sie unter RFC 6698, Das DNS-based Authentication of Named Entities (DANE) Transport Layer Security (TLS) -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 verwenden, nehmen Sie alle Werte für eine Domäne (example.com) oder Subdomäne (www.example.com) in den gleichen TXT-Datensatz auf.

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)

  • ! " # $ % & ' ( ) * + , - / : ; < = > ? @ [ \ ] ^ _ ` { | } ~ .

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:

<Value>"String 1" "String 2" "String 3"</Value>

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.

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:

<Value>"This string includes \"quotation marks\"."</Value>
<Value>"The last character in this string is an accented e specified in octal format: \351"</Value>
<Value>"v=spf1 ip4:192.168.0.1/16 -all"</Value>