Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS
draft-ietf-dprive-unilateral-probing-13

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-dprive-unilateral-probing and RFC 9539, changed IESG state to RFC Published)

The revised -13 addresses the remaining comments received during IESG evaluation that were not addressed over email. No objection to this -13 was received from the IETF community.

[Ballot comment]
Based on the authors response to my DISCUSS (https://mailarchive.ietf.org/arch/msg/dns-privacy/mVGvnh3g0Z9O70XeguVNUx59SYk/), I have updated by ballot to ABSTAIN.

I do not see any use of this draft. In its regular use, the user is still sending their queries in the clear initially. The draft assumes that after the initial leak, queries for the same target will be encrypted opportunistically. I tried pointing out that on most mobile devices, this is not the case due to frequent network changes and DNS cache purges. Any Operational or Security Considerations related to this were deemed out of scope. I can only conclude that no privacy is gained, and that the additional complexity in code is not worth the effort of implementing.

Additionally, since the draft requires the DNS servers to generate a certificate, the difference between generating a self-signed certificate, and using an ACME based certificate that CAN be validated and wouldn't need unilateral opportunistic security, I see even less reasons to attempt to deploy this.

As no indications are given back to the user, the draft does the enduser no harm (other than possibly introducing bugs due to added complexity on the code) and I see no reason to further block it with a DISCUSS.

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

I only scanned for ART issues and didn't find any. Many thanks to Bron Gondwana for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/R6IORBQjJI4oZteiMhRa5OcBwMg/ and to the authors for addressing Bron's comments.

[Ballot comment]
Thank you to Rich Salz for the SECDIR review.

I support Paul’s DISCUSS positions.

** Section 4.6.3.4
  Because this probing policy is unilateral and opportunistic, the
  client connecting under this policy MUST accept any certificate
  presented by the server.  If the client cannot verify the server's
  identity, it MAY use that information for reporting, logging, or
  other analysis purposes.  But it MUST NOT reject the connection due
  to the authentication failure, as the result would be falling back to
  cleartext, which would leak the content of the session to a passive
  network monitor.

What verification is expected? When might it trigger “reporting, logging or other analysis”?  I ask because the text seems to unambiguously say all server certificates must be accepted and then again that no connections can be rejected.

[Ballot discuss]
# SEC AD comments for draft-ietf-dprive-unilateral-probing-12
CC @paulwouters

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## DISCUSS

### Leaking probes

        either or both of DoT and DoQ concurrently. The recursive resolver
        remembers what opportunistic encrypted transport protocols have
        worked recently based on a (clientIP, serverIP, protocol) tuple.

This makes little sense to me. If the passive attackers sees the outgoing
port 53 cleartext query, it doesn't even matter if DoT or DoQ is then
established in parallel. The privacy is already lost. I strongly believe
that DoT/DoQ should be tried first without unencrypted DNS, and only when
that doesn't work in a very short time (eg 3s? 5s?) send out the unencrypted
query.

### DNS cache handling

It does say anything about what it expects should happen with the
cached DNS data through a restart. Note that dropping the cache
and restarting, especially on mobile devices, will lead to easy
fingerprinting for passive attackets in recognising users when
their browser tabs reload (eg if queries to apollo.ns.cloudflare and
katelyn.ns.cloudflare.com. happen, even when encrypted, it could be
a sign of the mobile device trying to reach the ACLU. If that same IP
is trying to reach ken.ns.cloudflare.com. or jill.ns.cloudflare.com,
it could be that ietf.org is being looked up. The two of these combined
would most likely mean the device on or behind this IP address is dkg)

While I understand that DNS cache handling over restarts is kind of out
of scope for this document, if this document is being read as "how to run
a DNS resolver with maximum privacy on your mobile device" then without
this advise, the whole unilateral probing gives us nothing. (note: in
Fedora I had this exact issue, where some people insisted on purging
DNS cache on interface change, and I insisted on keeping DNS cache, so
the NetworkManager got an option to tweak this behaviour). DNS cache
handling for DNS resolvers on non-mobile devices, eg those on static
IPs shared by many independent clients, might not need to consider this.

### Section 4.6.2 Pseudocode

Either I don't understand the pseudo code, or it is wrong:

        Otherwise:
        * Remove Q from Do53-queries[X]

        If R is successful:
        * If Q is in Do53-queries[X]:
          [...]

Since Q was just removed from Do53-queries, isn't this condition now always false ?

Also, what is "R is successful" ? because that seems to happen before
"R is further processed".  Wouldn't processing be needed to determine
if R is successful?

        But if R is unsuccessful (e.g. timeout or connection closed):

But the whole state starts with: "When a response R for query Q arrives" ???

### Section 4 / Section 7 : Security advise

Should it not clearly state the resolver MUST enable query
minimalization? Otherwise, sending queries to the root would leak all
privacy even if the TLD supports DoT/DoQ. Or the same one level lower
if the TLD doesn't support this yet.

Possibly it should RECOMMEND (or even REQUIRE) using RFC 8806 to prevent
leaking root queries.

(I noticed later this was mentioned in the Security Considerations, but
I think it would be good to promote those into Section 4 as SHOULDs)

### Zone owner recommendations ?

Should zone owners get a recommendation for using out-domain nameservers
to reduce leaking at the root and TLD? Eg if nohats.ca uses ns1.example.com
and ns1.example.com supports DoT/DoQ, but the root and .com do not, then
queries for nohats.ca are not leaked to the root or .com. While when using
in-domain nameservers, the target domain is leaked.

[Ballot comment]
## Comments


### Section 3:

        An authoritative server implementing DoT or DoQ MUST
        authoritatively serve the same zones over all supported
        transports. If both DoT and DoQ are offered, a nameserver's
        reply to a particular query MUST be the same on both transports
        (with the possible exception of how the TC bit is set)

I think there might be more differences, eg EDNS0 options related
to packet sizes.  I think what is meant to be said is:

        An authoritative server implementing DoT or DoQ MUST
        populate the repsonse from the same authoritative zone
        data and the unencryped DNS transports. As encrypted
        transports have their own characteristic response size
        that might be different from the unencrypted DNS transports,
        response sizes and response size related options (eg EDNS0)
        and flags (eg TC bit) might vary based on the transport.

### Section 3.1

As Éric Vyncke also commented, a third option could be to ensure
that the load balancer knows/probes which ports/services are
available on the servers being load-balanced, and only sends queries
for those ports to the authoritative servers responding to that same port.

### Section 3.2

        The simplest deployment would simply provide a self-issued,
        regularly-updated X.509 certificate.

Why does it need to be regularly-updated? The even more simplest solution
would simply generate a certificate once only and use that forever.
Although perhaps it should be made abundantly clear that any DoT or DoQ
TLS ciphersuite MUST be one with Ephemeral DH. (so passive attackers cannot
be given a list of known certs private keys for instant decryption)


### Section 4.2

ICMP port closed message should be "ICMP port destination unreachable" ?

### Section 4.3

A damping value of 1 day seems very long. What discussion lead to this
value instead of say, 1 hour ? Is a factor 24 that important?

### Section 4.4: MTI

        To follow this guidance, a recursive resolver MUST implement at
        least one of either DoT or DoQ in its capacity as a client of
        authoritative nameservers. A recursive resolver SHOULD implement
        the client side of DoT. A recursive resolver SHOULD implement
        the client side of DoQ.

That's a pretty odd way of saying:

        To follow this guidance, a recursive resolver MUST implement
        at least one of DoT or DoQ but SHOULD implement both,
        in its capacity as a client of authoritative nameservers.

(I think the "in its capacity as [...]" can also safely be removed.

### Section 4.4: localhost

        SHOULD also accept queries from its clients over some encrypted transport.

Maybe add: unless it only accept queries from localhost


### Section 4.6.1

As stated in my DISCUSS, I still think a 3-5 second delay for unencrypted DNS
packets is required, or the gain of unilateral probing becomes next to
nothing (at least unless the entire world uses cloudflare as auth servers)

### Section 4.6.3:

        If the recursive resolver has a preferred encrypted transport,
        but only a different transport is in the established state,
        it MAY also initiate a new connection to X over its preferred
        transport while concurrently sending the query over the
        established transport E.

I am confused by "preferred encrypted transport" and "established transport".
Is this trying to talk about only encrypted transports and less and more
preferred ones? Or does this include unencrypted transports? If the latter
is included, 1) see my above comments on delays on do53, and 2) a UDP 53
transport is not "established", only TCP 53 is. In which case, "but what
about UDP then" ?

### Section 6.1:

Would it make sense to recommend an SNI using the IP address in presentation
format as the SNI host_name? eg I assume that would be the same as the
SNI for a request to https://192.0.2.1/  ?

I'm not sure if it is well supported these days to omit an SNI in TLS
libraries or not.

### Section 7

See my DISCUSS on leaking do53 and localroot / query minimalization

It does list the leaking happy eyeballs. I still believe as mentioned
earlier, that at least a brief attempt should be made to avoid leaking
over port 53 immediately for every new nameserver contacted.

Ahh, I see now that local root and query minimalization are mentioned.
I think these deserve to be more than just Security Considerations,
and be part of the rough specification of unilateral probing as this
document defines.

### ection 8

        and the system would need to be able to differentiate queries
        for recursive answers from queries for authoritative answers.

Isn't that just core DNS functionality (eg the Recursion Desired (RD)
flag and the query ID) ? I don't think this is an operational consideration
for unilateral probing.

### NITS:

awkward sentence: The simplest deployment would simply [...]

with two A records -> with two address records

        This document uses the notation E-foo to refer to the
        foo parameter for the encrypted transport E. For example
        DoT-persistence [...]

This took me a few reads before I understood this. I recommend:

        This document uses the notation -foo to refer to the
        foo parameter for the encrypted transport . For example
        DoT-persistence [...]

[Ballot comment]
# Internet AD comments for draft-ietf-dprive-unilateral-probing-12
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S3.1

* A 3rd option for a pool operator is to use a load-balancer that forwards
  queries/connections on encrypted transports to only those members of the
  pool known (e.g. via monitoring) to support the given encrypted transport.

### S4.2

* There is no "port closed" ICMP message.  There is a Port Unreachable code
  under the Destination Unreachable type category.

* The IP addresses given are not "two A records" but rather the values that
  might appear in an A Resource Resource and AAAA Resource Record.

### S4.4

* The use of lowercase "must" for the ALPN strings seems a bit odd.

  Should this section say that the ALPN is a "MUST"?  It could perhaps be
  reworded to say something like "... and if an APLN is included it MUST be
  ".

### S4.6.3 or S8

* I think a very important caveat here is when a node running its own
  recursive resolver has just joined a network and not yet completed any
  captive portal probes.  Initiating encrypted transport connections prior
  to satisfying the captive portal testing stage could have negative
  consequences (especially given the MUST in S4.6.3.4).

  Whether the state of the captive portal check(s) can be known by the
  recursive resolver function or not is an implementation-specific matter.

  Yes, this really only applies to recursive resolvers running on mobile
  devices, but some devices can actually do this.

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

The IANA Functions Operator has reviewed draft-ietf-dprive-unilateral-probing-11, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

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

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2023-08-28):

From: The IESG
To: IETF-Announce
CC: brian@innovationslab.net, dns-privacy@ietf.org, dprive-chairs@ietf.org, draft-ietf-dprive-unilateral-probing@ietf.org, evyncke@cisco.com, tjw.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS) to Experimental RFC


The IESG has received a request from the DNS PRIVate Exchange WG (dprive) to
consider the following document: - 'Unilateral Opportunistic Deployment of
Encrypted Recursive-to-Authoritative DNS'
  as Experimental RFC

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 2023-08-28. 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 sets out steps that DNS servers (recursive resolvers
  and authoritative servers) can take unilaterally (without any
  coordination with other peers) to defend DNS query privacy against a
  passive network monitor.  The steps in this document can be defeated
  by an active attacker, but should be simpler and less risky to deploy
  than more powerful defenses.

  The goal of this document is to simplify and speed deployment of
  opportunistic encrypted transport in the recursive-to-authoritative
  hop of the DNS ecosystem.  Wider easy deployment of the underlying
  transport on an opportunistic basis may facilitate the future
  specification of stronger cryptographic protections against more
  powerful attacks.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dprive-unilateral-probing/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/5904/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is broad agreement within the WG for this document as an Experimental document.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

As this document defines new features for DNS message exchanges, there was some controversy around the potential impact to certain types of DNS servers (e.g., distributed authoritative servers). Due to those concerns, the document describes a set of measurements to be collected once the document is published as an RFC. Those measurements will allow the WG to determine the overall operational impact of this type of probing on DNS services supporting this specification.

3. 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 publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Yes, this document contains a list of current implementations per RFC 7942.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document contains features designed strictly for DNS. Key participants in the WG represent implementers, operators, researchers, and users and all constituencies have provided reviews on this document. Given the impact of DNS on other layers of the protocol stack, the chairs requested, and received, directorate reviews from the DNS, Security, Int, and Gen directorates. The authors have been timely in addressing issues raised during those reviews.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, this document has received a number of reviews, the authors have been responsive to comments, and some WG participants are already implementing/experimenting based on the contents of the current draft.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The document shepherd has confirmed that this draft conforms with all of the guidance described for Internet Area topics/issues as well as those specifically called out for DNS in the Operations & Management Area topics.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

This document is to be published as Experimental. This type is appropriate due to the need to encourage experimentation of the approaches described in the document in order to measure any operational impact on a critical infrastructure protocol (DNS). This status is accurately reflected in the document header as well as the Intended Status field of the datatracker.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, the authors and the WG have been reminded of their responsibilities to declare any known IPR in a timely fashion. There has been one declaration of an IPR claim, but no one in the WG has indicated that the declaration was problematic.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

All authors listed have been active contributors to the work and want to be recognized as such.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

This document does not have remaining nits.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The references are correct.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

N/A

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

N/A

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document does not contain any IANA actions.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

-10 contains many changes from the AD review. But the shepherd's write up and appendix A of -10 do not agree. This must be resolved before going to IETF Last Call.
https://mailarchive.ietf.org/arch/msg/dns-privacy/LipmqMe_sxgoFH8CjONAlXzqq6A/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is broad agreement within the WG for this document as an Experimental document.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

As this document defines new features for DNS message exchanges, there was some controversy around the potential impact to certain types of DNS servers (e.g., distributed authoritative servers). Due to those concerns, the document describes a set of measurements to be collected once the document is published as an RFC. Those measurements will allow the WG to determine the overall operational impact of this type of probing on DNS services supporting this specification.

3. 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 publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document contains a list of current implementations. The WG would like to ensure that this list remains in the document once it is published as an RFC in order to facilitate the measurements described within it. Maintaining the list of implementations will allow readers to easily find implementations to use for testing and experimentation.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document contains features designed strictly for DNS. Key participants in the WG represent implementers, operators, researchers, and users and all constituencies have provided reviews on this document. Given the impact of DNS on other layers of the protocol stack, the chairs requested, and received, directorate reviews from the DNS, Security, Int, and Gen directorates. The authors have been timely in addressing issues raised during those reviews.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, this document has received a number of reviews, the authors have been responsive to comments, and some WG participants are already implementing/experimenting based on the contents of the current draft.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The document shepherd has confirmed that this draft conforms with all of the guidance described for Internet Area topics/issues as well as those specifically called out for DNS in the Operations & Management Area topics.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

This document is to be published as Experimental. This type is appropriate due to the need to encourage experimentation of the approaches described in the document in order to measure any operational impact on a critical infrastructure protocol (DNS). This status is accurately reflected in the document header as well as the Intended Status field of the datatracker.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, the authors and the WG have been reminded of their responsibilities to declare any known IPR in a timely fashion. There has been one declaration of an IPR claim, but no one in the WG has indicated that the declaration was problematic.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

All authors listed have been active contributors to the work and want to be recognized as such.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

This document does not have remaining nits.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The references are correct.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

N/A

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

N/A

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document does not contain any IANA actions.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There is broad agreement within the WG for this document as an Experimental document.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

As this document defines new features for DNS message exchanges, there was some controversy around the potential impact to certain types of DNS servers (e.g., distributed authoritative servers). Due to those concerns, the document describes a set of measurements to be collected once the document is published as an RFC. Those measurements will allow the WG to determine the overall operational impact of this type of probing on DNS services supporting this specification.

3. 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 publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document contains a list of current implementations. The WG would like to ensure that this list remains in the document once it is published as an RFC in order to facilitate the measurements described within it. Maintaining the list of implementations will allow readers to easily find implementations to use for testing and experimentation.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document contains features designed strictly for DNS. Key participants in the WG represent implementers, operators, researchers, and users and all constituencies have provided reviews on this document. Given the impact of DNS on other layers of the protocol stack, the chairs requested, and received, directorate reviews from the DNS, Security, Int, and Gen directorates. The authors have been timely in addressing issues raised during those reviews.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, this document has received a number of reviews, the authors have been responsive to comments, and some WG participants are already implementing/experimenting based on the contents of the current draft.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The document shepherd has confirmed that this draft conforms with all of the guidance described for Internet Area topics/issues as well as those specifically called out for DNS in the Operations & Management Area topics.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

This document is to be published as Experimental. This type is appropriate due to the need to encourage experimentation of the approaches described in the document in order to measure any operational impact on a critical infrastructure protocol (DNS). This status is accurately reflected in the document header as well as the Intended Status field of the datatracker.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, the authors and the WG have been reminded of their responsibilities to declare any known IPR in a timely fashion. There has been one declaration of an IPR claim, but no one in the WG has indicated that the declaration was problematic.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

All authors listed have been active contributors to the work and want to be recognized as such.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

This document does not have remaining nits.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The references are correct.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

N/A

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

N/A

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This document does not contain any IANA actions.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/