Resolve through the alias and delegation
04A recursive resolver follows the CNAME target using ordinary DNS resolution. This chosen uncached sequence shows separate parent and child servers; caching or a parent that also serves the child can reduce the exchanges.
The recursive result can include the encountered CNAME and final PTR. A reverse mapping is published DNS data; it alone does not prove a host’s identity, ownership or matching forward address.
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.
The client asks for PTR at the ordinary reverse owner. It does not need to know the invented child-zone label.
- The client asks for PTR at the ordinary reverse owner. It does not need to know the invented child-zone label.
- After a CNAME, the resolver continues looking for the original requested type at the target name. A child-zone referral identifies where to continue; it is not itself the PTR answer.
- RFC 1034 Sections 4.3.2 and 5.3 describe the supporting lookup behavior. This scene is a selected high-level path, not mandatory packet counts, glue behavior, retries or DNSSEC validation.
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 ↗