Iterative DNS-Abfrage
Eine Anfrage an einen DNS-Server: Gib mir die endgültige Antwort auf meine Anfrage. Sende, wenn nötig, zusätzliche Anfragen an andere Server.
Rekursive DNS-Abfrage
Eine Anfrage an einen DNS-Server: Gib mir alle Informationen, die du hast. Sende keine weiteren Anfragen an andere Server.
Folgendes erfordert
DS- undDNSKey-Records. Hetzner unterstützt aktuell nurDS-Records.
Domain Name System Security Extensions (DNSSEC) sind eine Reihe von Erweiterungsspezifikationen (z.B. DS- und DNSKEY-Records), die verwendet werden, um sicherzustellen, dass DNS-Antworten von autoritativen Nameservern an rekursive Nameserver sicher sind und nicht abgefangen oder manipuliert wurden.
Der rekursive Nameserver verwendet Key Signing Keys (KSK) und Zone Signing Keys (ZSK) von jedem autoritativen Nameserver, um von jeder DNS-Antwort die Authentizität zu überprüfen — dadurch entsteht ein Chain-Of-Trust.
Um den Chain-Of-Trust von Anfang an zu etablieren, muss der rekursive Nameserver den gehashten PubKSK des root-Nameservers bereits lokal besitzen. Dabei ist es wichtig, dass dieser Key auf anderem Weg als über das DNS-Protokoll bezogen wurde (z.B. im Betriebssystem enthalten), um dessen Authentizität sicherzustellen.
Schritte in der DNSSEC-Validierung
Angenommen der Client versucht auf https://example.com zuzugreifen.
Erst sendet der rekursive Nameserver eine Anfrage an die root-Zone. Die root-Zone verweist auf die .com-Zone und übermittelt den gehashten PubKSK der .com-Zone.
Wenn der rekursive Nameserver der DNS-Antwort von der root-Zone vertraut, sendet er eine Anfrage an die .com-Zone. Mit dem zuvor von der root-Zone übermittelten .com-PubKSK, kann der Chain-Of-Trust fortgesetzt werden.
Wenn der rekursive Nameserver der DNS-Antwort von der .com-Zone vertraut, sendet er eine Anfrage an die example-Zone. Mit dem zuvor von der .com-Zone übermittelten example-PubKSK, kann der Chain-Of-Trust fortgesetzt werden.
Wenn der rekursive Nameserver der DNS-Antwort von der example-Zone vertraut, kann er die IP-Adresse zu example.com an den Client senden.
Im obenstehenden Beispiel würden die DNS-Records in etwa so aussehen:
Hier klicken, um zu erfahren, wie Sie rDNS (PTR) von Hetzer IPs bearbeiten
Hetzner IPs besitzen PTR-Records, die von Hetzner verwaltet werden. Die IPs zeigen standardmäßig auf eine Domain, die in etwa so aussieht:
static.1.113.0.203.clients.your-server.deIn folgenden Artikeln wird erklärt, wie Sie den Wert bearbeiten können:
In Hetzner Console, können Sie den Wert bearbeiten, indem Sie Ihren Cloud Server oder Load Balancer auswählen und in der oberen Menüleiste zu "Networking" navigieren. Ersetzen Sie
static.<your_reverse_ip>.clients.your-server.demit Ihrer eigenen Domain, die auf die IP-Adresse des Cloud Servers oder Load Balancers zeigt. Der von Hetzner verwaltete PTR-Record wird automatisch entsprechend aktualisiert. Die reverse DNS von Primären IPs und Floating IPs können Sie ebenfalls bearbeiten, indem Sie zur entsprechenden IP navigieren.
Wenn sehr viele Reverse-DNS-Eintrage bearbeitet werden müssen, können Sie das Robot Webservice oder die Cloud API verwenden.
Mit Reverse-DNS (rDNS) kann ein Client prüfen, zu welcher Domain eine bestimmte IP-Adresse gehört (zum Beispiel über dnschecker.org oder dig -x <ip-address>).
Der Wert der IP-Adresse wird in einem PTR-Record bestimmt, der in der Regel vom Besitzer der IP-Adresse (z.B. Hetzner) verwaltet wird. PTR-Records für rDNS werden nicht in der Zone der Domain angelegt, sondern in einer Reverse-Zone (z.B. <ip-in-reverse>.in-addr.arpa.), die vom Besitzer der IP verwaltet wird. Eine detaillierte Erkärung, finden Sie untenstehend bei rDNS-Zonen.
Beispiel:
In diesem Beispiel stimmt der Hostname in den Forward- und Reverse-DNS-Anfragen nur einmal überein:
www.example.com ---> 203.0.113.1
203.0.113.1 ---> edu.example.org
blog.example.com ---> 198.51.100.1
mail.example.com ---> 198.51.100.1 ─┐ Hostnamen
198.51.100.1 ---> mail.example.com ─┘ stimmen übereinin-addr.arpa oder ip6.arpa).
PTR-Record zurück. Wenn Sie in Ihrer eigenen Domain-Zone einen PTR-Record hinzufügen, wird dieser ignoriert, da der Client bei Reverse-Lookups nie Ihre Zone abfragt.
traceroute lösen IP-Adressen häufig über Reverse-DNS in Hostnamen auf. Das erleichtert die Fehlersuche erheblich.Wir empfehlen folgende Anforderungen bei der Zuweisung einzuhalten:
static.1.113.0.203.clients.your-server.de; solche Namen werden von Spam-Filtern möglicherweise als „Spam“ eingestuft.same.example.com ---> 192.0.2.254
192.0.2.254 ---> same.example.comDer PTR-Record von einer IP-Adresse wird in der Reverse-DNS-Zone verwaltet, die der jeweiligen IP-Adresse entspricht. Typischerweise besitzt ein Anbieter oder eine Organisation einen gesamten IP-Adressbereich. In solchen Fällen wird der gesamte IP-Bereich über eine einzelne Reverse-DNS-Zone verwaltet, die dem Subnetz entspricht.
Die Internet Assigned Numbers Authority (IANA) verwaltet die obersten Reverse-DNS-Zonen in-addr.arpa und ip6.arpa. Diese Zonen delegieren an die Nameserver der Regional Internet Registries (RIRs), welche für das oberste Subnetz zuständig sind, in das die angefragte IP-Adresse fällt — häufig ein /8-Block (z.B. 203 bei 203.0.113.1).
Ein RIR delegiert Top-Level-Subnetze (z.B. 203 bei 203.0.113.1) an die Nameserver des IP-Besitzers, der für das Subnetz verantwortlich ist, in das die angefragte IP-Adresse fällt — häufig ein /16- oder /24-Block (z.B. 203.0 bei 203.0.113.1).
Beispiel:
| Besitzer | IP-Bereich | Adressen |
|---|---|---|
| Holu | 198.51.100.0/24 | 198.51.100.0 bis 198.51.100.255 |
| Hetzner | 203.0.0.0/16 | 203.0.0.0 bis 203.0.255.255 |
Wenn ein Mailserver eine E-Mail versendet, prüft der Absender den MX-Record für die Domain, die nach dem @-Symbol des Empfängers angegeben ist. Bei der E-Mail-Adresse holu@example.com, zum Beispiel, prüft der Absender den MX-Record für example.com. Die E-Mail wird an die IP-Adresse aus der DNS-Antwort versendet. Der Absender prüft nicht den PTR-Record von dieser IP-Adresse.
Wenn ein Mailserver eine E-Mail empfängt, verwendet dieser Forward-confirmed reverse DNS (FCrDNS) für die Verifizierung. Dabei wird der PTR-Record von der IP-Adresse des Absenders (aus der TCP-Verbindung) überprüft. Anschließend wird geprüft, ob der A-Record der zurückgegebenen Domain auf dieselbe IP-Adresse zeigt. Wenn die IP-Adresse und Domain in beiden Einträgen übereinstimmen, gilt der Absender als vertrauenswürdig und die Nachricht wird mit geringerer Wahrscheinlichkeit als Spam eingestuft.
Zum Beispiel:
Folgendes passiert, wenn jemand anderes eine E-Mail von Ihnen empfängt:
Folgendes passiert, wenn jemand anderes eine E-Mail an Sie sendet:
CDN ist ein System, über das Website-Betreiber im Cache speicherbare Inhalte (z.B. statischen Ressourcen wie JavaScript, CSS oder große Dateien wie Bilder, Videos) von dem Server bereitstellen können, der dem Client am nächsten ist. Manchmal werden Edge-Server auch als Proxy eingesetzt, um Anfragen weiterzuleiten und den Origin-Server zu verbergen.
In einem CDN wird der Server, auf dem die ursprüngliche Version der Inhalte liegt, Origin-Server genannt:
Bei einem CDN gibt es zusätzlich mehrere Edge-Server, die über verschiedene geografische Standorte verteilt sind. Diese Edge-Server rufen die Inhalte vom Origin-Server ab und speichern sie in ihrem Cache. Wenn ein Nutzer den Inhalt aufruft, wird dieser von dem Edge-Server bereitgestellt, der dem Nutzer geografisch am nächsten ist.
Vereinfachte Beispiel-Visualisierung:
Vorteile im Überblick:
Technische Umsetzung:
Folgende Methoden werden für diesen Zweck häufig verwendet:
| DNS-basierte Lastverteilung | eine IP » ein Server |
| Mehrere Server mit jeweils eigener IP über die ganze Welt verteilt. DNS versucht die IP des Servers zurückzugeben, der dem Client geografisch am nächsten ist. | |
| Anycast-basierte Lastverteilung | eine IP » Gruppe von Servern |
| Mehrere Server teilen sich eine IP, die aus vielen verschiedenen Orten erreichbar ist. Internet-Routing findet automatisch den kürzesten Weg zu einem dieser Orte, basierend auf dem Standort des Clients im Internet. | |
Mit DNS-basierter Lastverteilung prüft der rekursive Nameserver die DNS-Records der angefragten Domain (z.B. example.com).
NS-Records delegieren die Domain an die Nameserver des CDN-Anbieters.
Der CDN-Anbieter:
Prüft den Standort des rekursiven Nameservers
Hier ist zu beachten, dass der rekursive Nameserver sich an einem anderen Standort befinden kann als der Client
Wählt einen Edge-Server, der dem Standort des rekursiven Nameservers am nächsten ist.
Die Edge-Server werden üblicherweise von einem CDN-Anbieter bereitgestellt und verwaltet.
Beispiel:
Mit Anycast-basierter Lastverteilung teilt sich eine Gruppe von Servern dieselbe öffentliche IP-Adresse.
Der Besitzer der Domain delegiert die Zone normalerweise zum CDN-Anbieter.
In der Domain-Zone des CDN-Anbieters zeigt ein A-Record auf die öffentliche IP-Adresse, die der Anycast-Gruppe der Edge-Server zugeordnet ist.
Die Edge-Server und deren Anycast-IP werden von einem CDN-Anbieter bereitgestellt und verwaltet.
Neben Edge-Servern wird Anycast-basierte Lastverteilung auch häufig bei DNS-Nameservern verwendet, insbesondere bei Root-Servern, TLD-Servern und großen autoritativen DNS-Anbietern (siehe zum Beispiel die Beschreibung des F-Root, einem der 13 Internet Root-Nameserver).
Im Gegensatz zu DNS-basierter Lastverteilung muss Anycast-basierte Lastverteilung nicht den Standort des Clients bestimmen oder geografische Berechnungen durchführen, da es ein bestehendes Routing-Protokoll verwendet.
Das Routing-Protokoll, das im Internet verwendet wird, wählt meist die Route mit den niedrigsten Kosten. Die Kosten steigen, je höher die Anzahl der Autonomous Systems (ASes), je länger der Pfad (Latenz) und je geringer die verfügbare Bandbreite. Der kosteneffizienteste Pfad zu einem Ziel in einer Anycast-Gruppe ist häufig der Server, der dem Client geografisch am nächsten liegt.
Beispiel:
Ein Client in Toronto sendet eine Anfrage an example.com, was auf die IP-Adresse 203.0.113.1 aufgelöst wird.
Diese IP-Adresse wird von zwei Servern gemeinsam genutzt: einem in Ashburn und einem weiteren in Helsinki.
Folgende Netzwerkpfade sind möglich:
Das Routing-Protokoll weiß nicht, dass das Ziel tatsächlich zwei verschiedene Maschinen sind, da es keine Informationen über geografische Standorte hat. Aus der Sicht vom Routing-Protokoll gibt es nur eine Quelle und ein Ziel. Für das Routing-Protokoll ist das Ziel eine einzelne Maschine an einem einzigen Standort, mit mehreren möglichen Pfaden, um es zu erreichen. Das liegt daran, dass das Routing-Protokoll Pfade nur als Abfolge von Autonomous Systems (ASes) sieht:
In diesem Beispiel würde der Pfad, bei dem nur ein AS dazwischenliegt wahrscheinlich dem Pfad vorgezogen werden, bei dem zwei ASes dazwischenliegen. Meist entspricht der kostengünstigste Pfad gleichzeitig auch dem geografisch nächstgelegenen Server.