Can I put the whole /24 zone on my own name server instead of the subzone?

That only works for your own resolver. Nobody on the internet points to your server for that /24, so the rest of the world does not see your records. Worse: your own servers do, so everything appears to work. Use exactly the subzone name the manager of the /24 delegated.

How long until a changed PTR record is visible everywhere?

As long as the TTL of the old record. Resolvers that already have it cached keep using that answer until the TTL expires. If you plan a change, lower the TTL beforehand.

Does DNSSEC work with classless delegation?

Yes. The subzone is an ordinary delegation, so if you sign your own zone, the DS record goes into the parent zone at the manager of the /24. Without a DS the delegation is simply unsigned, and that works too.

Classless delegation in practice: setting up, testing and troubleshooting

In part 1 you saw how RFC 2317 works: the manager of the /24 delegates a subzone to your name servers and adds a CNAME into it for each address. This part is about your side. What goes into the zone, how do you check that the whole chain works, and where does it go wrong. The examples use 192.0.2.0/27 with the subzone 0/27.2.0.192.in-addr.arpa.

Agree on the name first

Before you configure anything, ask the manager of the /24 what the subzone will be called. 0/27 is common, but 0-27 and 0-31 occur too, as does a name of their own choosing. Your zone must have exactly that name. Give the manager the names of your name servers as well, and make sure they already answer before the delegation goes live.

The zone on your side

A zone with the agreed name, with an SOA, your NS records and a PTR for each address you use:

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

If you run secondary name servers, the zone must be known there too, under the same name. A / in the zone name is no problem for most name server software, but leave it out of the file name on disk, or your shell or configuration management will turn it into a directory.

Checking the chain

Always test from a resolver outside your own network. On your own servers a local zone or cache can give an answer the rest of the internet does not see.

dig -x 192.0.2.25 +short

If all is well you see two lines: first the CNAME to 25.0/27.2.0.192.in-addr.arpa., then mail.example.com.. If only the CNAME comes back, the problem is on your side. If nothing comes back, it is earlier in the chain.

To see where it stops, follow the steps one by one:

The CNAME — dig 25.2.0.192.in-addr.arpa CNAME must point to the subzone. If not, the CNAME is missing at the manager of the /24.
The delegation — dig NS 0/27.2.0.192.in-addr.arpa must name your name servers. With +trace you see which server hands out the delegation.
Your answer — dig @ns1.example.com 25.0/27.2.0.192.in-addr.arpa PTR must return the PTR record with the aa flag. Without that flag your server is not authoritative for that name.

For mail, the same check as for any PTR record follows: mail.example.com must point back to 192.0.2.25. Why that matters is in Setting up reverse DNS.

The mistakes we see most often

Forgetting the trailing dot — 25 IN PTR mail.example.com without a dot becomes mail.example.com.0/27.2.0.192.in-addr.arpa. The zone loads without complaint; only the answer shows something is wrong.
A zone name other than agreed — your server answers REFUSED or without the aa flag, and the resolver gives up. Often it is 0-27 versus 0/27.
The whole /24 configured locally — the zone 2.0.192.in-addr.arpa on your own name server works on your own network and nowhere else. Precisely because your own tests pass, this mistake stays in place for a long time.
Serial not increased — the primary has the change, the secondary does not. Half the queries get the old answer, depending on which server the resolver picks.
A lame delegation — a name server in the NS records that does not (or no longer) know the zone, for example after moving your DNS. Resolvers try another server, but it costs time, and if it is the only one, reverse DNS disappears.
A checker that treats the CNAME as an error — some older test tools only ask for a PTR record and report "no PTR" when a CNAME comes back. Resolvers and mail servers do follow the CNAME; go by what dig says.

Planning changes

The CNAMEs and the delegation rarely change. Your own PTR records do, and for those the TTL is all that counts: if you put a new mail server on an address, lower the TTL a day ahead so the new record is everywhere quickly. If it is a mail server, look at the rest of the chain at the same time, such as SPF and DMARC; see DMARC to p=reject.

Reverse DNS at Xyphen IT

For addresses you get from us through IP transit or with colocation, you set reverse DNS in our dashboard. Would you rather manage a block smaller than a /24 on your own name servers, or is an existing delegation stuck? Get in touch and we will look at the chain. If you manage your own address space, read about our LIR services too.