idnits 2.17.00 (12 Aug 2021) /tmp/idnits32563/draft-ietf-dnsop-glue-is-not-optional-02.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 19 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 8 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 (26 July 2021) is 299 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: 27 January 2022 P. Wouters 7 Aiven 8 D. Wessels 9 Verisign 10 26 July 2021 12 Glue In DNS Referral Responses Is Not Optional 13 draft-ietf-dnsop-glue-is-not-optional-02 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. 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 27 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 . . . . . . . . . . . . . . . . . . . . . 3 60 2. Glue record example . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Missing glue . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Updates to RFC 1034 . . . . . . . . . . . . . . . . . . . . . 4 63 4. Sibling Glue . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1. Sibling Glue example . . . . . . . . . . . . . . . . . . 5 65 5. Promoted (or orphaned) glue . . . . . . . . . . . . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 69 9. Informative References . . . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 The Domain Name System (DNS) [RFC1034], [RFC1035] uses glue records 75 to allow iterative clients to find the addresses of nameservers that 76 are contained within a delegated zone. Glue records are added to the 77 parent zone as part of the delegation process and returned in 78 referral responses, otherwise a resolver following the referral has 79 no way of finding these addresses. Authoritative servers are 80 expected to return all available glue records in referrals. If 81 message size constraints prevent the inclusion of all glue records in 82 a UDP response, the server MUST set the TC (Truncated) flag to inform 83 the client that the response is incomplete, and that the client 84 SHOULD use TCP to retrieve the full response. This document 85 clarifies that expectation. 87 DNS responses sometimes contain optional data in the additional 88 section. Glue records however are not optional. Several other 89 protocol extensions, when used, are also not optional. This includes 90 TSIG [RFC2845], OPT [RFC6891], and SIG(0) [RFC2931]. 92 1.1. Reserved Words 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 2. Glue record example 100 The following is a simple example of glue records present in the 101 delegating zone "test" for the child zone "foo.test". The 102 nameservers for foo.test (ns1.foo.test and ns2.foo.test) are both 103 below the delegation point. They are configured as glue records in 104 the "test" zone: 106 foo.test. 86400 IN NS ns1.foo.test. 107 foo.test. 86400 IN NS ns2.foo.test. 108 ns1.foo.test. 86400 IN A 192.0.1.1 109 ns2.foo.test. 86400 IN A 192.0.1.2 111 Referral responses from "test" for "foo.test" must include the glue 112 records in the additional section (and set TC=1 if they do not fit): 114 ;; QUESTION SECTION: 115 ;www.foo.test. IN A 117 ;; AUTHORITY SECTION: 118 foo.test. 86400 IN NS ns1.foo.test. 119 foo.test. 86400 IN NS ns2.foo.test. 121 ;; ADDITIONAL SECTION: 122 ns1.foo.test. 86400 IN A 192.0.1.1 123 ns2.foo.test. 86400 IN A 192.0.1.2 125 2.1. Missing glue 127 While not common, real life examples of servers that fail to set TC=1 128 when glue records are available, exist and they do cause resolution 129 failures. 131 The example below from June 2020 shows a case where none of the glue 132 records, present in the zone, fitted into the available space and 133 TC=1 was not set in the response. While this example shows an DNSSEC 134 [RFC4033], [RFC4034], [RFC4035] referral response, this behaviour has 135 also been seen with plain DNS responses as well. The records have 136 been truncated for display purposes. Note that at the time of this 137 writing, this configuration has been corrected and the response 138 correctly sets the TC=1 flag. 140 % dig +norec +dnssec +bufsize=512 +ignore @a.gov-servers.net \ 141 rh202ns2.355.dhhs.gov 143 ; <<>> DiG 9.15.4 <<>> +norec +dnssec +bufsize +ignore \ 144 @a.gov-servers.net rh202ns2.355.dhhs.gov 145 ; (2 servers found) 146 ;; global options: +cmd 147 ;; Got answer: 148 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8798 149 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 1 151 ;; OPT PSEUDOSECTION: 152 ; EDNS: version: 0, flags: do; udp: 4096 153 ;; QUESTION SECTION: 154 ;rh202ns2.355.dhhs.gov. IN A 156 ;; AUTHORITY SECTION: 157 dhhs.gov. 86400 IN NS rh120ns2.368.dhhs.gov. 158 dhhs.gov. 86400 IN NS rh202ns2.355.dhhs.gov. 159 dhhs.gov. 86400 IN NS rh120ns1.368.dhhs.gov. 160 dhhs.gov. 86400 IN NS rh202ns1.355.dhhs.gov. 161 dhhs.gov. 3600 IN DS 51937 8 1 ... 162 dhhs.gov. 3600 IN DS 635 8 2 ... 163 dhhs.gov. 3600 IN DS 51937 8 2 ... 164 dhhs.gov. 3600 IN DS 635 8 1 ... 165 dhhs.gov. 3600 IN RRSIG DS 8 2 3600 ... 167 3. Updates to RFC 1034 169 Replace 171 "Copy the NS RRs for the subzone into the authority section of the 172 reply. Put whatever addresses are available into the additional 173 section, using glue RRs if the addresses are not available from 174 authoritative data or the cache. Go to step 4." 176 with 178 "Copy the NS RRs for the subzone into the authority section of the 179 reply. Put whatever addresses are available into the additional 180 section, using glue RRs if the addresses are not available from 181 authoritative data or the cache. If all glue RRs do not fit, set 182 TC=1 in the header. Go to step 4." 184 4. Sibling Glue 186 Sibling glue are glue records that are not contained in the delegated 187 zone itself, but in another delegated zone from the same parent. In 188 many cases, these are not strictly required for resolution, since the 189 resolver can make follow-on queries to the same zone to resolve the 190 nameserver addresses after following the referral to the sibling 191 zone. However, most nameserver implementations today provide them as 192 an optimization to obviate the need for extra traffic from iterative 193 resolvers. 195 This document clarifies that sibling glue (being part of all 196 available glue records) MUST be returned in referral responses, and 197 that the requirement to set TC=1 applies to sibling glue that cannot 198 fit in the response too. 200 4.1. Sibling Glue example 202 Here the delegating zone "test" contains 2 sub-delegations for the 203 subzones "bar.test" and "foo.test". 205 bar.test. 86400 IN NS ns1.bar.test. 206 bar.test. 86400 IN NS ns2.bar.test. 207 ns1.bar.test. 86400 IN A 192.0.1.1 208 ns2.bar.test. 86400 IN A 192.0.1.2 210 foo.test. 86400 IN NS ns1.bar.test. 211 foo.test. 86400 IN NS ns2.bar.test. 213 Referral responses from "test" for "foo.test" must include the 214 sibling glue (and set TC=1 if they do not fit): 216 ;; QUESTION SECTION: 217 ;www.foo.test. IN A 219 ;; AUTHORITY SECTION: 220 foo.test. 86400 IN NS ns1.bar.test. 221 foo.test. 86400 IN NS ns2.bar.test. 223 ;; ADDITIONAL SECTION: 224 ns1.bar.test. 86400 IN A 192.0.1.1 225 ns2.bar.test. 86400 IN A 192.0.1.2 227 5. Promoted (or orphaned) glue 229 When a zone is deleted but the parent notices that its NS glue 230 records are required for other zones, it MAY opt to take these (now 231 orphaned) glue records into its own zone to ensure that other zones 232 depending on this glue are not broken. Technically, these address 233 records are no longer glue records, but authoritative data of the 234 parent zone, and should be added to the DNS response similarly to 235 regular glue records. 237 6. Security Considerations 239 This document clarifies correct DNS server behaviour and does not 240 introduce any changes or new security considerations. 242 7. IANA Considerations 244 There are no actions for IANA. 246 8. Normative References 248 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 249 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 250 . 252 [RFC1035] Mockapetris, P., "Domain names - implementation and 253 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 254 November 1987, . 256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, 258 DOI 10.17487/RFC2119, March 1997, 259 . 261 9. Informative References 263 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 264 Wellington, "Secret Key Transaction Authentication for DNS 265 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 266 . 268 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 269 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 270 2000, . 272 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 273 Rose, "DNS Security Introduction and Requirements", 274 RFC 4033, DOI 10.17487/RFC4033, March 2005, 275 . 277 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 278 Rose, "Resource Records for the DNS Security Extensions", 279 RFC 4034, DOI 10.17487/RFC4034, March 2005, 280 . 282 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 283 Rose, "Protocol Modifications for the DNS Security 284 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 285 . 287 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 288 for DNS (EDNS(0))", STD 75, RFC 6891, 289 DOI 10.17487/RFC6891, April 2013, 290 . 292 Authors' Addresses 294 M. Andrews 295 ISC 297 Email: marka@isc.org 299 Shumon Huque 300 Salesforce 302 Email: shuque@gmail.com 304 Paul Wouters 305 Aiven 307 Email: paul.wouters@aiven.io 309 Duane Wessels 310 Verisign 312 Email: dwessels@verisign.com