idnits 2.17.1 draft-hardaker-dnsop-drop-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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 86: '...TC bit to be set SHOULD set the DP bit...' RFC 2119 keyword, line 102: '... a response SHOULD set both the TC b...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 20, 2019) is 1613 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Hardaker 3 Internet-Draft USC/ISI 4 Intended status: Standards Track November 20, 2019 5 Expires: May 23, 2020 7 Dropped Remaining Other Propaganda in DNS Responses 8 draft-hardaker-dnsop-drop-00 10 Abstract 12 When DNS replies to be sent over UDP exceed the requestor's UDP 13 payload size, servers are expected to set the Truncated bit (TC) and 14 remove remove additional information from the response. Clients 15 receiving the TC bit might choose to retry the request over TCP to 16 fetch the removed information. Sometimes this extra information is 17 not important to the DNS resolution process and retrying over TCP may 18 not be needed. This document defines the DP bit to indicate that the 19 dropped information that caused the TC bit was supplemental 20 information. This is useful, for example, in the case of Extended 21 DNS Error information which may be mostly debugging related 22 information. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 23, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Modifications to DNS Processing . . . . . . . . . . . . . . . 2 60 3. Applicable Use Cases . . . . . . . . . . . . . . . . . . . . 2 61 3.1. Extended DNS Errors . . . . . . . . . . . . . . . . . . . 3 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 64 6. Informative References . . . . . . . . . . . . . . . . . . . 3 65 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 3 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1. Introduction 70 When DNS replies to be sent over UDP exceed the requestor's UDP 71 payload size [EDNS0], servers are expected to set the Truncated bit 72 (TC) [DOMANINAMES] and remove remove additional information from the 73 response. Clients receiving the TC bit might choose to retry the 74 request over TCP to fetch the removed information. Sometimes this 75 extra information is not important to the DNS resolution process and 76 retrying over TCP may not be needed. This document defines the 77 "drop" bit (DP) to indicate that the dropped information that caused 78 the TC bit was supplemental information. This is useful, for 79 example, in the case of Extended DNS Error information which may be 80 mostly debugging related information. 82 2. Modifications to DNS Processing 84 Servers returning a UDP response containing supplemental information 85 (such as Extended DNS Error information (xxx: need non-RFC here)) 86 that caused the TC bit to be set SHOULD set the DP bit. 88 Clients receiving a UDP response with both the TC bit and the DP bit 89 set may choose to not resend their request over TCP since DP bit 90 indicates the extra information is ignorable. 92 3. Applicable Use Cases 94 The removal of any other information from a DNS response that would 95 set the TC bit should not set the DP bit unless a specification 96 indicates it should be set. This specification lists the following 97 scenarios where this should be set. 99 3.1. Extended DNS Errors 101 DNS servers setting the TC bit when EDE information was removed from 102 a response SHOULD set both the TC bit and the DP bit. 104 4. Security Considerations 106 Bits are unsigned unless sent over TLS. If a malicious device-in- 107 the-middle attacker set the DP bit, it may cause a client not to re- 108 query for the dropped information. However, an attacker could just 109 as easily unset the TC bit as they could set the DP bit, thus the 110 security exposure of the bits are no worse than before. 112 5. IANA Considerations 114 This document (will) adds the BD bit to the IANA EDNS0 flag registry. 116 6. Informative References 118 [DOMANINAMES] 119 Mockapetris, P., "Domain names - implementation and 120 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 121 November 1987, . 123 [EDNS0] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 124 for DNS (EDNS(0))", STD 75, RFC 6891, 125 DOI 10.17487/RFC6891, April 2013, . 128 Appendix A. Acknowledgments 130 The creation of an extra bit was first suggested by Viktor Dukuhvni's 131 associate and later refined by Brian Dickson. 133 Author's Address 135 Wes Hardaker 136 USC/ISI 138 Email: ietf@hardakers.net