KennisbankNetwerk

Classless reverse DNS delegatie: hoe RFC 2317 werkt

29 oktober 20266 min leestijd

Wie een blok IPv4-adressen kleiner dan een /24 heeft, bijvoorbeeld een /27 voor een paar servers, loopt bij reverse DNS tegen een beperking aan: de zone waar de PTR-records van die adressen in staan, is van de provider en niet van jou. Je kunt de namen laten instellen, zoals in Reverse DNS instellen beschreven, maar je kunt ze niet zelf op je eigen nameservers beheren. Classless delegatie, vastgelegd in RFC 2317, maakt dat wel mogelijk. Dit eerste deel legt uit hoe het werkt; deel 2 gaat over opzetten en fouten zoeken.

Waarom reverse DNS per octet loopt

Reverse DNS voor IPv4 staat onder in-addr.arpa, met de octetten van het adres in omgekeerde volgorde. Het PTR-record voor 192.0.2.25 heet 25.2.0.192.in-addr.arpa. Elk octet is een label, en een zonegrens kan alleen tussen twee labels liggen.

Daardoor heb je zones voor een /8, een /16 en een /24, en niets daartussen. De zone 2.0.192.in-addr.arpa bevat alle 256 adressen van 192.0.2.0/24. Een /27 is een stuk van één label, 0 tot en met 31 in het laatste octet, en voor zo'n stuk bestaat geen naam die je met een NS-record aan andere nameservers kunt geven.

Dat zie je ook terug bij de RIR: RIPE NCC delegeert reverse zones voor IPv4 op /16- en /24-grenzen. Een /24 van jezelf kun je dus gewoon naar je eigen nameservers laten wijzen. Alles daaronder hangt af van de partij die de /24 beheert.

De oplossing: een subzone en een CNAME per adres

RFC 2317 verandert niets aan DNS zelf. Het combineert twee dingen die altijd al konden:

  • Een subzone met een zelfgekozen naam — binnen 2.0.192.in-addr.arpa maakt de beheerder van de /24 een naam als 0/27, en delegeert die met NS-records naar jouw nameservers. Dat is een gewone delegatie, alleen van een label dat geen octet is.
  • Een CNAME per adres — voor elk adres in jouw blok zet de beheerder een CNAME van de normale reverse-naam naar dezelfde naam onder de subzone: 25.2.0.192.in-addr.arpa wijst naar 25.0/27.2.0.192.in-addr.arpa.
  • Jouw PTR-records — in de zone 0/27.2.0.192.in-addr.arpa op jouw nameservers zet je de PTR-records zelf, en die pas je aan wanneer je wilt.

Een resolver die 192.0.2.25 opzoekt, vraagt naar 25.2.0.192.in-addr.arpa, krijgt de CNAME terug, volgt die naar de subzone, ziet daar de delegatie naar jouw nameservers en krijgt van jou het PTR-record. Twee stappen meer dan normaal, en verder niets bijzonders.

Wat er waar staat

Bij de beheerder van de /24 staan in 2.0.192.in-addr.arpa de NS-records voor de subzone en de 32 CNAME's:

0/27    IN NS     ns1.example.nl.
0/27    IN NS     ns2.example.nl.
0       IN CNAME  0.0/27
1       IN CNAME  1.0/27
...
31      IN CNAME  31.0/27

Op jouw nameservers staat de zone 0/27.2.0.192.in-addr.arpa, met een SOA, je eigen NS-records en de PTR's:

25      IN PTR    mail.example.nl.
26      IN PTR    web1.example.nl.

De CNAME's zet de beheerder één keer, voor het hele blok. Daarna hoeft er aan die kant niets meer te gebeuren als jij een naam wijzigt of een adres in gebruik neemt.

De schuine streep is een afspraak

De misvatting is dat 0/27 een speciale syntax is die DNS-software begrijpt. Dat is het niet. Het is een label als elk ander; DNS staat een / in labels toe, alleen in hostnames niet. RFC 2317 gebruikt het omdat het leesbaar is: het eerste adres en de prefixlengte.

Je kunt net zo goed 0-31 of klant-a gebruiken, en sommige beheerders doen dat ook, omdat een / in een bestandsnaam of in de API van een DNS-paneel problemen geeft. Waar het om gaat: de naam die de beheerder van de /24 kiest, is de naam die jouw zone moet hebben, letter voor letter. Wijkt die af, dan is je nameserver niet authoritative voor wat de resolver vraagt en krijg je geen antwoord.

IPv6 heeft dit niet nodig

Onder ip6.arpa is elk label een nibble, vier bits. Een /48, /56 of /64 valt dus op een labelgrens en heeft een eigen zonenaam die je direct kunt delegeren. Classless delegatie is een IPv4-probleem, en een gevolg van hoe klein IPv4-blokken tegenwoordig worden uitgegeven. Meer over de overstap lees je in IPv6 invoeren.

Reverse DNS bij Xyphen IT

Krijg je adressen van ons via IP-transit of bij colocatie, dan stel je de PTR-records in ons dashboard in en is delegatie niet nodig. Wil je ze zelf hosten, of beheer je eigen adresruimte via onze LIR-services? Neem contact op. Hoe je de zone aan jouw kant opzet en controleert, lees je in deel 2.

Veelgestelde vragen

Veelgestelde vragen

Waarom kan mijn provider mijn /27 niet gewoon aan mij delegeren?

Omdat reverse DNS voor IPv4 per octet in zones is opgeknipt. De kleinste zone die vanzelf bestaat, hoort bij een /24. Voor een blok daarbinnen bestaat geen zonenaam die je kunt delegeren; daar is de CNAME-constructie uit RFC 2317 voor.

Heb ik dit ook nodig voor IPv6?

Meestal niet. IPv6-reverse loopt per nibble (vier bits), dus een /48, /56 of /64 heeft een eigen zonenaam en kan direct met NS-records worden gedelegeerd. Alleen bij een prefixlengte die geen veelvoud van vier is, zou hetzelfde probleem terugkomen.

Volgen resolvers en mailservers die CNAME wel?

Ja. Een resolver volgt een CNAME bij een PTR-vraag net zo als bij elke andere vraag, en dat doen ze al decennia. Wel tonen sommige testtools de CNAME en het PTR-record als twee regels, wat er bij de eerste keer kijken uitziet als een fout.

Antwoord niet gevonden?

Stel je vraag direct aan een engineer — we reageren doorgaans binnen één werkdag.