Architecture

• Iterative DNS Query
  A request to a DNS server: Give me the final response to my request. Send out any additional requests as needed.

• Recursive DNS Query
  A request to a DNS server: Give me any information you have. Don't send out additional requests.

DNSSEC validation

This requires DS and DNSKey records. At the moment, Hetzner only supports DS records.

Domain Name System Security Extensions (DNSSEC) is a suite of extension specifications (e.g. DS and DNSKEY records) that are used to ensure that DNS responses from authoritative name servers to the recursive name server are secure and have not been intercepted or tampered with.

The recursive name server uses Key Signing Keys (KSK) and Zone Signing Keys (ZSK) from each authoritative name server to verify the authenticity of every DNS response — establishing a chain of trust.

To start the chain of trust, the recursive name server must already have the hashed PubKSK of the root name server stored locally. It's important that this key was obtained through means other than the DNS protocol (e.g. included in the operating system) to ensure its authenticity.

The DNSSEC Validation Steps

Let's assume the client wants to access https://example.com.

First, the recursive name server sends a request to the root zone. The root zone will refer to the .com zone and provide the hashed PubKSK of the .com zone.

If the recursive name server trusts the DNS response of the root zone, it can send a request to the .com zone and continue the chain of trust with the .com PubKSK provided by the root zone.

If the recursive name server trusts the DNS response of the .com zone, it can send a request to the example zone and continue the chain of trust with the example PubKSK provided by the .com zone.

If the recursive name server trusts the DNS response of the example zone, it can return the IP address of example.com to the client.

In the example above, the DNS records would look like this:

reverse DNS (rDNS)

Click here to learn how to edit the rDNS (PTR) of Hetzer IPs

Hetzner IPs have PTR records managed by Hetzner. By default, the IP points to a domain that looks like this:

static.1.113.0.203.clients.your-server.de

You can edit the value as explained in these articles:

• Hetzner Console
• Robot

In Hetzner Console, you can edit the value by selecting your cloud server or Load Balancer and navigating to the "Networking" tab in the top menu bar. Replace static.<your_reverse_ip>.clients.your-server.de with your own domain that points to the IP address of that cloud server or Load Balancer. The PTR record managed by Hetzner is automatically updated accordingly. You can edit the reverse DNS of Primary IPs and Floating IPs as well.

To edit a large number of reverse DNS entries, you may use the Robot Webservice or the Cloud API.

In a reverse DNS (rDNS) lookup, a client requests the domain name associated with an IP address (for example via dnschecker.org or dig -x <ip-address>).

The value of the IP address is defined in a PTR record that is usually set up by the provider who owns the IP address (e.g. Hetzner). PTR records for rDNS are not added in the zone of the domain. Instead, they are added in a reverse zone (e.g. <ip-in-reverse>.in-addr.arpa.) that belongs to the owner of the IP. For a more detailed description, see rDNS zones below.

For example:

In this example, the hostnames for forward and reverse DNS lookups match only once:

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      ─┐ hostnames
198.51.100.1       --->   mail.example.com  ─┘ match

Purpose of rDNS

• Tools like traceroute often resolve IP addresses to hostnames using reverse DNS. This makes it considerably easier to diagnose errors.
• Many mail servers only accept incoming emails if the sender's IP address has a reverse DNS entry.
• Reverse DNS entries can be included in SPF records (Sender Policy Framework — technology for the prevention of spam and virus-containing emails from spoof senders).

Allocation guidelines

We recommend the following allocation guidelines:

• The reverse DNS entry should not take the form of an automatically generated name, such as static.1.113.0.203.clients.your-server.de; spam filters might identify these as "spam".
• The domain, which the name derives from, should actually exist. Please do not invent any names.
• The reverse DNS entry should also resolve "forwards" to the same IP address.

  same.example.com   --->   192.0.2.254
  192.0.2.254        --->   same.example.com

• The hostname provided by the mail server while the connection is being established (HELO/EHLO) should match the reverse DNS entry for the corresponding IP address.

rDNS zones

The PTR record for an IP address is managed in the reverse DNS zone corresponding to that specific IP. Typically, a provider or organization owns an entire IP range. In such cases, the entire IP range is managed through a single reverse DNS zone that corresponds to the subnet.

The Internet Assigned Numbers Authority (IANA) manages the top-level reverse DNS zones in-addr.arpa and ip6.arpa. These zones delegate to the name servers of Regional Internet Registries (RIRs), which are responsible for the top-level subnet that the requested IP address falls into — often a /8 block (e.g. 203 in 203.0.113.1).

An RIR delegates top-level subnets (e.g. 203 in 203.0.113.1) to the name servers of the IP address owner who is responsible for the subnet that the requested IP address falls into — often a /16 or /24 block (e.g. 203.0 in 203.0.113.1).

Example:

DNS with mail servers

When a mail server sends out an email, the sender will look up the MX record for the domain that follows after the @ sign. If the email address is holu@example.com, for example, the sender will look up the MX record for example.com. The email is sent to the IP address provided in the DNS response. The sender does not check the PTR record of that IP address.

When a mail server receives an email, it uses Forward-confirmed reverse DNS (FCrDNS) verification. This involves checking the PTR record of the sending mail server's IP address (from the TCP source address) and verifying that the corresponding A record of the returned domain points back to the same IP address. If the IP and domain of both records match, the sender is considered more trustworthy and the message is less likely to be marked as spam.

For example:

Here's what happens when someone receives an email from you:

Here's what happens when someone else sends an email to you: