Reverse-DNS (rDNS) ordnet einer IP-Adresse einen Hostnamen zu - das Gegenteil der normalen DNS-Auflösung. PTR-Records sind besonders für E-Mail-Server wichtig.
Was ist Reverse-DNS?
Forward vs Reverse DNS
Forward DNS:
mail.example.de → 192.168.1.10
Reverse DNS:
192.168.1.10 → mail.example.de
PTR = Pointer Record
Warum wichtig?
1. E-Mail-Zustellung
- Spam-Filter prüfen PTR-Record
- Ohne PTR: E-Mails werden abgelehnt
2. Server-Authentizität
- Identität verifizieren
- SSH-Warnungen vermeiden
3. Logging
- Hostnames statt IPs in Logs
PTR-Record prüfen
Mit dig
# IPv4 Reverse Lookup
dig -x 192.168.1.10
# Oder direkt im in-addr.arpa Format
dig 10.1.168.192.in-addr.arpa PTR
# IPv6 Reverse Lookup
dig -x 2001:db8::1
Mit host
host 192.168.1.10
# Ausgabe: 10.1.168.192.in-addr.arpa domain name pointer mail.example.de.
Mit nslookup
nslookup 192.168.1.10
- https://mxtoolbox.com/ReverseLookup.aspx
- https://www.whatsmydns.net/reverse-dns-lookup
- https://www.dnswatch.info/
PTR-Record einrichten
Beim Hosting-Provider
Der PTR-Record wird vom Eigentümer der IP-Adresse gesetzt!
→ Bei vServern/Dedicated Servern:
Im Kundenportal des Providers
→ Bei Cloud-Anbietern:
AWS: Route 53 / EC2 Settings
Azure: Reverse DNS Settings
Google Cloud: DNS-Einstellungen
Typische Provider-Portale
Serverdiscounter:
1. Kundenbereich → Server verwalten
2. Netzwerk → Reverse-DNS
3. PTR-Eintrag setzen
Hetzner:
1. Robot → Server
2. IPs → PTR setzen
Netcup:
1. Server Control Panel
2. Netzwerk → Reverse-DNS
IPv4
IP: 192.168.1.10
PTR-Name: 10.1.168.192.in-addr.arpa
PTR-Wert: mail.example.de.
Format: [letzte Oktet].[dritte].[zweite].[erste].in-addr.arpa
IPv6
IP: 2001:db8:85a3::8a2e:370:7334
PTR-Name: 4.3.3.7.0.7.3.0.e.2.a.8.0.0.0.0.0.0.0.0.3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa
PTR-Wert: mail.example.de.
Jede Hex-Ziffer wird einzeln umgekehrt!
Berechnung IPv6 PTR
# Mit ipcalc
ipcalc 2001:db8::1 -r
# Manuell:
# 2001:0db8:0000:0000:0000:0000:0000:0001
# Umkehren: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2
# Anhängen: .ip6.arpa
Eigene Reverse-Zone verwalten
Voraussetzung
- Sie müssen einen IP-Block (Subnet) besitzen
- Typisch: /24 für IPv4, /48 für IPv6
- Kleinere Blöcke: Delegation durch Provider
BIND Reverse-Zone
# /etc/bind/named.conf.local
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/zones/db.192.168.1";
allow-transfer { 192.168.1.2; };
};
; /etc/bind/zones/db.192.168.1
$TTL 86400
@ IN SOA ns1.example.de. admin.example.de. (
2026012601
3600
1800
604800
86400 )
IN NS ns1.example.de.
IN NS ns2.example.de.
; PTR Records
10 IN PTR www.example.de.
20 IN PTR mail.example.de.
30 IN PTR ftp.example.de.
PowerDNS Reverse-Zone
# Zone erstellen
pdnsutil create-zone 1.168.192.in-addr.arpa ns1.example.de
# PTR-Records
pdnsutil add-record 1.168.192.in-addr.arpa 10 PTR www.example.de
pdnsutil add-record 1.168.192.in-addr.arpa 20 PTR mail.example.de
Best Practices
Forward und Reverse übereinstimmen
Forward: mail.example.de → 192.168.1.20
Reverse: 192.168.1.20 → mail.example.de
Beide MÜSSEN übereinstimmen (FCrDNS)!
FCrDNS (Forward Confirmed Reverse DNS)
# Prüfen
IP=192.168.1.20
HOSTNAME=$(dig -x $IP +short)
RESOLVED_IP=$(dig $HOSTNAME A +short)
if [ "$IP" = "$RESOLVED_IP" ]; then
echo "FCrDNS OK"
else
echo "FCrDNS FAILED"
fi
E-Mail-Konfiguration
PTR: 192.168.1.20 → mail.example.de
A: mail.example.de → 192.168.1.20
MX: example.de → mail.example.de
SPF: v=spf1 ip4:192.168.1.20 -all
E-Mail-Server testen
Vollständige Prüfung
# PTR
dig -x 192.168.1.20 +short
# Sollte: mail.example.de. ausgeben
# A-Record
dig mail.example.de A +short
# Sollte: 192.168.1.20 ausgeben
# MX-Record
dig example.de MX +short
# Sollte: 10 mail.example.de. ausgeben
https://mxtoolbox.com/SuperTool.aspx
Eingabe: 192.168.1.20
→ Zeigt PTR, Blacklist-Status, etc.
mail-tester.com
1. E-Mail an test@mail-tester.com senden
2. Ergebnis auf Website prüfen
3. Zeigt PTR-Probleme an
Häufige Probleme
Kein PTR-Record
Problem: E-Mails werden als Spam markiert oder abgelehnt
Lösung:
1. PTR-Record beim Provider setzen
2. 24-48h auf Propagierung warten
3. Erneut testen
PTR stimmt nicht überein
Problem:
PTR: mail.provider.de (vom Provider)
Gewünscht: mail.example.de
Lösung:
1. PTR beim Provider ändern
2. Alternativ: IP mit korrektem PTR vom Provider
Mehrere PTR-Records
Problem: Eine IP hat mehrere PTR-Records
Lösung: Nur EIN PTR-Record pro IP
(technisch möglich, aber nicht empfohlen)
Generischer PTR
Problem:
PTR: static-192-168-1-20.provider.de
Manche Mailserver akzeptieren generische PTRs nicht!
Lösung: Eigenen Hostnamen als PTR setzen
Automatisierung
PTR-Check Skript
#!/bin/bash
# /usr/local/bin/check-ptr.sh
IP="$1"
EXPECTED="$2"
PTR=$(dig -x "$IP" +short | sed 's/\.$//')
if [ "$PTR" = "$EXPECTED" ]; then
echo "OK: $IP → $PTR"
exit 0
else
echo "FAIL: $IP → $PTR (expected: $EXPECTED)"
exit 1
fi
Monitoring mit Nagios/Icinga
#!/bin/bash
# check_ptr.sh
IP=$1
EXPECTED=$2
PTR=$(dig -x "$IP" +short 2>/dev/null | head -1 | sed 's/\.$//')
if [ -z "$PTR" ]; then
echo "CRITICAL - No PTR record for $IP"
exit 2
elif [ "$PTR" != "$EXPECTED" ]; then
echo "WARNING - PTR mismatch: $PTR (expected $EXPECTED)"
exit 1
else
echo "OK - PTR: $PTR"
exit 0
fi
Zusammenfassung
| Aspekt | Details |
|---|
| PTR-Record | IP → Hostname |
| A-Record | Hostname → IP |
| FCrDNS | Beide müssen übereinstimmen |
| Zuständig | IP-Eigentümer (Provider) |
| Befehl | Funktion |
|---|
| dig -x IP | Reverse Lookup |
| host IP | Reverse Lookup |
| nslookup IP | Reverse Lookup |
| E-Mail-Relevanz | Beschreibung |
|---|
| Spam-Filter | Prüfen PTR-Record |
| Blacklists | Prüfen PTR |
| DMARC/SPF | Ergänzend zum PTR |
| Häufige Fehler | Lösung |
|---|
| Kein PTR | Beim Provider setzen |
| Falscher PTR | Provider kontaktieren |
| Mehrere PTRs | Auf einen reduzieren |
Fazit
PTR-Records sind für E-Mail-Server unverzichtbar. Ohne korrekten Reverse-DNS werden E-Mails häufig als Spam markiert oder abgelehnt. Der PTR muss beim IP-Eigentümer (meist dem Hosting-Provider) eingetragen werden und mit dem Forward-DNS übereinstimmen. Regelmäßige Prüfung der DNS-Konfiguration verhindert Zustellprobleme.