RFC 9526
Simple Provisioning of Public Names for Residential Networks
RFC 9526: Simple Provisioning of Public Names for Residential Networks ๐ โจ
Okay bestie, here's the vibe check on this doc ๐
- Number and title: RFC 9526, Simple Provisioning of Public Names for Residential Networks ๐
- Publisher: Internet Engineering Task Force (IETF) ๐
- Authors: D. Migault (Ericsson), R. Weber (Nominum), M. Richardson (Sandelman Software Works), and R. Hunter (Globis Consulting BV) ๐
- Category: Experimental ๐งช
- Date: January 2024 ๐
- ISSN: 2070-1721
- Obsoletes / Updates: the title block doesn't list any RFCs as obsoleted or updated ๐ฆ
Abstract ๐ธ
So home network owners want to reach their stuff from the Internet (aka from outside the house) ๐กโก๏ธ๐. Like, a device or service sitting on their home network that they want to get to from anywhere. Home networks are getting more and more numbered with IPv6 addresses, which in theory makes this easier, but the Internet can only get to those devices if their names and IP addresses are published in the public DNS ๐.
This document describes how a Home Naming Authority (NHA) tells the outsourced infrastructure to publish all that info in the public DNS ๐. The names and IP addresses of the home network are set in the Public Homenet Zone by the Homenet Naming Authority (HNA). The HNA then tells an outsourced infrastructure to publish that zone on behalf of the home network owner ๐ซถ.
Status of This Memo ๐
This document is not an Internet Standards Track specification. It's published so people can examine it, try experimental implementations, and evaluate it ๐งช.
It defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community ๐ค. It has had public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for the details ๐ .
Info about the current status of this document, any errata, and how to send feedback can be found at https://www.rfc-editor.org/info/rfc9526 ๐.
Copyright Notice ยฉ๏ธ
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved ๐.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions for this document ๐. Code Components extracted from this document must include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License โ๏ธ.
Table of Contents ๐
1. Introduction
2. Terminology
3. Selecting Names and Addresses to Publish
4. Envisioned Deployment Scenarios
4.1. CPE Vendor
4.2. Agnostic CPE
5. Architecture Description
5.1. Architecture Overview
5.2. Distribution Manager (DM) Communication Channels
6. Control Channel
6.1. Building the Public Homenet Zone
6.2. Building the DNSSEC Chain of Trust
6.3. Setting Up the Synchronization Channel
6.4. Deleting the Delegation
6.5. Message Exchange Description
6.5.1. Retrieving Information for the Public Homenet Zone
6.5.2. Providing Information for the DNSSEC Chain of Trust
6.5.3. Providing Information for the Synchronization Channel
6.5.4. Initiating Deletion of the Delegation
6.6. Securing the Control Channel
7. Synchronization Channel
7.1. Securing the Synchronization Channel
8. DM Distribution Channel
9. HNA Security Policies
10. Public Homenet Reverse Zone
11. DNSSEC-Compliant Homenet Architecture
12. Renumbering
13. Privacy Considerations
14. Security Considerations
14.1. Registered Homenet Domain
14.2. HNA DM Channels
14.3. Names Are Less Secure than IP Addresses
14.4. Names Are Less Volatile than IP Addresses
14.5. Deployment Considerations
14.6. Operational Considerations
15. IANA Considerations
16. References
16.1. Normative References
16.2. Informative References
Appendix A. HNA Channel Configurations
A.1. Public Homenet Zone
Appendix B. Information Model for Outsourced Information
Appendix C. Example: A Manufacturer-Provisioned HNA Product Flow
Acknowledgments
Contributors
Authors' Addresses1. Introduction โจ
Okay so home network owners want to reach devices or services on their home network from the Internet, meaning from a network outside the home ๐ก๐. Using IPv6 addresses at home makes the actual network access simpler, in principle. But the addresses are super hard to remember and get renumbered regularly ๐ญ. So to make life easier for regular home owners, there needs to be a simple way for the names and IP addresses of these devices and services to get published in the public DNS ๐.
As shown in Figure 1, the names and IP address of the home network are made available in the Public Homenet Zone by the Homenet Naming Authority (HNA). The HNA then tells the DNS Outsourcing Infrastructure (DOI) to publish the zone on its behalf. This document describes how an HNA can instruct a DOI to publish a Public Homenet Zone on its behalf ๐ฆ.
This document introduces the Synchronization Channel and the Control Channel between the HNA and the Distribution Manager (DM), which is the main interface to the DOI ๐.
The Synchronization Channel (see Section 7) is used to synchronize the Public Homenet Zone ๐.
Internet
.---------------------. .-------------------.
| Home Network | Control | DOI |
|.-------------------.| Channel |.-----------------.|
|| HNA |<----------->| Distribution ||
||.-----------------.|| || Manager ||
||| Public Homenet ||| || ||
||| Zone ||<----------->| ||
||| myhome.example ||| Synchron- |'-----------------'|
||'-----------------'|| ization | | |
|'-------------------'| Channel | V |
| | |.-----------------.|
| | || Public Homenet ||
'---------------------' || Zone ||
|| myhome.example ||
|'-----------------'|
'---^--^--^--^--^---'
| | | | |
(served on the Internet)
Figure 1: High-Level Architecture Overview of Outsourcing the
Public Homenet ZoneThe Synchronization Channel is a zone transfer. The HNA is set up as a primary server and the Distribution Manager is set up as a secondary server. Some operators call this kind of setup a "hidden primary," but this document doesn't use that term. It isn't precisely defined anywhere, and it means slightly different things to different people ๐คทโโ๏ธ.
The Control Channel (see Section 6) is used to set up the Synchronization Channel ๐ ๏ธ. It's a dynamic DNS update process, and it's authenticated by TLS ๐.
For example, to build the Public Homenet Zone, the HNA needs the authoritative servers (and their associated IP addresses) of the DOI's servers, which are the visible primaries actually serving the zone ๐. Similarly, the DOI needs to know the IP address of the (hidden) primary, which is the HNA. It may also need the hash of the Key Signing Key (KSK) in the DS RRset to secure the DNSSEC delegation with the parent zone ๐. Main character energy for sure ๐.
The rest of the document is laid out like this ๐บ๏ธ. Section 2 defines the terminology. Section 3 presents the general problem of publishing names and IP addresses. Section 4 briefly describes some potential deployment scenarios. Section 5 gives an architectural view of the HNA, DM, and DOI, plus their different communication channels (Control Channel, Synchronization Channel, and DM Distribution Channel), which are described in Sections 6, 7, and 8 respectively ๐ง.
Sections 6 and 7 cover the two channels that interface with the home. Section 8 lays out a set of requirements and expectations for how the distribution system works. This section is non-normative and not subject to standardization, but it reflects how many scalable DNS distribution systems operate ๐.
Sections 9 and 11 detail HNA security policies and DNSSEC compliance within the home network respectively ๐. Section 12 talks about how renumbering should be handled ๐. Finally, Sections 13 and 14 discuss privacy and security considerations when outsourcing the Public Homenet Zone ๐๐.
The appendices cover the following: management (see Section 10), provisioning (see Section 10), configurations (see Appendix B), and deployment (see Section 4 and Appendix C) ๐.
2. Terminology โจ
okay bestie, first things first ๐ the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they show up in all capitals, just like here ๐
Customer Premises Equipment (CPE): a router that provides connectivity to the home network ๐
Homenet Zone: the DNS zone for use within the boundaries of the home network: home.arpa (see [RFC8375]). This zone is not considered public and is out of scope for this document ๐
Registered Homenet Domain: the domain name that's associated with the home network. A given home network may have multiple Registered Homenet Domains ๐ธ
Public Homenet Zone: holds the names in the home network that are expected to be publicly resolvable on the Internet. A home network can have multiple Public Homenet Zones โจ
Homenet Naming Authority (HNA): a function responsible for managing the Public Homenet Zone. This includes populating the Public Homenet Zone, signing the zone for DNSSEC, as well as managing the distribution of that Homenet Zone to the DOI ๐
DNS Outsourcing Infrastructure (DOI): the infrastructure responsible for receiving the Public Homenet Zone and publishing it on the Internet. It's mainly composed of a Distribution Manager and Public Authoritative Servers ๐ฆ
Public Authoritative Servers: the authoritative name servers for the Public Homenet Zone. Name resolution requests for the Registered Homenet Domain are sent to these servers. Some DNS operators refer to these as public secondaries, and higher resiliency networks are often implemented in an anycast fashion ๐
Homenet Authoritative Servers: the authoritative name servers for the Homenet Zone within the Homenet network itself. These are sometimes called "hidden primary servers" ๐
Distribution Manager (DM): the server (or set of servers) that the HNA synchronizes the Public Homenet Zone to, and that then distributes the relevant information to the Public Authoritative Servers. This server has historically been known as the Distribution Master ๐
Public Homenet Reverse Zone: the reverse zone file associated with the Public Homenet Zone ๐
Reverse Public Authoritative Servers: these are equivalent to Public Authoritative Servers, specifically for reverse resolution ๐
Reverse Distribution Manager: this is equivalent to the Distribution Manager, specifically for reverse resolution ๐ซถ
DNS Resolver: a resolver that performs a DNS resolution on the Internet for the Public Homenet Zone. The resolution is performed by requesting the Public Authoritative Servers. While the resolver does not necessarily perform DNSSEC resolutions, it is RECOMMENDED that DNSSEC is enabled ๐
Note that when "DNS Resolver" is used in this document, it refers to "DNS or DNSSEC Resolver" ๐
Homenet DNS Resolver: a resolver that performs a DNS or DNSSEC resolution on the home network for the Public Homenet Zone. The resolution is performed by requesting the Homenet Authoritative Servers ๐ง
3. Selecting Names and Addresses to Publish โจ
okay so this document doesn't create any normative mechanism to pick the names to publish ๐ โโ๏ธ but it does anticipate that the home network administrator (a human being) will be shown a list of current names and addresses, either directly on the HNA or via another device like a smartphone ๐ฑ
The administrator marks which devices and services (by name) are to be published. The HNA then collects the IP address(es) associated with that device or service and puts the name into the Public Homenet Zone ๐ The address of the device or service can be collected from a bunch of places: Multicast DNS (mDNS) [RFC6762], DHCP [RFC8415], Universal Plug and Play (UPnP), the Port Control Protocol (PCP) [RFC6887], or manual configuration ๐ธ
A device or service SHOULD have Global Unicast Addresses (GUAs) (IPv6 [RFC3587] or IPv4) but MAY also have IPv6 Unique Local Addresses (ULAs) [RFC4193], IPv6 Link-Local Addresses (LLAs) [RFC4291] [RFC7404], IPv4 LLAs [RFC3927], and private IPv4 addresses [RFC1918] ๐ฆ
Of these, the LLAs are almost never useful for the Public Zone and should be omitted ๐
The IPv6 ULA and private IPv4 addresses may be useful to publish, if the home network environment features a VPN that would let the home owner reach the network ๐ [RFC1918] addresses in public zones are generally filtered out by many DNS servers, since they're considered rebind attacks [REBIND] ๐จ
In general, one expects the GUA to be the default address to be published. A direct advantage of enabling local communication is that it keeps communications going even when the Internet is disrupted ๐ Since communications are established with names that stay a global identifier, the communication can be protected (at the very least with integrity protection) by TLS the same way it's protected on the global Internet -- by using certificates ๐โจ
4. Envisioned Deployment Scenarios ๐
a bunch of deployment scenarios have been envisioned, and this section gives a brief description of them ๐บ๏ธ The use cases are not limitations, and this section is not normative ๐
The main difference between the various deployments is how the HNA gets provisioned (that is, how it's configured to outsource the Public Homenet Zone to the DOI), as well as how the Public Homenet Zone gets provisioned before it's outsourced. In both cases, these configuration aspects are out of scope for this document ๐
Provisioning the configuration related to the DOI is expected to be as automated as possible and to require as little interaction with the end user as possible. Zero configuration can only be achieved under some circumstances, and [RFC9527] provides one such example, under the assumption that the ISP provides the DOI ๐ง Section 4.1 describes another variant, where the Customer Premises Equipment (CPE) is provided preconfigured with the DOI ๐ฆ Section 4.2 describes how an agnostic CPE may be configured by the home network administrator ๐ ๏ธ Of course, even in this case, the configuration can leverage mechanisms that stop the end user from having to type in all the information by hand โจ
On the other hand, provisioning the Public Homenet Zone needs to combine the ability to closely reflect what the end user wishes to publish on the Internet with making that interaction easy ๐ฅฐ The HNA may implement such interactions using web-based GUIs or specific mobile applications ๐ฒ
With the CPE configured with the DOI, the HNA contacts the DOI to build a template for the Public Homenet Zone, and then provisions the Public Homenet Zone. Once the Public Homenet Zone is built, the HNA starts synchronizing it with the DOI on the Synchronization Channel ๐๐
4.1. CPE Vendor ๐
A specific vendor that has specific relations with a registrar or a registry may sell a CPE that's provisioned with a domain name. That domain name is probably not very human friendly, and may consist of some kind of serial number associated with the device being sold ๐ข
One possible scenario is that the vendor provisions the HNA with a private key, plus an associated certificate used for mutual TLS authentication. Note that these keys are not expected to be used for DNSSEC signing ๐
Instead, these keys are solely used by the HNA to authenticate to the DM. Normally, the keys are necessary and sufficient to get the authentication done ๐
When the home network owner plugs in the CPE at home, the relation between the HNA and DM is expected to work out of the box ๐
4.2. Agnostic CPE ๐งฉ
A CPE that is not preconfigured may also use the protocol defined in this document, but some configuration steps will be needed ๐ ๏ธ
- The owner of the home network buys a domain name from a registrar and, as such, creates an account on that registrar ๐๏ธ
- The registrar may provide the outsourcing infrastructure, or the home network may need to create a specific account on the outsourcing infrastructure ๐๏ธ
- If the DOI is the DNS Registrar, it has, by design, a proof of ownership of the domain name by the Homenet owner. In this case, it is expected that the DOI provides the necessary parameters to the home network owner to configure the HNA. One potential mechanism to provide the parameters would be to give the user a JSON object that they can copy and paste into the CPE, such as the one described in Appendix B ๐ But what matters to the infrastructure is that the HNA is able to authenticate itself to the DOI ๐
- If the DOI is not the DNS Registrar, then the proof of ownership needs to be established using some other protocol. Automatic Certificate Management Environment (ACME) [RFC8555] is one protocol that would let an owner of an existing domain name prove their ownership (but it requires that they already have DNS set up!) ๐ญ There are other ways to establish proof, such as providing a DOI-generated TXT record, or web site contents, as championed by entities like Google's Sitemaster and Postmaster protocols ๐ [DOMAIN-VALIDATION] describes a few ways ownership or control of a domain can be achieved ๐
5. Architecture Description โจ
this section gives an overview of the architecture for outsourcing the authoritative naming service from the HNA to the DOI ๐๏ธ As a consequence, the HNA is prevented from handling the DNS traffic from the Internet that's associated with resolving the Homenet Zone ๐ซ
The device-assigned zone or user-configurable zone that's used as the domain to publicly serve hostnames in the home network is called the Public Homenet Zone. In this document, "myhome.example" is used as the example for an end-user-owned domain configured as a Public Homenet Zone ๐ก
More specifically, DNS resolution for the Public Homenet Zone (here "myhome.example") from Internet DNSSEC resolvers is handled by the DOI, as opposed to the HNA. The DOI benefits from a cloud infrastructure, while the HNA is dimensioned for a home network and, as such, is likely unable to support any load ๐ฉ๏ธ In the case where the HNA is a CPE, outsourcing to the DOI reduces the attack surface of the home network to DDoS, for example ๐ก๏ธ Of course, the DOI needs to be informed dynamically about the content of myhome.example ๐ The description of such a synchronization mechanism is the purpose of this document ๐
Note that Appendix B shows the necessary parameters to configure the HNA ๐
5.1. Architecture Overview ๐
Okay so, here's the big picture bestie ๐บ๏ธ Figure 2 shows the whole setup, and the home side and the Internet side each get their own box.
.----------------------------. .-----------------------------.
| Home Network | | Internet |
| .-----------------------. | Control | .-----------------------. |
| | HNA | | Channel | | DOI | |
| | (hidden primary) |<------------->| (hidden secondary) | |
| | | | DNSUPD | | Distribution Manager | |
| | .-------------------. | | | | | |
| | | Public Homenet | | | | | .-------------------.| |
| | | Zone |<------------------>|Public Homenet Zone|| |
| | | myhome.example | | |Synchron-| | | myhome.example || |
| | '-------------------' | |ization | | '-------------------'| |
| '-----------------------' |Channel | | | | |
| ^ | AXFR | | | | |
| | | | | v | |
| .-----------------------. | | |.---------------------.| |
| | Homenet Authoritative | | | || Public Authoritative|| |
| | Server | | | || (secondary) Servers || |
| | + myhome.example | | | || + myhome.example || |
| | + home.arpa | | | || + x.y.z.ip6.arpa || |
| | + x.y.z.ip6.arpa | | | || || |
| '-----------------------' | | || || |
| | ^ | | |'---------------------'| |
| | | | | | ^ | | |
| | | | | '--|------------|-------' |
| v | | | | v |
| .----------------------. | | .------------------------. |
| | Homenet DNS Resolver | | | | Internet Resolvers | |
| '----------------------' | | '------------------------' |
| | | |
'----------------------------' | |
'-----------------------------'
Figure 2: Homenet Naming ArchitectureFigure 2 shows the setup where the HNA hands off publishing the Public Homenet Zone to the DOI. The DOI answers every DNS request for that zone that comes in from outside the home network ๐ If the request comes from inside the home, it's the Homenet DNS Resolver that handles it, and we'll get into that more below ๐ก
In this example, the Public Homenet Zone is named by the Registered Homenet Domain "myhome.example" โจ The diagram also shows a reverse IPv6 map being hosted over there ๐ช
Quick heads up: ".local" and ".home.arpa" are explicitly NOT Public Homenet Zones ๐ โโ๏ธ That's why they show up as a Homenet Zone in Figure 2. They get resolved locally but they never get published, because they're treated as local-only stuff ๐
It is RECOMMENDED that the HNA implements DNSSEC ๐ and if it does, the HNA MUST sign the Public Homenet Zone with DNSSEC. No skipping that part, periodt ๐
The HNA handles all the operations and keying material DNSSEC needs. So this architecture has zero provision for moving private DNSSEC keying material between the HNA and the DM ๐ โโ๏ธ๐
Once the Public Homenet Zone is built, the HNA syncs it with the DOI using a primary/secondary setup, just like Figure 2 shows ๐ค The HNA acts as a stealth server (see [RFC8499]) and the DM acts as a hidden secondary ๐ซฅ The DM is in charge of spreading the Public Homenet Zone out to all the Public Authoritative Server instances that the DOI runs ๐ The DM has three communication channels:
- DM Control Channel (Section 6) is how the HNA and the DOI configure each other ๐๏ธ It carries the parameters for the primary/secondary relationship, plus some info from the DOI that the HNA has to put into the Public Homenet Zone.
- DM Synchronization Channel (Section 7) is how the Public Homenet Zone gets synced between the HNA and the DM, with the primary/secondary set up properly ๐ It's a zone transfer over mutually authenticated TLS ๐ซถ
- One or more Distribution Channels (Section 8) push the Public Homenet Zone from the DM out to the Public Authoritative Servers that serve it on the Internet ๐ฎ
There could be multiple DMs, and multiple servers per DM ๐ง This document just assumes a single DM server to keep things simple. But nothing says each channel has to live on the same server or use the same codebase, so go wild ๐
Important tea โ Even though the HNA is set up as an authoritative server, it is NOT expected to answer DNS requests from the _public_ Internet for the Public Homenet Zone ๐ To be specific, the addresses of the HNA SHOULD NOT be listed in the NS records of the Public Homenet Zone, unless extra security provisions to protect the HNA from outside attacks have been put in place ๐ก๏ธ
The HNA is not supposed to be the public face of the zone. Keep it hidden unless you've locked it down properly ๐จ
The DOI is also responsible for making sure the DS record gets updated in the parent zone ๐
Resolution is done by DNS Resolvers ๐ When resolution happens outside the home network, the DNS Resolver looks up the DS record on the Global DNS, and looks up the name of the Public Homenet Zone (myhome.example) on the Public Authoritative Servers ๐
Now, for resilience in case the WAN goes down ๐ก๐, the Homenet DNS Resolver MUST be able to do its resolution on the Homenet Authoritative Servers. Bonus privacy perk ๐ซข Using the Homenet DNS Resolver means the people on the home network stop leaking their internal service lookups to an external DNS provider and to anyone sitting on the path ๐ These servers aren't expected to be mentioned in the Public Homenet Zone, and they aren't expected to be reachable from the Internet either ๐ So their info, plus the matching signed DS record, MAY be handed from the HNA to the Homenet DNS Resolvers. For example, that could go over the Home Networking Control Protocol (HNCP) [RFC7788] or by configuring a trust anchor [DRO-RECS] ๐๏ธ That configuration is outside the scope of this document, so it's not our problem here ๐ Since the Homenet Authoritative Servers only care about the home network, they're expected to serve the Homenet Zone exactly as Figure 2 shows ๐ โจ
5.2. Distribution Manager (DM) Communication Channels ๐ก
This section goes through the DM channels: the Control Channel, the Synchronization Channel, and the Distribution Channel ๐งฉ
The Control Channel and the Synchronization Channel are the interfaces between the HNA and the DOI ๐ค On the DOI side, the DM is the entity that handles these conversations. Communications between the HNA and the DM MUST be protected and mutually authenticated ๐ There's more detail on the security options in Section 6.6 ๐ซถ
The info exchanged between the HNA and the DM uses DNS messages protected by DNS over TLS (DoT) [RFC7858] ๐ It's set up the same way as described in [RFC9103], Section 9.3.3 โจ
Here's something that matters a lot ๐ก The DM and the HNA have to agree on a shared configuration, or else they can't set up the Synchronization Channel or build and serve a coherent Public Homenet Zone ๐งฑ Like we said earlier, the visible NS records of the Public Homenet Zone (the ones the HNA builds) keep pointing at the IP address of the DOI's Public Authoritative Servers ๐ Unless the HNA can handle the traffic load, the HNA SHOULD NOT show up as a visible NS record of the Public Homenet Zone ๐ โโ๏ธ On top of that, depending on how the DOI is set up, the DM also has to update the parent zone's NS, DS, and associated A or AAAA glue records ๐ง Check out Section 6.2 for the full scoop ๐
This specification assumes:
- The DM serves both the Control Channel and the Synchronization Channel on a single IP address, on a single port, using a single transport protocol ๐ฏ
- By default, the HNA uses a single IP address for both the Control and Synchronization channels ๐ท๏ธ The HNA MAY use separate IP addresses for each of them, though. See Sections 7 and 6.3 for more ๐
The Distribution Channel is internal to the DOI, so this specification doesn't normatively define it ๐ซ
6. Control Channel ๐๏ธ
The DM Control Channel is how the HNA and the DOI swap info about the delegation setup ๐ค That includes the info needed to build the Public Homenet Zone (Section 6.1), to build the DNSSEC chain of trust (Section 6.2), and to set up the Synchronization Channel (Section 6.3) ๐
Some info flows from the DOI to the HNA, which we'll cover in the next section ๐ The HNA updates the DOI with the IP address where the zone is going to be transferred over the Synchronization Channel ๐ฌ The HNA is always the one that starts the exchange, in both directions ๐
So the HNA already knows a few things before any of this starts โจ It knows the DM's identity (via an X.509 certificate), the IP address and port number to use, and which protocol to use for a secure session ๐ The DM, on the other hand, learns the identity of the HNA (also via X.509 certificate), along with the Registered Homenet Domain ๐ท๏ธ If you want the details on how this can be done, check out Appendix A.1 ๐
6.1. Building the Public Homenet Zone ๐งฑ
The HNA builds the Public Homenet Zone from a template that the DM sends back to it ๐ Section 6.5 explains how this uses the Authoritative Transfer (AXFR) mechanism ๐
To build its zone completely, the HNA needs the names (and maybe IP addresses) of the Public Authoritative Name Servers ๐ท๏ธ Those get used to fill in the NS records for the zone ๐
All the content of the zone MUST be created by the HNA, because the zone is DNSSEC signed ๐ No outsourcing the zone content, bestie ๐ โโ๏ธ
The HNA also needs to know what goes into the MNAME of the SOA, and only the DOI knows that answer ๐คทโโ๏ธ The DM MUST also provide useful operational parameters for the other SOA fields (SERIAL, RNAME, REFRESH, RETRY, EXPIRE, and MINIMUM) ๐ The HNA is still free to override those values based on its local configuration ๐ For example, an HNA might want to change them if it senses a renumbering event is coming up ๐
Because the HNA can't move forward without the DM's info, this information exchange is mandatory ๐ซก
Last step: the HNA does a DNS Update to the DOI, adding an NS, a DS, and A and AAAA records ๐ฎ These records tell the DOI where the Synchronization Channel lives ๐ The DOI doesn't publish this NS record, though. It just uses it to do its zone transfers ๐ฆ
6.2. Building the DNSSEC Chain of Trust ๐
okay so the HNA MUST provide the hash of the KSK through the DS RRset, so the DOI can hand that value over to the parent zone ๐โจ. A super common setup is that the DOI is the registrar of the Registered Homenet Domain. That means it already has a relationship with the registry of the parent zone, so it can update the parent zone for you ๐ . When that relationship exists, the HNA should be able to ask the DOI to update the DS RRset in the parent zone. A direct update is especially necessary to initialize the chain of trust ๐ซถ.
Though the HNA may also update the DS values directly over the Control Channel later on, it is RECOMMENDED to use other mechanisms, like CDS and CDNSKEY [RFC7344], for transparent updates during key rollovers ๐๐.
As some deployments may not provide a DOI that can update the DS in the parent zone, this information exchange is OPTIONAL ๐.
By accepting the DS RR, the DM commits to advertising the DS to the parent zone ๐ค. On the other hand, if the DM can't advertise the DS to the parent zone, it says so by refusing the update to the DS RR ๐.
6.3. Setting Up the Synchronization Channel ๐ช
the HNA is basically a hidden primary authoritative DNS server, and the DM acts like a secondary one ๐ง. Because of that, the HNA has to tell the DM which IP address the DM should use to reach it ๐.
If the HNA detects that it has been renumbered, then it MUST use the Control Channel to update the DOI with the new IPv6 address it was assigned ๐จ. Major renumbering alert, bestie ๐ญ.
The Synchronization Channel will be set up between the new IPv6 (and IPv4) address and the IP address of the DM ๐ฆ. By default, the DM considers the IP address the HNA uses in the Control Channel, so the HNA only has to spell out an IP explicitly if it wants to, which is OPTIONAL ๐. The transport channel (including the port number) is the same one used between the HNA and the DM for the Control Channel ๐.
6.4. Deleting the Delegation ๐๏ธ
the previous sections are all about exchanging info so a delegation can be set up. Now we get to the other side of the story. The HNA MUST also be able to delete a delegation with a specific DM ๐ฅ.
Section 6.5.4 explains how a DNS Update operation on the Control Channel is used to do this ๐ ๏ธ.
When the DM receives the instruction to delete the delegation, it MUST stop serving the Public Homenet Zone ๐.
Whether the DM deletes an inactive HNA is part of the commercial agreement between the DOI and the HNA ๐โจ.
6.5. Message Exchange Description ๐
there were lots of ways to figure out how the control info could get exchanged between the HNA and the DM, so the team really thought it through ๐ง .
This spec defines a mechanism that reuses the DNS zone transfer format ๐. Quick heads up, though: even though the info travels in DNS exchanges, it's not meant to be saved in any zone file. It's used as commands between the HNA and the DM instead ๐ฏ. This turned out to be simpler on the home router side, since the HNA already has to have code for all the DNS encodings and decodings anyway ๐ . Inventing a brand new way to encode the DNS info in something like JSON seemed like extra complexity for no real payoff ๐ โโ๏ธ.
The Control Channel is not expected to be a long-term session ๐ฐ๏ธ. After a predefined timer (kinda like the ones TCP uses), the Control Channel is expected to be terminated by closing the transport channel ๐. The Control Channel MAY be reopened at any later time ๐.
Using TLS session tickets (see [RFC8446], Section 4.6.1) is RECOMMENDED ๐๏ธ.
The channel MUST be authenticated with certificates for both the DM and each HNA ๐. The DM may also create the initial configuration for the delegation zone in the parent zone during the provisioning process ๐ช.
6.5.1. Retrieving Information for the Public Homenet Zone ๐ฅ
The DM hands info to the HNA through an AXFR exchange [RFC1034], and the HNA retrieves it that way ๐ฆ. AXFR lets the response carry any type of RRset, so it's super flexible ๐ธ.
To get everything it needs to build the Public Homenet Zone, the HNA MUST send a DNS request of type AXFR associated with the Registered Homenet Domain ๐จ.
The zone the DM sends back is used by the HNA as a template to build its own zone ๐งฉ.
The zone template MUST contain an RRset of type SOA, one or more RRsets of type NS, and zero or more RRsets of type A or AAAA (if the NS is in-domain [RFC8499]) ๐. The template includes TTL values for each RR, and the HNA SHOULD treat those as suggested maximum values. It MAY use lower values for operational reasons, like an upcoming renumbering event โณ.
- The SOA RR tells the HNA the value of the MNAME of the Public Homenet Zone โจ.
- The NAME of the SOA RR MUST be the Registered Homenet Domain ๐ท๏ธ.
- The MNAME value of the SOA RDATA is the value the DOI provided to the HNA ๐.
- The other RDATA values (RNAME, REFRESH, RETRY, EXPIRE, and MINIMUM) are provided by the DOI as suggestions ๐ก.
The NS RRsets carry the Public Authoritative Servers of the DOI ๐ฅ๏ธ. Their associated NAME MUST be the Registered Homenet Domain ๐.
On top of the default TTL stuff above, the HNA SHOULD be careful not to pick a TTL that's larger than the parent NS, based on the resolver guidelines in [NS-REVALIDATION] and [DRO-RECS] ๐ง. The RRsets of type A and AAAA MUST have their NAME matching the NSDNAME of one of the NS RRsets ๐ฏ.
When the response arrives, the HNA MUST validate the format and properties of the SOA, NS, and A or AAAA RRsets ๐. If an error occurs, the HNA MUST stop proceeding and MUST log an error ๐ซ๐. Otherwise, the HNA builds the Public Homenet Zone by setting the MNAME value of the SOA to whatever the SOA in the AXFR response says โ . The HNA MUST NOT exceed the values of NAME, REFRESH, RETRY, EXPIRE, and MINIMUM from the SOA in the AXFR response ๐ โโ๏ธ. The HNA MUST insert the NS and corresponding A or AAAA RRsets into its Public Homenet Zone ๐งฑ. The HNA MUST ignore other RRsets ๐.
If the DM sends back an error message, the HNA MUST proceed as a regular DNS resolution ๐. Error messages SHOULD be logged so they can be analyzed later ๐. If the resolution doesn't succeed, the outsourcing operation is aborted and the HNA MUST close the Control Channel ๐๐.
6.5.2. Providing Information for the DNSSEC Chain of Trust ๐
To send the DS RRset that initializes the DNSSEC chain of trust, the HNA MAY send a DNS update [RFC3007] message ๐ซ.
The DNS update message is made up of a Header section, a Zone section, a Prerequisite section, an Update section, and an additional section ๐งฑ. The Zone section MUST set the ZNAME to the parent zone of the Registered Homenet Domain, which is where the DS records should be inserted ๐. As described in [RFC2136], ZTYPE is set to SOA and ZCLASS is set to the zone's class ๐. The Prerequisite section MUST be empty ๐ซ. The Update section is a DS RRset whose NAME is set to the Registered Homenet Domain, and the associated RDATA corresponds to the value of the DS ๐. The Additional Data section MUST be empty ๐งน.
Though the DM MAY ignore the Prerequisite section, this value is fixed so it stays coherent with a standard DNS update ๐งฉ.
When the DM gets the DNS update request, it reads the DS RRset in the Update section ๐. It checks that ZNAME corresponds to the parent zone ๐. The DM MUST ignore the Prerequisite and Additional Data sections, if they're present ๐ โโ๏ธ. The DM MAY update the TTL value before it updates the DS RRset in the parent zone โฑ๏ธ. After a successful update, the DM should return a NOERROR response as a commitment to update the parent zone with the provided DS ๐ . An error means the DM did not update the DS, so the HNA needs to act accordingly. Otherwise, another method should be used by the HNA ๐.
When an error occurs, the regular DNS error message MUST be returned to the HNA โ. Specifically, FORMERR comes back when a format error is found, including when unexpected RRsets are added or when RRsets are missing ๐. SERVFAIL comes back when an internal error is encountered ๐ฅ. NOTZONE comes back when the Update and Zone sections don't match up ๐งฉ. NOTAUTH comes back when the DM isn't authoritative for the Zone section ๐ท. REFUSED comes back when the DM refuses the configuration or refuses to perform the requested action ๐ โโ๏ธ๐.
6.5.3. Providing Information for the Synchronization Channel ๐ช
By default, the HNA uses the IP address of the Control Channel for the Synchronization Channel ๐. If it wants a different IP address, the HNA MAY send a DNS UPDATE message ๐.
Similar to what's described in Section 6.5.2, the HNA MAY specify the IP address using a DNS update message ๐. The Zone section sets its ZNAME to the parent zone of the Registered Homenet Domain, ZTYPE to SOA, and ZCLASS to the zone's type ๐งพ. The Prerequisite section is empty ๐ซ. The Update section is an RRset of type NS. The Additional Data section contains the RRsets of type A or AAAA that designate the IP addresses associated with the primary (or the HNA) ๐งฉ.
The reason for providing these IP addresses is to keep them unpublished so they can't be resolved ๐. It is RECOMMENDED that the HNA's IP address be randomly chosen so it's harder to find too ๐ฒ๐ซฃ.
When the DM gets the DNS update request, it reads the IP addresses and checks that ZNAME corresponds to the parent zone ๐. The DM MUST ignore a non-empty Prerequisite section ๐ โโ๏ธ. The DM configures the secondary with the IP addresses and returns a NOERROR response to show it's committed to serving as a secondary ๐ค๐.
Similar to what's described in Section 6.5.2, DNS errors are used here too, and an error means the DM is not configured as a secondary ๐ฌ.
6.5.4. Initiating Deletion of the Delegation ๐งน
To start deleting the delegation, the HNA sends a DNS UPDATE Delete message ๐๏ธ.
The Zone section sets its ZNAME to the Registered Homenet Domain, the ZTYPE to SOA, and the ZCLASS to the zone's type ๐. The Prerequisite section is empty ๐ซ. The Update section is an RRset of type NS, with the NAME set to the Registered Domain Name ๐ท๏ธ. As indicated in [RFC2136], Section 2.5.2, the delete instruction is started by setting TTL to 0, CLASS to ANY, and RDLENGTH to 0, and RDATA MUST be empty ๐ช. The Additional Data section is empty ๐งผ.
When the DM gets the DNS update request, it checks the request and removes the delegation ๐ซง. It returns a NOERROR response to show the delegation has been deleted ๐. Similar to what's described in Section 6.5.2, DNS errors are used here too, and an error means the delegation has not been deleted ๐ฅฒ.
6.6. Securing the Control Channel ๐โจ
okay bestie, security time ๐ค๐ TLS [RFC8446] MUST be used to secure the transactions between the DM and the HNA, and the DM and HNA MUST be mutually authenticated. The DNS exchanges are performed using DNS over TLS [RFC7858]. no cap, both sides have to prove who they are ๐ซถ
The HNA may be provisioned by the manufacturer or during some user-initiated onboarding process. For example, a person might use a browser and sign up with a service provider, and then an OAuth 2.0 token gets handed to the HNA. This kind of process may pass settings from a registrar into the HNA through an http API interface. (This is not in scope for this document.) ๐ง
When the HNA connects to the DM's Control Channel, TLS will be used and the connection will be mutually authenticated. The DM will authenticate the HNA's certificate based on it having taken part in some provisioning process. That process is not standardized by this document ๐ The results of the provisioning process are a series of settings described in Appendix A.1.
The HNA will validate the DM's Control Channel certificate by doing a DNS-ID check on the name, as described in [RFC9525]. โ
In the future, other specifications may protect DNS messages with other transport layers, such as DNS over DTLS [RFC8094], DNS over HTTPS (DoH) [RFC8484], or DNS over QUIC [RFC9250]. the future is looking so bright ๐
7. Synchronization Channel ๐๐
okay, the DM Synchronization Channel is the channel the HNA and the DM use to keep the Public Homenet Zone in sync. ngl this is where it gets a little tricky ๐ The Control Channel and the Synchronization Channel are different channels by construction, even though they may use the same IP address. Say the HNA and the DM are both using one IP address called XX, and YYYYY and ZZZZZ are the ports involved in the communication.
The Control Channel is between:
- the HNA working as a client, using port number
YYYYY(an ephemeral port, also commonly called a high range port), and - a service provided by the DM at port
853, when using DoT.
The Synchronization Channel, on the other hand, is between:
- the DM working as a client, using port
ZZZZZ(another ephemeral port), and - a service provided by the HNA at port
853.
So even though the same pair of IP addresses may be involved, the Control Channel and the Synchronization Channel are always distinct channels. two different lanes, same road ๐ฃ๏ธโจ
Uploading and dynamically updating the zone file on the DM can be seen as zone provisioning between the HNA (hidden primary server) and the DM (secondary server). This is handled with the normal zone transfer mechanism, which involves AXFR and Incremental Zone Transfer (IXFR). it's giving classic DNS ๐
Part of the zone update process involves the owner of the zone (the hidden primary server, which is the HNA) sending a DNS Notify to the secondaries. In this situation, the only destination the HNA knows about is the DM's Control Channel. So DNS Notifies get sent over the Control Channel, secured by a mutually authenticated TLS. ๐ฃ
Please note that DNS Notifies are not critical to normal operation, because the DM will check the zone regularly based on SOA record comments. DNS Notifies do speed things up, though. They cause the DM to use the Synchronization Channel to immediately do an SOA query and detect any updates. If there are any changes, the DM immediately transfers the zone updates. zoom zoom โก
This specification standardizes the use of a primary/secondary mechanism [RFC1996] rather than an extended series of DNS update messages. The primary/secondary mechanism was picked because it scales better and avoids DoS attacks. Because this AXFR runs over a TCP channel secured by a mutually authenticated TLS, the DNS update is more complicated. ๐ง
Heads up: this document provides no standard way to distribute a DNS primary between multiple devices. So if multiple devices are candidates for hosting the hidden primary server, some specific mechanisms should be designed so the home network only selects a single HNA for the hidden primary server. Selection mechanisms based on HNCP [RFC7788] are good candidates for future work. ๐จ
7.1. Securing the Synchronization Channel ๐๐
The Synchronization Channel uses mutually authenticated TLS, as described by [RFC9103]. ๐
There is a TLS client certificate that the DM uses to authenticate itself. The DM uses the same certificate that was configured into the HNA for authenticating the Control Channel, but as a client certificate rather than a server certificate. so it's the same cert, just wearing a different hat ๐ฉ
[RFC9103] makes no requirements or recommendations on any extended key usage flags for zone transfers. This document takes the view that none should be required. Note that once an update to [RFC9103] is published, this document's normative reference to [RFC9103] will be considered updated as well. ๐
For the TLS server certificate, the HNA uses the same certificate that it uses to authenticate itself to the DM for the Control Channel. ๐ซง
The HNA MAY use this certificate as the authorization for the zone transfer. Or the HNA MAY have been configured with an Access Control List (ACL) that determines whether the zone transfer can proceed. This is a local configuration option, since it's too early to tell which one will be operationally simpler. ๐คทโโ๏ธ
When the HNA expects to do zone transfer authorization by certificate only, the HNA MAY still apply an ACL on inbound connection requests to avoid load. In this case, the HNA MUST regularly check (via a DNS resolution) the validity of the address(es) of the DM in the filter. the vibe is "check your guest list often" ๐๐
8. DM Distribution Channel ๐โจ
The DM Distribution Channel is used for communication between the DM and the Public Authoritative Servers. The architecture and communication for the DM Distribution Channels are outside the scope of this document. There are plenty of existing solutions, though, e.g., rsync, DNS AXFR, REST, and DB copy. options options options ๐
9. HNA Security Policies ๐ก๏ธ๐
The HNA, as the hidden primary server, only processes a limited set of message exchanges on its Internet-facing interface. This should be enforced using security policies, so that only a subset of DNS requests get received by the HNA. ๐
The hidden primary server on the HNA is different from the regular authoritative server for the home network, for these reasons:
- Interface Binding: The hidden primary server will almost certainly listen on the WAN Interface, whereas a regular Homenet Authoritative Server will listen on the internal home network interface. ๐ โก๏ธ๐
- Limited Exchanges: The purpose of the hidden primary server is to synchronize with the DM, not to serve any zones to end users or the public Internet. This results in a limited number of possible exchanges (AXFR/IXFR) with a small number of IP addresses. An implementation MUST enable filtering policies: it should only respond to queries that are required to do zone transfers. That list includes SOA queries and AXFR/IXFR queries. only the essentials, bestie ๐ โโ๏ธ
10. Public Homenet Reverse Zone ๐๐ธ
The Public Homenet Reverse Zone works similarly to the Public Homenet Zone. The main difference is that the ISP providing the IPv6 connectivity is likely to also be the owner of the corresponding IPv6 reverse zone, and it administrates the Reverse Public Authoritative Servers. The configuration and the setting of the Synchronization Channel and Control Channel can largely be automated using DHCPv6 messages that are part of the IPv6 prefix delegation process. โจ๐ช
The Public Homenet Zone is associated with a Registered Homenet Domain. Owning that domain requires a specific registration from the end user, as well as the HNA being provisioned with some authentication credentials. Those steps are mandatory unless the DOI has some other means to authenticate the HNA. That situation may occur, for example, when the ISP provides the Homenet Domain as well as the DOI. ๐งพ
In this case, the HNA may be authenticated by the physical link layer, in which case the HNA's authentication may happen without additional provisioning. While this may not be so common for the Public Homenet Zone, it is expected to be quite common for the Reverse Homenet Zone, since the ISP owns the IP address or IP prefix. ๐
More specifically, a common case is that the upstream ISP provides the IPv6 prefix to the Homenet with an identity association for a prefix delegation (IA_PD) option [RFC8415], and it manages the DOI of the associated reverse zone. ๐ฌ
This leaves room for setting up the relation between the HNA and the DOI automatically, as described in [RFC9527]. ๐ค
In the case of the reverse zone, the DOI authenticates the source of the updates by IPv6 ACLs, and the ISP knows exactly which addresses have been delegated. Therefore, the HNA SHOULD always originate Synchronization Channel updates from an IP address within the zone that is being updated. Exceptionally, the Synchronization Channel might come from a different zone delegated to the HNA, for instance if there are multiple zones or renumbering events in progress. ๐ข
For example, if the ISP has assigned 2001:db8:f00d:1234::/64 to the WAN interface (by DHCPv6 or PPP with Router Advertisement (RA)), then the HNA should originate Synchronization Channel updates from, for example, 2001:db8:f00d:1234::2. ๐
If an ISP has delegated 2001:db8:aeae::/56 to the HNA via DHCPv6-PD, then the HNA should originate Synchronization Channel updates to an IP address within that subnet, such as 2001:db8:aeae:1::2. ๐ฏ
With this relation automatically configured, the synchronization between the home network and the DOI happens in a similar way to the synchronization of the Public Homenet Zone described earlier in this document. it's basically the same energy, just a different zone ๐
Note that for home networks connected to multiple ISPs, each ISP provides only the DOI of the reverse zones associated with the delegated prefix. It is also likely that the DNS exchanges will need to be performed on dedicated interfaces to be accepted by the ISP. More specifically, the reverse zone update associated with prefix 1 cannot be performed by the HNA using an IP address that belongs to prefix 2. Such constraints do not raise major concerns for hot standby or load-sharing configurations. ๐๐ซถ
With IPv6, the reverse domain space for IP addresses associated with a subnet such as ::/64 is so large that the reverse zone may face scalability issues. How the reverse zone is generated is out of scope of this document. [RFC8501] provides guidance on how to address scalability issues. the numbers are WILD ๐คฏ๐
11. DNSSEC-Compliant Homenet Architecture ๐โจ
okay so Section 3.7.3 of [RFC7368] recommends that DNSSEC be deployed on both the authoritative server and the resolver ๐
The resolver side is out of scope for this doc, so we're only looking at the authoritative part of the server ๐ซถ Other docs like [RFC5011] handle the continuous updating of trust anchors that a DNSSEC Resolver needs to work ๐ธ
The Public Homenet Zone and the Public Reverse Zone MUST be DNSSEC signed by the HNA ๐ฅ
Secure delegation only works if the DS RRset is properly set in the parent zone ๐ The HNA or the DOI can handle secure delegation, and which one it is really depends on who is authorized to make those updates ๐ค Usually the DS RRset gets updated by hand through a registrar interface, and it can also be maintained with mechanisms like CDS [RFC7344] ๐ฆ
When the DOI operator is also the registrar for the domain, it's a total breeze for the DOI to set up the relevant DS records in the parent zone โจ In other cases some other setup will be needed, and that depends on the infrastructure involved. That's beyond the scope of this doc ๐
โ ๏ธ There may be situations where the HNA can't arrange secure delegation for the zones, but the HNA MUST still sign the zones. No skipping the signing, bestie ๐ญ
12. Renumbering ๐
okay, renumbering. During a renumbering of the home network, the HNA IP address may change, and the HNA will update the Public Homenet Zone with new AAAA records ๐
Then the HNA tells the DM via a NOTIFY on the Control Channel ๐ฃ The DM needs to note the new originating IP for the connection and update its internal database of Synchronization Channels ๐ง After that, a new zone transfer happens with the new records for the resources the HNA wants to publish ๐
The rest of this section gives recommendations for provisioning the Public Homenet Zone, especially the IP addresses ๐
Renumbering is extensively described in [RFC4192] and analyzed in [RFC7010], so you're expected to be familiar with those before reading this section ๐ In the make-before-break renumbering scenario, the new prefix gets advertised and the network is set up to prepare the switch to it โจ For a while the old and new prefixes coexist before the old prefix is totally removed ๐ธ New resource records with the new prefix SHOULD be published, and the old resource records with the old prefixes SHOULD be withdrawn ๐ซถ If the HNA expects the overlap to be long (maybe because it knows the router and DHCPv6 lifetimes), it MAY publish the old prefixes with a significantly lower TTL ๐ฆ
In break-before-make renumbering scenarios, including flash renumbering scenarios [RFC8978], the old prefix becomes unusable before the new prefix is known or advertised ๐ As [RFC8978] explains, some flash renumberings happen because the HNA got power cycled, and ISPs don't always properly remember which prefixes they assigned to which user ๐
An HNA that boots up MUST immediately use the Control Channel to update the location for the Synchronization Channel ๐ Doing this on every boot is totally reasonable, because the HNA has no idea how long it's been offline, or whether the (DNSSEC) zone may have expired while it was powered off ๐ฌ
The HNA has a list of names that should be published, but it might not have IP addresses for those devices yet ๐งธ That can happen because the other devices weren't online yet at power on ๐ If the HNA is sure the prefix hasn't changed, it should use the previously known addresses, with a very low TTL ๐ญ
Even though the new and old IP addresses might both be stored in the Public Homenet Zone, it is RECOMMENDED that only the newly reachable IP addresses be published ๐
Now the Public Homenet Reverse Zone ๐ช The new one has to be populated as soon as possible, and the old one gets deleted by the zone's owner (and the owner of the old prefix, which is usually the ISP) once the prefix is no longer assigned to the HNA ๐๏ธ The ISP MUST ensure the DNS cache has expired before reassigning the prefix to a new home network โณ This can be enforced by controlling the TTL values โฐ
To avoid reachability disruption, IP connectivity info provided by the DNS MUST be coherent with the IP in use ๐ In this case, that means the old IP address MUST NOT be provided via the DNS once it isn't reachable anymore ๐ซ
In the make-before-break scenario, it's possible to make the transition seamless โจ Let T be the TTL associated with an RRset of the Public Homenet Zone, Time_NEW be the time the new IP address replaces the old IP address in the Homenet Zone, and Time_OLD_UNREACHABLE be the time the old IP won't be reachable anymore ๐งฎ
In the make-before-break scenario, seamless reachability is provided as long as Time_OLD_UNREACHABLE - T_NEW > (2 * T) ๐ฆ If that isn't satisfied, then devices tied to the old IP address in the home network may become unreachable for 2 * T - (Time_OLD_UNREACHABLE - Time_NEW) ๐ญ
In a break-before-make scenario, Time_OLD_UNREACHABLE = Time_NEW, and the device may become unreachable for up to 2 * T ๐ Of course, if Time_NEW >= Time_OLD_UNREACHABLE, then the outage isn't seamless ๐
13. Privacy Considerations ๐ซฃ๐
Outsourcing the DNS Authoritative service from the HNA to a third party raises a few privacy concerns ๐ต๏ธโโ๏ธ
The Public Homenet Zone lists the names of services hosted in the home network ๐ Combined with blocking of AXFR queries, using NSEC3 [RFC5155] (vs. NSEC [RFC4034]) keeps an attacker from walking the zone to discover all the names ๐ But recent work [GPUNSEC3] [ZONEENUM] has shown that NSEC3's protection against dictionary attacks should be considered cautiously, and [RFC9276] has guidelines for configuring NSEC3 properly ๐ An attacker may also be able to walk the reverse DNS zone or use other recon techniques to learn this info, as described in [RFC7707] ๐
The zone may also be exposed during synchronization between the primary and the secondary ๐ The casual risk of this happening is low, and using [RFC9103] significantly reduces it โจ Even if the DOI uses DNS zone transfer over TLS [RFC9103], the zone's existence may still leak through Notifies ๐ฎ The protocol in this document doesn't increase that risk, since all Notifies use the encrypted Control Channel ๐
In general, a home network owner is expected to publish only names they have some need to reference externally ๐ Publishing a name doesn't mean the service is necessarily reachable from any or all parts of the Internet ๐ โโ๏ธ [RFC7084] mandates that the outgoing-only policy [RFC6092] be available, and in many cases it's on by default ๐ A well-designed user interface would pair a policy for making a service public by name with a policy on who may access it ๐ง
In many cases, and for privacy reasons, the home network owner wants to publish names only for services they'll be able to access ๐ฅน Access control might be an IP source address range, or access may be restricted through some VPN functionality ๐ก๏ธ The main perks of publishing names are that the service can be accessed by the same name both inside and outside the home, and DNS resolution can be handled the same way both inside and outside the home โจ That makes VPNs a lot easier to use, since the VPN can be picked based on the IP address of the service ๐ช Typically, a user might configure their device to reach their Homenet devices via a VPN while the rest of the traffic goes direct ๐ธ
Enterprise networks have generally adopted another strategy called split-horizon-DNS ๐ข It might look like it gives more privacy at first glance, but it's genuinely hard to implement and the privacy advantages need careful thought ๐ตโ๐ซ In split-horizon-DNS, names get internal names that can only be resolved inside the corporate network ๐ When that strategy is applied to the homenet, VPNs need to be configured with naming resolution policies and routing policies ๐บ๏ธ That might be reasonable with a single VPN, but keeping a coherent DNS space and IP space across various VPNs comes with serious complexity ๐ First, if multiple homenets use the same domain name (like home.arpa), it gets hard to tell which network the resolution should happen on ๐คฏ So homenets should at least be told apart by a domain name ๐ท๏ธ Second, split-horizon-DNS requires each VPN to be tied to a resolver, with specific resolutions handled by the dedicated resolver ๐งฉ Those policies can easily cause conflicts (with significant privacy issues) and are still hard to implement ๐ค
Besides the Public Homenet Zone, pervasive DNS monitoring can also watch the traffic associated with the Public Homenet Zone ๐๏ธ That traffic can reveal which services an end user accesses, plus how and when they use them ๐ Caching may hide this info inside the home network, but it's likely that it won't be cached outside the home network ๐
14. Security Considerations ๐ก๏ธ๐
The HNA never answers DNS requests from the Internet ๐ โโ๏ธ Those requests are served by the DOI instead ๐ซถ
Even though this limits how exposed the HNA is, the HNA still has some exposure to attacks from the Internet ๐ฐ This section analyzes the attack surface of those communications, the data published by the DOI, and operational considerations ๐
14.1. Registered Homenet Domain ๐ก
The DOI MUST NOT serve any Public Homenet Zone when it isn't confident that the HNA owns the Registered Homenet Domain ๐จ Proof of ownership is outside the scope of this doc, so it's assumed that this step happened before the zone was outsourced ๐ค
14.2. HNA DM Channels
okay bestie, the channels between HNA and DM are mutually authenticated AND encrypted with TLS [RFC8446], and its associated security considerations apply too ๐โจ
To make sure the multiple TLS sessions keep authenticating the same entity ๐, TLS may take advantage of second-factor authentication as described in [RFC8672] for the TLS server certificate for the Control Channel. The HNA should also cache the TLS server certificate used by the DM, so it can authenticate the DM while setting up the Synchronization Channel. (Alternatively, the HNA is configured with an ACL that says which Synchronization Channel connections will originate from where ๐๏ธ)
The Control Channel and Synchronization Channel follow the guidelines in [RFC7858] and [RFC9103], respectively ๐
DNS is subject to reflection attacks, but these are mostly a problem when DNS is carried over UDP. The interfaces between the HNA and DM use TLS over TCP, which prevents such reflection attacks ๐ก๏ธ Public Authoritative servers hosted by the DOI are subject to such attacks, but that's out of scope for this document, so we're not getting into it here.
Note that for the Reverse Homenet Zone, the data is less subject to attacks than in the Public Homenet Zone. Also, the DM and Reverse Distribution Manager (RDM) may be provided by the ISP, as described in [RFC9527]. In that case, DM and RDM might be less exposed to attacks, since the communications stay within a network ๐ธ
14.3. Names Are Less Secure than IP Addresses
so this doc is about how an end user can make their services and devices on their home network reachable on the Internet using names instead of IP addresses ๐ and honestly? That exposes the home network to attackers ๐ฌ because names are expected to have less entropy than IP addresses.
IPv4 addresses are 4-bytes long, which gives 2^32 possibilities. With IPv6 addresses, the Interface Identifier is 64-bits long, leading to up to 2^64 possibilities for a given subnetwork. And it doesn't stop there: the subnet prefix is also 64-bits long, which gives up to 2^64 possibilities too ๐คฏ
On the other hand, names used for either the home network domain or the devices carry less entropy (livebox, router, printer, nicolas, jennifer, ...). That means they could potentially expose the devices to dictionary attacks ๐
14.4. Names Are Less Volatile than IP Addresses
IP addresses can be used to locate a device, a host, or a service. But home networks are not expected to be assigned a time-invariant prefix by ISPs ๐ Plus, IPv6 enables temporary addresses that make them even more volatile [RFC8981]. So observing IP addresses only gives you some ephemeral info about who is accessing the service ๐ซ
Names, on the other hand, are not expected to be as volatile as IP addresses. That's why logging names over time may be more valuable than logging IP addresses, especially if someone wants to profile an end user's characteristics ๐
PTR provides a way to bind an IP address to a name, so responding to PTR DNS queries may affect the end user's privacy ๐ For that reason, PTR DNS queries MAY be configured to return with NXDOMAIN instead โจ
14.5. Deployment Considerations
The HNA is expected to sign the DNSSEC zone and, as such, hold the private KSK and Zone Signing Key (ZSK) ๐
There's no strong justification for using a separate KSK and ZSK here. If an attacker gets access to one of them, it's likely they'll get access to both ๐ญ If the HNA runs in a home router with a secure element (SE) or trusted platform module (TPM), storing the private keys in the secure element would be a useful precaution ๐ง The DNSSEC keys are generally needed on an hourly to weekly basis, but not more often.
While there is some risk that malicious parties might disclose the DNSSEC keys, the bigger risk is that they'll simply get lost if the home router is factory reset, or just thrown out or replaced with a newer model ๐ฆ
Generating new DNSSEC keys is relatively easy, and they can be deployed using the Control Channel to the DM ๐ The key used to authenticate that connection is the critical key that needs protection, and it should ideally be backed up to offline storage (such as a USB key) ๐พ
14.6. Operational Considerations
Homenet technologies make it easier to expose devices and services to the Internet, which brings broader operational considerations for the operator and the Internet ๐ Here's the tea:
- The home network operator must carefully assess whether a device or service previously fielded only on a home network is robust enough to be exposed to the Internet ๐ง
- The home network operator will need to level up their diligence and regularly manage these exposed devices, because their risk posture is higher once they're on the Internet ๐ช
- Depending on the operational practices of home network operators, there is an increased risk to the Internet through the possible introduction of additional Internet-exposed systems that are poorly managed and likely to be compromised ๐จ
15. IANA Considerations โจ
no IANA actions for this one, bestie ๐ซถ This document has none.
16. References ๐
16.1. Normative References
[RFC1034]Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,https://www.rfc-editor.org/info/rfc1034.[RFC1918]Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,https://www.rfc-editor.org/info/rfc1918.[RFC1996]Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, August 1996,https://www.rfc-editor.org/info/rfc1996.[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,https://www.rfc-editor.org/info/rfc2119.[RFC3007]Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,https://www.rfc-editor.org/info/rfc3007.[RFC4034]Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005,https://www.rfc-editor.org/info/rfc4034.[RFC5155]Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,https://www.rfc-editor.org/info/rfc5155.[RFC7344]Kumari, W., Gudmundsson, O., and G. Barwood, "Automating DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 10.17487/RFC7344, September 2014,https://www.rfc-editor.org/info/rfc7344.[RFC7858]Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016,https://www.rfc-editor.org/info/rfc7858.[RFC8174]Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,https://www.rfc-editor.org/info/rfc8174.[RFC8375]Pfister, P. and T. Lemon, "Special-Use Domain 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018,https://www.rfc-editor.org/info/rfc8375.[RFC8446]Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,https://www.rfc-editor.org/info/rfc8446.[RFC8499]Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019,https://www.rfc-editor.org/info/rfc8499.[RFC9103]Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A. Mankin, "DNS Zone Transfer over TLS", RFC 9103, DOI 10.17487/RFC9103, August 2021,https://www.rfc-editor.org/info/rfc9103.[RFC9525]Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, November 2023,https://www.rfc-editor.org/info/rfc9525.
16.2. Informative References ๐
Okay bestie, here's the extra-credit reading list. These are the optional-but-super-useful references, and every single one is still listed in full ๐ซถ
[DOMAIN-VALIDATION] Sahib, S., Huque, S., Wouters, P., and E. Nygren, "Domain Control Validation using DNS", Work in Progress, Internet-Draft, draft-ietf-dnsop-domain-verification-techniques-03, 17 October 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-03>.
[DRO-RECS] Migault, D., Lewis, E., and D. York, "Recommendations for DNSSEC Resolvers Operators", Work in Progress, Internet-Draft, draft-ietf-dnsop-dnssec-validator-requirements-07, 13 November 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dnssec-validator-requirements-07>.
[GPUNSEC3] Wander, M., Schwittmann, L., Boelmann, C., and T. Weis, "GPU-Based NSEC3 Hash Breaking", DOI 10.1109/NCA.2014.27, August 2014, <https://doi.org/10.1109/NCA.2014.27>.
[HOMEROUTER-PROVISION] Richardson, M., "Provisioning Initial Device Identifiers into Home Routers", Work in Progress, Internet-Draft, draft-richardson-homerouter-provisioning-02, 14 November 2021, <https://datatracker.ietf.org/doc/html/draft-richardson-homerouter-provisioning-02>.
[NS-REVALIDATION] Huque, S., Vixie, P., and R. Dolmans, "Delegation Revalidation by DNS Resolvers", Work in Progress, Internet-Draft, draft-ietf-dnsop-ns-revalidation-04, 13 March 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-ns-revalidation-04>.
[REBIND] Wikipedia, "DNS rebinding", September 2023, <https://en.wikipedia.org/w/index.php?title=DNS_rebinding&oldid=1173433859>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <https://www.rfc-editor.org/info/rfc2136>.
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, DOI 10.17487/RFC3587, August 2003, <https://www.rfc-editor.org/info/rfc3587>.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, DOI 10.17487/RFC3927, May 2005, <https://www.rfc-editor.org/info/rfc3927>.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, DOI 10.17487/RFC4192, September 2005, <https://www.rfc-editor.org/info/rfc4192>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, September 2007, <https://www.rfc-editor.org/info/rfc5011>.
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, DOI 10.17487/RFC6092, January 2011, <https://www.rfc-editor.org/info/rfc6092>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, <https://www.rfc-editor.org/info/rfc6887>.
[RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, DOI 10.17487/RFC7010, September 2013, <https://www.rfc-editor.org/info/rfc7010>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, November 2013, <https://www.rfc-editor.org/info/rfc7084>.
[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. Weil, "IPv6 Home Networking Architecture Principles", RFC 7368, DOI 10.17487/RFC7368, October 2014, <https://www.rfc-editor.org/info/rfc7368>.
[RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local Addressing inside an IPv6 Network", RFC 7404, DOI 10.17487/RFC7404, November 2014, <https://www.rfc-editor.org/info/rfc7404>.
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, <https://www.rfc-editor.org/info/rfc7707>.
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016, <https://www.rfc-editor.org/info/rfc7788>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/RFC8094, February 2017, <https://www.rfc-editor.org/info/rfc8094>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.
[RFC8501] Howard, L., "Reverse DNS in IPv6 for Internet Service Providers", RFC 8501, DOI 10.17487/RFC8501, November 2018, <https://www.rfc-editor.org/info/rfc8501>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, <https://www.rfc-editor.org/info/rfc8555>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8672] Sheffer, Y. and D. Migault, "TLS Server Identity Pinning with Tickets", RFC 8672, DOI 10.17487/RFC8672, October 2019, <https://www.rfc-editor.org/info/rfc8672>.
[RFC8978] Gont, F., ลฝorลพ, J., and R. Patterson, "Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events", RFC 8978, DOI 10.17487/RFC8978, March 2021, <https://www.rfc-editor.org/info/rfc8978>.
[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", RFC 8981, DOI 10.17487/RFC8981, February 2021, <https://www.rfc-editor.org/info/rfc8981>.
[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, May 2022, <https://www.rfc-editor.org/info/rfc9250>.
[RFC9276] Hardaker, W. and V. Dukhovni, "Guidance for NSEC3 Parameter Settings", BCP 236, RFC 9276, DOI 10.17487/RFC9276, August 2022, <https://www.rfc-editor.org/info/rfc9276>.
[RFC9527] Migault, D., Weber, R., and T. Mrugalski, "DHCPv6 Options for the Homenet Naming Authority", RFC 9527, DOI 10.17487/RFC9527, January 2024, <https://www.rfc-editor.org/info/rfc9527>.
[ZONEENUM] Wang, Z., Xiao, L., and R. Wang, "An efficient DNSSEC zone enumeration algorithm", DOI 10.2495/MIIT130591, April 2014, <https://doi.org/10.2495/MIIT130591>.
Appendix A. HNA Channel Configurations ๐ธ
A.1. Public Homenet Zone ๐ก
This doc doesn't cover how the HNA gets set up with a trusted relationship to the Distribution Manager for the forward zone. That's a different story ๐
This section spells out what needs to get loaded into the HNA, and it basically works as a requirements list for the mechanisms. Here's the vibe check:
- the Registered Domain (e.g., myhome.example);
- the contact information for the DM, including the DNS name (the fully qualified domain name (FQDN)), possibly the IP literal, and a certificate (or anchor) to be used to authenticate the service;
- the DM transport protocol and port (the default is DNS over TLS, on port 853); and
- the HNA credentials used by the DM for its authentication.
The HNA is going to need to pick an IP address for the Synchronization Channel. Usually that's the WAN address of the CPE, but if a home has multiple ISPs (and multiple border routers), it could be an IPv6 LAN address instead. Section 6.5.3 has the details on this, when the NS and A or AAAA RRsets get communicated. ๐
The above parameters MUST be provisioned for ISP-specific reverse zones. [RFC9527] has one example of how to do that ๐ซถ ISP-specific forward zones MAY also be provisioned using [RFC9527], but zones that aren't tied to a specific ISP (like ones run by a DNS provider) must be provisioned through other means. Not everything can come from the ISP, bestie.
Same energy if the HNA comes from a registrar: it may already be handed to the end user preconfigured. โจ
If there's no pre-established relationship, the end user may enter these pieces of information by hand. To make that less painful for them, the following scheme may be implemented. ๐ง
The HNA may show the end user a web interface where they can pick their Registered Homenet Domain or their registrar, maybe from a preselected list. Once the registrar is chosen, the HNA redirects the end user to that registrar to get an access token. That token lets the HNA pull the DM parameters tied to the Registered Domain, and those parameters include the credentials the HNA uses to set up the Control and Synchronization Channels. Main character setup, honestly ๐
Such an architecture cuts down on the steps the end user has to take to configure the HNA. Iconic, periodt ๐
Appendix B. Information Model for Outsourced Information โจ
Okay bestie, this section is so important ๐ฅบ It specifies an optional format for the set of parameters the HNA needs to set up the naming architecture of this document ๐
So picture this: a home router wasn't provisioned by the manufacturer (for when the forward zones come from the maker) or by the ISP (when the ISP is the one offering this service) ๐ Then the home user/owner has to configure these settings themselves through an administrative interface. Yikes.
That's why defining a standard format (in JSON) for this config info is such a glow-up โจ The user/owner may be able to copy and paste a configuration blob from the service provider right into the HNA's administrative interface. Easy peasy ๐
This format may also be the basis for a future OAuth 2.0 [RFC6749] flow that could do the setup automatically. Iykyk, automation is always iconic ๐ค
The HNA needs to be configured with the following parameters, described using the Concise Data Definition Language (CDDL) [RFC8610]. These parameters are what establish a secure channel between the HNA and the DM, and they also specify the DNS zone that's in scope for the communication ๐
hna-configuration = {
"registered_domain" : tstr,
"dm" : tstr,
? "dm_transport" : "DoT"
? "dm_port" : uint,
? "dm_acl" : hna-acl / [ +hna-acl ]
? "hna_auth_method": hna-auth-method
? "hna_certificate": tstr
}
hna-acl = tstr
hna-auth-method /= "certificate"Here's an example, bestie ๐
{
"registered_domain" : "n8d234f.r.example.net",
"dm" : "2001:db8:1234:111:222::2",
"dm_transport" : "DoT",
"dm_port" : 4433,
"dm_acl" : "2001:db8:1f15:62e::/64"
or [ "2001:db8:1f15:62e::/64", ... ]
"hna_auth_method" : "certificate",
"hna_certificate" : "-----BEGIN CERTIFICATE-----\nMIIDTjCCFGy..",
}Now let's go through each field, because each one matters ๐
Registered Homenet Domain (registered_domain): This is the Domain Name of the zone. Multiple Registered Homenet Domains may be provided, and that generates the creation of multiple Public Homenet Zones. This parameter is mandatory, so no skipping it ๐ญ
Distribution Manager notification address (dm): These are the associated FQDNs or IP addresses of the DM that DNS Notifies should be sent to. This parameter is mandatory. IP addresses are optional, and the FQDN is sufficient and preferred โจ If there are concerns about the security of the name to IP translation, then DNSSEC should be employed ๐ฅ
As the session between the HNA and the DM is authenticated with TLS, using names is easier ๐ซถ
Also, certificates are more commonly issued for FQDNs than for IP addresses, so it's preferred to use names and authenticate the name of the DM during the TLS session establishment. Main character energy ๐
Supported Transport (dm_transport): This is the transport that carries the DNS exchanges between the HNA and the DM. The typical value is "DoT", but it may be extended in the future with "DoH" or "DoQ", for example. This parameter is optional, and the HNA uses DoT by default ๐ฆ
Distribution Manager Port (dm_port): This indicates the port used by the DM. This parameter is optional, and the default value is provided by the Supported Transport. In the future, an additional transport may not have a default port. In that case, either a default port needs to be defined, or this parameter becomes mandatory ๐ง
Heads up: the Synchronization Channel doesn't get ports defined by HNA. This isn't expected to be part of the configuration. Instead, it's negotiated through the Configuration Channel. Right now, the Configuration Channel doesn't provide this and limits its agility to a dedicated IP address. If that agility is needed in the future, additional exchanges will need to be defined ๐จ
Authentication Method ("hna_auth_method"): This is how the HNA authenticates itself to the DM within the TLS connection(s). The authentication method can typically be "certificate", "psk", or "none". This parameter is optional, and the Authentication Method is "certificate" by default ๐
Authentication data ("hna_certificate", "hna_key"): This is the certificate chain used to authenticate the HNA. This parameter is optional. When it isn't specified, a self-signed certificate is used ๐ธ
Distribution Manager AXFR permission netmask (dm_acl): This is the subnet from which the CPE should accept SOA queries and AXFR requests. A subnet is used in the case where the DOI consists of a number of different systems. An array of addresses is permitted too. This parameter is optional. If it's unspecified, the CPE uses the IP addresses provided by the dm parameter. That works either directly when dm indicates the IP address(es), or via the DNS or DNSSEC resolution when dm indicates an FQDN ๐
For forward zones, the relationship between the HNA and the forward zone provider may come from a few different transactions:
- The forward zone outsourcing may be provided by the maker of the Homenet router. In this case, the identity and authorization could be built into the device at manufacturer provisioning time. The device would need to be provisioned with a device-unique credential, and it's likely that the Registered Homenet Domain would be derived from a public attribute of the device, such as a serial number (see Appendix C or [HOMEROUTER-PROVISION] for more details) ๐ญ
- The forward zone outsourcing may be provided by the ISP. In this case, the use of [RFC9527] to provide the credentials is appropriate ๐ก
- The forward zone may be outsourced to a third party, such as a domain registrar. In this case, the JSON-serialized YANG data model described in this section is appropriate, since it can easily be copy and pasted by the user or downloaded as part of a web transaction ๐
For reverse zones, the relationship is always with the upstream ISP (although there may be more than one), so [RFC9527] always applies ๐
Here's an abridged example of the set of data that represents the needed configuration parameters for outsourcing โจ
Appendix C. Example: A Manufacturer-Provisioned HNA Product Flow ๐ญ
Okay, this scenario is so cute ๐ฅน It's one where a Homenet router device manufacturer decides to offer DNS hosting as a value add ๐
[HOMEROUTER-PROVISION] describes a process for a home router credential provisioning system. The outline of it is that near the end of manufacturing, as part of the firmware loading, the manufacturer provisions a private key and certificate into the device ๐
On top of having an asymmetric credential known to the manufacturer, the device has also been provisioned with an agreed-upon name. In the example in the above document, the name n8d234f.r.example.net has already been allocated and confirmed with the manufacturer ๐
The HNA can use that domain for itself. It's not very pretty or personal, but if the owner wants a better name, they can arrange one ๐
The configuration would look like this:
{
"dm" : "2001:db8:1234:111:222::2",
"dm_acl" : "2001:db8:1234:111:222::/64",
"dm_ctrl" : "manufacturer.example.net",
"dm_port" : "4433",
"ns_list" : [ "ns1.publicdns.example", "ns2.publicdns.example"],
"zone" : "n8d234f.r.example.net",
"auth_method" : "certificate",
"hna_certificate":"-----BEGIN CERTIFICATE-----\nMIIDTjCCFGy....",
}The dm_ctrl and dm_port values would be built into the firmware ๐ง
Acknowledgments ๐ซถ
The authors wish to thank Philippe Lemordant for his contributions to the earlier draft versions of this document. Ole Troan gets a shout-out for pointing out issues with the IPv6-routed home concept and placing the scope of this document in a wider picture ๐ Mark Townsley gets love for encouragement and for injecting a healthy debate on the merits of the idea ๐ Ulrik de Bie is thanked for providing alternative solutions ๐ก Paul Mockapetris, Christian Jacquenet, Francis Dupont, and Ludovic Eschard are thanked for their remarks on HNA and low power devices ๐ Olafur Gudmundsson is thanked for clarifying the DNSSEC capabilities of small devices ๐ Simon Kelley is thanked for feedback as a dnsmasq implementer ๐ฃ Andrew Sullivan, Mark Andrew, Ted Lemon, Mikael Abrahamson, Stephen Farrell, and Ray Bellis are thanked for their feedback on handling different views, and for clarifying the impact of outsourcing the zone-signing operation outside the HNA ๐ Finally, Mark Andrew and Peter Koch are thanked for clarifying the renumbering ๐
The authors would like to thank Kiran Makhijani for her in-depth review, which helped shape the final version of this document ๐
The authors would also like to thank our Area Director รric Vyncke for his constant support and for pushing the document through the IESG process ๐ Many thanks as well to the reviewers from various directorates, including Anthony Somerset, Geoff Huston, Tim Chown, Tim Wicinski, Matt Brown, Darrel Miller, and Christer Holmberg ๐ธ
Contributors ๐
The coauthors would like to thank Chris Griffiths and Wouter Cloetens for their significant contributions to the earlier draft versions of this document ๐ฆ
Authors' Addresses ๐
Daniel Migault
Ericsson
8275 Trans Canada Route
Saint Laurent QC 4S 0B6
Canada
Email: daniel.migault@ericsson.comRalf Weber
Nominum
2000 Seaport Blvd.
Redwood City, CA 94063
United States of America
Email: ralf.weber@nominum.comMichael Richardson
Sandelman Software Works
470 Dawson Avenue
Ottawa ON K1Z 5V7
Canada
Email: mcr+ietf@sandelman.caRay Hunter
Globis Consulting BV
Weegschaalstraat 3
5632CW Eindhoven
Netherlands
Email: v6ops@globis.netAnd that's a wrap on the whole RFC, bestie ๐โจ๐
๐ฆ where this page comes from
- ietf: rfc9526 2024-01
- ๐ girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms