{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreieyvx3ftkgwemkz2wquaosg6wkqnwtco5vvki6u627vljqq2kgzwq",
    "uri": "at://did:plc:nkxz2ojdvmieg2nhphvputvp/app.bsky.feed.post/3mmogfghttcg2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreignq27ibqjtbh4peapu4a5zsdlep5uuqert2zzqder46ivugkgnxa"
    },
    "mimeType": "image/png",
    "size": 659242
  },
  "description": "Wer eine kleinere IP-Range als /24 hat (typisch beim Reseller mit /28 oder /29), kann keine eigene PTR-Zone betreiben. RFC 2317 loest das per CNAME-Delegation im /24 des Providers. Praxis-Walkthrough mit BIND-Zonenfiles auf beiden Seiten und der Standard-Stolperstein bei der Sub-Range-Notation.",
  "path": "/2014/10/17/ip-reverse-map-delegation/",
  "publishedAt": "2026-05-25T11:57:45.000Z",
  "site": "https://www.kernel-error.de",
  "tags": [
    "DNS",
    "DNSSEC",
    "Hardening",
    "Networking",
    "router",
    "SelfHosted",
    "Sysadmin",
    "RFC 2317",
    "Einfach melden."
  ],
  "textContent": "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.\n\n### Warum man es braucht\n\nIn 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.\n\nDer 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.\n\n### Die Provider-Seite\n\nIn 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:\n\n\n    $ORIGIN 3.2.1.in-addr.arpa.\n    $TTL 1D\n    @   1D IN SOA ns1.kernel-error.de. hostmaster.kernel-error.de. (\n                  2014101701 ; serial\n                  6H         ; refresh\n                  30M        ; retry\n                  2W         ; expiry\n                  1D )       ; minimum\n\n             IN NS  ns1.kernel-error.de.\n             IN NS  ns2.kernel-error.org.\n\n    ; Delegation für 1.2.3.0/29 an den Kunden\n    0/29     IN NS    ns1.vandemeer.de.\n    0/29     IN NS    ns2.vandemeer.de.\n    0        IN CNAME 0.0/29.3.2.1.in-addr.arpa.\n    1        IN CNAME 1.0/29.3.2.1.in-addr.arpa.\n    2        IN CNAME 2.0/29.3.2.1.in-addr.arpa.\n    3        IN CNAME 3.0/29.3.2.1.in-addr.arpa.\n    4        IN CNAME 4.0/29.3.2.1.in-addr.arpa.\n    5        IN CNAME 5.0/29.3.2.1.in-addr.arpa.\n    6        IN CNAME 6.0/29.3.2.1.in-addr.arpa.\n    7        IN CNAME 7.0/29.3.2.1.in-addr.arpa.\n\n### Die Kunden-Seite\n\nDer Kunde richtet auf seinem DNS-Server die Sub-Zone ein und kann dort seine PTR-Records setzen wie gewohnt:\n\n\n    $ORIGIN 0/29.3.2.1.in-addr.arpa.\n    $TTL 1D\n    @   1D IN SOA ns1.vandemeer.de. hostmaster.vandemeer.de. (\n                  2014101701 ; serial\n                  6H         ; refresh\n                  30M        ; retry\n                  2W         ; expiry\n                  1D )       ; minimum\n\n             IN NS  ns1.vandemeer.de.\n             IN NS  ns2.vandemeer.de.\n\n    0        IN PTR netzadresse.vandemeer.de.\n    1        IN PTR router.vandemeer.de.\n    2        IN PTR mailin.vandemeer.de.\n    3        IN PTR imap.vandemeer.de.\n    4        IN PTR webserver.vandemeer.de.\n    5        IN PTR frei.vandemeer.de.\n    6        IN PTR frei.vandemeer.de.\n    7        IN PTR broadcastadresse.vandemeer.de.\n\n### Ergebnis\n\nEine 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:\n\n\n    dig -x 1.2.3.4 +short\n    4.0/29.3.2.1.in-addr.arpa.\n    webserver.vandemeer.de.\n\n### Probleme\n\nWäre ja zu schön, wenn es keine gäbe.\n\nLaut 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.\n\nAuß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:\n\n\n    450 4.7.1 Client host rejected: cannot find your hostname, [4.5.6.7]\n\nWer 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.\n\nFragen? Einfach melden.",
  "title": "IP Reverse Map Delegation: Einrichtung und Fehlerbehebung"
}