Special-Use Domain 'home.arpa.'
updates
- rfc-7788 — Home Networking Control Protocol
Extracted elements (20)
An exception is made for stub resolvers to use locally provided resolvers for 'home.arpa.' even when configured to use other resolvers because non-local resolvers will either fail to answer or provide incorrect answers for homenet-local subdomains.
'.home' was replaced by 'home.arpa.' because '.home' queries frequently leaked to root name servers and conflicted with existing uses. Using 'home.arpa.' leverages the existing '.arpa.' allocation process (RFC 3172) and enables the necessary insecure delegation that '.home' could not obtain.
The delegation of 'home.arpa.' must be insecure (no DS record) rather than providing an authenticated denial of existence because a validating resolver lacking special-case logic for 'home.arpa.' would treat an authenticated denial as proof that names under 'home.arpa.' don't exist, causing validation failures on homenets.
This document updates RFC 7788 (HNCP) by replacing '.home' with 'home.arpa.' as the default domain. All unregistered uses of '.home', particularly as specified in RFC 7788, are deprecated.
Use of 'home.arpa.' is not restricted to networks deploying HNCP; it is the correct domain for any local name service in residential homenets regardless of feature set.
An authoritative DNS server that checks for delegation before answering authoritatively for 'home.arpa.' MUST be configurable to either skip this check or ignore its results, since 'home.arpa.' will never have a global delegation.
Application software SHOULD NOT treat names ending in '.home.arpa.' differently than other names, and there is no basis for trusting names that are subdomains of 'home.arpa.' more than any other DNS response.
DNS queries for names ending with '.home.arpa.' MUST NOT be recursively forwarded to servers outside the logical boundaries of the homenet.
Name resolution APIs and libraries MUST NOT recognize names ending in '.home.arpa.' as special and MUST NOT treat them as having special significance, except that such APIs must not bypass locally configured recursive resolvers.
Recursive resolvers at sites using 'home.arpa.' MUST transparently support DNSSEC queries: queries for DNSSEC records and queries with the DNSSEC OK (DO) bit set.
Recursive resolvers that can be used in a homenet MUST be configurable to forward queries for 'home.arpa.' and its subdomains to an authoritative server for 'home.arpa.' within that homenet.
The delegation of 'home.arpa.' in the '.arpa.' zone MUST NOT include a DS record and MUST point to black hole servers (e.g., 'blackhole-1.iana.org.'), breaking the DNSSEC chain of trust intentionally to allow validating resolvers to accept locally-signed names.
Unless configured otherwise, recursive resolvers and DNS proxies MUST behave as described in RFC 6303 Section 3: queries for 'home.arpa.' and its subdomains MUST NOT be forwarded, with the exception that a DS record query with the DO bit set MUST return the correct answer including proper authority section information.
'home.arpa.' is designated as a special-use domain name for non-unique use in residential home networks. Names ending in '.home.arpa.' have only local significance within the scope of a homenet and are not globally unique.
The HNCP default domain is updated from '.home' to 'home.arpa.' for network-wide zone qualification. An administrator MAY configure a different domain via the Domain-Name TLV; if multiple TLVs are announced, the domain of the node with the greatest node identifier takes precedence.
The 'home.arpa.' special-use name does not require a special resolution protocol; names with rightmost two labels 'home.arpa.' are resolved using the standard DNS protocol per RFC 1035.
IANA has recorded 'home.arpa.' in the 'Special-Use Domain Names' registry and created a new subregistry within 'Locally-Served DNS Zones' titled 'Transport-Independent Locally-Served DNS Zone Registry', adding 'home.arpa.' with description 'Homenet Special-Use Domain'. The registration procedure is IETF Review.
Allowing stub resolvers to query local resolvers for 'home.arpa.' subdomains even when manually configured to use other resolvers (as permitted in Section 4 item 3) has security and privacy implications; implementors are encouraged to consider deployment context when deciding whether to apply this exception.
DNS responses for subdomains of 'home.arpa.' MUST NOT be considered more trustworthy than responses for any other DNS query; because 'home.arpa.' is not globally scoped and cannot be DNSSEC-secured via the root trust anchor, users may receive surprising results when roaming to different homenets.
It is not possible to install a trust anchor (DS RR) for 'home.arpa.' in the '.arpa' zone because no single key-signing key would work for a non-globally-unique zone. Consequently, DNSSEC signing and validation of names within 'home.arpa.' is not possible unless a trust anchor for that specific instance is manually configured.