idnits 2.17.00 (12 Aug 2021) /tmp/idnits31428/draft-ietf-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 11 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 7 instances 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 -- The document date (12 July 2021) is 313 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 (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP M. Andrews 3 Internet-Draft ISC 4 Updates: 1034 (if approved) S. Huque 5 Intended status: Standards Track Salesforce 6 Expires: 13 January 2022 P. Wouters 7 Aiven 8 D. Wessels 9 Verisign 10 12 July 2021 12 Glue In DNS Referral Responses Is Not Optional 13 draft-ietf-dnsop-glue-is-not-optional-01 15 Abstract 17 The DNS uses glue records to allow iterative clients to find the 18 addresses of nameservers that are contained within a delegated zone. 19 Servers are expected to return available glue records in referrals. 20 If message size constraints prevent the inclusion of glue records in 21 a UDP response, the server MUST set the TC flag to inform the client 22 that the response is incomplete, and that the client SHOULD use TCP 23 to retrieve the full response. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 13 January 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . 2 60 2. Clarifying modifications to RFC1034 . . . . . . . . . . . . . 3 61 3. Why glue is required . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Example one: Missing glue . . . . . . . . . . . . . . . . 3 63 3.2. Example two: Sibling Glue from the same delegating 64 zone . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.3. Example three: Cross Zone Sibling Glue . . . . . . . . . 5 66 3.4. Promoted (or orphaned) glue . . . . . . . . . . . . . . . 6 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 6. Normative References . . . . . . . . . . . . . . . . . . . . 6 70 7. Informative References . . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 The Domain Name System (DNS) [RFC1034], [RFC1035] uses glue records 76 to allow iterative clients to find the addresses of nameservers that 77 are contained within a delegated zone. Glue records are added to the 78 parent zone as part of the delegation process. Servers are expected 79 to return available glue records in referrals. If message size 80 constraints prevent the inclusion of glue records in a UDP response, 81 the server MUST set the TC flag to inform the client that the 82 response is incomplete, and that the client SHOULD use TCP to 83 retrieve the full response. This document clarifies that 84 expectation. 86 1.1. Reserved Words 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 2. Clarifying modifications to RFC1034 94 Replace 96 "Copy the NS RRs for the subzone into the authority section of the 97 reply. Put whatever addresses are available into the additional 98 section, using glue RRs if the addresses are not available from 99 authoritative data or the cache. Go to step 4." 101 with 103 "Copy the NS RRs for the subzone into the authority section of the 104 reply. Put whatever addresses are available into the additional 105 section, using glue RRs if the addresses are not available from 106 authoritative data or the cache. If glue RRs do not fit, set TC=1 in 107 the header. Go to step 4." 109 3. Why glue is required 111 While not common, real life examples of servers that fail to set TC=1 112 when glue records are available exist and they do cause resolution 113 failures. 115 3.1. Example one: Missing glue 117 The example below from June 2020 shows a case where none of the glue 118 records, present in the zone, fitted into the available space and 119 TC=1 was not set in the response. While this example shows an DNSSEC 120 [RFC4033], [RFC4034], [RFC4035] referral response, this behaviour has 121 also been seen with plain DNS responses as well. The records have 122 been truncated for display purposes. Note that at the time of this 123 writing, this configuration has been corrected and the response 124 correctly sets the TC=1 flag. 126 % dig +norec +dnssec +bufsize=512 +ignore @a.gov-servers.net \ 127 rh202ns2.355.dhhs.gov 129 ; <<>> DiG 9.15.4 <<>> +norec +dnssec +bufsize +ignore \ 130 @a.gov-servers.net rh202ns2.355.dhhs.gov 131 ; (2 servers found) 132 ;; global options: +cmd 133 ;; Got answer: 134 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8798 135 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 1 137 ;; OPT PSEUDOSECTION: 138 ; EDNS: version: 0, flags: do; udp: 4096 139 ;; QUESTION SECTION: 140 ;rh202ns2.355.dhhs.gov. IN A 142 ;; AUTHORITY SECTION: 143 dhhs.gov. 86400 IN NS rh120ns2.368.dhhs.gov. 144 dhhs.gov. 86400 IN NS rh202ns2.355.dhhs.gov. 145 dhhs.gov. 86400 IN NS rh120ns1.368.dhhs.gov. 146 dhhs.gov. 86400 IN NS rh202ns1.355.dhhs.gov. 147 dhhs.gov. 3600 IN DS 51937 8 1 ... 148 dhhs.gov. 3600 IN DS 635 8 2 ... 149 dhhs.gov. 3600 IN DS 51937 8 2 ... 150 dhhs.gov. 3600 IN DS 635 8 1 ... 151 dhhs.gov. 3600 IN RRSIG DS 8 2 3600 ... 153 ;; Query time: 226 msec 154 ;; SERVER: 69.36.157.30#53(69.36.157.30) 155 ;; WHEN: Wed Apr 15 13:34:43 AEST 2020 156 ;; MSG SIZE rcvd: 500 158 % 160 DNS responses sometimes contain optional data in the additional 161 section. Glue records however are not optional. Several other 162 protocol extensions, when used, are also not optional. This includes 163 TSIG [RFC2845], OPT [RFC6891], and SIG(0) [RFC2931]. 165 3.2. Example two: Sibling Glue from the same delegating zone 167 Sibling glue are glue records that are not contained in the 168 delegating zone itself, but in another delegated zone. In many 169 cases, these are not strictly required for resolution, since the 170 resolver can make follow-on queries to the same zone to resolve the 171 nameserver addresses after following the referral to the sibling 172 zone. However, most nameserver implementations provide them as an 173 optimization to obviate the need for extra traffic. 175 Here the delegating zone "test" contains 2 delegations for the 176 subzones "bar.test" and "foo.test". The nameservers for "foo.test" 177 consist of sibling glue for "bar.test" (ns1.bar.test and ns2.bar.test). 179 bar.test. 86400 IN NS ns1.bar.test. 180 bar.test. 86400 IN NS ns2.bar.test. 181 ns1.bar.test. 86400 IN A 192.0.1.1 182 ns2.bar.test. 86400 IN A 192.0.1.2 184 foo.test. 86400 IN NS ns1.bar.test. 185 foo.test. 86400 IN NS ns2.bar.test. 187 Referral responses from test for foo.test should include the sibling 188 glue: 190 ;; QUESTION SECTION: 191 ;www.foo.test. IN A 193 ;; AUTHORITY SECTION: 194 foo.test. 86400 IN NS ns1.bar.test. 195 foo.test. 86400 IN NS ns2.bar.test. 197 ;; ADDITIONAL SECTION: 198 ns1.bar.test. 86400 IN A 192.0.1.1 199 ns2.bar.test. 86400 IN A 192.0.1.2 201 Question: if sibling glue from the same delegating zone does not fit 202 into the response, should we also recommend or require that TC=1 be 203 set? 205 3.3. Example three: Cross Zone Sibling Glue 207 Here is a more complex example of sibling glue that lives in another 208 zone, but is required to resolve a circular dependency in the zone 209 configuration. 211 example.com. 86400 IN NS ns1.example.net. 212 example.com. 86400 IN NS ns2.example.net. 213 ns1.example.com. 86400 IN A 192.0.1.1 214 ns2.example.com. 86400 IN A 192.0.1.2 216 example.net. 86400 IN NS ns1.example.com. 217 example.net. 86400 IN NS ns2.example.com. 218 ns1.example.net. 86400 IN A 198.51.100.1 219 ns2.example.net. 86400 IN A 198.51.100.2 221 3.4. Promoted (or orphaned) glue 223 When a zone is deleted but the parent notices that its NS glue 224 records are required for other zones, it MAY opt to take these (now 225 orphaned) glue records into its own zone to ensure that other zones 226 depending on this glue are not broken. Technically, these NS records 227 are no longer glue records, but authoritative data of the parent 228 zone, and should be added to the DNS response similarly to regular 229 glue records. 231 4. Security Considerations 233 This document clarifies correct DNS server behaviour and does not 234 introduce any changes or new security considerations. 236 5. IANA Considerations 238 There are no actions for IANA. 240 6. Normative References 242 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 243 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 244 . 246 [RFC1035] Mockapetris, P., "Domain names - implementation and 247 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 248 November 1987, . 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, 252 DOI 10.17487/RFC2119, March 1997, 253 . 255 7. Informative References 257 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 258 Wellington, "Secret Key Transaction Authentication for DNS 259 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 260 . 262 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 263 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 264 2000, . 266 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 267 Rose, "DNS Security Introduction and Requirements", 268 RFC 4033, DOI 10.17487/RFC4033, March 2005, 269 . 271 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 272 Rose, "Resource Records for the DNS Security Extensions", 273 RFC 4034, DOI 10.17487/RFC4034, March 2005, 274 . 276 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 277 Rose, "Protocol Modifications for the DNS Security 278 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 279 . 281 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 282 for DNS (EDNS(0))", STD 75, RFC 6891, 283 DOI 10.17487/RFC6891, April 2013, 284 . 286 Authors' Addresses 288 M. Andrews 289 ISC 291 Email: marka@isc.org 293 Shumon Huque 294 Salesforce 296 Email: shuque@gmail.com 298 Paul Wouters 299 Aiven 301 Email: paul.wouters@aiven.io 303 Duane Wessels 304 Verisign 306 Email: dwessels@verisign.com