Connect the alias to the PTR owner
03A CNAME record says that one DNS name is an alias of another. The parent holds the ordinary reverse alias; the child holds the PTR at the new target name.
The parent CNAME and child PTR live at two different owners. Do not put PTR alongside CNAME at the parent alias owner. Generating the required per-address aliases is separate from updating the child PTR data.
Source for this drawing: RFC 2317 · Read RFC section 4 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Parent owner 129.2.0.192.in-addr.arpa. has CNAME target 129.128-26.2.0.192.in-addr.arpa. The target is another DNS lookup name, not the final host name.
- Parent owner 129.2.0.192.in-addr.arpa. has CNAME target 129.128-26.2.0.192.in-addr.arpa. The target is another DNS lookup name, not the final host name.
- Child owner 129.128-26.2.0.192.in-addr.arpa. holds PTR host1.b.example. Parent alias owner and child PTR owner are distinct names.
- An absolute name ends with a dot in a zone file. A relative name is extended with $ORIGIN. CNAME and ordinary PTR data cannot coexist at the same owner; see RFC 2181 Section 10.1.
Fictional documentation addresses and .example names. Zone snippets omit TTLs, SOA timers and other deployment settings. This is DNS delegation, not a routing change or proof of identity.
Read the RFC section ↗