idnits 2.17.00 (12 Aug 2021) /tmp/idnits6615/draft-ietf-dnsind-clarify-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (January 1997) is 9256 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 normative reference: RFC 1700 (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. 'DNSSEC' Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Robert Elz 2 Internet Draft University of Melbourne 3 Expiration Date: July 1997 4 Randy Bush 5 RGnet, Inc. 7 January 1997 9 Clarifications to the DNS Specification 11 draft-ietf-dnsind-clarify-03.txt 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 1. Abstract 33 Please do not bother with this draft, it was intended to be posted 34 before the San Jose IETF, but missed the deadline by minutes. It was 35 (other than this paragraph) later posted to the namedroppers mailing 36 list. A new version, which responds to comments received from that 37 mailing list posting will be posted to the I-D directories within 38 days, please wait for that one, and don't waste time on this. This 39 version is appearing solely to keep the I-D numbering sequence sane, 40 the mailing list version was called -03, so we must have a -03 so the 41 next real version can be -04 ... 43 This draft considers some areas that have been identified as problems 44 with the specification of the Domain Name System, and proposes 45 remedies for the defects identified. Five separate issues are 46 considered: 48 + IP packet header address usage from multi-homed servers, 49 + TTLs in sets of records with the same name, class, and type, 50 + correct handling of zone cuts, 51 + the issue of what is an authoritative, or canonical, name, 52 + and the issue of what makes a valid DNS label. 54 The first three of these are areas where the correct behaviour has 55 been somewhat unclear, we seek to rectify that. The other two are 56 already adequately specified, however the specifications seem to be 57 sometimes ignored. We seek to reinforce the existing specification. 59 Contents 61 1 Abstract ................................................... 1 62 2 Introduction ............................................... 2 63 3 Server Reply Source Address Selection ...................... 3 64 4 Resource Record Sets ....................................... 3 65 5 Zone Cuts .................................................. 6 66 6 Naming issues .............................................. 7 67 7 Name syntax ................................................ 9 68 8 Security Considerations .................................... 10 69 9 References ................................................. 10 70 10 Acknowledgements ........................................... 10 71 11 Authors' addresses ......................................... 11 73 2. Introduction 75 Several problem areas in the Domain Name System specification 76 [RFC1034, RFC1035] have been noted through the years [RFC1123]. This 77 draft addresses several additional problem areas. The issues here 78 are independent. Those issues are the question of which source 79 address a multi-homed DNS server should use when replying to a query, 80 the issue of differing TTLs for DNS records with the same label, 81 class and type, and the issue of canonical names, what they are, how 82 CNAME records relate, what names are legal in what parts of the DNS, 83 and what is the valid syntax of a DNS name. 85 Suggestions for clarifications to the DNS specification to avoid 86 these problems are made in this memo. The solutions proposed herein 87 are intended to stimulate discussion. It is possible that the sense 88 of either may be reversed before the next iteration of this draft, 89 but less likely now than it was before the previous version. 91 3. Server Reply Source Address Selection 93 Most, if not all, DNS clients, whether servers acting as clients for 94 the purposes of recursive query resolution, or resolvers, expect the 95 address from which a reply is received to be the same address as that 96 to which the query eliciting the reply was sent. This, along with 97 the identifier (ID) in the reply is used for disambiguating replies, 98 and filtering spurious responses. This may, or may not, have been 99 intended when the DNS was designed, but is now a fact of life. 101 Some multi-homed hosts running DNS servers fail to anticipate this 102 usage, and consequently send replies from the "wrong" source address, 103 causing the reply to be discarded by the client. 105 3.1. UDP Source Address Selection 107 To avoid these problems, servers when responding to queries using UDP 108 must cause the reply to be sent with the source address field in the 109 IP header set to the address that was in the destination address 110 field of the IP header of the packet containing the query causing the 111 response. If this would cause the response to be sent from an IP 112 address which is not permitted for this purpose, then the response 113 may be sent from any legal IP address allocated to the server. That 114 address should be chosen to maximise the possibility that the client 115 will be able to use it for further queries. Servers configured in 116 such a way that not all their addresses are equally reachable from 117 all potential clients need take particular care when responding to 118 queries sent to anycast, multicast, or similar, addresses. 120 3.2. Port Number Selection 122 Replies to all queries must be directed to the port from which they 123 were sent. With queries received via TCP this is an inherent part of 124 the transport protocol, for queries received by UDP the server must 125 take note of the source port and use that as the destination port in 126 the response. Replies should always be sent from the port to which 127 they were directed. Except in extraordinary circumstances, this will 128 be the well known port assigned for DNS queries [RFC1700]. 130 4. Resource Record Sets 132 Each DNS Resource Record (RR) has a label, class, type, and data. 133 While it is meaningless for two records to ever have label, class, 134 type and data all equal (servers should suppress such duplicates if 135 encountered), it is possible for many record types to exist with the 136 same label class and type, but with different data. Such a group of 137 records is hereby defined to be a Resource Record Set (RRSet). 139 4.1. Sending RRs from an RRSet 141 A query for a specific (or non-specific) label, class, and type, will 142 always return all records in the associated RRSet - whether that be 143 one or more RRs, or the response shall be marked as "truncated" if 144 the entire RRSet will not fit in the response. 146 4.2. TTLs of RRs in an RRSet 148 Resource Records also have a time to live (TTL). It is possible for 149 the RRs in an RRSet to have different TTLs, however no uses for this 150 have been found which cannot be better accomplished in other ways. 151 This can, however, cause partial replies (not marked "truncated") 152 from a caching server, where the TTLs for some but not all of the RRs 153 in the RRSet have expired. 155 Consequently the use of differing TTLs in an RRSet is hereby 156 deprecated, the TTLs of all RRs in an RRSet must be the same. 158 Should a client receive a response containing RRs from an RRSet with 159 differing TTLs, it should treat the RRs for all purposes as if all 160 TTLs in the RRSet had been set to the value of the lowest TTL in the 161 RRSet. 163 4.3. Receiving RRSets 165 Servers must never merge RRs from a response with RRs in their cache 166 to form an RRSet. If a response contains data which would form an 167 RRSet with data in a server's cache the server must either ignore the 168 RRs in the response, or use those to replace the existing RRSet in 169 the cache, as appropriate. Consequently the issue of TTLs varying 170 between the cache and a response does not cause concern, one will be 171 ignored. That is, one of the data sets is always incorrect if the 172 data from an answer differs from the data in the cache. The 173 challenge for the server is to determine which of the data sets is 174 correct, assuming that one is, and retain that, while ignoring the 175 other. Note that if a server receives an answer containing an RRSet 176 that is identical to that in its cache, with the possible exception 177 of the TTL value, it may update the TTL in its cache with the TTL of 178 the received answer. It should do this if the received answer would 179 be considered more authoritative (as discussed in the next section) 180 than the previously cached answer. 182 4.3.1. Ranking data 184 When considering whether to accept an RRSet in a reply, or retain an 185 RRSet already in its cache instead, a server should consider the 186 relative likely trustworthiness of the various data. That is, an 187 authoritative answer from a reply should replace cached data that had 188 been obtained from additional information in an earlier reply, but 189 additional information from a reply will be ignored if the cache 190 contains data from an authoritative answer or a zone file. 192 The accuracy of data available is assumed from its source. 193 Trustworthiness shall be, in order from most to least: 195 + Data from a primary zone file, other than glue data, 196 + Data from a zone transfer, other than glue, 197 + That from the answer section of an authoritative reply, 198 + Glue from a primary zone, or glue from a zone transfer, 199 + Data from the authority section of an authoritative answer, 200 + Data from the answer section of a non-authoritative answer, 201 + Additional information from an authoritative answer, 202 + Data from the authority section of a non-authoritative answer, 203 + Additional information from non-authoritative answers. 205 When DNS security [DNSSEC] is in use, and authenticated data has been 206 received and verified, it shall be considered more trustworthy than 207 unauthenticated data of the same type. Note that throughout this 208 document, "authoritative" is used to mean a reply with the AA bit 209 set. DNSSEC uses trusted chains of SIG and KEY records to determine 210 what data is authenticated, the AA bit is almost irrelevant. However 211 DNSSEC aware servers must still correctly set the AA bit in responses 212 to enable correct operation with servers that are not security aware 213 (almost all currently). 215 Note that, glue excluded, it is impossible for data from two primary 216 zone files, two secondary zones (data from zone transfers) or data 217 from primary and secondary zones to ever conflict. Where glue for 218 the same name exists in multiple zones, and differs in value, the 219 nameserver should select data from a primary zone file in preference 220 to secondary, but otherwise may choose any single set of such data. 221 Choosing that which appears to come from a source nearer the 222 authoritative data source may make sense where that can be 223 determined. Choosing primary data over secondary allows the source 224 of incorrect glue data to be discovered more readily, when such data 225 does exist. 227 "Glue" above includes any record in a zone file that is not properly 228 part of that zone, including nameserver records of delegated sub- 229 zones (NS records), address records that accompany those NS records 230 (A, AAAA, etc), and any other stray data that might appear. 232 4.4. Sending RRSets (reprise) 234 A Resource Record Set should only be included once in any DNS reply. 235 It may occur in any of the Answer, Authority, or Additional 236 Information sections, as required, however should not be repeated in 237 the same, or any other, section, except where explicitly required by 238 a specification. For example, an AXFR response requires the SOA 239 record (always an RRSet containing a single RR) be both the first and 240 last record of the reply. Where duplicates are required this way, 241 the TTL transmitted in each case must be the same. 243 5. Zone Cuts 245 A "Zone" is a set of one, or usually, more, domains collected and 246 treated as a unit. A "Zone Cut" is the division between one zone and 247 another. A zone comprises some subset of the DNS tree, rooted at a 248 domain known as the "origin" of the zone. The origin domain itself, 249 and some, or all, of its sub-domains, form the zone. The existence 250 of a zone cut is indicated by the presence, in the zone, of a 251 NameServer (NS) record for any domain other than the origin of the 252 zone. 254 5.1. Zone authority 256 The authoritative servers for a zone are listed in the NS records for 257 the origin of the zone, which, along with a Start of Authority (SOA) 258 record are the mandatory records in every zone. Such a server is 259 authoritative for all resource records in a zone which are not in 260 another zone. The NS records that indicate a zone cut are the 261 property of the child zone created, as are any other records for the 262 origin of that child zone, or any sub-domains of it. A server for 263 the parent zone should not return authoritative answers for queries 264 related to names in a child zone, which includes the NS records at 265 the zone cut, unless it also happens to be a server for the child 266 zone of course. 268 Other than the DNSSEC cases mentioned immediately below, servers 269 should ignore data other than NS records, and necessary A records to 270 locate the servers listed in the NS records, that may happen to be 271 configured in a zone at a zone cut. 273 5.2. DNSSEC issues 275 The DNS security mechanisms [DNSSEC] complicate this somewhat, as 276 some of the new resource record types added are very unusual when 277 compared with other DNS RRs. In particular the NXT ("next") RR type 278 contains information about which names exist in a zone, and hence 279 which do not, and thus must necessarily relate to the zone in which 280 it exists. In fact, the same domain name may have different NXT 281 records in the parent zone and the child zone, and both are valid, 282 and are not an RRSet. 284 Since NXT records are intended to be automatically generated, rather 285 than configured by DNS operators, servers may, but are not required 286 to, retain all differing NXT records they receive regardless of the 287 rules in section 4.3. 289 To indicate that a subzone is insecure, securely, that is, from a 290 secure parent zone, DNSSEC requires that a KEY RR indicating that the 291 subzone is insecure, and the parent zone's authenticating SIG RR(s) 292 be present in the parent zone, as they by definition cannot be in the 293 subzone. Where a subzone is secure, the KEY and SIG can be 294 duplicated in both zone files, but should always be present in the 295 subzone. 297 Note that in none of these cases should a server for the parent zone, 298 not also being a server for the subzone, set the AA bit in any 299 response for a label at a zone cut. 301 6. Naming issues 303 It has sometimes been inferred from some sections of the DNS 304 specification [RFC1034, RFC1035] that a host, or perhaps an interface 305 of a host, is permitted exactly one authoritative, or official, name, 306 called the canonical name. There is no such requirement in the DNS. 308 6.1. CNAME records 310 The DNS CNAME ("canonical name") record exists to provide the 311 canonical name associated with an alias name. There may be only one 312 such canonical name for any one alias. That name should generally be 313 a name that exists elsewhere in the DNS, though some applications for 314 aliases with no accompanying canonical name exist. An alias name 315 (label of a CNAME record) may, if DNSSEC is in use, have SIG, NXT, 316 and KEY RRs, but may have no other data. That is, for any label in 317 the DNS (any domain name) exactly one of the following is true: 319 + one CNAME record exists, optionally accompanied by SIG, NXT, and 320 KEY RRs, 321 + other records exist, possibly many records, none of them being 322 CNAME records 323 + the name does not exist at all. 325 If the canonical name associated with an alias does not exist, a 326 lookup of the alias seeking anything but one of the CNAME, SIG, NXT, 327 or KEY RR (or the pseudo-type ANY) should indicate that the name does 328 not exist, just as if the alias itself did not exist. A CNAME (or 329 ANY) type lookup should return the CNAME RR itself. Lookups for SIG, 330 NXT or KEY records should return any such associated RR's that the 331 alias may own (as would an ANY lookup). 333 6.1.1. CNAME terminology 335 It has been traditional to refer to the label of a CNAME record as "a 336 CNAME". This is unfortunate, as "CNAME" is an abbreviation of 337 "canonical name", and the label of a CNAME record is most certainly 338 not a canonical name. It is, however, an entrenched usage, care must 339 therefore be taken to be very clear whether the label, or the value 340 (the canonical name) of a CNAME resource record is intended. In this 341 document, the label of a CNAME resource record will always be 342 referred to as an alias. 344 6.2. PTR records 346 Confusion about canonical names has lead to a belief that a PTR 347 record should have exactly one RR in its RRSet. This is incorrect, 348 the relevant section of RFC1034 (section 3.6.2) indicates that the 349 value of a PTR record should be a canonical name. That is, it should 350 not be an alias. There is no implication in that section that only 351 one PTR record is permitted for a name, and no such restriction 352 should be inferred. 354 6.3. MX and NS records 356 The domain name used as the value of a NS resource record, or part of 357 the value of a MX resource record should not be an alias. Not only 358 is the specification quite clear on this point, but using an alias in 359 either of these positions neither works as well as might be hoped, 360 nor well fulfills the ambition that may have led to this approach. 362 Searching for either NS or MX records causes "additional section 363 processing" in which address records associated with the value of the 364 record sought are appended to the answer. This helps avoid needless 365 extra queries which are easily anticipated when the first was made. 367 Additional section processing does not include CNAME records, let 368 alone the address records that may be associated with the canonical 369 name derived from the alias. Thus, if an alias is used as the value 370 of an NS or MX record, no address will be returned together with the 371 NS or MX value. This can cause extra queries, and extra network 372 burden, on every query, that could have been trivially avoided by 373 resolving the alias and placing the canonical name directly in the 374 affected record just once when it was updated or installed. In some 375 particular hard cases the lack of the additional section address 376 records in the results of a NS lookup can actually cause the request 377 to fail. 379 7. Name syntax 381 Occasionally it is assumed that the Domain Name System serves only 382 the purpose of mapping Internet host names to data, and mapping 383 Internet addresses to host names. This is not correct, the DNS is a 384 general (if somewhat limited) hierarchical database, and can store 385 almost any kind of data, for almost any purpose. 387 The DNS itself places only one restriction upon the particular labels 388 that can be used to identify resource records. That one restriction 389 relates to the length of the label and the full name. Any one label 390 is limited to 63 octets, and a full name is limited to 255 octets 391 (including the separators). That restriction aside, any binary 392 string whatever can be used as the label of any resource record, and 393 as the value of one of the records that includes a domain name as 394 some or all of its value (SOA, NS, MX, PTR, CNAME, SRV, and any 395 others that may be added). Implementations of the DNS protocols must 396 not place any restrictions on the labels that can be used. 398 Note however, that the various applications that make use of DNS data 399 can have restrictions imposed upon what particular data is acceptable 400 in their environment. For example, that any binary label can have an 401 MX record does not imply that any binary name can be used as the host 402 part of an e-mail address. Clients of the DNS can impose whatever 403 restrictions are appropriate to their circumstances to the values 404 they use as keys for DNS lookup requests, and to the values returned 405 by the DNS. 407 See also [RFC1123] section 6.1.3.5. 409 8. Security Considerations 411 This document does not consider security. 413 In particular, nothing in section 3 is any way related to, or useful 414 for, any security related purposes. 416 Section 4.3.1 is also not related to security. Security of DNS data 417 will be obtained by the Secure DNS [DNSSEC], which is orthogonal to 418 this memo. 420 It is not believed that anything in this document adds to any 421 security issues that may exist with the DNS, nor does it do anything 422 to lessen them. 424 9. References 426 [RFC1034] Domain Names - Concepts and Facilities, (STD 13) 427 P. Mockapetris, ISI, November 1987. 429 [RFC1035] Domain Names - Implementation and Specification (STD 13) 430 P. Mockapetris, ISI, November 1987 432 [RFC1123] Requirements for Internet hosts - application and support, 433 (STD 3) R. Braden, January 1989 435 [RFC1700] Assigned Numbers (STD 2) 436 J. Reynolds, J. Postel, October 1994. 438 [DNSSEC] Domain Name System Security Extensions, 439 D. E. Eastlake, 3rd, C. W. Kaufman, 440 Work in Progress (soon to be an RFC), August 1996. 442 10. Acknowledgements 444 This memo arose from discussions in the DNSIND working group of the 445 IETF in 1995 and 1996, the members of that working group are largely 446 responsible for the ideas captured herein. Particular thanks to 447 Donald E. Eastlake, 3rd, for assistance with the DNSSEC issues in 448 this document. 450 11. Authors' addresses 452 Robert Elz 453 Computer Science 454 University of Melbourne 455 Parkville, Victoria, 3052 456 Australia. 458 EMail: kre@munnari.OZ.AU 460 Randy Bush 461 RGnet, Inc. 462 10361 NE Sasquatch Lane 463 Bainbridge Island, Washington, 98110 464 United States. 466 EMail: randy@psg.com