idnits 2.17.1 draft-andrews-dnsop-glue-is-not-optional-01.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC1034, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1034, updated by this document, for RFC5378 checks: 1987-11-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 16, 2020) is 1442 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) -- Obsolete informational reference (is this intentional?): RFC 2845 (Obsoleted by RFC 8945) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Andrews 3 Internet-Draft ISC 4 Updates: 1034 (if approved) April 16, 2020 5 Intended status: Standards Track 6 Expires: October 18, 2020 8 Glue In DNS Referral Responses Is Not Optional 9 draft-andrews-dnsop-glue-is-not-optional-01 11 Abstract 13 The DNS uses glue records to allow iterative clients to find the 14 addresses of nameservers that live within the delegated zone. Glue 15 records are expected to be returned as part of a referral and if they 16 cannot be fitted into the UDP response, TC=1 MUST be set to inform 17 the client that the response is incomplete and that TCP SHOULD be 18 used to retrieve the full response. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 18, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . 4 56 2. Modifications to RFC1034 . . . . . . . . . . . . . . . . . . 4 57 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 61 5.2. Informative References . . . . . . . . . . . . . . . . . 5 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 64 1. Introduction 66 The DNS [RFC1034], [RFC1035] uses glue records to allow iterative 67 clients to find the addresses of nameservers that live within the 68 delegated zone. Glue records are expected to be returned as part of 69 a referral and if they cannot be fitted into the UDP response, TC=1 70 MUST be set to inform the client that the response is incomplete and 71 that TCP SHOULD be used to retrieve the full response. 73 While not common, real life examples of servers that fail to set TC=1 74 when glue records are available exist and they do cause resolution 75 failures. The example below shows a case where none of the glue 76 records, present in the zone, fitted into the available space and 77 TC=1 was not set in the response. While this example shows an DNSSEC 78 [RFC4033], [RFC4034], [RFC4035] referral response, this behaviour has 79 also been seen with plain DNS responses as well. The records have 80 been truncated for display purposes. 82 % dig +norec +dnssec +bufsize=512 +ignore @a.gov-servers.net \ 83 rh202ns2.355.dhhs.gov 85 ; <<>> DiG 9.15.4 <<>> +norec +dnssec +bufsize +ignore \ 86 @a.gov-servers.net rh202ns2.355.dhhs.gov 87 ; (2 servers found) 88 ;; global options: +cmd 89 ;; Got answer: 90 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8798 91 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 1 93 ;; OPT PSEUDOSECTION: 94 ; EDNS: version: 0, flags: do; udp: 4096 95 ;; QUESTION SECTION: 96 ;rh202ns2.355.dhhs.gov. IN A 98 ;; AUTHORITY SECTION: 99 dhhs.gov. 86400 IN NS rh120ns2.368.dhhs.gov. 100 dhhs.gov. 86400 IN NS rh202ns2.355.dhhs.gov. 101 dhhs.gov. 86400 IN NS rh120ns1.368.dhhs.gov. 102 dhhs.gov. 86400 IN NS rh202ns1.355.dhhs.gov. 103 dhhs.gov. 3600 IN DS 51937 8 1 ... 104 dhhs.gov. 3600 IN DS 635 8 2 ... 105 dhhs.gov. 3600 IN DS 51937 8 2 ... 106 dhhs.gov. 3600 IN DS 635 8 1 ... 107 dhhs.gov. 3600 IN RRSIG DS 8 2 3600 ... 109 ;; Query time: 226 msec 110 ;; SERVER: 69.36.157.30#53(69.36.157.30) 111 ;; WHEN: Wed Apr 15 13:34:43 AEST 2020 112 ;; MSG SIZE rcvd: 500 114 % 116 This is almost certainly due a wide spread misbelief that all 117 additional section records are optional. This has never been the 118 case with respect to glue records and later protocol extension have 119 added more cases where records in the additional section are not 120 optional in the response. This includes TSIG [RFC2845], OPT 121 [RFC6891], and SIG(0) [RFC2931]. 123 Glue records are added to the parent zone as part of the delegation 124 process. They are expected to be returned as part of a referral and 125 if they can't fit in a UDP response TC=1 MUST be set to signal to the 126 client to retry over TCP. This document reinforces that expectation. 128 1.1. Reserved Words 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 2. Modifications to RFC1034 136 Replace 138 "Copy the NS RRs for the subzone into the authority section of the 139 reply. Put whatever addresses are available into the additional 140 section, using glue RRs if the addresses are not available from 141 authoritative data or the cache. Go to step 4." 143 with 145 "Copy the NS RRs for the subzone into the authority section of the 146 reply. Put whatever addresses are available into the additional 147 section, using glue RRs if the addresses are not available from 148 authoritative data or the cache. If glue RRs do not fit set TC=1 in 149 the header. Go to step 4." 151 3. Security Considerations 153 This document reinforces DNS server behaviour expectations and does 154 not introduce new security considerations. 156 4. IANA Considerations 158 There are no actions for IANA. 160 5. References 162 5.1. Normative References 164 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 165 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 166 . 168 [RFC1035] Mockapetris, P., "Domain names - implementation and 169 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 170 November 1987, . 172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 173 Requirement Levels", BCP 14, RFC 2119, 174 DOI 10.17487/RFC2119, March 1997, 175 . 177 5.2. Informative References 179 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 180 Wellington, "Secret Key Transaction Authentication for DNS 181 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 182 . 184 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 185 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 186 2000, . 188 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 189 Rose, "DNS Security Introduction and Requirements", 190 RFC 4033, DOI 10.17487/RFC4033, March 2005, 191 . 193 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 194 Rose, "Resource Records for the DNS Security Extensions", 195 RFC 4034, DOI 10.17487/RFC4034, March 2005, 196 . 198 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 199 Rose, "Protocol Modifications for the DNS Security 200 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 201 . 203 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 204 for DNS (EDNS(0))", STD 75, RFC 6891, 205 DOI 10.17487/RFC6891, April 2013, 206 . 208 Author's Address 210 M. Andrews 211 Internet Systems Consortium 212 PO Box 360 213 Newmarket, NH 03857 214 US 216 Email: marka@isc.org