-=Kernel-Error=-

IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: Email (Seite 4 von 11)

Apache 2.4 und Diffie-Hellman DHE mit 4096bit

6. Juli 2015 / / Keine Kommentare

Kaum geht mein Artikel zur erweiterten Sicherheit meiner Webseite online >>TLS Sicherheit weiter verschärft….<< schon kommen Fragen. Eine habe ich nun schon vier mal bekomme, daher hier direkt die Antwort. Ach ja, die Frage:

Wie habe ich meinen Apache dazu überredet DHE-Keys mit 4096bit zu benutzen?

Also… Der Apache beherrscht seit Version 2.4 Diffie Hellman mit mehr als 1024bit. Um dieses nutzen zu können, muss der Apache die passenden dh-params haben. Der Apache nutzt dabei automatisch die ihm gegebene Key stärke.

Ich generiere den DH Teil gerne direkt mit dem jeweiligen Zertifikat und verbinde dieses. Beschrieben habe ich es hier: >>Sicheres SSL / TLS Zertifikat<<

Wer gerne nachträglich generieren möchte macht es mir:

$ openssl gendh 4096 > dh_4096.pem

Dieses lässt sich nun einfach wie ein normales Zertifikat mit in die Konfiguration des Apachen einbinden. Im Grunde nichts besonders und nachdem man es gelesen und absolut einleuchtend, man sucht aber dann doch zuerst etwas.

Viele andere Dienste (Postfix usw…) bringen ja meist einen eigenen Konfigurationspunkt dafür mit. Im Apache liegt es ohne große Konfiguration in Zertifikatsnähe.

easy

So long….

Fragen? Einfach melden.

Testtool Liste für schnelle und einfache Tests

2. Juli 2015 / / Keine Kommentare

Ich bin schon ein paar mal darum gebeten worden, doch bitte eine gesammelte Liste der verschiedenen Testtools zu erstellen.

Hiermit möchte ich dieser Bitte nachkommen.

Bitte beachtet aber, dass diese Tests/Checks in den meisten Fällen grob sind und nur verlässlich mitteilen können, ob etwas klappt oder nicht. Dennoch ist es hier und da eine schnelle und einfache Hilfe für Experimente und/oder um zu prüfen ob eine Änderungen greift!

So long….

Tests für Mail Server

SSL/TLS/TLSA/DANE/DNSSEC/SMTP Tests:
https://de.ssl-tools.net/mailservers/kernel-error.de

SSL/TLS/SMTP/POP/IMAP Tests:
http://www.checktls.com/

DANE SMTP Validator:
https://dane.sys4.de/smtp/kernel-error.de

DMARC TEST:
https://dmarcian.com/dmarc-inspector/kernel-error.de

SPF TEST:
https://dmarcian.com/spf-survey/kernel-error.de

http://www.kitterman.com/spf/validate.html

Mailserver Blacklist check:
http://mxtoolbox.com/blacklists.aspx

https://talosintelligence.com/

http://www.barracudacentral.org/lookups

DKIM / SPF / DMARC E-Mail Testadresse:
check-auth@verifier.port25.com

check-auth2@verifier.port25.com

Microsoft Tests:

https://testconnectivity.microsoft.com

Tests für Web Server

SSL/TLS Test:
https://www.ssllabs.com/ssltest/analyze.html?d=kernel-error.de

https://de.ssl-tools.net/webservers/www.kernel-error.de

SPDY Test:
https://spdycheck.org/#www.kernel-error.de

Tests für DNS Server

DNSserver:
http://www.dnsinspect.com/kernel-error.de

DNSSEC:
http://dnssec-debugger.verisignlabs.com/www.kernel-error.de

http://dnsviz.net/d/kernel-error.de/dnssec/

Tests für Jabber/XMPP Server

Jabber/XMMPP-Security Test:
http://www.xmpp.net/

Tests für Clients

IPv6 Client-Test:
http://test-ipv6.com

Webbrowser Test:
https://www.ssllabs.com/ssltest/viewMyClient.html

OPENGPGKEY RR:
https://openpgpkey.info/?email=kernel-error%40kernel-error.com

Siehe auch: Hardenize Security Scanner

Fragen? Einfach melden.

OPENPGPKEY: GPG-Schlüssel direkt im DNS veröffentlichen

1. April 2015 / / Keine Kommentare

Schon länger kann man GPG-Schlüssel per CERT-Record im DNS hinterlegen — allerdings nur als Verweis auf einen Ort, an dem der Schlüssel liegt. Mit dem OPENPGPKEY Resource Record (RFC 7929) geht es einen Schritt weiter: Der komplette öffentliche Schlüssel steckt direkt im DNS-Record. Ist die Zone per DNSSEC gesichert, kann der Schlüssel nicht gefälscht werden — unabhängig von Keyservern und den dort möglicherweise kursierenden Fake-Keys.

Aufbau des Records

Der Hostname des OPENPGPKEY-Records wird aus der E-Mail-Adresse abgeleitet. Aus dem Localpart (alles vor dem @) wird ein SHA-256-Hash gebildet und die ersten 56 Zeichen davon als Subdomain unter _openpgpkey.domain verwendet. Für user@example.de:

echo -n "user" | sha256sum
# Ergebnis: 04f8996da763b7a969b1028ee3007569eaf3a635486ddab211d512c85b9df8fb
# Die ersten 56 Zeichen des Hashes werden zum Hostnamen:
04f8996da763b7a969b1028ee3007569eaf3a635486ddab211d512c85b._openpgpkey.example.de. IN OPENPGPKEY <base64-encoded-key>

Der Wert des Records ist der GPG Public Key im Binärformat, Base64-kodiert.

Record erzeugen

Den Hash des Localparts berechnen:

echo -n "kernel-error" | sha256sum | cut -c1-56
# 4e1543e4c2a42754aa23025a940a30d0d3d106025c9e03be8e525ac4

Den Public Key exportieren und Base64-kodieren:

gpg --export --export-options export-minimal kernel-error@kernel-error.com \
  | base64 -w 0

Beides zusammen ergibt den Zoneneintrag:

4e1543e4c2a42754aa23025a940a30d0d3d106025c9e03be8e525ac4._openpgpkey.kernel-error.com. IN OPENPGPKEY mQINBF...==

Zugegeben — der Record sprengt etwas die Zonenlesbarkeit. Ein GPG-Schlüssel hat schnell mehrere Kilobyte, das wird im Zonefile eine lange Zeile. BIND kommt damit problemlos klar.

Schlüssel automatisch aus dem DNS holen

GnuPG ab Version 2.1 kann OPENPGPKEY-Records direkt abfragen. Will man eine E-Mail verschlüsseln und hat den Schlüssel des Empfängers noch nicht, reicht:

gpg --auto-key-locate dane --locate-keys kernel-error@kernel-error.com

GnuPG sucht den OPENPGPKEY-Record im DNS, prüft die DNSSEC-Signatur und importiert den Schlüssel automatisch. Kein Keyserver nötig, kein manueller Import.

Testen

Ob der Record korrekt im DNS steht, lässt sich online prüfen: openpgpkey.info — E-Mail-Adresse eingeben, der Dienst fragt den OPENPGPKEY-Record ab und zeigt den gefundenen Schlüssel an.

OPENPGPKEY vs. CERT-Record

Der ältere CERT-Record enthält nur eine URL zum Schlüssel — der Client muss den Schlüssel dann von dort herunterladen. OPENPGPKEY packt den kompletten Schlüssel ins DNS. Vorteil: Ein einziger DNS-Lookup genügt, kein zusätzlicher HTTP-Request nötig. Nachteil: Große DNS-Antworten, die bei UDP-Transport fragmentiert werden können — aber mit passender EDNS-Konfiguration kein Problem.

Siehe auch: GPG-Schlüssel per PKA im DNS, GPG: E-Mails signieren und verschlüsseln mit GnuPG, Der sichere GPG-Schlüssel

Fragen? Einfach melden.

Postfix und DANE: „Server certificate not verified“ debuggen

2. Februar 2015 / / Keine Kommentare

Eine Mail kommt als unzustellbar zurück. Im Bounce steht Server certificate not verified, im Postfix-Log sieht es so aus:

smtp[1520]: Trusted TLS connection established to example.de[...]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384
smtp[1520]: 30E4E7461347: Server certificate not verified
smtp[1520]: 30E4E7461347: to=, dsn=4.7.5, status=deferred (Server certificate not verified)

Erst „Trusted TLS connection“, dann „Server certificate not verified“. Das klingt widersprüchlich, hat aber eine klare Ursache.

Ursache: DANE/TLSA-Prüfung fehlgeschlagen

Ohne DANE würde Postfix die Mail trotzdem zustellen, auch wenn das Zertifikat nicht verifizierbar ist. Aber wenn der Empfänger einen TLSA-Record im DNS veröffentlicht hat, prüft Postfix das Zertifikat gegen diesen Record. Stimmt der Hash nicht überein, verweigert Postfix die Zustellung. Das ist gewolltes Verhalten: Entweder der Empfänger hat seinen TLSA-Record nicht aktualisiert (z.B. nach einem Zertifikatstausch), oder jemand versucht sich dazwischen zu drängen.

Debugging mit posttls-finger

posttls-finger (Teil von Postfix) prüft den kompletten DANE-Ablauf für eine Domain:

posttls-finger -t30 -T180 -c -L verbose,summary example.de

In der Ausgabe steht am Ende entweder Verified TLS connection established (alles OK) oder Untrusted TLS connection established (TLSA-Prüfung fehlgeschlagen). Zusätzlich zeigt das Tool den TLSA-Record aus dem DNS und den Fingerprint des Zertifikats. Stimmen die beiden nicht überein, liegt das Problem beim Empfänger.

Was Postfix dann macht

Eine fehlgeschlagene DANE-Prüfung erzeugt einen temporären Fehler (4.7.5). Postfix behält die Mail in der Queue und versucht es über mehrere Tage erneut. Wenn der Empfänger seinen TLSA-Record in der Zwischenzeit korrigiert, geht die Mail durch. Passiert das nicht, kommt die Mail als Bounce zurück.

Das ist genau das richtige Verhalten. Lieber eine Mail verzögern als sie über eine möglicherweise kompromittierte Verbindung zuzustellen. Wer TLSA-Records manuell prüfen will, findet dazu eine Anleitung mit OpenSSL. Die Grundlagen zu DANE und Postfix stehen im Beitrag Postfix mit DANE und DNSSEC absichern. Fragen? Einfach melden.

Thunderbird Filelink und owncloud / nextcloud

2. Februar 2015 / / Keine Kommentare

Inzwischen hat ja fast jeder bei uns „schnelles“ Internet…. So lassen sich per E-Mail auch mal etwas größere Dateien verschicken. Dennoch sollte man so ab 5MB ein schlechtes Gefühl haben und sich ab 10MB Anhängen nicht mehr über abgewiesene E-Mails ärgern.

Das Problem mit großen Dateianhängen bei E-Mails ist ja nicht nur die Verstopfung der Leitungen… Mailserver arbeiten sich daran ab, der absendende und empfangende Client ebenfalls. Hängt dann noch ein Virenscanner dazwischen rechnet noch jemand. Dann liegt die Datei auf dem System des Absenders, in dessen Postfach, im Postfach dem Empfängers und natürlich noch auf dem System des Empfängers. Bei einem 500MB Anhang sind das schon mal 2GB für nix.

Inzwischen gibt es 1000 Möglichkeiten um große Dateien schnell und einfach auszutauschen. Selbst ohne seine Daten auf irgendeinen Server bei irgendeinem Anbieter zu legen. So zum Beispiel über owncloud….. Hochladen muss man die Datei ja in jedem Fall zu seinem Mailserver, warum also nicht lieber in die „Cloud“? Ok, es ist etwas aufwendig. Erst hochladen, dann teilen, dann den Link kopieren und in die E-Mail packen, usw. usw…

Für Anwender des Mailclients Thunderbird gibt es in diesem Zusammenhang eine noch schönere Lösung. Sie nennt sich filelink. Im Grunde nichts weiter als eine kleine Funktion, welche dem Anwender etwas Arbeit abnimmt!

Hängt der Anwender eine Datei an seine E-Mail an, welche einen einstellbaren Schwellwert überschreitet, schlägt Thunderbird diesem vor, den Anhang für den Anwender in einen dieser „Austauschservices“ zu laden. Stimmt der Anwender zu, schiebt Thunderbird die Datei hoch und verlinkt sie automatisch in den E-Mail Body. Dieses hält die E-Mai klein und der Empfänger kann selbst entscheiden, ob und wann er den „Anhang“ herunterladen möchte.

Aktuell bringt Thunderbird aus dem Karton leider nur die Verknüpfung zu den bekannten großen Anbietern wie z.B.: dopbox mit. Dort möchte man ja nicht unbedingt seine Daten ablegen. Für owncloud habe ich vor kurzem eine gut funktionierendes Thunderbird Plugin gefunden:

https://github.com/guillaumev/owncloud_for_filelink

Einfach herunterladen, installieren, zwei drei Kleinigkeiten in der eigenen Cloud einstellen und glücklich sein. Mit zwei/drei erklärenden Sätzen in der E-Mail versteht es zudem fast jeder Empfänger. Noch Fragen?

Fragen? Einfach melden.

Mal wieder auffällig viele Brute-Force SSH Angriffe….

11. Januar 2015 / / Keine Kommentare

Seit gestern fällt es irgendwie auf… Da rattert wieder etwas über die Systeme.

Probiert werden die User:

– root
– admin
– mail
– Alphanetworks
– MANAGER
– test
– Factory
– vodafone
– telecomadmin
– draytek
– super
– FIELD
– ADVMAIL
– WP
– HELLO
– citel
– SPOOLMAN
– comcast
– wlseuser
– OPERATOR
– PCUSER
– MGR
– patrol
– netadmin
– anonymous
– craft
– websecadm
– netman
– MD110
– supervisor
– tiger
– manuf
– PBX
– NETWORK
– MDaemon
– readonly
– davox
– scout
– blank
– coress
– usw. usw. usw…..

Spannenderweise mit immer neuen Adressen aus verschiedenen großen Netzen. Im groben lässt es sich „eindampfen“ auf:

– 117.253.0.0/16
– 109.161.236.0/22
– 189.51.16.0/20

Hier und da noch etwas verteiltes… Indien, Brasilien, Italien, wenn man dem WHOIS trauen kann. Was da wieder los ist? Dann wird wohl bald wieder mehr Spam kommen, hm?

Ich wünsche in jedem Fall ein paar klebrige Finger!

Jan 11 11:42:53 ssh-honeypot sshd[21822]: Invalid user MANAGER from 182.74.23.34
Jan 11 11:42:53 ssh-honeypot sshd[21822]: input_userauth_request: invalid user MANAGER [preauth]
Jan 11 11:42:56 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:42:58 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:01 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:03 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:05 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2
Jan 11 11:43:08 ssh-honeypot sshd[21822]: Failed password for invalid user MANAGER from 182.74.23.34 port 2657 ssh2

Siehe auch: SSH-Server absichern mit MFA, SSH Brute Force, Raspberry Pi als Angriffsziel: SSH-Brute-Force auf den User pi, SSH-Brute-Force mit veralteter Implementierung: Angriffsmuster erkennen​

Fragen? Einfach melden.

Postfix: TLS-Protokoll und Cipher-Infos im E-Mail-Header anzeigen​

17. Dezember 2014 / / Keine Kommentare

Als kleiner Postfix Tipp am Rande…. Wenn man gerade mit seinen TLS Einstellungen „herumspielt“, kann es helfen die groben Informationen für jede E-Mail nicht immer aus dem Logfile sammeln zu müssen.

Postfix bietet die schnelle Möglichkeit, genau diese Informationen einfach mit in den Mail Header zu packen.

Folgende Konfigurationserweiterung ist dafür nötig:

/etc/postfix/main.cf:
smtpd_tls_received_header = yes

Ab diesem Moment finden sich Informationen wie die unten stehende in eingehenden E-Mails.

So long….

Received: from mx01.domain.de (mx01.domain.de [1.2.3.4])
    (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits))
    (No client certificate requested)
    by smtp.kernel-error.de (Postfix) with ESMTPS id 245478112D9
    for <kernel-error@kernel-error.com>; Wed, 17 Dec 2014 05:15:10 +0100 (CET)

Siehe auch: Client-Initiated Renegotiation deaktivieren

Fragen? Einfach melden.

Postfix: EECDH mit 2048-Bit DH und spezifischen Kurven konfigurieren​

17. Dezember 2014 / / Keine Kommentare

Kex exchange basierend auf EECDH (diese elliptischen Kurven nach DH Diffie-Hellmann), sollte ja inzwischen ein alter Hut sein. Ich gehe also mal von einer aktivieten und funktionsfähigen Konfiguration aus (irgendwo habe ich das wohl auch schon mal beschrieben).

Im Standard läuft dieses nun bei 1024bit also EECDH mit ca. 128bit (smtpd_tls_eecdh_grade=strong). Möchte man alles auf 2048bit EECDH mit ca. 192bit aufbohren… Was ca. die doppelte „Sicherheit“ zu EECDH mit 128bit bedeutet, dann ist folgendes zu erledigen.

Zuerst benötigen für eine große prime group:

$ cd /etc/postfix
$ openssl dhparam -out dh_2048.tmp 2048 && mv dh_2048.tmp dh_2048.pem
$ chmod 644 dh_2048.pem

Dann Postifix mitteilen, dass er sie bitte nutzten soll (ist kein Typo, gehört zur Option „smtpd_tls_dh1024_param_file„). 

/etc/postfix/main.cf:
    smtpd_tls_dh1024_param_file = /etc/postfix/dh2048.pem
    smtpd_tls_dh512_param_file = /etc/postfix/dh512.pem

Nun wechselt smtpd_tls_eecdh_grade von strong zu ultra und ich setzte noch die zu verwendende „Kurve“ fest.

/etc/postfix/main.cf:
    smtpd_tls_eecdh_grade = ultra
    tls_eecdh_strong_curve = prime256v1
    tls_eecdh_ultra_curve = secp384r1

Diese Aktion könne nicht ganz Schmerzfrei sein. Für privat und mein Testsystem sicher zu verantworten. Manche MSA (Mail SUbmission Agent) könnten damit Probleme bekommen. Hat also jemand ein Problem mit E-Mail zu senden, bitte melden.

So long….

Siehe auch: Perfect Forward Secrecy

Fragen? Einfach melden.

TLS_FALLBACK_SCSV Debian 7 Wheezy OpenSSL 1.0.1e to 1.0.1j Upgrade

9. Dezember 2014 / / Keine Kommentare

Veraltet: Debian 7 (Wheezy) hat seit 2018 keinerlei Support mehr. TLS_FALLBACK_SCSV ist seit Jahren in allen aktuellen OpenSSL-Versionen enthalten und muss nicht mehr manuell kompiliert werden.

Wer bei seinem Debian TLS_FALLBACK_SCSV im Apache nutzen möchte, muss im Grunde nur auf eine OpenSSL Version >=1.0.1j wechseln.

Einen direkten Backport gibt es dafür leider nicht, also selbst übersetzten. Dazu nutzt man einfachsten direkt den „Debian-Weg“.

Vorbereiten fürs Kompilieren:

$ cd /usr/src
$ apt-get install build-essential fakeroot
$ apt-get build-dep openssl

Herunterladen der aktuellen Version:

$ wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1j-1.dsc
$ wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1j.orig.tar.gz
$ wget http://ftp.de.debian.org/debian/pool/main/o/openssl/openssl_1.0.1j-1.debian.tar.xz

Auspacken des Archives und mit den Patchen „verknüpfen“:

$ dpkg-source -x openssl_1.0.1j-1.dsc

Ins neue Verzeichnis wechseln:

$ cd openssl-1.0.1j

Kompilieren und deb Pakete erstellen:

$ dpkg-buildpackage -us -uc -rfakeroot

Die neuen Pakete installieren:

$ cd ..
$ dpkg -i libssl1.0.0_1.0.1j-1_amd64.deb libssl1.0.0-dbg_1.0.1j-1_amd64.deb libssl-dev_1.0.1j-1_amd64.deb libssl-doc_1.0.1j-1_all.deb openssl_1.0.1j-1_amd64.deb

Kontrolle der Version:

$ openssl version
OpenSSL 1.0.1j 15 Oct 2014

ACHTUNG… Ab diesem Moment ist man natürlich selbst dafür verantwortlich Pachte zu installieren.

So long…..

Selbstverständlich profitieren damit alle Anwendungen, die auf OpenSSL aufbauen, so auch Postfix, Dovecot usw:

$ openssl s_client -connect smtp.kernel-error.de:465 -fallback_scsv -no_tls1_2
CONNECTED(00000003)
140410198378152:error:1407743E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert inappropriate fallback:s23_clnt.c:770:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 215 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

U-P-D-A-T-E

Denkt an die Updates.

$ openssl version
OpenSSL 1.0.1k 8 Jan 2015

IP Reverse Map Delegation: Einrichtung und Fehlerbehebung

17. Oktober 2014 / / Keine Kommentare

Reverse Map Delegation nach RFC 2317 klingt komplizierter als es ist. Es löst ein konkretes Problem: Wer ein kleines IP-Netz hat (kleiner als /24), kann normalerweise keine eigene PTR-Zone betreiben. Mit Reverse Map Delegation geht es doch.

Warum man es braucht

In der guten alten Zeit bekam man ein /24 (256 Adressen). Da legt man einfach eine Zone 3.2.1.in-addr.arpa. an und fertig. Heute bekommt man, wenn überhaupt, ein /29 (8 Adressen). Und da liegt das Problem: DNS-Zonen werden am Punkt getrennt. Bei einem /24 passt das, bei einem /29 gibt es keinen Punkt an dem man die Zone aufteilen kann.

Der Provider behält also die /24-Zone und richtet für das kleine Subnetz CNAMEs ein, die auf eine „Sub-Zone“ des Kunden zeigen. Der Kunde kann dann seine PTR-Records selbst verwalten.

Die Provider-Seite

In der /24-Zone des Providers wird für das Subnetz 1.2.3.0/29 eine Delegation eingerichtet. Jede IP-Adresse bekommt einen CNAME in die Sub-Zone des Kunden:

$ORIGIN 3.2.1.in-addr.arpa.
$TTL 1D
@   1D IN SOA ns1.kernel-error.de. hostmaster.kernel-error.de. (
              2014101701 ; serial
              6H         ; refresh
              30M        ; retry
              2W         ; expiry
              1D )       ; minimum

         IN NS  ns1.kernel-error.de.
         IN NS  ns2.kernel-error.org.

; Delegation für 1.2.3.0/29 an den Kunden
0/29     IN NS    ns1.vandemeer.de.
0/29     IN NS    ns2.vandemeer.de.
0        IN CNAME 0.0/29.3.2.1.in-addr.arpa.
1        IN CNAME 1.0/29.3.2.1.in-addr.arpa.
2        IN CNAME 2.0/29.3.2.1.in-addr.arpa.
3        IN CNAME 3.0/29.3.2.1.in-addr.arpa.
4        IN CNAME 4.0/29.3.2.1.in-addr.arpa.
5        IN CNAME 5.0/29.3.2.1.in-addr.arpa.
6        IN CNAME 6.0/29.3.2.1.in-addr.arpa.
7        IN CNAME 7.0/29.3.2.1.in-addr.arpa.

Die Kunden-Seite

Der Kunde richtet auf seinem DNS-Server die Sub-Zone ein und kann dort seine PTR-Records setzen wie gewohnt:

$ORIGIN 0/29.3.2.1.in-addr.arpa.
$TTL 1D
@   1D IN SOA ns1.vandemeer.de. hostmaster.vandemeer.de. (
              2014101701 ; serial
              6H         ; refresh
              30M        ; retry
              2W         ; expiry
              1D )       ; minimum

         IN NS  ns1.vandemeer.de.
         IN NS  ns2.vandemeer.de.

0        IN PTR netzadresse.vandemeer.de.
1        IN PTR router.vandemeer.de.
2        IN PTR mailin.vandemeer.de.
3        IN PTR imap.vandemeer.de.
4        IN PTR webserver.vandemeer.de.
5        IN PTR frei.vandemeer.de.
6        IN PTR frei.vandemeer.de.
7        IN PTR broadcastadresse.vandemeer.de.

Ergebnis

Eine Reverse-Lookup-Abfrage für 1.2.3.4 läuft jetzt über den CNAME zum DNS des Kunden und liefert den gewünschten PTR-Record:

dig -x 1.2.3.4 +short
4.0/29.3.2.1.in-addr.arpa.
webserver.vandemeer.de.

Probleme

Wäre ja zu schön, wenn es keine gäbe.

Laut RFC darf ein PTR-Record eigentlich kein CNAME sein, außer in genau diesem Fall. Das RFC ist von 1998, aber es hat sich nicht überall herumgesprochen. Man muss seinem Gegenüber gelegentlich RFC 2317 erklären, bevor die Diskussion weitergeht.

Außerdem macht Postfix Ärger, wenn man reject_unknown_client in den smtpd_restrictions hat. Diese Prüfung erwartet, dass PTR und A/AAAA-Record zueinander passen. Bei Reverse Map Delegation tun sie das nicht, weil der CNAME dazwischen steht:

450 4.7.1 Client host rejected: cannot find your hostname, [4.5.6.7]

Wer einen größeren Mailserver betreibt, sollte auf der Mail-IP kein Reverse Map Delegation einsetzen, sondern den PTR direkt beim Provider setzen lassen. Spart Arbeit und Ärger.

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑