Reviewer: Geoff Huston Review result: Ready with Issues I have been selected as the DNS Directorate reviewer for this draft. The DNS Directorate seeks to review all DNS or DNS-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the ADs. For more information about the DNS Directorate, please see https://wiki.ietf.org/en/group/dnsdir I am surprised that this draft has had 24 prior iterations and still has managed to raise so many questions on the part of this reviewer. These are not necessarily "major" issues, but there are many of them, including some questions about the precise role of this document, noted below, so I think "ready with issues" best encompasses my review advice. It strikes me that the overall intent canm be summarised in one sentence: If a homenet domain wished to publish in the DNS a number of homenet-located services in the DNS and does not want to use a conventional DNS zone delegation then a hidden primary DNS configuration may be appropriate. The document does not make it clear if it is a discussion of design choices or a normative protocol specification and the flip between the two modes is highly confusing to the reader. It may not be the normal practice in the Homenet working group but this specificatiopn seems to be begging for at least two independent implementations with proven interoperabil;ity as a precondition to publication. The specification seem to be indistinct and vague in some aspects as noted in the detaled comments and some feedback from implementation might help There are a few instances of lower case "must". Given that this uses the normative terms it would be helpful to use a different word if the normative MUST is not intended here, and use a capitalized version if it was. Document walk-through: Section 2 It would be useful to include a catchall that explains that all other DNS terms are used in the document with meanings as described in RFC8499 The definition of "Public Authoritative Service" includes the comment that "for higher resiliency networks, are often implemented in an anycast fashion" which seems like a spurious comment to me in the context of this document. On a more general note I find it curious that the documnent is inventing new names for existing DNS concepts - "Homenet Zone" is just a Zone, "Registered Homenet Domain" is just a domain. Aside from adding "Homenet" everywhere, does this deviation from a standard nomenclature for DNS components provide some essential additional clarity to the document? This reviewer tends to answer this question in the negative. Section 4.1 CPE Vendor The text notes: "Such a domain name is probably not human friendly, and may consist of some kind of serial number associated with the device being sold." The use of a specific reference to a serial number in the domain name is not clear to this reviewer. Surely the point is that such a pre-configured domain name is unique to each individual CPE device. 4.1.1. Agnostic CPE s/roof/proof/ It is not clear to me that the issue of circularity in the use of ACME has been appropriately considered. If the role of ACME is for the name holder is attempting to demonstrate their control of an as-yet-undelegated domain via ACME then how can the CA test this control if the domain is not delegated? 5. Architecture Description Grammar: "this prevents HNA to handle the DNS traffic from the Internet associated with the resolution of the Homenet Zone." surely this should read "HNA from handling"? "The DOI benefits from a cloud infrastructure" - This is not necessarily the case. What technology the publically accessible DNS authoritative name servers (or what this documnent oddly calls "DOI") uses to implemment their service (cloud or otherwise) is up to them, not this document. "In the case the HNA is a CPE, outsourcing to the DOI protects the home network against DDoS for example." If only this were the case. If the CPE uses a public network address then all form of unsolocited traffic can be directed to it. Directing DNS authoritative server queries elsewhat does not really provide any meaningful DDOS protection. "The description of such a synchronization mechanism is the purpose of this document." At this point I am left wondering about the purpose of this document. If you strip the customised nomenclature then this document advocates the use of a hidden primary for homenets. How secondaries synchronise from a hidden primary is already existing practice. Why do we need a dedicated document to add the work "homenet" to an already well understood mechanism? "The HNA signs the Public Homenet Zone with DNSSEC." - is this a MUST, a SHOULD, or a MAY" "The HNA handles all operations and keying material required for DNSSEC, so there is no provision made in this architecture for transferring private DNSSEC related keying material between the HNA and the DM." This is a curious limitation as it precludes the use of authoritative servers that use DNSSEC signing-on-the-fly. The document should note this limitation and provide some justification for the limitation. Is there a genuine issue here or is it precluded becuase it is just too hard to document here? "Resolution is performed by DNS(SEC) resolvers." This is a paragraph that a consideration of resolvers whether or not they perform DNSSEC validation, and then considers the context of DS validation. This is a clumsy construction. 5.2 Distribution Manager (DM) Communication Channels "The information exchanged between the HNA and the DM uses DNS messages protected by DNS over TLS (DoT) [RFC7858]." - is this a MUST, SHOULD or a MAY? Or at least use a forward reference to section 6.6. "The Distribution Channel is internal to the DOI and as such is not normatively defined by this specification." If the objective is interoperation between different implementations then surely this would benefit from a normative description. 6. Control Channel "The HNA is always initiating the exchange in both directions." - the HNA always initiates communications between the HNA and the DM. 6.1. Information to Build the Public Homenet Zone The document is coy on the normative requirement for DNSSEC-signing of the home zone until this point, and still is here. The sentence states: "All the content of the zone MUST be created by the HNA, because the zone is DNSSEC signed.", yet I can find no normative requirement for the zone to be DNSSEC signed. "this information exchange is mandatory." It would be preferable to rephrase this using normative language. "The HNA then perhaps and DNS Update operation to the DOI, updating the DOI with an NS, DS, A and AAAA records. " This is not a sentence. "These indicates where its Synchronization Channel is." this is very unclear. Its unlikey that the DS records would be useful in this context. 6.2. Information to build the DNSSEC chain of trust "The HNA SHOULD provide the hash of the KSK via the DS RRset, so that the DOI can provide this value to the parent zone. " - this does not address the situation where the HNA uses a hash algorithm that is not supported by the parent ands the parent performs a check on the DS prior to insertion into the zone (i.e. the rationale for the use of CDNSKEY). Should the document address this casze, as in subsequent text in this paragraph it explicitly mentions the is CDNSKEY 6.3. Information to set up the Synchronization Channel "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 has been assigned." - and what happens when its IPv4 address has changed? "By default, the IP address used by the HNA in the Control Channel is considered by the DM and the explicit specification of the IP by the HNA is only OPTIONAL." - this is unclear - is there a better way of expressing this? 6.5. Messages Exchange Description "Multiple ways were considered on how the control information could be exchanged between the HNA and the DM. This specification defines a mechanism that re-use the DNS zone transfer format. Note that while information is provided using DNS exchanges, the exchanged information is not expected to be set in any zone file, instead this information is used as commands between the HNA and the DM. This was found to be simpler on the home router side, as the HNA already has to have code to deal with all the DNS encodings/decodings. Inventing a new way to encode the DNS information in, for instance, JSON, seemed to add complexity for no return on investment." Is this justification a necessary part of a specification? It strikes me that a commentary on the design decisions has no place in a normative specification. At best a seperate RFC and if the desigire is a single document then its best to make this an appendix. "After a predefined timer" Best to NEVER use an unspecified timer in a normative specification. Either give a value or give a range of values and say "pick at random" 6.6. Securing the Control Channel "In the future, other specifications may consider protecting DNS messages with other transport layers, among others, DNS over DTLS [RFC8094], or DNS over HTTPs (DoH) [RFC8484] or DNS over QUIC [RFC9250]." Given that the three features used by this specificate when using DoT is mutual authentication using TLS, payload intgegrity and channel encryption, then DOH and DOQ appear to offer similar functionalty and could be incorporated into this specification in a seamless manner. Regarding DNS over DTLS please see section 1.1 of RFC8094. 10. Public Homenet Reverse Zone This section is very IPv6-centric. What are the considerations in this specification that apply to IPv4? 11. DNSSEC compliant Homenet Architecture "The HNA MUST DNSSEC sign the Public Homenet Zone and the Public Reverse Zone." This turnsa the "highly desirable" turns RFC7368 into a normative requirement. It seems odd to this reviewer to insist on this in all situation including those when the parent zone is unsigned, as noted in the final paragraph of this section. 12. Renumbering "During a renumbering of the home network, the HNA IP address may be changed and the Public Homenet Zone will be updated by the HNA with new AAAA records." - what about if the IPv4 address changes? The discussive commentary of section 12 is interesting, but is it properly a part of a normative specification? 13. Privacy Considerations The discussive commentary of section 13 is interesting, but is it properly a part of a normative specification? There are some logical inconsistencies in this session. If it is the case that "In general a home network owner is expected to publish only names for which there is some need to be able to reference externally." then exactly what is being protected by attempting to counter third party zone enumeration? "Enterprise networks have generally adopted another strategy designated as split-horizon-DNS. " This paragraph seems to this reviewer to be out of scope in a normative specification. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
