Kan ik de hele /24-zone op mijn eigen nameserver zetten in plaats van de subzone?

Dat werkt alleen voor je eigen resolver. Op internet wijst niemand naar jouw server voor die /24, dus de rest van de wereld ziet je records niet. Erger: je eigen servers zien ze wel, waardoor het lijkt alsof alles klopt. Gebruik exact de subzonenaam die de beheerder van de /24 heeft gedelegeerd.

Hoe lang duurt het voor een gewijzigd PTR-record overal zichtbaar is?

Zo lang als de TTL van het oude record. Resolvers die het al in hun cache hebben, blijven dat antwoord gebruiken tot die TTL verloopt. Wie een wijziging plant, zet de TTL vooraf lager.

Werkt DNSSEC met classless delegatie?

Ja. De subzone is een gewone delegatie, dus onderteken je je eigen zone, dan moet het DS-record bij de beheerder van de /24 in de bovenliggende zone komen. Zonder DS is de delegatie gewoon niet ondertekend, en dat werkt ook.

Classless delegatie in de praktijk: opzetten, testen en fouten vinden

In deel 1 zag je hoe RFC 2317 werkt: de beheerder van de /24 delegeert een subzone naar jouw nameservers en zet voor elk adres een CNAME daarheen. Dit deel gaat over jouw kant. Wat moet er in de zone staan, hoe controleer je of de hele keten werkt, en waar gaat het mis. De voorbeelden gebruiken 192.0.2.0/27 met de subzone 0/27.2.0.192.in-addr.arpa.

Eerst de naam afspreken

Voor je iets configureert, vraag je de beheerder van de /24 welke naam de subzone krijgt. 0/27 is gangbaar, maar 0-27 en 0-31 komen ook voor, net als een eigen naam. Je zone moet exact die naam hebben. Geef de beheerder daarnaast de namen van je nameservers, en zorg dat die al antwoorden voordat de delegatie live gaat.

De zone aan jouw kant

Een zone met de naam uit de afspraak, met een SOA, je NS-records en een PTR per adres dat je gebruikt:

$ORIGIN 0/27.2.0.192.in-addr.arpa.
$TTL 3600
@     IN SOA  ns1.example.nl. hostmaster.example.nl. (
              2026102901 7200 3600 1209600 3600 )
      IN NS   ns1.example.nl.
      IN NS   ns2.example.nl.
25    IN PTR  mail.example.nl.
26    IN PTR  web1.example.nl.

Draai je secundaire nameservers, dan moet de zone daar ook bekend zijn, met dezelfde naam. Een / in de zonenaam is voor de meeste nameserversoftware geen probleem, maar het bestand op schijf noem je beter zonder, anders maakt je shell of je configuratiebeheer er een map van.

De keten controleren

Test altijd vanaf een resolver buiten je eigen netwerk. Op je eigen servers kan een lokale zone of cache een antwoord geven dat de rest van internet niet ziet.

dig -x 192.0.2.25 +short

Gaat alles goed, dan zie je twee regels: eerst de CNAME naar 25.0/27.2.0.192.in-addr.arpa., dan mail.example.nl.. Komt alleen de CNAME terug, dan ligt het aan jouw kant. Komt er niets, dan zit het probleem eerder in de keten.

Om te zien waar het stopt, volg je de stappen een voor een:

De CNAME — dig 25.2.0.192.in-addr.arpa CNAME moet naar de subzone wijzen. Zo niet, dan ontbreekt de CNAME bij de beheerder van de /24.
De delegatie — dig NS 0/27.2.0.192.in-addr.arpa moet jouw nameservers noemen. Met +trace zie je welke server de delegatie geeft.
Jouw antwoord — dig @ns1.example.nl 25.0/27.2.0.192.in-addr.arpa PTR moet het PTR-record geven met de aa-flag. Zonder die flag is je server niet authoritative voor die naam.

Voor mail is daarna dezelfde controle nodig als bij elk PTR-record: mail.example.nl moet terugwijzen naar 192.0.2.25. Waarom dat telt, lees je in Reverse DNS instellen.

De fouten die we het vaakst zien

De punt aan het eind vergeten — 25 IN PTR mail.example.nl zonder punt wordt mail.example.nl.0/27.2.0.192.in-addr.arpa. De zone laadt zonder klagen; pas het antwoord laat zien dat er iets mis is.
Een andere zonenaam dan afgesproken — je server antwoordt met REFUSED of zonder aa-flag, en de resolver geeft op. Vaak gaat het om 0-27 tegenover 0/27.
De hele /24 lokaal geconfigureerd — de zone 2.0.192.in-addr.arpa op je eigen nameserver werkt op je eigen netwerk en nergens anders. Juist omdat je eigen tests slagen, blijft deze fout lang staan.
Serial niet verhoogd — de primaire server heeft de wijziging, de secundaire niet. De helft van de vragen krijgt het oude antwoord, afhankelijk van welke server de resolver kiest.
Een lame delegation — een nameserver in de NS-records die de zone niet (meer) kent, bijvoorbeeld na een verhuizing van je DNS. Resolvers proberen een andere server, maar het kost tijd, en als het de enige is, valt reverse DNS weg.
Een checker die de CNAME als fout ziet — sommige oudere testtools vragen alleen een PTR-record op en melden "geen PTR" als er een CNAME terugkomt. Resolvers en mailservers volgen de CNAME wel; kijk naar wat dig zegt.

Wijzigingen plannen

De CNAME's en de delegatie veranderen zelden. Je eigen PTR-records wel, en daarvoor is de TTL het enige wat telt: wie een nieuwe mailserver op een adres zet, verlaagt de TTL een dag van tevoren, zodat het nieuwe record snel overal staat. Gaat het om een mailserver, kijk dan meteen naar de rest van de keten, zoals SPF en DMARC; zie DMARC naar p=reject.

Reverse DNS bij Xyphen IT

Voor adressen die je van ons krijgt via IP-transit of bij colocatie, stel je reverse DNS in ons dashboard in. Wil je een blok kleiner dan een /24 liever op je eigen nameservers beheren, of loopt een bestaande delegatie vast? Neem contact op, dan kijken we naar de keten. Beheer je eigen adresruimte, lees dan ook over onze LIR-services.