idnits 2.17.1 draft-hoffman-dns-terminology-ter-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC8499, but the abstract doesn't seem to directly say this. It does mention RFC8499 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 24, 2019) is 1859 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC8499' on line 120 looks like a reference -- Missing reference section? 'RFC1035' on line 107 looks like a reference -- Missing reference section? 'RFC8484' on line 116 looks like a reference -- Missing reference section? 'RFC7858' on line 111 looks like a reference -- Missing reference section? 'I-D.ietf-doh-resolver-associated-doh' on line 102 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft ICANN 4 Updates: RFC 8499 (if approved) March 24, 2019 5 Intended status: Standards Track 6 Expires: September 25, 2019 8 Abbreviations for DNS Transports and Location 9 draft-hoffman-dns-terminology-ter-00 11 Abstract 13 This document adds abbreviations to "DNS Terminology" (RFC 8499) that 14 relate to DNS running over various transports, as well as 15 abbreviations for DNS resolution at traditional and non-traditional 16 locations. 18 [[ This is an early attempt at these terms. They will probably be 19 improved over time. [] 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 25, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. New Abbreviations . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Normative References . . . . . . . . . . . . . . . . . . . . 3 57 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1. New Abbreviations 62 The following abbreviations are added to Section 6 of [RFC8499]. 64 Do53: DNS over UDP or TCP as defined in [RFC1035] and its successors. 65 Do53 applies to DNS communication between stub resolvers and 66 recursive resolvers, and between recursive resolvers and 67 authoritative servers. 69 DoH: DNS over HTTPS as defined in [RFC8484] and its successors. 71 DoT: DNS over TLS as defined in [RFC7858] and its successors. 73 RDoT: RDoT specifically means DoT for transport between stub 74 resolvers and recursive resolvers. This term is necessary because it 75 is expected that DNS over TLS will later be defined as a transport 76 between recursive resolvers and authoritative servers, The "R" in 77 RDoT stands for "recursive", the endpoint. 79 ADoT: If DoT is later defined as the transport between recursive 80 resolvers and authoritative servers, ADoT specifically means DoT for 81 transport between recursive resolvers and authoritative servers. The 82 "A" in ADoT stands for "authoritative", the endpoint. 84 DaT: DNS resolution between a stub resolver and the recursive 85 resolver at the the traditional location configured in the operating 86 system. The "T" stands for "traditional". DaT is typically 87 configured by DHCP, IPv6 router advertisements, or an administrator 88 editing a configuration file on a host. If 89 [I-D.ietf-doh-resolver-associated-doh] becomes standardized, DoH to 90 the DoH server associated with the traditional resolver would also be 91 considered DaT. 93 DaO: DNS resolution between a stub resolver and a recursive resolver 94 at other than the traditional location configured in the operating 95 system. DaO can be configured by a user changing the configuration 96 on a host (such as editing /etc/resolv.conf), or an application 97 running RDoT or DoH to a resolver that is not the same as the 98 traditional location configured in the operating system, 100 2. Normative References 102 [I-D.ietf-doh-resolver-associated-doh] 103 Hoffman, P., "Associating a DoH Server with a Resolver", 104 draft-ietf-doh-resolver-associated-doh-02 (work in 105 progress), March 2019. 107 [RFC1035] Mockapetris, P., "Domain names - implementation and 108 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 109 November 1987, . 111 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 112 and P. Hoffman, "Specification for DNS over Transport 113 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 114 2016, . 116 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 117 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 118 . 120 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 121 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 122 January 2019, . 124 Acknowledgments 126 Sara Dickinson contributed ideas before the first draft was 127 published. 129 Author's Address 131 Paul Hoffman 132 ICANN 134 Email: paul.hoffman@icann.org