Delegate a real child zone
02A delegation gives named authoritative servers responsibility for a child zone. The label 128-26 is an operator-chosen DNS label; a resolver does not interpret it as a subnet mask.
The new boundary is below 128-26, not below every number from 128 to 191. Ordinary reverse owners such as 129 still need parent-side CNAME records to reach this delegated zone.
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.
NS records identify the child zone’s authoritative name servers. The parent publishes the delegation at 128-26.2.0.192.in-addr.arpa.
- NS records identify the child zone’s authoritative name servers. The parent publishes the delegation at 128-26.2.0.192.in-addr.arpa.
- The child zone has its own SOA (start of authority) and apex NS records. Using two fictional name servers follows the publication’s example; this picture is not a complete deployment recipe.
- The RFC permits a slash in these DNS names but advises a conservative character such as a hyphen for compatibility. These zone labels are not hostnames and have no automatic arithmetic meaning.
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 ↗