Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on <https://www.rfc-editor.org/search>. --> 2) <!-- [rfced] Section 1: This sentence read oddly, as it indicated that this document checks each local domain hint against a globally valid parent zone. We updated it as follows. If this is incorrect, please clarify the text. Original: This specification relies on securely identified local DNS servers, and checks each local domain hint against a globally valid parent zone. Currently: This specification expects that local DNS servers will be securely identified and that each local domain hint will be checked against a globally valid parent zone. --> 3) <!-- [rfced] Section 3: We see the following: * RFC 6762 uses '".local."' and '".local" * RFC 6763 uses '"local."' * <https://www.iana.org/assignments/special-use-domain-names/> lists 'local.' (per RFC 6762) * Quite a few subsequent RFCs use '".local"' Are any clarifications required here, or will '".local"' be clear to readers as is? Original: All of the special-use domain names registered with IANA [RFC6761], most notably ".home.arpa", "resolver.arpa.", "ipv4only.arpa." and ".local", are never unique to a specific DNS server's authority. --> 4) <!-- [rfced] Section 5: We see that I-D.ietf-dnsop-domain-verification-techniques was restructured (i.e., the section numbering changed) between versions -04 and -06. As it appears that "5.1" should now be "5.2" and "5.2" should now be "5.3", we updated this citation accordingly. Please review this diff file and let us know if this update is accurate: https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-domain-verification-techniques-04&url2=draft-ietf-dnsop-domain-verification-techniques-06 Original: The zone operator then publishes a "Verification Record" with the following structure, following the best practices outlined in Sections 5.1 and 5.2 of [I-D.ietf-dnsop-domain-verification-techniques]: Currently: The zone operator then publishes a "Verification Record" with the following structure, following the best practices outlined in Sections 5.2 and 5.3 of [DOMAIN-VERIFICATION-TECHNIQUES]: --> 5) <!-- [rfced] Sections 5 and 5.1: Are the lists with "=" correct as they are (i.e., tagged as <ul>), or may we update them to use <dl>? Original: * Type = TXT. * Owner Name = Concatenation of the ADN, "_splitdns-challenge", and the parent zone name. * Contents = "key/value" pairs, e.g., "token=base64url($TOKEN)" (without padding) ... * ADN = "resolver17.parent.example" * Parent = "parent.example" * Subdomains = "payroll.parent.example", "secret.project.parent.example" * Hash Algorithm = SHA-384 [RFC6234] * Salt = "example salt octets (should be random)" Perhaps: Type: TXT Owner Name: Concatenation of the ADN, "_splitdns-challenge", and the parent zone name Contents: "key/value" pairs, e.g., "token=base64url($TOKEN)" (without padding) ... ADN: "resolver17.parent.example" Parent: "parent.example" Subdomains: "payroll.parent.example", "secret.project.parent.example" Hash Algorithm: SHA-384 [RFC6234] Salt: "example salt octets (should be random)" --> 6) <!-- [rfced] Section 5.1: Should the "(should be random)" portion of this entry be placed outside of the quotes? Please compare with the "Contents =" entry in Section 5, where "(without padding)" is outside of the quotes. Original: * Salt = "example salt octets (should be random)" Possibly: * Salt = "example salt octets" (should be random) --> 7) <!-- [rfced] Section 5.1: We see the following note just before the sourcecode in this section: NOTE: '\' line wrapping per [RFC8792] We also see that the sourcecode in Section 7 also seems to implement line wrapping but does not include the note. Should this note also appear before the sourcecode in Section 7? Two alternatives for you to consider: 1. Place the note inside of the sourcecode, per (for example) rfc9645.xml (https://www.rfc-editor.org/info/rfc9645). 2. Remove the note and add text to the Terminology section explaining the convention for line wrapping, as follows: Lone lines in examples are wrapped using a single backslash ("\") per [RFC8792]. --> 8) <!-- [rfced] Section 5.2.2: There appeared to be a conflict between the following text in this section and some text in Section 12 (which mentions "Section 5.2" in the context of the "ZONEMD Schemes" registry). As it appears that in this section (5.2.2), "Section 5.2" should be "Section 5.3" per the fourth bullet in Section 5, we updated the citation in this section accordingly. If this is incorrect, please provide text that resolves the conflicting information. (Section 5.2 of RFC 8976 has the title "ZONEMD Scheme" and defines the "ZONEMD Schemes" registry; Section 5.3 of RFC 8976 has the title "ZONEMD Hash Algorithms" and defines the "ZONEMD Hash Algorithms" registry.) Original: * "algorithm": The hash algorithm is represented by its "Mnemonic" string from the ZONEMD Hash Algorithms registry ([RFC8976], Section 5.2). ... Algorithm Agility (see [RFC7696]) is achieved by providing implementations with flexibility to choose hashing algorithms from the ZONEMD Schemes registry ([RFC8976], Section 5.2). Currently: "algorithm": The hash algorithm, represented by its "Mnemonic" string from the "ZONEMD Hash Algorithms" registry (Section 5.3 of [RFC8976]). --> 9) <!-- [rfced] Section 5.2.2: Four registries are discussed in Section 13, one of which is the new registry defined in Section 13.3. Because Section 13.3 cites this section and this section defines the parameters listed in Section 13.3, we clarified the citation in this sentence accordingly. Please let us know any objections. Original: Future specifications aiming to define new keys will need to add them to the IANA registry defined in Section 13. Currently: Future specifications aiming to define new keys will need to add them to the IANA registry defined in Section 13.3. --> 10) <!-- [rfced] Section 7: Does "can be accomplished simply by placing" mean "can be accomplished easily by placing", "can be accomplished by simply placing", or something else? Original: When the local zone can be signed with globally trusted keys for the parent zone, support for DNSSEC can be accomplished simply by placing a zone cut at the parent zone and including a suitable DS record for the local resolver's DNSKEY. --> 11) <!-- [rfced] Section 7: As it appears that "RR" in this sentence stands for "Resource Record" and "Resource Record" is not marked well known on <https://www.rfc-editor.org/rpc/wiki/doku.php?id=abbrev_list>, we expanded it here for ease of the reader. If this expansion is incorrect, please provide the correct definition. Original: At least one resulting DNSKEY RR MUST match the DS RDATA from the "ds" key in the Verification Record. Currently: At least one resulting DNSKEY Resource Record (RR) MUST match the DS RDATA from the "ds" key in the Verification Record. --> 12) <!-- [rfced] Section 7: Please review whether the "type" attribute should be set for the following sourcecode element in the XML file. (Other sourcecode elements have the "type" attribute set.) Original: <sourcecode> ;; Parent zone. ... If the current list of preferred values for "type" (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) does not contain an applicable type, please let us know. Also, it is acceptable to leave the "type" attribute unset. --> 13) <!-- [rfced] Section 7: The second and third lines of this sourcecode were too long for the text output. We adjusted as follows. Please review, and let us know any concerns. Original: ; NSEC record indicating that unsigned delegations are permitted at ; this subdomain. This is required for compatibility with non-split-aware ; validating stub resolvers. If the claimed label is confidential, the ; parent zone can conceal it using NSEC3 (with or without "opt-out"). Currently: ; NSEC record indicating that unsigned delegations are permitted at ; this subdomain. This is required for compatibility with ; non-split-aware validating stub resolvers. If the claimed label is ; confidential, the parent zone can conceal it using NSEC3 (with or ; without "opt-out"). --> 14) <!-- [rfced] It appears that <tt>s might be inconsistently applied in this document. Some of the example URLs are enclosed in <tt>, while others are not or are enclosed in quotation marks instead. Please review the lists below, and let us know if any updates are needed. Terms enclosed with <tt>: dns.example.net *.example.com example.com *.internal.example.com internal.example.com pvd.example.com www.example.com Similar terms without <tt>: "example.com" pvd.example.com internal.example.com "internal.example.com" "ns1.internal.example.com" "private1.internal.example.com" "private2.internal.example.com" "*.internal.example.com" --> 15) <!-- [rfced] Section 8: We could not determine which example is the second of the two examples in this section. Do Sections 8.1, 8.1.1, and 8.1.2 show three examples, rather than two? Section 8.1 seems straightforward, but Sections 8.1.1 and 8.1.2 are confusing in that they seem to show two additional examples. Please review and clarify. Original: Two examples are shown below. The first example shows a company with an internal-only DNS server that claims the entire zone for that company (e.g., *.example.com). In the second example, the internal servers resolves only a subdomain of the company's zone (e.g., *.internal.example.com). 8.1. Split-Horizon Entire Zone ... 8.1.1. Verification Using an External Resolver ... Figure 3: Verifying claims using an external resolver ... 8.1.2. Verification using DNSSEC ... Figure 4: An Example of Verifying Claims using DNSSEC --> 16) <!-- [rfced] Figures 2 and 3: Would you like spacing between the step descriptions and the step numbers to be consistent? For example: Original: ... resolve pvd.example.com (4) A or AAAA records (5) ... _splitdns-challenge.example.com (1) TXT "token=ABC..." (2) resolving example.com (3) ... Possibly: ... resolve pvd.example.com (4) A or AAAA records (5) ... _splitdns-challenge.example.com (1) TXT "token=ABC..." (2) resolving example.com (3) ... --> 17) <!-- [rfced] Section 10: We do not see "ENCDNS_IP*_*" or "ENCDNS_IP*_" in RFC 9464. Will the use of the additional underscore be clear to readers, or should "ENCDNS_IP*_*" be changed to "ENCDNS_IP*" per RFC 9464? Original: When the endpoint is using a VPN tunnel and the tunnel is IPsec, the encrypted DNS resolver hosted by the VPN service provider can be securely discovered by the endpoint using the ENCDNS_IP*_* IKEv2 Configuration Payload Attribute Types defined in [RFC9464]. --> 18) <!-- [rfced] Section 11: As it appears that "to prompt the DHCP clients for dynamically requesting" means "to prompt the DHCP client to dynamically request", we updated this sentence accordingly. If this update is incorrect, please clarify "to prompt ... for ... requesting". Original: 1. DHCP reconfiguration can be initiated by a DHCP server that has previously communicated with a DHCP client and negotiated for the DHCP client to listen for Reconfigure messages, to prompt the DHCP clients for dynamically requesting the updated Authorization Claim. Currently: 1. DHCP reconfiguration can be initiated by a DHCP server that has previously communicated with a DHCP client and negotiated for the DHCP client to listen for Reconfigure messages, to prompt the DHCP client to dynamically request the updated authorization claim. --> 19) <!-- [rfced] Section 11: We had trouble following the meaning of "until the DHCP lease time or PvD Additional Information expiry". If the suggested text is not correct, please clarify. Original: 3. The old verification record needs to be maintained until the DHCP lease time or PvD Additional Information expiry. Suggested: 3. The old verification record needs to be maintained until the DHCP lease time or PvD Additional Information period expires. --> 20) <!-- [rfced] Section 13.2: This title is difficult to interpret. Does it mean "Provisioning Domains Using Split DNS Additional Information", "Provisioning Domains: Split DNS Additional Information", or something else? Please clarify. Original: 13.2. Provisioning Domains Split DNS Additional Information --> 21) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide at <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> 22) <!-- [rfced] Please let us know if any changes are needed for the following: a) The following terms were used inconsistently in this document. We chose to use the latter forms. Please let us know any objections. Authorization Claim (13 instances in text) / authorization claim (3 instances in text) (per post-6000 published RFCs) Global DNS / global DNS (per RFC 9499 and other post-6000 published RFCs, except for RFC 9526) PvD additional information (1 instance / PvD Additional Information (2 instances) (per post-6000 published RFCs) RRSet / RRset (per much more common usage in post-6000 published RFCs) b) The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. "ds=..." (2 instances) / "ds" (4 instances) * * It is not clear whether these variations refer to the same parameter or two distinct parameters. Please advise. Verification Record (15 instances in text) / verification record (6 instances in text in Section 11) ** ** We could not find a precedent in published RFCs to date. If this is not considered a proper term, we suggest the lowercase form. --> Thank you. RFC Editor/lb/ar On Dec 13, 2024, rfc-edi...@rfc-editor.org wrote: *****IMPORTANT***** Updated 2024/12/13 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * rfc-edi...@rfc-editor.org (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * auth48archive@rfc-editor.org, which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, auth48archive@rfc-editor.org will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9704.xml https://www.rfc-editor.org/authors/rfc9704.html https://www.rfc-editor.org/authors/rfc9704.pdf https://www.rfc-editor.org/authors/rfc9704.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9704-diff.html https://www.rfc-editor.org/authors/rfc9704-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9704-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9704 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9704 (draft-ietf-add-split-horizon-authority-14) Title : Establishing Local DNS Authority in Validated Split-Horizon Environments Author(s) : T. Reddy.K, D. Wing, K. Smith, B. Schwartz WG Chair(s) : David C Lawrence, Glenn Deen Area Director(s) : Erik Kline, Éric Vyncke -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
