draft-ietf-dnsop-resolver-information-00.txt   draft-ietf-dnsop-resolver-information-01.txt 
Network Working Group P. Sood Network Working Group P. Sood
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track R. Arends Intended status: Standards Track R. Arends
Expires: February 20, 2020 P. Hoffman Expires: August 14, 2020 P. Hoffman
ICANN ICANN
August 19, 2019 February 11, 2020
DNS Resolver Information Self-publication DNS Resolver Information Self-publication
draft-ietf-dnsop-resolver-information-00 draft-ietf-dnsop-resolver-information-01
Abstract Abstract
This document describes methods for DNS resolvers to self-publish This document describes methods for DNS resolvers to self-publish
information about themselves, such as whether they perform DNSSEC information about themselves, such as whether they perform DNSSEC
validation or are available over transports other than what is validation or are available over transports other than what is
defined in RFC 1035. The information is returned as a JSON object. defined in RFC 1035. The information is returned as a JSON object.
The names in this object are defined in an IANA registry that allows The names in this object are defined in an IANA registry that allows
for light-weight registration. Applications and operating systems for light-weight registration. Applications and operating systems
can use the methods defined here to get the information from can use the methods defined here to get the information from
resolvers in order to make choices about how to send future queries resolvers in order to make choices about how to send future queries
to those resolvers. to those resolvers.
There is a GitHub repo for this draft where pull requests can be
issued: https://github.com/DNSOP/draft-ietf-dnsop-resolver-
information However, starting issues on the WG mailing list is
preferred.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 20, 2020. This Internet-Draft will expire on August 14, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 22 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Retrieving Resolver Information by DNS . . . . . . . . . . . 3 2. Retrieving Resolver Information by DNS . . . . . . . . . . . 3
3. Retrieving Resolver Information by Well-Known URI . . . . . . 4 3. Retrieving Resolver Information by Well-Known URI . . . . . . 4
4. Contents of the Returned I-JSON Object . . . . . . . . . . . 5 4. Contents of the Returned I-JSON Object . . . . . . . . . . . 5
4.1. The "inventory" name . . . . . . . . . . . . . . . . . . 6 4.1. The "inventory" name . . . . . . . . . . . . . . . . . . 6
4.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5.1. RESINFO RRtype . . . . . . . . . . . . . . . . . . . . . 6 5.1. RESINFO RRtype . . . . . . . . . . . . . . . . . . . . . 6
5.2. Registry for DNS Resolver Information . . . . . . . . . . 6 5.2. Registry for DNS Resolver Information . . . . . . . . . . 7
5.3. resolver-info Well-known URI . . . . . . . . . . . . . . 7 5.3. resolver-info Well-known URI . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
skipping to change at page 4, line 19 skipping to change at page 4, line 27
information in its query. For example, if the stub knows that it information in its query. For example, if the stub knows that it
wants information whose name is "temp-field2", it would send the wants information whose name is "temp-field2", it would send the
query temp-field2.<reverse-ip>.{in-addr,ip6}.arpa/IN/RESINFO. As query temp-field2.<reverse-ip>.{in-addr,ip6}.arpa/IN/RESINFO. As
described in Section 4, the JSON object in the response is likely to described in Section 4, the JSON object in the response is likely to
have name/value pairs in addition to the one requested. have name/value pairs in addition to the one requested.
Any query for the RESINFO RRtype that is not in <reverse-ip>.{in- Any query for the RESINFO RRtype that is not in <reverse-ip>.{in-
addr,ip6}.arpa/IN or a subdomain of <reverse-ip>.{in-addr,ip6}.arpa/ addr,ip6}.arpa/IN or a subdomain of <reverse-ip>.{in-addr,ip6}.arpa/
IN is meaningless and MUST result in a NODATA or NXDOMAIN response. IN is meaningless and MUST result in a NODATA or NXDOMAIN response.
Resolvers would not need any special code to meet this requirement; Resolvers would not need any special code to meet this requirement;
they only need code to handle the RESINFO RRtype that is not in they only need code to handle the RESINFO RRtype that is in <reverse-
<reverse-ip>.{in-addr,ip6}.arpa/IN or a subdomain of <reverse- ip>.{in-addr,ip6}.arpa/IN or a subdomain of <reverse-ip>.{in-
ip>.{in-addr,ip6}.arpa/IN . addr,ip6}.arpa/IN.
3. Retrieving Resolver Information by Well-Known URI 3. Retrieving Resolver Information by Well-Known URI
A stub that wants to use HTTPS to get information about a resolver A stub that wants to use HTTPS to get information about a resolver
can use the well-known URI defined here. Because this uses HTTPS, can use the well-known URI defined here. Because this uses HTTPS,
the stub has the possibility of authenticating the TLS connection. the stub has the possibility of authenticating the TLS connection.
If the connection cannot be authenticated (such as if the stub only If the connection cannot be authenticated (such as if the stub only
knows the IP address of the resolver and the resolver's certificate knows the IP address of the resolver and the resolver's certificate
does not have the IP address, or the correct IP address), the stub does not have the IP address, or the correct IP address), the stub
MAY still use the results with the same lack of assuredness as it MAY still use the results with the same lack of assuredness as it
skipping to change at page 8, line 37 skipping to change at page 8, line 45
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-acme-ip] [I-D.ietf-acme-ip]
Shoemaker, R., "ACME IP Identifier Validation Extension", Shoemaker, R., "ACME IP Identifier Validation Extension",
draft-ietf-acme-ip-06 (work in progress), May 2019. draft-ietf-acme-ip-08 (work in progress), October 2019.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
 End of changes. 9 change blocks. 
10 lines changed or deleted 15 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/