Discovery of Designated Resolvers
draft-ietf-add-ddr-10

[Ballot comment]

# SEC AD comments for {draft-ietf-add-ddr-10}
CC @paulwouters

## Abstain

I find the set of documents in the ADD WG incomplete from a security point
of view. This is due to client policy being purposefully left out of the WG
charter, which is unfixable at this point in the process. I will therefore
abstain so that these documents can be published. Hopefully, a BoF/WG in the
future will attempt to address this security problem.

## unresolved DISCUSS items

Below follows my specific old DISCUSS items that were not addressed.

###

  Clients MUST NOT automatically use a Designated
  Resolver without some sort of validation

Why not? What is the alternative? Using unencrypted DNS to the party that
told you how and where to contact these (unvalidated) Designated Resolvers.

###

      2.  The client MUST verify that the certificate contains the IP
      address of the designating Unencrypted Resolver in a
      subjectAltName extension.

How feasible is it to get a certificate with SAN=ip from one of the generally
accepted root store CA's? Can you give me one example where I can get a certificate
for nssec.nohats.ca with SAN=193.110.157.123 ?  I do not think this is currently
possible or easy. If I am right, that means all of Section 4.2 is wishful thinking
and not realistic to get rolled out. (I know we can see the cert for 1.1.1.1, so it
is possible, but I know of no ACME supported CA that issues these)

###

  If these checks fail, the client MUST NOT automatically use the
  discovered Designated Resolver.

This creates a strange policy when compared to DNR where if you get a DHCP or RA
for the Designated Resolver, which is also not validatable, that you do end up using it?
And section 6.5 states DNR trumps DDR.
Note: this was updated in -10 to match the DNR, but it matches the weak method of DHCP/RA,
so that if the TLS checks fail, it might still end up being used as "Verified Discovery".

###

  If the Designated Resolver and the Unencrypted Resolver share an IP
  address, clients MAY choose to opportunistically use the Designated
  Resolver even without this certificate check (Section 4.3).

Why only when the IP is the same? Why not for when the IP is different?
What's to lose, since the only fallback option is stick to using the
unencrypted resolver?
###

Opportunistic Discovery has the same "same IP" issue. As the alternative
is to use unencrypted DNS, why not just use it anyway?
Note: the text was changed but the issue remains

###

  A DNS forwarder SHOULD NOT forward queries for "resolver.arpa" upstream.

Unfortunately, all currently deployed software does not know this, so it will
be very common that this happens.
Note: Also, why is this not a MUST NOT?

###

  To limit the impact of discovery
  queries being dropped either maliciously or unintentionally, clients
  can re-send their SVCB queries periodically.

I don't see how this would improve security for the client. It also mixes
up behaviour of proper DNS clients that have their own retransmit logic
for if they get no answer.

###

  Section 8.2 of [I-D.ietf-add-svcb-dns] describes a second downgrade
  attack where an attacker can block connections to the encrypted DNS
  server, and recommends that clients prevent it by switching to SVCB-
  reliant behavior once SVCB resolution does succeed.  For DDR, this
  means that once a client discovers a compatible Designated Resolver,
  it SHOULD NOT use unencrypted DNS until the SVCB record expires

I wonder which attacker can block encrypted DNS connections but not spoof
(or block!) an unsigned SVCB record to the local client? And even if that is the case,
this would be a denial of service attack if the DNS client cannot fallback
to unencrypted DNS. Spoofing an SVCB to a bogus IP with an SVCB TTL of a few
hours would be a very cheap 1 packet attack to keep the DNS client down for
hours. This seems dangerous to implement.

###

  DoH resolvers that allow discovery using DNS SVCB answers over
  unencrypted DNS MUST NOT provide differentiated behavior based on the
  HTTP path alone, since an attacker could modify the "dohpath"
  parameter.  For example, if a DoH resolver provides provides a
  filtering service for one URI path, and a non-filtered service for
  another URI path, [...]

It seems likely that this advise will get ignored a lot, eg by people
who have limited public IPs to use to spin up a DoH server, or who have
to pay-per-IP. This advise seems more appropriate for local private IP
DoH servers. So I would change this MUST NOT to SHOULD NOT for that reason.

##

  If the IP address of a Designated Resolver differs from that of an
  Unencrypted Resolver, clients applying Verified Discovery
  (Section 4.2) MUST validate that the IP address of the Unencrypted
  Resolver is covered by the SubjectAlternativeName of the Designated
  Resolver's TLS certificate.

How would one obtain such a certificate via ACME? Since on the IP of the
unencrypted resolver, there would be no HTTP server running? Additionally,
if the client notices a failed verification of the Designated Resolver's
TLS certificate, wouldn't it fallback to the Unencrypted Resolver? But now
it may not? So this becomes a denial of service then ?

###

I kind of miss the mode of where there is no indication of DDR or DNR, and
you use "unilateral probing" (draft-ietf-dprive-unilateral-probing) to just
connect to the DoT or DoQ ports of the Unencrypted Resolver and see if you
get anything back. It might be unauthenticated TLS but better than port 53?

## Unresolved Comments

###

section 3

  To avoid name lookup deadlock, Designated Resolvers SHOULD follow the
  guidance in Section 10 of [RFC8484] regarding the avoidance of DNS-
  based references that block the completion of the TLS handshake.

I find that reference to list more the issues than solutions that can be followed.
The solution to use another DoH server is not really appropriate in most cases
The client's other interface likely resides on other networks where its private
DoH server cannot resolve the name of another network's private DoH server. It is
also not easy to get an IP based certificate (eg SAN=ip) that is accepted by general
webpki root stores. And things like OCSP stapling doesn't help if the target is
malicious - they just would omit the stapling that proves against its malicious use.
The only real advise usable from RFC8484 is "use the local unencrypted resolver to resolve
the encrypted resolver". Might as well say that and remove the 8484 reference.

[Ballot comment]
# GEN AD review of draft-ietf-add-ddr-08

CC @larseggert

Thanks to Robert Sparks for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/mHeRXL46i0vY3KUKqmxW7l4ZP_k).

## Comments

### Section 2, paragraph 5
```
    Encrypted Resolver:  A DNS resolver using any encrypted DNS
        transport.  This includes current mechanisms such as DoH, DoT, and
        DoQ, as well as future mechanisms.

    Unencrypted Resolver:  A DNS resolver using TCP or UDP port 53
        without encryption.
```
Wouldn't "unencrypting resolver" be a more accurate term? (Same for "encrypting
resolver".)

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `blind`; alternatives might be `visually impaired`, `unmindful of`,
  `unconcerned about`, `negligent of`, `unaware`, `uncomprehending`,
  `unaware`, `uncritical`, `unthinking`, `hasty`, `blocked`, `opaque`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Grammar/style

#### Section 4, paragraph 5
```
an IPv6 address, it ought to provide a AAAA record for an IPv6 address of th
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 6.5, paragraph 1
```
r example, if a DoH resolver provides provides a filtering service for one U
                            ^^^^^^^^^^^^^^^^^
```
Possible typo: you repeated a word.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
Thank you for the work on this document.

Many thanks to Thomas Fossati for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/PT-6Rhoa4WieVi3lmSFMhlvbSo4/, and to the authors for addressing Thomas' comments.

Francesca

[Ballot comment]
I support Lars's DISCUSS blocking for IANA actions.  Specifically, the problem seems to be that RFC 6761 wasn't followed.  Please review that document, and in particular its Section 5.

Thanks to Thomas Fossati for his ARTART review.

I think there are way too many bald SHOULDs in this document.  Since SHOULD presents an implementer with a choice, it's usually a good idea to describe that choice rather than presenting something that looks like "you really should do this, but it's probably fine if you don't" and moves on.  To wit:

* An example of one that could use improvement is the first one in Section 4, as I've no idea why you would not always do what it says.

* An example of one that does provide such guidance is the second one in Section 4, where I understand the consequences of not doing what it says.

[Ballot comment]
[ Thank you for addressing my DISCUSS (see https://mailarchive.ietf.org/arch/msg/add/KhCzRdbyoq8fo-LlEr5FOW61PGA/ ) - I'm clearing and trusting that y'all will fold in the PR and answer the questions. ]


Has the potential new load that this introduces on the .arpa servers been considered and discussed with the IANA? Yes, the document says that the name should also be added to the "Locally-Served DNS Zones" registry, but obviously that doesn't get deployed immediately (13 years after j.root-servers.net changed addresses, it was (and still is!) getting queries on the old address: https://indico.dns-oarc.net/event/24/contributions/378/attachments/353/613/2015-old-j-root.pdf )
Probably the ARPA servers don't care, but it seems impolite to not at least ask...

[Ballot discuss]
[ Apologies, I'm currently participating in the IEEE 802 Plenary meeting, and so was not able to perform as detailed (or timely!) review as normal ]

Sec 8.1 - Special Use Domain Name "resolver.arpa"
"This document calls for the addition of "resolver.arpa" to the Special-Use Domain Names (SUDN) registry established by [RFC6761]."

Unfortunately RFC6761 Section 4 (Procedure) says:
"The specification MUST state how implementations determine that the special handling is required for any given name." and "The specification also MUST state, in each of the seven "Domain Name Reservation Considerations" categories below, what special treatment, if any, is to be applied."

And RFC6761 Section 5 (Domain Name Reservation Considerations) says: "An IETF "Standards Action" or "IESG Approval" document specifying some new naming behaviour, which requires a Special-Use Domain Name be reserved to implement this desired new behaviour, needs to contain a subsection of the "IANA Considerations" section titled "Domain Name Reservation Considerations" giving answers in the seven categories listed below." (and lists the categories).

I do not see a "Domain Name Reservation Considerations" section, nor answers to the 7 questions.

[ Apologies again for not being able to do a more in-depth review ]

[Ballot discuss]
[ Apologies, I'm currently participating in the IEEE 802 Plenary meeting, and so was not able to perform as detailed (or timely!) review as normal ]

Sec 8.1 - Special Use Domain Name "resolver.arpa"
"This document calls for the addition of "resolver.arpa" to the Special-Use Domain Names (SUDN) registry established by [RFC6761]."

Unfortunately RFC6761 Section 4 (Procedure) says:
"The specification MUST state how implementations determine that the special handling is required for any given name." and "The specification also MUST state, in each of the seven "Domain Name Reservation Considerations" categories below, what special treatment, if any, is to be applied."

And RFC6761 Section 5 (Domain Name Reservation Considerations) says: "An IETF "Standards Action" or "IESG Approval" document specifying some new naming behaviour, which requires a Special-Use Domain Name be reserved to implement this desired new behaviour, needs to contain a subsection of the "IANA Considerations" section titled "Domain Name Reservation Considerations" giving answers in the seven categories listed below." (and lists the categories).

I do not see a "Domain Name Reservation Considerations" section, nor answers to the 7 questions.

[Ballot comment]
Has the potential new load that this introduces on the .arpa servers been considered and discussed with the IANA? Yes, the document says that the name should also be added to the "Locally-Served DNS Zones" registry, but obviously that doesn't get deployed immediately (13 years after j.root-servers.net changed addresses, it was (and still is!) getting queries on the old address: https://indico.dns-oarc.net/event/24/contributions/378/attachments/353/613/2015-old-j-root.pdf )
Probably the ARPA servers don't care, but it seems impolite to not at least ask...

[Ballot discuss]
# SEC AD comments for {draft-ietf-add-ddr-08}
CC @paulwouters

## Discuss

See my discuss on draft-ietf-add-ddr-11 for my generic ADD DNR/DDR concerns

###

  Clients MUST NOT automatically use a Designated
  Resolver without some sort of validation

Why not? What is the alternative? Using unencrypted DNS to the party that
told you how and where to contact these (unvalidated) Designated Resolvers.

###

  However, if a given Unencrypted Resolver designates a Designated
  Resolver that does not use a private or local IP address and can be
  verified using the mechanism described in Section 4.2, it MAY be used
  on different network connections so long as the subsequent
  connections over other networks can also be successfully verified
  using the mechanism described in Section 4.2.

This seems to go against a lot of advise in the documents that networks must
be treated independently. Also, the network _wants_ you to use their designated
resolver, so to say it is okay to use a totally different Designated Resolvers
seems to violate the whole DNR/DDR architecture.

This will also cause failure if there is split-DNS or internal-only data.

Also, using "public IP" is not a good trustworthy method to prove that these
IPs are truly the same Designated Resolver used by both networks. I can easily
use an internal only zone with dns.nohats.ca. IN A 8.8.8.8 and get a valid ACME'd
certificate with SAN=dns.nohats.ca. The user connecting to another network might
now be switching from my private DNS on my stolen 8.8.8.8 IP to the real google DNS.

###

      2.  The client MUST verify that the certificate contains the IP
      address of the designating Unencrypted Resolver in a
      subjectAltName extension.

How feasible is it to get a certificate with SAN=ip from one of the generally
accepted root store CA's? Can you give me one example where I can get a certificate
for nssec.nohats.ca with SAN=193.110.157.123 ?  I do not think this is currently
possible or easy. If I am right, that means all of Section 4.2 is wishful thinking
and not realistic to get rolled out. (I know we can see the cert for 1.1.1.1, so it
is possible, but I know of no ACME supported CA that issues these)

###

  If these checks fail, the client MUST NOT automatically use the
  discovered Designated Resolver.

This creates a strange policy when compared to DNR where if you get a DHCP or RA
for the Designated Resolver, which is also not validatable, that you do end up using it?
And section 6.5 states DNR trumps DDR.

###

  If the Designated Resolver and the Unencrypted Resolver share an IP
  address, clients MAY choose to opportunistically use the Designated
  Resolver even without this certificate check (Section 4.3).

Why only when the IP is the same? Why not for when the IP is different?
What's to lose, since the only fallback option is stick to using the
unencrypted resolver?

###

  If resolving the name of a Designated Resolver from an SVCB record
  yields an IP address that was not presented in the Additional Answers
  section or ipv4hint or ipv6hint fields of the original SVCB query,
  the connection made to that IP address MUST pass the same TLS
  certificate checks before being allowed to replace a previously known
  and validated IP address for the same Designated Resolver name.

How does the appearance of an (unsigned) Additional Answer entry convey
any kind of real world trust/authentication? In other words, why should
it not ALWAYS pass the same TLS certificate checks ?

###

Opportunistic Discovery has the same "same IP" issue. As the alternative
is to use unencrypted DNS, why not just use it anyway?

###

  A DNS client that already knows the name of an Encrypted Resolver can
  use DDR to discover details about all supported encrypted DNS
  protocols.

It's a little odd to mention this as the DNR draft really tries hard to
say to only use the network's offered encrypted DNS servers, so this
option is in conflict with the DNR draft.

###

  A DNS forwarder SHOULD NOT forward queries for "resolver.arpa" upstream.

Unfortunately, all currently deployed software does not know this, so it will
be very common that this happens.

##

  DNS resolvers that support DDR by responding to queries for
  _dns.resolver.arpa SHOULD treat resolver.arpa as a locally served
  zone per [RFC6303]

Why is this not a MUST ?

###

  To limit the impact of discovery
  queries being dropped either maliciously or unintentionally, clients
  can re-send their SVCB queries periodically.

I don't see how this would improve security for the client. It also mixes
up behaviour of proper DNS clients that have their own retransmit logic
for if they get no answer.

###

  Section 8.2 of [I-D.ietf-add-svcb-dns] describes a second downgrade
  attack where an attacker can block connections to the encrypted DNS
  server, and recommends that clients prevent it by switching to SVCB-
  reliant behavior once SVCB resolution does succeed.  For DDR, this
  means that once a client discovers a compatible Designated Resolver,
  it SHOULD NOT use unencrypted DNS until the SVCB record expires

I wonder which attacker can block encrypted DNS connections but not spoof
(or block!) an unsigned SVCB record to the local client? And even if that is the case,
this would be a denial of service attack if the DNS client cannot fallback
to unencrypted DNS. Spoofing an SVCB to a bogus IP with an SVCB TTL of a few
hours would be a very cheap 1 packet attack to keep the DNS client down for
hours. This seems dangerous to implement.

###

  DoH resolvers that allow discovery using DNS SVCB answers over
  unencrypted DNS MUST NOT provide differentiated behavior based on the
  HTTP path alone, since an attacker could modify the "dohpath"
  parameter.  For example, if a DoH resolver provides provides a
  filtering service for one URI path, and a non-filtered service for
  another URI path, [...]

It seems likely that this advise will get ignored a lot, eg by people
who have limited public IPs to use to spin up a DoH server, or who have
to pay-per-IP. This advise seems more appropriate for local private IP
DoH servers. So I would change this MUST NOT to SHOULD NOT for that reason.

###

  If the IP address of a Designated Resolver differs from that of an
  Unencrypted Resolver, clients applying Verified Discovery
  (Section 4.2) MUST validate that the IP address of the Unencrypted
  Resolver is covered by the SubjectAlternativeName of the Designated
  Resolver's TLS certificate.

How would one obtain such a certificate via ACME? Since on the IP of the
unencrypted resolver, there would be no HTTP server running? Additionally,
if the client notices a failed verification of the Designated Resolver's
TLS certificate, wouldn't it fallback to the Unencrypted Resolver? But now
it may not? So this becomes a denial of service then ?

###

  Clients using Opportunistic Discovery (Section 4.3) MUST be limited
  to cases where the Unencrypted Resolver and Designated Resolver have
  the same IP address.

Based on earlier text, this should read "the same non-public IP address".

###

I kind of miss the mode of where there is no indication of DDR or DNR, and
you use "unilateral probing" (draft-ietf-dprive-unilateral-probing) to just
connect to the DoT or DoQ ports of the Unencrypted Resolver and see if you
get anything back. It might be unauthenticated TLS but better than port 53?

###

  This document calls for the addition of "resolver.arpa" to the
  Special-Use Domain Names (SUDN) registry established by [RFC6761].

Why not pick resolver.local? As .local is already handled to not be forwarded
by DNS forwarders. It would also not require an addition to SUDN. Even if
someone was already using resolver.local, it would not interfere with that usage
because that usage would not be using SVCB records.

## Comments

###

section 3

  To avoid name lookup deadlock, Designated Resolvers SHOULD follow the
  guidance in Section 10 of [RFC8484] regarding the avoidance of DNS-
  based references that block the completion of the TLS handshake.

I find that reference to list more the issues than solutions that can be followed.
The solution to use another DoH server is not really appropriate in most cases
The client's other interface likely resides on other networks where its private
DoH server cannot resolve the name of another network's private DoH server. It is
also not easy to get an IP based certificate (eg SAN=ip) that is accepted by general
webpki root stores. And things like OCSP stapling doesn't help if the target is
malicious - they just would omit the stapling that proves against its malicious use.
The only real advise usable from RFC8484 is "use the local unencrypted resolver to resolve
the encrypted resolver". Might as well say that and remove the 8484 reference.

###

I would argue that I-D.ietf-add-dnr is not an informative but normative reference,
as the protocol is mentioned throughout the document as interacting with this protocol.

###

      Clients that support SVCB will generally send out three queries
      when accessing web content on a dual-stack network: A, AAAA, and
      HTTPS queries.  Discovering a Designated Resolver as part of one
      of these queries, without having to add yet another query,
      minimizes the total number of queries clients send.

I don't understand this paragraph. Once clients can send SVCB queries for
web content, they already have had to do all the DDR/DNR related queries,
so I don't understand the argument of "saving queries" ? Also, it is
adding queries for a specific target, eg resolver.arpa, and this cannot
be "saved" either? What am I misunderstanding here?

###

NITS

provides provides -> provides

[Ballot comment]
Hi,

Thanks for this.

Re: section1, Introduction:

                          Such mechanisms include network provisioning
  protocols like DHCP [RFC2132] [RFC8415] and IPv6 Router Advertisement
  (RA) options [RFC8106], as well as manual configuration.

Do you know if there is any work being done in the IETF to add more options to DHCP, RA, or manual configuration to allow more complex DHCP server information to be provisioned/setup? Since longer term that would seem to be an easier/safer solution than needing to use SVCB records to move from unencrypted to encrypted comms.

2) I also had a question regarding section 5:

                          In the following example, the SVCB answers
  indicate that resolver.example.com supports both DoH and DoT, and
  that the DoH server indicates a higher priority than the DoT server.

  _dns.resolver.example.com.  7200  IN SVCB 1 resolver.example.com. (
        alpn=h2 dohpath=/dns-query{?dns} )
  _dns.resolver.example.com.  7200  IN SVCB 1 resolver.example.com. (
        alpn=dot )

Is there a bug in the example (e.g., second entry should be 2 rather than 1)?  Or otherwise it wasn't obvious to me why DoH had higher priority.

Regards,
Rob

[Ballot comment]
# Internet AD comments for {draft-ietf-add-ddr-08}
CC @ekline

## Comments

### S2

* I might suggest a slightly less binding wording where port 53 is
  concerned for the Unencrypted Resolver definition.  Perhaps:

  "A DNS resolver using a transport without encryption, historically
  TCP or UDP port 53."

### S4

* I'd be in favor of using more RFC 8174 "SHOULD/SHOULD NOT" text in place
  of "ought [not] to".  Specifically, for the text about address family
  support, consider perhaps something like:

  OLD:
    ... The Designated Resolver can support more
    address families than the Unencrypted Resolver, but it ought not to
    support fewer.

  NEW:
    ... The Designated Resolver MAY support more
    address families than the Unencrypted Resolver, but it SHOULD NOT
    support fewer.

### S5, S6.3, ...

* I wonder if it's good to require that clients MUST NOT/SHOULD NOT accept
  certificates claiming to be for resolver.arpa?  This might be
  over-specifying things and/or it might be a check against some types of
  misconfigurations.

[Ballot discuss]
# GEN AD review of draft-ietf-add-ddr-08

CC @larseggert

Thanks to Robert Sparks for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/mHeRXL46i0vY3KUKqmxW7l4ZP_k).

## Discuss

### IANA

This document seems to have unresolved IANA issues. Holding a DISCUSS for IANA,
so we can determine next steps during the telechat.

[Ballot comment]
## Comments

### Section 2, paragraph 5
```
    Encrypted Resolver:  A DNS resolver using any encrypted DNS
        transport.  This includes current mechanisms such as DoH, DoT, and
        DoQ, as well as future mechanisms.

    Unencrypted Resolver:  A DNS resolver using TCP or UDP port 53
        without encryption.
```
Wouldn't "unencrypting resolver" be a more accurate term? (Same for "encrypting
resolver".)

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `blind`; alternatives might be `visually impaired`, `unmindful of`,
  `unconcerned about`, `negligent of`, `unaware`, `uncomprehending`,
  `unaware`, `uncritical`, `unthinking`, `hasty`, `blocked`, `opaque`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Grammar/style

#### Section 4, paragraph 5
```
an IPv6 address, it ought to provide a AAAA record for an IPv6 address of th
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 6.5, paragraph 1
```
r example, if a DoH resolver provides provides a filtering service for one U
                            ^^^^^^^^^^^^^^^^^
```
Possible typo: you repeated a word.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
Thanks for the painless read! Just a few trivial comments.

Minor:

1. The editorial commentary in the IANA Considerations section seems out of place -- generally IANA Considerations is, well, requests to IANA, not interesting and fun trivia about the resources being requested. But, IANA are smart enough to disregard the superflous material.

Nits:

2. §3,

                    The client can still use others records in the
  same response
 
s/others/other/

3. §7,

  provides provides

s/provides//

[Ballot comment]
** Thank you to Ben Schwartz for the IETF LC SECDIR review.  This review highlights several places where design choices or implementation guidance would benefit from additional explanatory text.  Instead of repeating the issues here, please see https://mailarchive.ietf.org/arch/msg/secdir/WWrVmObWkKeBNDI-fPhV7Jipn3c/.

** Section 4.2
  2.  The client MUST verify that the certificate contains the IP
      address of the designating Unencrypted Resolver in a
      subjectAltName extension.

Consider being more precise by saying:

NEW
2.  The client MUST verify that the certificate contains the IP address of the designating Unencrypted Resolver in an iPAddress entry of the subjectAltName extension (see 4.2.1.6 of [RFC5280]).

** Section 5.
For these cases, the client simply sends a DNS SVCB query using the
  known name of the resolver.  This query can be issued to the named
  Encrypted Resolver itself or to any other resolver.  Unlike the case
  of bootstrapping from an Unencrypted Resolver (Section 4), these
  records SHOULD be available in the public DNS.

If there was a limited domain mechanism using DDR, why would these records be in public DNS?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-add-ddr-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, IANA understands that this document calls for the addition of "resolver.arpa" to the Special-Use Domain Names (SUDN) registry established by RFC6761. RFC6761 specifically requires that any request for a Special-Use Domain Name needs to contain a subsection of the "IANA Considerations" section titled Domain Name Reservation Considerations. The current draft does not have such a section.

IANA Question --> Could the authors either conform to the requirements of RFC6761 or provide explicit guidance as to why that section is not appropriate?

Second, in the Transport-Independent Locally-Served DNS Zone Registry on the Locally-Served DNS Zones registry page located at:

https://www.iana.org/assignments/locally-served-dns-zones/

a new registration will be made as follows:

Zone: resolver.arpa.
Description: DNS Resolver Special-Use Domain
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Michelle Thangtamsatid
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-07-08):

From: The IESG
To: IETF-Announce
CC: Andrew.Campling@419.Consulting, add-chairs@ietf.org, add@ietf.org, draft-ietf-add-ddr@ietf.org, evyncke@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Discovery of Designated Resolvers) to Proposed Standard


The IESG has received a request from the Adaptive DNS Discovery WG (add) to
consider the following document: - 'Discovery of Designated Resolvers'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-07-08. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines Discovery of Designated Resolvers (DDR), a
  mechanism for DNS clients to use DNS records to discover a resolver's
  encrypted DNS configuration.  This mechanism can be used to move from
  unencrypted DNS to encrypted DNS when only the IP address of a
  resolver is known.  This mechanism is designed to be limited to cases
  where unencrypted resolvers and their designated resolvers are
  operated by the same entity or cooperating entities.  It can also be
  used to discover support for encrypted DNS protocols when the name of
  an encrypted resolver is known.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-add-ddr/

This document also relies on https://datatracker.ietf.org/doc/draft-ietf-add-svcb-dns/ and the ADD WG has another document https://datatracker.ietf.org/doc/draft-ietf-add-dnr/, which should probably be reviewed at the same time.

No IPR declarations have been submitted directly on this I-D.

Title: Discovery of Designated Resolvers

Current Version: draft-ietf-add-ddr-06


(1.a)  Who is the Document Shepherd for this document? 

Document Shepherd: Andrew Campling


Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

I have reviewed the document and believe that it is ready for consideration by the IESG


(1.b)  Has the document had adequate review both from key WG members and from key non-WG members? 

It has been extensively reviewed by working group members, hence the number of iterations of the draft to date.  Just under 150 mailing list posts directly reference the various DDR drafts, complemented by 34 closed issues and 27 closed pull requests on GitHub.  The authors have also given updates on progress during working group sessions at IETF meetings to highlight the draft to a broader audience.

Looking outside of the ADD working group, there has been consultation with 6man on the way that RFC 8106 has been interpreted.  In addition, support for DDR has already been implemented by Cisco in its Umbrella software, by Quad9 in its resolver, Microsoft in its Windows operating system and by Apple in both iOS 16 and macOS Ventura. 


Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.  A number of reviews of the document were posted to the working group mailing list, along with the issues and pull requests logged on GitHub. 


(1.c)  Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML?

No – the authors have done a good job in highlighting specific sections where they have sought additional review or input.


(1.d)  Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of?  For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it.  In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 

No.


Has an IPR disclosure related to this document been filed?  If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

No IPR disclosures have been filed relating to this document.

There was a very vague IPR disclosure by Verisign shortly after the ADD working group was formed that may pertain in some way to ADD.  It involved unpublished filings and did not include any detail other than that Verisign had filed a patent with the USPTO. 

For reference, the following link is to the relevant posts on the ADD mailing list.

https://mailarchive.ietf.org/arch/msg/add/lB8c9COt5jyqgHhWjW9TFH_V4Nk/


(1.e)  How solid is the WG consensus behind this document?  Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There has been extensive discussion amongst a variety of individuals.  I believe that the document represents the consensus view of the working group as a whole.


(1.f)  Has anyone threatened an appeal or otherwise indicated extreme discontent?  If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.  (It should be in a separate email because this questionnaire is entered into the ID Tracker.)

There are no open issues that I am aware of, nor any other outstanding areas of concern. 


(1.g)  Has the Document Shepherd personally verified that the document satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this check needs to be thorough. 

Yes.  One outstanding nit remains as follows:

- There are 7 instances of lines with non-RFC2606-compliant FQDNs in the document – this is a false positive caused by references to “resolver.arpa” in the text

In addition, although not essential, the draft would benefit from the addition of a temporary implementation status section to aid reviewers and marked for removal by the RFC editor before publication.  This has been flagged to the authors for their consideration.


Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? 

Not applicable.


If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.

Intended RFC status: standard


(1.h)  Has the document split its references into normative and informative? 

Yes.  The normative references, together with an indication of the type and whether they have been updated by later versions, are as follows:

draft-ietf-add-svcb-dns – Standards Track, the link in the text references -02 which expires 5 August 2022, the document is currently at version 3

draft-ietf-dnsop-svcb-https – Standards Track, the link in the text references -08 which expired 15 April 2022, the document is currently at version 10

RFC 1918 – BCP 5 (updated by RFC 6761)
RFC 6303 – BCP 163
RFC 6761 – Standards Track
RFC 7858– Standards Track (updated by RFC 8310)
RFC 8484– Standards Track


Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? 

Five of the seven normative references are to RFCs, with the remaining two referencing Internet-Drafts.  The text in the draft providing links to the two Internet-Drafts currently references older versions which have been superseded by new drafts.


If such normative references exist, what is the strategy for their completion? 

The links to the relevant Internet-Drafts will update during the next iteration of the document. 


Are there normative references that are downward references, as described in [RFC3967]?  If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].

Not applicable.


(1.i)  Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? 

Section 8 of the document contains the IANA considerations, addressing the need for a special use domain name “resolver.arpa” as referenced elsewhere in the document.  Specifically, IANA is requested to add an entry in "Transport-Independent Locally-Served DNS Zones" registry for 'resolver.arpa.' with the description "DNS Resolver Special-Use Domain", listing this document (ie DDR) as the reference.


If the document specifies protocol extensions, are reservations requested in appropriate IANA registries?  Are the IANA registries clearly identified? 

Yes.  The document calls for the addition of "resolver.arpa" to the Special-Use Domain Names (SUDN) registry established by RFC 6761.  IANA is requested to add an entry in "Transport-Independent Locally Served DNS Zones" registry for 'resolver.arpa.' with the description "DNS Resolver Special-Use Domain"


If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? 

Not applicable.


Does it suggest a reasonable name for the new registry?  See [RFC2434]. 

Not applicable.


If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?

Not applicable.


(1.j)  Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

Not applicable.

Title: Discovery of Designated Resolvers

Current Version: draft-ietf-add-ddr-06


(1.a)  Who is the Document Shepherd for this document? 

Document Shepherd: Andrew Campling


Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

I have reviewed the document and believe that it is ready for consideration by the IESG


(1.b)  Has the document had adequate review both from key WG members and from key non-WG members? 

It has been extensively reviewed by working group members, hence the number of iterations of the draft to date.  Just under 150 mailing list posts directly reference the various DDR drafts, complemented by 34 closed issues and 27 closed pull requests on GitHub.  The authors have also given updates on progress during working group sessions at IETF meetings to highlight the draft to a broader audience.

Looking outside of the ADD working group, there has been consultation with 6man on the way that RFC 8106 has been interpreted.  In addition, support for DDR has already been implemented by Cisco in its Umbrella software, by Quad9 in its resolver, Microsoft in its Windows operating system and by Apple in both iOS 16 and macOS Ventura. 


Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.  A number of reviews of the document were posted to the working group mailing list, along with the issues and pull requests logged on GitHub. 


(1.c)  Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML?

No – the authors have done a good job in highlighting specific sections where they have sought additional review or input.


(1.d)  Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of?  For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it.  In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 

No.


Has an IPR disclosure related to this document been filed?  If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

No IPR disclosures have been filed relating to this document.

There was a very vague IPR disclosure by Verisign shortly after the ADD working group was formed that may pertain in some way to ADD.  It involved unpublished filings and did not include any detail other than that Verisign had filed a patent with the USPTO. 

For reference, the following link is to the relevant posts on the ADD mailing list.

https://mailarchive.ietf.org/arch/msg/add/lB8c9COt5jyqgHhWjW9TFH_V4Nk/


(1.e)  How solid is the WG consensus behind this document?  Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There has been extensive discussion amongst a variety of individuals.  I believe that the document represents the consensus view of the working group as a whole.


(1.f)  Has anyone threatened an appeal or otherwise indicated extreme discontent?  If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.  (It should be in a separate email because this questionnaire is entered into the ID Tracker.)

There are no open issues that I am aware of, nor any other outstanding areas of concern. 


(1.g)  Has the Document Shepherd personally verified that the document satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this check needs to be thorough. 

Yes.  One outstanding nit remains as follows:

- There are 7 instances of lines with non-RFC2606-compliant FQDNs in the document – this is a false positive caused by references to “resolver.arpa” in the text

In addition, although not essential, the draft would benefit from the addition of a temporary implementation status section to aid reviewers and marked for removal by the RFC editor before publication.  This has been flagged to the authors for their consideration.


Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? 

Not applicable.


If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.

Intended RFC status: standard


(1.h)  Has the document split its references into normative and informative? 

Yes.  The normative references, together with an indication of the type and whether they have been updated by later versions, are as follows:

draft-ietf-add-svcb-dns – Standards Track, the link in the text references -02 which expires 5 August 2022, the document is currently at version 3

draft-ietf-dnsop-svcb-https – Standards Track, the link in the text references -08 which expired 15 April 2022, the document is currently at version 10

RFC 1918 – BCP 5 (updated by RFC 6761)
RFC 6303 – BCP 163
RFC 6761 – Standards Track
RFC 7858– Standards Track (updated by RFC 8310)
RFC 8484– Standards Track


Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? 

Five of the seven normative references are to RFCs, with the remaining two referencing Internet-Drafts.  The text in the draft providing links to the two Internet-Drafts currently references older versions which have been superseded by new drafts.


If such normative references exist, what is the strategy for their completion? 

The links to the relevant Internet-Drafts will update during the next iteration of the document. 


Are there normative references that are downward references, as described in [RFC3967]?  If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].

Not applicable.


(1.i)  Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? 

Section 8 of the document contains the IANA considerations, addressing the need for a special use domain name “resolver.arpa” as referenced elsewhere in the document.  Specifically, IANA is requested to add an entry in "Transport-Independent Locally-Served DNS Zones" registry for 'resolver.arpa.' with the description "DNS Resolver Special-Use Domain", listing this document (ie DDR) as the reference.


If the document specifies protocol extensions, are reservations requested in appropriate IANA registries?  Are the IANA registries clearly identified? 

Yes.  The document calls for the addition of "resolver.arpa" to the Special-Use Domain Names (SUDN) registry established by RFC 6761.  IANA is requested to add an entry in "Transport-Independent Locally Served DNS Zones" registry for 'resolver.arpa.' with the description "DNS Resolver Special-Use Domain"


If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? 

Not applicable.


Does it suggest a reasonable name for the new registry?  See [RFC2434]. 

Not applicable.


If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?

Not applicable.


(1.j)  Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

Not applicable.

Title: Discovery of Designated Resolvers

Current Version: draft-ietf-add-ddr-06


(1.a)  Who is the Document Shepherd for this document? 

Document Shepherd: Andrew Campling


Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

I have reviewed the document and believe that it is ready for consideration by the IESG


(1.b)  Has the document had adequate review both from key WG members and from key non-WG members? 

It has been extensively reviewed by working group members, hence the number of iterations of the draft to date.  Just under 150 mailing list posts directly reference the various DDR drafts, complemented by 34 closed issues and 27 closed pull requests on GitHub.  The authors have also given updates on progress during working group sessions at IETF meetings to highlight the draft to a broader audience.

Looking outside of the ADD working group, there has been consultation with 6man on the way that RFC 8106 has been interpreted.  In addition, support for DDR has already been implemented by Cisco in its Umbrella software, by Quad9 in its resolver, Microsoft in its Windows operating system and by Apple in both iOS 16 and macOS Ventura. 


Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.  A number of reviews of the document were posted to the working group mailing list, along with the issues and pull requests logged on GitHub. 


(1.c)  Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML?

No – the authors have done a good job in highlighting specific sections where they have sought additional review or input.


(1.d)  Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of?  For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it.  In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 

No.


Has an IPR disclosure related to this document been filed?  If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

No IPR disclosures have been filed relating to this document.

There was a very vague IPR disclosure by Verisign shortly after the ADD working group was formed that may pertain in some way to ADD.  It involved unpublished filings and did not include any detail other than that Verisign had filed a patent with the USPTO. 

For reference, the following link is to the relevant posts on the ADD mailing list.

https://mailarchive.ietf.org/arch/msg/add/lB8c9COt5jyqgHhWjW9TFH_V4Nk/


(1.e)  How solid is the WG consensus behind this document?  Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There has been extensive discussion amongst a variety of individuals.  I believe that the document represents the consensus view of the working group as a whole.


(1.f)  Has anyone threatened an appeal or otherwise indicated extreme discontent?  If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.  (It should be in a separate email because this questionnaire is entered into the ID Tracker.)

There are no open issues that I am aware of, nor any other outstanding areas of concern. 


(1.g)  Has the Document Shepherd personally verified that the document satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this check needs to be thorough. 

Yes.  One outstanding nit remains as follows:

- There are 7 instances of lines with non-RFC2606-compliant FQDNs in the document – this is a false positive caused by references to “resolver.arpa” in the text

In addition, although not essential, the draft would benefit from the addition of a temporary implementation status section to aid reviewers and marked for removal by the RFC editor before publication.  This has been flagged to the authors for their consideration.


Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? 

Not applicable.


If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.

Intended RFC status: standard


(1.h)  Has the document split its references into normative and informative? 

Yes.  The normative references are as follows:

draft-ietf-add-svcb-dns – Standards Track, the link in the text references -02 which expires 5 August 2022, the document is currently at version 3

draft-ietf-dnsop-svcb-https – Standards Track, the link in the text references -08 which expired 15 April 2022, the document is currently at version 10

RFC 1918 – BCP 5 (updated by RFC 6761)
RFC 6303 – BCP 163
RFC 6761 – Standards Track
RFC 7858– Standards Track (updated by RFC 8310)
RFC 8484– Standards Track


Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? 

Five of the seven normative references are to RFCs, with the remaining two referencing Internet-Drafts.  The text in the draft providing links to the two Internet-Drafts currently references older versions which have been superseded by new drafts.


If such normative references exist, what is the strategy for their completion? 

The links to the relevant Internet-Drafts will update during the next iteration of the document. 


Are there normative references that are downward references, as described in [RFC3967]?  If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].

Not applicable.


(1.i)  Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? 

Section 8 of the document contains the IANA considerations, addressing the need for a special use domain name “resolver.arpa” as referenced elsewhere in the document.  Specifically, IANA is requested to add an entry in "Transport-Independent Locally-Served DNS Zones" registry for 'resolver.arpa.' with the description "DNS Resolver Special-Use Domain", listing this document (ie DDR) as the reference.


If the document specifies protocol extensions, are reservations requested in appropriate IANA registries?  Are the IANA registries clearly identified? 

Yes.  The document calls for the addition of "resolver.arpa" to the Special-Use Domain Names (SUDN) registry established by RFC 6761.  IANA is requested to add an entry in "Transport-Independent Locally Served DNS Zones" registry for 'resolver.arpa.' with the description "DNS Resolver Special-Use Domain"


If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? 

Not applicable.


Does it suggest a reasonable name for the new registry?  See [RFC2434]. 

Not applicable.


If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?

Not applicable.


(1.j)  Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

Not applicable.

Title: Discovery of Designated Resolvers

Current Version: draft-ietf-add-ddr-06


(1.a)  Who is the Document Shepherd for this document? 

Document Shepherd: Andrew Campling


Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

I have reviewed the document and believe that it is ready for consideration by the IESG


(1.b)  Has the document had adequate review both from key WG members and from key non-WG members? 

It has been extensively reviewed by working group members, hence the number of iterations of the draft to date.  Just under 150 mailing list posts directly reference the various DDR drafts, complemented by 34 closed issues and 27 closed pull requests on GitHub.  The authors have also given updates on progress during working group sessions at IETF meetings to highlight the draft to a broader audience.

Looking outside of the ADD working group, there has been consultation with 6man on the way that RFC 8106 has been interpreted.  In addition, support for DDR has already been implemented by Cisco in its Umbrella software, by Quad9 in its resolver, Microsoft in its Windows operating system and by Apple in both iOS 16 and macOS Ventura. 


Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.  A number of reviews of the document were posted to the working group mailing list, along with the issues and pull requests logged on GitHub. 


(1.c)  Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML?

No – the authors have done a good job in highlighting specific sections where they have sought additional review or input.


(1.d)  Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of?  For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it.  In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 

No.


Has an IPR disclosure related to this document been filed?  If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

No IPR disclosures have been filed relating to this document.


(1.e)  How solid is the WG consensus behind this document?  Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There has been extensive discussion amongst a variety of individuals.  I believe that the document represents the consensus view of the working group as a whole.


(1.f)  Has anyone threatened an appeal or otherwise indicated extreme discontent?  If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.  (It should be in a separate email because this questionnaire is entered into the ID Tracker.)

There are no open issues that I am aware of, nor any other outstanding areas of concern. 


(1.g)  Has the Document Shepherd personally verified that the document satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this check needs to be thorough. 

Yes.  One outstanding nit remains as follows:

- There are 7 instances of lines with non-RFC2606-compliant FQDNs in the document – this is a false positive caused by references to “resolver.arpa” in the text

In addition, although not essential, the draft would benefit from the addition of a temporary implementation status section to aid reviewers and marked for removal by the RFC editor before publication.  This has been
flagged to the authors for their consideration.


Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? 

Not applicable.


If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.

Intended RFC status: standard


(1.h)  Has the document split its references into normative and informative? 

Yes.  The normative references are as follows:

draft-ietf-add-svcb-dns – Standards Track, the link in the text references -02 which expires 5 August 2022, the document is currently at version 3

draft-ietf-dnsop-svcb-https – Standards Track, the link in the text references -08 which expired 15 April 2022, the document is currently at version 10

RFC 1918 – BCP 5 (updated by RFC 6761)
RFC 6303 – BCP 163
RFC 6761 – Standards Track
RFC 7858– Standards Track (updated by RFC 8310)
RFC 8484– Standards Track


Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? 

Five of the seven normative references are to RFCs, with the remaining two referencing Internet-Drafts.  The text in the draft providing links to the two Internet-Drafts currently references older versions which have been superseded by new drafts.


If such normative references exist, what is the strategy for their completion? 

The links to the relevant Internet-Drafts will update during the next iteration of the document. 


Are there normative references that are downward references, as described in [RFC3967]?  If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].

Not applicable.


(1.i)  Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? 

Section 8 of the document contains the IANA considerations, addressing the need for a special use domain name “resolver.arpa” as referenced elsewhere in the document.  Specifically, IANA is requested to add an entry in "Transport-Independent Locally-Served DNS Zones" registry for 'resolver.arpa.' with the description "DNS Resolver Special-Use Domain", listing this document (ie DDR) as the reference.


If the document specifies protocol extensions, are reservations requested in appropriate IANA registries?  Are the IANA registries clearly identified? 

Yes.  The document calls for the addition of "resolver.arpa" to the Special-Use Domain Names (SUDN) registry established by RFC 6761.  IANA is requested to add an entry in "Transport-Independent Locally Served DNS Zones" registry for 'resolver.arpa.' with the description "DNS Resolver Special-Use Domain"


If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? 

Not applicable.


Does it suggest a reasonable name for the new registry?  See [RFC2434]. 

Not applicable.


If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?

Not applicable.


(1.j)  Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

Not applicable.