Um zu verstehen was mit reverse map delegation von IPv4 und IPv6 Adressen nach RFC 2317 (http://tools.ietf.org/html/rfc2317) gemeint ist, hilft es zu verstehen warum man es überhaupt braucht. Daher versuche ich mit meiner kurzen Erklärung damit zu starten….
Wenn man in der „guten alten Zeit“ des Internets ein paar öffentliche IPv4 Adresse brauchte, ging man zu seiner RIR und bekam ein /24 in die Hand.
Als Beispiel: 1.2.3.0/24 also mit der Netzmaske 255.255.255.0
So hatte man ein Netz mit 256 Adressen. Wenn man nun in seinem DNS eine Zone für die PTR-Records anlegen wollte, war es kein Problem. Man konnte ja ohne große Probleme die Zone 3.2.1.in-addr.arpa. anlegen und die Zone konnte alle 256 Adressen beinhalten und beantworten.
Inzwischen sind die IPv4 Adresse aber knapp, oder sagen wir besser… verbraucht! Man bekommt, wenn überhaupt, nur noch so viele, wie man auch gut begründen kann 🙂
Als Beispiel: 1.2.3.0/29 also mit der Netzmaske 255.255.255.248
So hat man ein kleines Netz mit 8 Adressen. Will man nun in seinem DNS eine Zone für die PTR-Records anlegen gibt es ein Problem. Denn im DNS macht man die einzelnen Domains, Subdomains usw. am Punkt fest!
Als Beispiel: www.kernel-error.de.
de ist dabei die Subdomain von der Root-Domain (.)
kernel-error ist demnach die Subdomain der TLD (de)
www ist nun die Subdomain/Hostadresse von (kernel-error)
Möchte ich also eine Zone für ein IP Netz mit der Netzmaske /24 – 255.255.255.0 anlegen, ist ein kein Problem da ich ja einfach den letzten Punkt als Trenner für meine DNS-Zone nutzen kann. Alle 256 möglichen IPv4 Adressen würden dann von dieser Zone bedient werden können. Bei einem /29 habe ich aber keine Möglichkeit die Zone auf die 8 möglichen IP-Adressen zu beschränken…
Natürlich könnte ich nun denn noch eine Zone anlegen, wie auch bei einem /24 und halt nur meine 8 IP-Adressen (6 Hostadressen). Dann gibt es aber zwei Probleme! 1. Dieser DNS Server würde sich auch für die anderen Adressen zuständig fühlen und falsche Antworten liefern. 2. Wird ein Netz vergeben muss dort auch ein zuständiger DNS Server für das Netz eingetragen werden. Ihr seht schon… das wird nix!
Was macht man also? Ganz einfach und sicher vielen bereits bekannt… Der Provider/Hoster oder oder übernimmt die DNS-Zone für das Netz. Seine Kunden müssen also alle Wünsche über die zu setzenden RECORDS bei diesem anfragen oder über ein Webinterface eintragen. Dieses ist ein gangbarer Weg… Leider ist es hin und wieder etwas zu unflexibel und/oder zu zeitintensive. Ebenso gibt es ja Menschen die ihren DNS-Server gerne selbst unter Kontrolle haben, richtig?
Genau hier kommt dieses reverse map delegation ins Spiel. Zwar ist der im Netz eingetragene DNS Server noch immer der vom Provider… Dieser setzt aber keinen echten Hostename mehr zu den einzelnen IP Adressen, sondern einen CNAME zu einem in der DNS Domain des Kunden. So kann der Kunde die „PTR-RECORDS“ für seine IP Adressen über einen kleinen Umweg denn noch selbst setzten. Das ist schon die ganze Magie hinter diesem Begriff….
Wie sieht es nun in der Praxis aus? Ich bleibe bei meinem Beispiel des Netzes 1.2.3.0/29 und beschreibe wie ich es in er Regel einrichte….
Die Zone des /24 würde damit wie folgt aussehen:
$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.
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.
Wie zu erkennen, ist die Zone zuständig für 1.2.3.0-255… Die DNS Server sind dabei (ns1.kernel-error.de und n2.kernle-error.org). Das erste /29 aus diesem /24 gehört dem Kunden hinter der Domain vandemeer.de. Es wird also eine „Subdomain“ angelegt mit dem Namen 0/29. Die 0 steht dabei für die Netzadresse des Netzes und die 29 für die CIDR Suffix. Diese „Subdomain“ wird von den DNS Servern ns1.vandemeer.de und ns2.vandemeer.de bedient. Damit nun alle angefragten PTR-RECORDS für dieses Netz auch an den DNS-Server des Kunden weiter gehen, muss für jede IP Adresse ein CNAME für eine Adresse in der neuen Zone des Kunden erstellt werden.
Für die IPv4-Adresse 1.2.3.4 wäre es also:
4 IN CNAME 4.0/29.3.2.1.in-addr.arpa.
Eine Abfrage mit dig würde jetzt bereits folgende Antwort liefern:
$ dig -x 1.2.3.4 ; <<>> DiG 9.10.1 <<>> -x 1.2.3.4 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47287 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;4.3.2.1.in-addr.arpa. IN PTR ;; ANSWER SECTION: 4.3.2.1.in-addr.arpa. 10799 IN CNAME 4.0/29.3.2.1.in-addr.arpa. ;; Query time: 103 msec ;; SERVER: 192.168.10.1#53(192.168.10.1) ;; WHEN: Fr Okt 17 10:59:19 CEST 2014 ;; MSG SIZE rcvd: 106
Jetzt kann der Kunde auf seinem DNS Server die folgende PTR-Zone einrichten:
$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.
Startet man nun die gleiche dig Abfrage, bekommt man die vollständige und gewünschte Antwort:
$ dig -x 1.2.3.4 ; <<>> DiG 9.10.1 <<>> -x 1.2.3.4 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47287 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;4.3.2.1.in-addr.arpa. IN PTR ;; ANSWER SECTION: 4.3.2.1.in-addr.arpa. 10799 IN CNAME 4.0/29.3.2.1.in-addr.arpa. 4.0/29.3.2.1.in-addr.arpa. 14399 IN PTR webserver.vandemeer.de. ;; Query time: 103 msec ;; SERVER: 192.168.10.1#53(192.168.10.1) ;; WHEN: Fr Okt 17 10:59:19 CEST 2014 ;; MSG SIZE rcvd: 106
Es klingt und sieht also mal wieder komplizierter aus als es ist!
Probleme?
Ja es gibt auch Probleme! Wäre ja zu schön, wenn nicht 😀
Laut RFC darf ein PTR-Record eigentlich kein CNAME sein. Nur halt für diesen speziellen Fall! Das RFC ist nun von 1998… Denn noch scheint es sich nicht sonderlich „herumgesprochen“ zu haben. Ich möchte damit sagen, dass es immer mal wieder bei Problemen dazu kommen kann, dass man seinem Gegenüber zuerst das RFC 2317 erklären muss, bevor es weiter geht 🙂
Ebenfalls macht Postfix ärger, wenn man folgende smtpd restrictions gesetzt hat: reject_unknown_client
Denn diese prüft ob helo / PTR und A/AAAA zueinander passen. Nutzt man reverse map delegation, werden diese nicht zueinander passen!
Oct 17 10:00:00 mx30 postfix/smtp[54786]: FFCC569824: host mx.example.org[4.5.6.7] said: 450 4.1.7 <super@maildomain.de>: Sender address rejected: unverified address: host mail.rennboot.de[3.4.5.6] said: 450 4.7.1 Client host rejected: cannot find your hostname, [4.5.6.7] (in reply to RCPT TO command) (in reply to RCPT TO command)
Betreibt man also einen größeren Mailserver, vermeidet es Arbeit und Ärger, wenn man auf dieser IPv4 Adresse kein reverse map delegation einsetzt.
Tja… Fragen? Dann wie immer: fragen! 😀
