Bound DNS data and coordinated tunnels
05Private address references should stay within their intended scope. DNS views and encapsulation are explicit operational designs, not properties automatically supplied by a private prefix.
The far border removes the outer wrapper and delivers the inner packet on the coordinated private network. No encryption or authentication is implied.
Source for this drawing: RFC 1918 · Read RFC section 5 ↗
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.
RFC 6761 formally updates RFC 1918 with private-address reverse-DNS special-use handling. Resolver defaults and explicit private-network configuration differ from application-level name lookup.
Read the updated RFC section ↗Keep local names local, and route an outer header across a public network.
- Outside DNS clients should not see the enterprise’s private addresses. Section 5 suggests an internal full-data authority and a public filtered authority, configured consistently from the same data. This is one method, not a mandatory two-server architecture.
- RFC 6761 §6.1 updates private reverse-DNS name handling. Caching resolvers SHOULD normally answer those names immediately instead of querying authoritative servers; a disabled-by-default option SHOULD allow upstream private resolution where configured. It is not a rule to suppress all DNS queries in applications.
- Coordinated sites can communicate across a public network using border encapsulation that keeps the private packet inside an outer packet. Private address plans must still cooperate. Encapsulation by itself is not a statement that data is encrypted or peers authenticated.
The DNS drawing is a record-selection schematic, not literal zone-file syntax: public IPv4 is a placeholder for an appropriately assigned address. printer.example.com and www.example.com are documentation names (RFC 6761 §6.5). The reverse example 8.0.20.10.in-addr.arpa maps 10.20.0.8; immediate positive or negative resolver responses are both permitted by the cited SHOULD. Tunnel headers are schematic; no specific tunnel protocol or cryptographic protection is assumed.
Read the RFC section ↗