idnits 2.17.00 (12 Aug 2021) /tmp/idnits35121/draft-ietf-dnsop-glue-is-not-optional-03.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 31 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (11 October 2021) is 222 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: 'SHOULD' is mentioned on line 271, but not defined -- 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: 14 April 2022 P. Wouters 7 Aiven 8 D. Wessels 9 Verisign 10 11 October 2021 12 Glue In DNS Referral Responses Is Not Optional 13 draft-ietf-dnsop-glue-is-not-optional-03 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 Authoritative Servers are expected to return all available glue 20 records in referrals. If message size constraints prevent the 21 inclusion of all glue records in a UDP response, the server MUST set 22 the TC flag to inform the client that the response is incomplete, and 23 that the client SHOULD use TCP to retrieve the full response. This 24 document updates RFC 1034 to clarify correct server behavior. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 14 April 2022. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . 3 61 2. Types of Glue . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. In-Domain Glue . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Sibling Glue . . . . . . . . . . . . . . . . . . . . . . 4 64 2.3. Sibling Cyclic Glue . . . . . . . . . . . . . . . . . . . 4 65 2.4. Missing glue . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.1. In-Domain Glue . . . . . . . . . . . . . . . . . . . . . 6 68 3.2. Sibling Glue . . . . . . . . . . . . . . . . . . . . . . 6 69 3.3. Updates to RFC 1034 . . . . . . . . . . . . . . . . . . . 6 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 73 7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 75 9. Informative References . . . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 The Domain Name System (DNS) [RFC1034], [RFC1035] uses glue records 81 to allow iterative clients to find the addresses of nameservers that 82 are contained within a delegated zone. Glue records are added to the 83 parent zone as part of the delegation process and returned in 84 referral responses, otherwise a resolver following the referral has 85 no way of finding these addresses. Authoritative servers are 86 expected to return all available glue records in referrals. If 87 message size constraints prevent the inclusion of all glue records in 88 a UDP response, the server MUST set the TC (Truncated) flag to inform 89 the client that the response is incomplete, and that the client 90 SHOULD use TCP to retrieve the full response. This document 91 clarifies that expectation. 93 DNS responses sometimes contain optional data in the additional 94 section. Glue records however are not optional. Several other 95 protocol extensions, when used, are also not optional. This includes 96 TSIG [RFC2845], OPT [RFC6891], and SIG(0) [RFC2931]. 98 Note that this document only clarifies requirements of name server 99 software implementations. It does not place any requirements on data 100 placed in DNS zones or registries. 102 1.1. Reserved Words 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 2. Types of Glue 110 This section describes different types of glue that may be found in 111 DNS referral responses. Note that the type of glue depends on the 112 QNAME. A particular record can be in-domain glue for one response 113 and sibling glue for another. 115 2.1. In-Domain Glue 117 The following is a simple example of glue records present in the 118 delegating zone "test" for the child zone "foo.test". The 119 nameservers for foo.test (ns1.foo.test and ns2.foo.test) are both 120 below the delegation point. They are configured as glue records in 121 the "test" zone: 123 foo.test. 86400 IN NS ns1.foo.test. 124 foo.test. 86400 IN NS ns2.foo.test. 125 ns1.foo.test. 86400 IN A 192.0.2.1 126 ns2.foo.test. 86400 IN AAAA 2001:db8::2:2 128 A referral response from "test" for "foo.test" with in-domain glue 129 looks like this: 131 ;; QUESTION SECTION: 132 ;www.foo.test. IN A 134 ;; AUTHORITY SECTION: 135 foo.test. 86400 IN NS ns1.foo.test. 136 foo.test. 86400 IN NS ns2.foo.test. 138 ;; ADDITIONAL SECTION: 139 ns1.foo.test. 86400 IN A 192.0.2.1 140 ns2.foo.test. 86400 IN AAAA 2001:db8::2:2 142 2.2. Sibling Glue 144 Sibling glue are glue records that are not contained in the delegated 145 zone itself, but in another delegated zone from the same parent. In 146 many cases, these are not strictly required for resolution, since the 147 resolver can make follow-on queries to the same zone to resolve the 148 nameserver addresses after following the referral to the sibling 149 zone. However, most nameserver implementations today provide them as 150 an optimization to obviate the need for extra traffic from iterative 151 resolvers. 153 Here the delegating zone "test" contains 2 sub-delegations for the 154 subzones "bar.test" and "foo.test": 156 bar.test. 86400 IN NS ns1.bar.test. 157 bar.test. 86400 IN NS ns2.bar.test. 158 ns1.bar.test. 86400 IN A 192.0.2.1 159 ns2.bar.test. 86400 IN AAAA 2001:db8::2:2 161 foo.test. 86400 IN NS ns1.bar.test. 162 foo.test. 86400 IN NS ns2.bar.test. 164 A referral response from "test" for "foo.test" with sibling glue 165 looks like this: 167 ;; QUESTION SECTION: 168 ;www.foo.test. IN A 170 ;; AUTHORITY SECTION: 171 foo.test. 86400 IN NS ns1.bar.test. 172 foo.test. 86400 IN NS ns2.bar.test. 174 ;; ADDITIONAL SECTION: 175 ns1.bar.test. 86400 IN A 192.0.2.1 176 ns2.bar.test. 86400 IN AAAA 2001:db8::2:2 178 2.3. Sibling Cyclic Glue 180 The use of sibling glue can introduce cyclic dependencies. This 181 happens when one domain specifies name servers from a sibling domain, 182 and vice versa. This type of cyclic dependency can only be broken 183 when the delegating name server includes the sibling glue in a 184 referral response. 186 Here the delegating zone "test" contains 2 sub-delegations for the 187 subzones "bar.test" and "foo.test", and each use name servers under 188 the other: 190 bar.test. 86400 IN NS ns1.foo.test. 191 bar.test. 86400 IN NS ns2.foo.test. 192 ns1.bar.test. 86400 IN A 192.0.2.1 193 ns2.bar.test. 86400 IN AAAA 2001:db8::2:2 195 foo.test. 86400 IN NS ns1.bar.test. 196 foo.test. 86400 IN NS ns2.bar.test. 197 ns1.foo.test. 86400 IN A 192.0.2.3 198 ns2.foo.test. 86400 IN AAAA 2001:db8::2:4 200 A referral response from "test" for "bar.test" with sibling glue 201 looks like this: 203 ;; QUESTION SECTION: 204 ;www.bar.test. IN A 206 ;; AUTHORITY SECTION: 207 bar.test. 86400 IN NS ns1.foo.test. 208 bar.test. 86400 IN NS ns2.foo.test. 210 ;; ADDITIONAL SECTION: 211 ns1.foo.test. 86400 IN A 192.0.2.3 212 ns2.foo.test. 86400 IN AAAA 2001:db8::2:4 214 2.4. Missing glue 216 An example of missing glue is included here, even though it is not 217 really a type of glue. While not common, real examples of responses 218 that lack required glue, and with TC=0, have been shown to occur and 219 cause resolution failures. 221 The example below is based on a response observed in June 2020. The 222 names have been altered to fall under documentation domains. It 223 shows a case where none of the glue records present in the zone fit 224 into the available space of the UDP respose, and TC=1 was not set. 225 While this example shows a referral with DNSSEC records [RFC4033], 226 [RFC4034], [RFC4035], this behaviour has been seen with plain DNS 227 responses as well. Some records have been truncated for display 228 purposes. Note that at the time of this writing, the servers 229 originally responsible for this example have been updated and now 230 correctly set the TC=1 flag. 232 % dig +norec +dnssec +bufsize=512 +ignore @ns.example.net \ 233 rh202ns2.355.foo.example 235 ; <<>> DiG 9.15.4 <<>> +norec +dnssec +bufsize +ignore \ 236 @ns.example.net rh202ns2.355.foo.example 237 ; (2 servers found) 238 ;; global options: +cmd 239 ;; Got answer: 240 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8798 241 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 1 243 ;; OPT PSEUDOSECTION: 244 ; EDNS: version: 0, flags: do; udp: 4096 245 ;; QUESTION SECTION: 246 ;rh202ns2.355.foo.example. IN A 248 ;; AUTHORITY SECTION: 249 foo.example. 86400 IN NS rh120ns2.368.foo.example. 250 foo.example. 86400 IN NS rh202ns2.355.foo.example. 251 foo.example. 86400 IN NS rh120ns1.368.foo.example. 252 foo.example. 86400 IN NS rh202ns1.355.foo.example. 253 foo.example. 3600 IN DS 51937 8 1 ... 254 foo.example. 3600 IN DS 635 8 2 ... 255 foo.example. 3600 IN DS 51937 8 2 ... 256 foo.example. 3600 IN DS 635 8 1 ... 257 foo.example. 3600 IN RRSIG DS 8 2 3600 ... 259 3. Requirements 261 3.1. In-Domain Glue 263 This document clarifies that when a name server generates a referral 264 response, it MUST include all available in-domain glue records in the 265 additional section. If all in-domain glue records do not fit in a 266 UDP response, the name server MUST set TC=1. 268 3.2. Sibling Glue 270 This document clarifies that when a name server generates a referral 271 response, it MUST [SHOULD] include available sibling glue records in 272 the additional section. If all sibling glue records do not fit in a 273 UDP response, the name server MUST [is NOT REQUIRED to] set TC=1. 275 3.3. Updates to RFC 1034 277 [this doesn't really account for SHOULD on sibling glue...] 279 Replace 280 "Copy the NS RRs for the subzone into the authority section of the 281 reply. Put whatever addresses are available into the additional 282 section, using glue RRs if the addresses are not available from 283 authoritative data or the cache. Go to step 4." 285 with 287 "Copy the NS RRs for the subzone into the authority section of the 288 reply. Put whatever addresses are available into the additional 289 section, using glue RRs if the addresses are not available from 290 authoritative data or the cache. If all glue RRs do not fit, set 291 TC=1 in the header. Go to step 4." 293 4. Security Considerations 295 This document clarifies correct DNS server behaviour and does not 296 introduce any changes or new security considerations. 298 5. IANA Considerations 300 There are no actions for IANA. 302 6. Acknowledgements 304 The authors wish to thank Joe Abley, Brian Dickson, Geoff Huston, 305 Jared Mauch, George Michaelson, Benno Overeinder, John R Levine, 306 Shinta Sato, Puneet Sood, Ralf Weber, Tim Wicinski, Suzanne Woolf, 307 and other members of the DNSOP working group for their input. 309 7. Changes 311 RFC Editor: Please remove this section before publication. 313 This section lists substantial changes to the document as it is being 314 worked on. 316 From -01 to -02: 318 * Clarified that "servers" means "authoritative servers". 320 * Clarified that "available glue" means "all available glue". 322 * Updated examples and placed before RFC 1034 update. 324 From -02 to -03: 326 * Clarified scope to focus only on name server responses, and not 327 zone/registry data. 329 * Reorganized with section 2 as Types of Glue and section 3 as 330 Requirements. 332 * Removed any discussion of promoted / orphan glue. 334 * Use appropriate documentation addresses and domain names. 336 * Added Sibling Cyclic Glue example. 338 8. Normative References 340 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 341 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 342 . 344 [RFC1035] Mockapetris, P., "Domain names - implementation and 345 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 346 November 1987, . 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, 350 DOI 10.17487/RFC2119, March 1997, 351 . 353 9. Informative References 355 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 356 Wellington, "Secret Key Transaction Authentication for DNS 357 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 358 . 360 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 361 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 362 2000, . 364 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 365 Rose, "DNS Security Introduction and Requirements", 366 RFC 4033, DOI 10.17487/RFC4033, March 2005, 367 . 369 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 370 Rose, "Resource Records for the DNS Security Extensions", 371 RFC 4034, DOI 10.17487/RFC4034, March 2005, 372 . 374 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 375 Rose, "Protocol Modifications for the DNS Security 376 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 377 . 379 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 380 for DNS (EDNS(0))", STD 75, RFC 6891, 381 DOI 10.17487/RFC6891, April 2013, 382 . 384 Authors' Addresses 386 M. Andrews 387 ISC 389 Email: marka@isc.org 391 Shumon Huque 392 Salesforce 394 Email: shuque@gmail.com 396 Paul Wouters 397 Aiven 399 Email: paul.wouters@aiven.io 401 Duane Wessels 402 Verisign 404 Email: dwessels@verisign.com