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

Online-Tools

- 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

Format des PTR-Records

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

MXToolbox

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.