A. Submission Date: October 31, 2023 B.1 Submission Type: [ X ] New RRTYPE [ ] Modification to RRTYPE B.2 Kind of RR: [ X ] Data RR [ ] Meta-RR C. Contact Information for submitter (will be publicly posted): Name: Mohamed BOUCADAIR Email Address: Mohamed.boucadair&orange.com D. Motivation for the new RRTYPE application. The ADD WG is chartered to define mechanisms for discovering behavior properties of encrypted DNS resolvers. This RR allows recursive resolvers to describe their capabilities in a well-structured manner. DNS clients can then use the resolver information to identify the capabilities of DNS resolvers. For example, retrieved information can be used to feed the server selection procedure. E. Description of the proposed RR type. Resolver information as key-value pairs of the pre-existing text format defined in Section 6.3 of RFC 6763. F. What existing RRTYPE or RRTYPEs come closest to filling that need and why are they unsatisfactory? SVCB and HTTPS records carry key-value stores that could in a literal sense be used for this purpose. However, reuse of the SVCB or HTTPS RR types was ruled out by the WG as bad practice for describing DNS server properties that are not strictly necessary to establish connectivity. G. What mnemonic is requested for the new RRTYPE (optional)? RESINFO H. Does the requested RRTYPE make use of any existing IANA registry or require the creation of a new IANA subregistry in DNS Parameters? If so, please indicate which registry is to be used or created. If a new subregistry is needed, specify the allocation policy for it and its initial contents. Also include what the modification procedures will be. The requested RRTYPE requires the creation of a new subregistry to be called “DNS Resolver Information Keys” under the “Domain Name System (DNS) Parameters” registry. The format of this registry is provided below with requested initial entries. Note that draft-ietf-add-resolver-info-06 is to be replaced with the RFC number to be assigned to draft-ietf-add-resolver-info. +==========+==========+============================+===============+ | Name | Value | Description | Specification | | | Type | | | +==========+==========+============================+===============+ | qnamemin | None | The presence of the key | draft-ietf-add-resolver-info-06 | | | | name indicates that | | | | | 'QNAME minimization' is | | | | | enabled | | +----------+----------+----------------------------+---------------+ | exterr | 16-bit | Lists the set of supported | draft-ietf-add-resolver-info-06 | | | unsigned | extended DNS errors. It | | | | integer | must be an INFO-CODE decimal value in the | | | | | "Extended DNS Error Codes" | | | | | registry. | | +----------+----------+----------------------------+---------------+ | infourl | string | Provides an URL that | draft-ietf-add-resolver-info-06 | | | | points to an unstructured | | | | | resolver information that | | | | | is used for | | | | | troubleshooting | | +----------+----------+----------------------------+---------------+ | sig | binary | Includes a signature of | draft-ietf-add-resolver-info-06 | | | | RESINFO RR for data origin | | | | | authentication | | +----------+----------+----------------------------+---------------+ I. Does the proposal require/expect any changes in DNS servers/resolvers that prevent the new type from being processed as an unknown RRTYPE (see [RFC3597])? No. J. Comments: Please refer to the associated specification that defines this new RR TYPE: https://datatracker.ietf.org/doc/draft-ietf-add-resolver-info/ The document has passed the WGLC and is about to be sent to the IESG for publication.