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: