Keep scope and location-disclosure limits visible
08Publishing a location can expose physical details. A LOC record reports data; it neither measures a device’s current position nor grants permission to find or approach it.
The record exists for all classes, but this memo defines no non-IN semantics or alternative-address search extension. The historical IN-ADDR.ARPAexample must not be relabelled as IPv6 reverse lookup.
Source for this drawing: RFC 1876 · Read RFC section 7 ↗
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.
§7 warns that high-precision location information can help an attacker plan a physical-security penetration. The guide uses fictional data and makes no live DNS or mapping request.
- §7 warns that high-precision location information can help an attacker plan a physical-security penetration. The guide uses fictional data and makes no live DNS or mapping request.
- §5.3 defines LOC for all DNS record classes, while semantics for non-IN classes such as HS/CH and extensions to other addressing schemes are not defined by this memo.
- Experimental status is not an Internet Standard. RFC1876 formally updates 1034 and 1035; it has no formal successor or additional update listed in the current RFCEditor metadata.
Examples are fictional, offline teaching fixtures. RFC1876 is Experimental; its classful IPv4 fallback is historical, not universal current geolocation. Follow the linked official sections for full requirements. Additional sources: §5.3 and publication status.
Read the RFC section ↗