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.
This requires
DSandDNSKeyrecords. At the moment, Hetzner only supportsDSrecords.
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:
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.deYou can edit the value as explained in these articles:
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.dewith 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 ─┘ matchin-addr.arpa or ip6.arpa zone).
PTR record. If you add a PTR record in your domain zone, it will be ignored because the client never queries your zone for reverse lookups.
traceroute often resolve IP addresses to hostnames using reverse DNS. This makes it considerably easier to diagnose errors.We recommend the following allocation guidelines:
static.1.113.0.203.clients.your-server.de; spam filters might identify these as "spam".same.example.com ---> 192.0.2.254
192.0.2.254 ---> same.example.comThe 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:
| Owner | IP range | Addresses |
|---|---|---|
| Holu | 198.51.100.0/24 | 198.51.100.0 to 198.51.100.255 |
| Hetzner | 203.0.0.0/16 | 203.0.0.0 to 203.0.255.255 |
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:
CDN is a system that enables content owners to deliver cacheable content (e.g. static resources such as JavaScript, CSS or large files like images, videos) to users from the server closest to them. Sometimes edge servers are used to proxy requests, hiding the origin servers from the user.
In a CDN, the server that stores the original version of the content is called the origin server:
With a CDN, there are also multiple edge servers distributed across different geographic locations. These edge servers retrieve the content from the origin server and store it in their cache. When a user makes a request, the edge server nearest to them serves the cached content.
Simplified example visualisation:
Overview of advantages:
Technical implementation:
The following solutions are often used for that purpose:
| DNS-based load balancing | one IP » one server |
| Multiple servers, each with their own IP, are distributed across the world. DNS tries to return the IP address of the server that is geographically closest to the client. | |
| Anycast-based load balancing | one IP » fleet of servers |
| Multiple servers share a single IP address that is reachable from many different locations. Internet routing automatically finds the shortest path to one of these locations based on the client's location on the Internet. | |
With DNS-based load balancing, the recursive name server checks the DNS records for the requested domain (e.g. example.com).
NS records delegate the domain to the CDN provider.
The CDN provider:
Checks the location of the recursive name server
Note that sometimes the recursive name server may be in a different location than the client
Chooses an edge server that is closest to the location of the recursive name server.
The edge servers are usually provided and managed by a CDN provider.
Example:
With Anycast-based load balancing, a group of servers shares the same public IP address.
The domain owner usually delegates the zone to the CDN provider.
In the domain zone managed by the CDN, an A record points at the public IP address that belongs to the Anycast group of edge servers.
The edge servers and their Anycast IP are provided and managed by a CDN provider.
Apart from edge servers, Anycast-based load balancing is also widely used with DNS name servers, especially root servers, TLD servers, and large authoritative DNS providers (see the description for F-Root for example, one of the 13 Internet root name servers).
Unlike DNS-based load balancing, Anycast-based load balancing does not need to determine the client's location or perform geographic calculations, because it leverages an existing routing protocol.
The routing protocol used on the Internet selects the route with the lowest cost. Costs increase with a higher number of autonomous systems (ASes), a longer path (latency), and lower available bandwidth. As a result, the most cost-efficient path to a destination in an Anycast group is often the server that is geographically closest to the client.
Example:
A client in Toronto sends a request to example.com, which resolves to the IP address 203.0.113.1.
This IP address is shared by two servers: one in Ashburn, and another in Helsinki.
The following network paths are possible:
The routing protocol does not know that the destination actually corresponds to two different machines, because it has no information about geographical locations. To the routing protocol, there appears to be only one source and one destination. From the routing protocol's perspective, the destination is a single machine in a single location, with multiple possible paths to reach it. This is because the routing protocol only sees paths as sequences of autonomous systems (ASes):
In this example, the path with a single AS in between would likely be preferred over the path with two ASes in between. As it happens, the more cost-effective path often also corresponds to the geographically closest server.