I went with a full review of the -08. Here are my comments:
to avoid noise about which domains we are referring to:
OLD :
17 When split-horizon DNS is deployed by a network, certain domains can
NEW:
17 When split-horizon DNS is deployed by a network, certain domain names can
more than one resolver may be conficured
OLD:
18 be resolved authoritatively by the network-provided DNS resolver.
NEW:
18 be resolved authoritatively by a network-provided DNS resolver.
Please reword this as there might be an apparent conflict between the two “use” in the sentence.
OLD:
19 DNS clients that are not configured to use this resolver can use it,
20 but only to resolve these domains.
Be explicit this is about DNS clients
OLD:
21 mechanism for domain owners to inform clients about local resolvers
NEW:
21 mechanism for domain owners to inform DNS clients about local resolvers
better clarity
OLD:
103 To resolve a DNS query, there are three essential behaviors that an
NEW:
103 To resolve a DNS query, there are three main behaviors that an
frequently may be seen as subjective if no data is provided. So, let’s soften the noise here:
OLD:
114 resolvers frequently support a local "hosts file" that preempts query
NEW:
114 resolvers support a local "hosts file" that preempts query
minor edit
OLD:
120 In many network environments, the network offers clients a DNS server
121 (e.g. DHCP OFFER, IPv6 Router Advertisement).
NEW:
120 Networks usually offers clients a DNS resolver using means such as
121 DHCP [RFC2132][RFC3646] or IPv6 Router Advertisement [RFC8106].
nit
OLD:
122 is formally specified as a recursive resolver (e.g. Section 5.1 of
NEW:
122 is formally specified as a recursive resolver (e.g., Section 5.1 of
what is a “network client”? I guess you meant DNS client
OLD:
129 Network clients that use pure stub resolution, sending all queries to
NEW:
129 DNS clients that use pure stub resolution, sending all queries to
Please use “DNS client” instead of “client” through the document as appropriate.
clarity
OLD:
150 This specification describes a protocol between domains, networks,
NEW:
150 This specification describes a procedure between domain names, networks,
I don’t think the document defines a protocol. Please use “procedure”, “mechanism”, or similar terms.
clarity: “s/domain/domain owner”?
OLD:
153 confirm that a local domain hint was authorized by the domain
154 (Section 6)
nit
OLD:
170 This document makes use of the terms defined in [RFC9499], e.g.
171 "Global DNS". The following additional terms are used throughout the
172 document:
NEW:
170 This document makes use of the terms defined in [RFC9499], e.g.,
171 "Global DNS". The following additional terms are used throughout the
172 document:
expand + cite authoritative references
OLD:
174 Encrypted DNS A DNS protocol that provides an encrypted channel
175 between a DNS client and server (e.g., DNS over TLS (DoT), HTTPS
176 (DoH), QUIC (DoQ)).
NEW:
174 Encrypted DNS A DNS protocol that provides an encrypted channel
175 between a DNS client and server (e.g., DNS over TLS (DoT) [RFC 7858], DNS over HTTPS
176 (DoH) [RFC8484], and DNS over QUIC (DoQ) [RFC 9250]).
what is a typical structure?
OLD:
226 typical Split DNS zone structure.
Missing reference
OLD:
228 * DNSSEC Compatibility: The specification supports DNSSEC-based
owner vs operator: pick one term if both are referring to the same entity; otherwise clarify the distinction in the text. The same applies for other occurrences in the text:
265 Authorization Claim to the parent zone operator.
This text smells like a normative dependency:
283 The zone operator then publishes a "Verification Record" with the
284 following structure, following the advice in Sections 5.1 and 5.2 of
285 [I-D.ietf-dnsop-domain-verification-techniques]:
I’m asking to make a change here, but I would be comfortable to keep the draft as informative, but make this tweak:
NEW:
283 The zone operator then publishes a "Verification Record" with the
284 following structure, following advices such as in Sections 5.1 and 5.2 of
285 [I-D.ietf-dnsop-domain-verification-techniques]:
Should we be explicit and indicate this is one in this order? Using || would be better, IMO.
289 * Owner Name = Concatenation of the ADN, "_splitdns-challenge", and
290 the parent zone name.
Missing reference
OLD:
308 * Hash Algorithm = SHA-384
NEW:
308 * Hash Algorithm = SHA-384 [RFC6234]
There is no “DHCPv4” per se. Add a reference as “DHCP” is what is intended here.
OLD:
332 value $TBD1, "Split DNS Authentication". In DHCPv4, the long-options
NEW:
332 value $TBD1, "Split DNS Authentication". In DHCPv4 [RFC2131], the long-options
Some missing details:
352 When using Provisioning Domains [RFC8801], the Authorization Claims
353 are represented by the PvD Additional Information key
354 "splitDnsClaims", whose value is a JSON Array. Each entry in the
355 array MUST be a JSON object with the following structure:
357 * "resolver": The ADN as a dot-separated name.
359 * "parent": The parent zone name as a dot-separated name.
361 "subdomains": An array containing the claimed subdomains, as dot-
362 separated names with the parent suffix already removed, in
363 canonical order. To claim the entire parent zone, the claimed
364 subdomain will be represented as an asterisk symbol "".
366 * "algorithm": The hash algorithm is represented by its "Mnemonic"
367 string from the ZONEMD Hash Algorithms registry ([RFC8976],
368 Section 5.2).
370 * "salt": The salt, encoded in base64url.
Add a forward reference to the IANA section where future keys can be defined
Indicate that other keys are allowed but that is up to the specs that registers those.
add a statement about unknown keys when present
clarity: what do you mean by “participating clients”? Say just “DNS clients” :-)
374 To validate an Authorization Claim provided by the network,
375 participating clients MUST resolve the Verification Record for that
nit
OLD:
381 Each validation of authority applies only to a specific
382 Authentication Domain Name.
NEW:
381 Each validation of authority applies only to a specific
382 ADN.
nit
OLD:
387 validation using a "tamperproof" DNS resolution method, i.e. a method
NEW:
387 validation using a "tamperproof" DNS resolution method, i.e., a method
expand acronym
OLD:
401 For example, if the client would check the AD bit or validate RRSIGs
NEW:
401 For example, if the client would check the Authenticated Data (AD)bit or validate RRSIGs
nit
OLD:
410 method of its choice (e.g. querying one of the network-provided
NEW:
410 method of its choice (e.g., querying one of the network-provided
What is a “DNR hostnames”? Please use terms defined in DNR
OLD:
589 Figure 2: Learning Local Claims of DNS Authority
NEW:
589 Figure 2: An Example of Learning Local Claims of DNS Authority
editing style
OLD:
591 8.1.1. Verification using an external resolver
NEW:
591 8.1.1. Verification Using an External Resolver
explicit the figure
OLD:
593 The figure below shows the steps performed to verify the local claims
NEW:
593 Figure 3 shows the steps performed to verify the local claims
Idem
OLD:
639 The figure below shows the steps performed to verify the local claims
NEW:
639 Figure 4 shows the steps performed to verify the local claims
this is an example
OLD:
680 Figure 4: Verifying claims using DNSSEC
NEW:
680 Figure 4: An Example of Verifying Claims using DNSSEC
Expand acronym
OLD:
692 signed by a CA trusted by the client.
NEW:
692 signed by a Certification Authority (CA) trusted by the client.
make idnits happy
OLD:
699 is “internal.example.com” and the network-provided DNS resolver is
700 “ns1.internal.example.com”, the network operator can structure the
NEW:
699 is "internal.example.com" and the network-provided DNS resolver is
700 "ns1.internal.example.com", the network operator can structure the
Hmm, I guess you don’t meant prefix delegation!
735 2. The sequence number in the RA (Router Advertisement) PvD (Prefix
736 Delegation)
No need to expand here as these terms were already used in the doc
NEW:
735 2. The sequence number in the RA PvD
minor edit:
OLD:
775 IANA is requested to add the following entry to the "Additional
776 Information PvD Keys" registry on the "Provisioning Domains (PvDs)"
777 page:
New:
775 IANA is requested to add the following entry to the "Additional
776 Information PvD Keys" registry under the "Provisioning Domains (PvDs)"
777 registry group:
minor edit
OLD:
799 IANA is requested to create a new registry "PvD Split DNS Claims
800 Registry", within the "Provisioning Domains (PvDs)" registry page.
NEW:
799 IANA is requested to create a new registry "PvD Split DNS Claims”
800 registry within the "Provisioning Domains (PvDs)" registry group.
minor edit
OLD:
816 IANA is requested to add the following entry to the "Underscored and
817 Globally Scoped DNS Node Names" registry on the "Domain Name System
818 (DNS) Parameters" page:
NEW:
816 IANA is requested to add the following entry to the "Underscored and
817 Globally Scoped DNS Node Names" registry under the "Domain Name System
818 (DNS) Parameters" registry group:
Hi Tiru,
I think that key technical comments were covered in this version.
Thanks also for addressing the comments I raised on github. I closed all of them, except this one: https://github.com/ietf-wg-add/draft-ietf-add-split-horizon-authority/issues/48. Please add the suggested DE guidance. This will save a comment from Murray, at least ;-)
I went with a full review of the -08. Here are my comments:
to avoid noise about which domains we are referring to:
OLD : 17 When split-horizon DNS is deployed by a network, certain domains can
NEW: 17 When split-horizon DNS is deployed by a network, certain domain names can
more than one resolver may be conficured
OLD: 18 be resolved authoritatively by the network-provided DNS resolver.
NEW: 18 be resolved authoritatively by a network-provided DNS resolver.
Please reword this as there might be an apparent conflict between the two “use” in the sentence.
OLD: 19 DNS clients that are not configured to use this resolver can use it, 20 but only to resolve these domains.
Be explicit this is about DNS clients
OLD: 21 mechanism for domain owners to inform clients about local resolvers
NEW: 21 mechanism for domain owners to inform DNS clients about local resolvers
better clarity
OLD: 103 To resolve a DNS query, there are three essential behaviors that an
NEW: 103 To resolve a DNS query, there are three main behaviors that an
frequently may be seen as subjective if no data is provided. So, let’s soften the noise here:
OLD: 114 resolvers frequently support a local "hosts file" that preempts query
NEW: 114 resolvers support a local "hosts file" that preempts query
minor edit
OLD: 120 In many network environments, the network offers clients a DNS server 121 (e.g. DHCP OFFER, IPv6 Router Advertisement).
NEW: 120 Networks usually offers clients a DNS resolver using means such as 121 DHCP [RFC2132][RFC3646] or IPv6 Router Advertisement [RFC8106].
nit
OLD: 122 is formally specified as a recursive resolver (e.g. Section 5.1 of
NEW: 122 is formally specified as a recursive resolver (e.g., Section 5.1 of
what is a “network client”? I guess you meant DNS client
OLD: 129 Network clients that use pure stub resolution, sending all queries to
NEW: 129 DNS clients that use pure stub resolution, sending all queries to
Please use “DNS client” instead of “client” through the document as appropriate.
clarity
OLD: 150 This specification describes a protocol between domains, networks,
NEW: 150 This specification describes a procedure between domain names, networks,
I don’t think the document defines a protocol. Please use “procedure”, “mechanism”, or similar terms.
clarity: “s/domain/domain owner”?
OLD: 153 confirm that a local domain hint was authorized by the domain 154 (Section 6)
nit
OLD:
170 This document makes use of the terms defined in [RFC9499], e.g. 171 "Global DNS". The following additional terms are used throughout the 172 document:
NEW:
170 This document makes use of the terms defined in [RFC9499], e.g., 171 "Global DNS". The following additional terms are used throughout the 172 document:
expand + cite authoritative references
OLD:
174 Encrypted DNS A DNS protocol that provides an encrypted channel 175 between a DNS client and server (e.g., DNS over TLS (DoT), HTTPS 176 (DoH), QUIC (DoQ)).
NEW:
174 Encrypted DNS A DNS protocol that provides an encrypted channel 175 between a DNS client and server (e.g., DNS over TLS (DoT) [RFC 7858], DNS over HTTPS 176 (DoH) [RFC8484], and DNS over QUIC (DoQ) [RFC 9250]).
what is a typical structure?
OLD: 226 typical Split DNS zone structure.
Missing reference
OLD: 228 * DNSSEC Compatibility: The specification supports DNSSEC-based
owner vs operator: pick one term if both are referring to the same entity; otherwise clarify the distinction in the text. The same applies for other occurrences in the text:
265 Authorization Claim to the parent zone operator.
This text smells like a normative dependency:
283 The zone operator then publishes a "Verification Record" with the 284 following structure, following the advice in Sections 5.1 and 5.2 of 285 [I-D.ietf-dnsop-domain-verification-techniques]:
I’m asking to make a change here, but I would be comfortable to keep the draft as informative, but make this tweak:
NEW: 283 The zone operator then publishes a "Verification Record" with the 284 following structure, following advices such as in Sections 5.1 and 5.2 of 285 [I-D.ietf-dnsop-domain-verification-techniques]:
Should we be explicit and indicate this is one in this order? Using || would be better, IMO.
289 * Owner Name = Concatenation of the ADN, "_splitdns-challenge", and 290 the parent zone name.
Missing reference
OLD: 308 * Hash Algorithm = SHA-384
NEW: 308 * Hash Algorithm = SHA-384 [RFC6234]
There is no “DHCPv4” per se. Add a reference as “DHCP” is what is intended here.
OLD: 332 value $TBD1, "Split DNS Authentication". In DHCPv4, the long-options
NEW: 332 value $TBD1, "Split DNS Authentication". In DHCPv4 [RFC2131], the long-options
Some missing details:
352 When using Provisioning Domains [RFC8801], the Authorization Claims 353 are represented by the PvD Additional Information key 354 "splitDnsClaims", whose value is a JSON Array. Each entry in the 355 array MUST be a JSON object with the following structure:
357 * "resolver": The ADN as a dot-separated name.
359 * "parent": The parent zone name as a dot-separated name.
361 "subdomains": An array containing the claimed subdomains, as dot- 362 separated names with the parent suffix already removed, in 363 canonical order. To claim the entire parent zone, the claimed 364 subdomain will be represented as an asterisk symbol "".
366 * "algorithm": The hash algorithm is represented by its "Mnemonic" 367 string from the ZONEMD Hash Algorithms registry ([RFC8976], 368 Section 5.2).
370 * "salt": The salt, encoded in base64url.
Add a forward reference to the IANA section where future keys can be defined
Indicate that other keys are allowed but that is up to the specs that registers those.
add a statement about unknown keys when present
clarity: what do you mean by “participating clients”? Say just “DNS clients” :-)
374 To validate an Authorization Claim provided by the network, 375 participating clients MUST resolve the Verification Record for that
nit
OLD: 381 Each validation of authority applies only to a specific 382 Authentication Domain Name.
NEW: 381 Each validation of authority applies only to a specific 382 ADN.
nit
OLD: 387 validation using a "tamperproof" DNS resolution method, i.e. a method
NEW: 387 validation using a "tamperproof" DNS resolution method, i.e., a method
expand acronym
OLD: 401 For example, if the client would check the AD bit or validate RRSIGs
NEW: 401 For example, if the client would check the Authenticated Data (AD)bit or validate RRSIGs
nit
OLD: 410 method of its choice (e.g. querying one of the network-provided
NEW: 410 method of its choice (e.g., querying one of the network-provided
What is a “DNR hostnames”? Please use terms defined in DNR
560 | Response with DNR hostnames & | | | 561 | PvD FQDN (2) | | | 562 |<-----------------------------------------------------------| 563 | ----------------------------\ | | | 564 |-| now knows DNR hostnames & | | | | 565 | | PvD FQDN | | | | 566 | |---------------------------/ | | |
Insist this is an example:
OLD: 589 Figure 2: Learning Local Claims of DNS Authority
NEW:
589 Figure 2: An Example of Learning Local Claims of DNS Authority
editing style
OLD: 591 8.1.1. Verification using an external resolver
NEW: 591 8.1.1. Verification Using an External Resolver
explicit the figure
OLD: 593 The figure below shows the steps performed to verify the local claims
NEW: 593 Figure 3 shows the steps performed to verify the local claims
Idem
OLD: 639 The figure below shows the steps performed to verify the local claims
NEW: 639 Figure 4 shows the steps performed to verify the local claims
this is an example
OLD: 680 Figure 4: Verifying claims using DNSSEC
NEW: 680 Figure 4: An Example of Verifying Claims using DNSSEC
Expand acronym
OLD: 692 signed by a CA trusted by the client.
NEW: 692 signed by a Certification Authority (CA) trusted by the client.
make idnits happy
OLD: 699 is “internal.example.com” and the network-provided DNS resolver is 700 “ns1.internal.example.com”, the network operator can structure the
NEW: 699 is "internal.example.com" and the network-provided DNS resolver is 700 "ns1.internal.example.com", the network operator can structure the
Hmm, I guess you don’t meant prefix delegation!
735 2. The sequence number in the RA (Router Advertisement) PvD (Prefix 736 Delegation)
No need to expand here as these terms were already used in the doc
NEW:
735 2. The sequence number in the RA PvD
minor edit:
OLD: 775 IANA is requested to add the following entry to the "Additional 776 Information PvD Keys" registry on the "Provisioning Domains (PvDs)" 777 page:
New: 775 IANA is requested to add the following entry to the "Additional 776 Information PvD Keys" registry under the "Provisioning Domains (PvDs)" 777 registry group:
minor edit
OLD: 799 IANA is requested to create a new registry "PvD Split DNS Claims 800 Registry", within the "Provisioning Domains (PvDs)" registry page.
NEW: 799 IANA is requested to create a new registry "PvD Split DNS Claims” 800 registry within the "Provisioning Domains (PvDs)" registry group.
minor edit
OLD: 816 IANA is requested to add the following entry to the "Underscored and 817 Globally Scoped DNS Node Names" registry on the "Domain Name System 818 (DNS) Parameters" page:
NEW:
816 IANA is requested to add the following entry to the "Underscored and 817 Globally Scoped DNS Node Names" registry under the "Domain Name System 818 (DNS) Parameters" registry group: