idnits 2.17.00 (12 Aug 2021) /tmp/idnits7922/draft-ietf-dnsind-clarify-04.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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 85: '...used expressions MUST, SHOULD, MAY, or...' 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) ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Robert Elz 3 Internet Draft University of Melbourne 4 Expiration Date: July 1997 5 Randy Bush 6 RGnet, Inc. 8 January 1997 10 Clarifications to the DNS Specification 12 draft-ietf-dnsind-clarify-04.txt 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 1. Abstract 34 This draft considers some areas that have been identified as problems 35 with the specification of the Domain Name System, and proposes 36 remedies for the defects identified. Five separate issues are 37 considered: 38 + IP packet header address usage from multi-homed servers, 39 + TTLs in sets of records with the same name, class, and type, 40 + correct handling of zone cuts, 41 + the issue of what is an authoritative, or canonical, name, 42 + and the issue of what makes a valid DNS label. 44 The first three of these are areas where the correct behaviour has 45 been somewhat unclear, we seek to rectify that. The other two are 46 already adequately specified, however the specifications seem to be 47 sometimes ignored. We seek to reinforce the existing specifications. 49 This version contains corrections and clarifications as suggested on 50 the mailing list. Most notable is a change to the order of 51 preference of similar information from multiple sources. 53 Contents 55 1 Abstract ................................................... 1 56 2 Introduction ............................................... 2 57 3 Terminology ................................................ 2 58 4 Server Reply Source Address Selection ...................... 3 59 5 Resource Record Sets ....................................... 4 60 6 Zone Cuts .................................................. 6 61 7 Naming issues .............................................. 7 62 8 Name syntax ................................................ 9 63 9 Security Considerations .................................... 10 64 10 References ................................................. 10 65 11 Acknowledgements ........................................... 10 66 12 Authors' addresses ......................................... 11 68 2. Introduction 70 Several problem areas in the Domain Name System specification 71 [RFC1034, RFC1035] have been noted through the years [RFC1123]. This 72 draft addresses several additional problem areas. The issues here 73 are independent. Those issues are the question of which source 74 address a multi-homed DNS server should use when replying to a query, 75 the issue of differing TTLs for DNS records with the same label, 76 class and type, and the issue of canonical names, what they are, how 77 CNAME records relate, what names are legal in what parts of the DNS, 78 and what is the valid syntax of a DNS name. 80 Clarifications to the DNS specification to avoid these problems are 81 made in this memo. 83 3. Terminology 85 This memo does not use the oft used expressions MUST, SHOULD, MAY, or 86 their negative forms. In some sections it may seem that a 87 specification is worded mildly, and hence some may infer that the 88 specification is optional. That is not correct. Anywhere that this 89 memo suggests that some action should be carried out, or must be 90 carried out, or that some behaviour is acceptable, or not, that is to 91 be considered as a fundamental aspect of this specification, 92 regardless of the specific words used. If some behaviour or action 93 is truly optional, that will be clearly specified by the text. 95 4. Server Reply Source Address Selection 97 Most, if not all, DNS clients, whether servers acting as clients for 98 the purposes of recursive query resolution, or resolvers, expect the 99 address from which a reply is received to be the same address as that 100 to which the query eliciting the reply was sent. This, along with 101 the identifier (ID) in the reply is used for disambiguating replies, 102 and filtering spurious responses. This may, or may not, have been 103 intended when the DNS was designed, but is now a fact of life. 105 Some multi-homed hosts running DNS servers fail to expect this usage. 106 Consequently they send replies from the "wrong" source address, 107 causing the reply to be discarded by the client. 109 4.1. UDP Source Address Selection 111 To avoid these problems, servers when responding to queries using UDP 112 must cause the reply to be sent with the source address field in the 113 IP header set to the address that was in the destination address 114 field of the IP header of the packet containing the query causing the 115 response. If this would cause the response to be sent from an IP 116 address that is not permitted for this purpose, then the response may 117 be sent from any legal IP address allocated to the server. That 118 address should be chosen to maximise the possibility that the client 119 will be able to use it for further queries. Servers configured in 120 such a way that not all their addresses are equally reachable from 121 all potential clients need take particular care when responding to 122 queries sent to anycast, multicast, or similar, addresses. 124 4.2. Port Number Selection 126 Replies to all queries must be directed to the port from which they 127 were sent. When queries are received via TCP this is an inherent 128 part of the transport protocol. For queries received by UDP the 129 server must take note of the source port and use that as the 130 destination port in the response. Replies should always be sent from 131 the port to which they were directed. Except in extraordinary 132 circumstances, this will be the well known port assigned for DNS 133 queries [RFC1700]. 135 5. Resource Record Sets 137 Each DNS Resource Record (RR) has a label, class, type, and data. It 138 is meaningless for two records to ever have label, class, type and 139 data all equal - servers should suppress such duplicates if 140 encountered. It is however possible for most record types to exist 141 with the same label class and type, but with different data. Such a 142 group of records is hereby defined to be a Resource Record Set 143 (RRSet). 145 5.1. Sending RRs from an RRSet 147 A query for a specific (or non-specific) label, class, and type, will 148 always return all records in the associated RRSet - whether that be 149 one or more RRs. The response must be marked as "truncated" if the 150 entire RRSet will not fit in the response. 152 5.2. TTLs of RRs in an RRSet 154 Resource Records also have a time to live (TTL). It is possible for 155 the RRs in an RRSet to have different TTLs. No uses for this have 156 been found that cannot be better accomplished in other ways. This 157 can, however, cause partial replies (not marked "truncated") from a 158 caching server, where the TTLs for some but not all the RRs in the 159 RRSet have expired. 161 Consequently the use of differing TTLs in an RRSet is hereby 162 deprecated, the TTLs of all RRs in an RRSet must be the same. 164 Should a client receive a response containing RRs from an RRSet with 165 differing TTLs, it should treat the RRs for all purposes as if all 166 TTLs in the RRSet had been set to the value of the lowest TTL in the 167 RRSet. 169 5.3. Receiving RRSets 171 Servers must never merge RRs from a response with RRs in their cache 172 to form an RRSet. If a response contains data that would form an 173 RRSet with data in a server's cache the server must either ignore the 174 RRs in the response, or discard the entire the existing RRSet in the 175 cache, as appropriate. Consequently the issue of TTLs varying 176 between the cache and a response does not cause concern, one will be 177 ignored. That is, one of the data sets is always incorrect if the 178 data from an answer differs from the data in the cache. The 179 challenge for the server is to determine which of the data sets is 180 correct, if one is, and retain that, while ignoring the other. Note 181 that if a server receives an answer containing an RRSet that is 182 identical to that in its cache, with the possible exception of the 183 TTL value, it may, optionally, update the TTL in its cache with the 184 TTL of the received answer. It should do this if the received answer 185 would be considered more authoritative (as discussed in the next 186 section) than the previously cached answer. 188 5.3.1. Ranking data 190 When considering whether to accept an RRSet in a reply, or retain an 191 RRSet already in its cache instead, a server should consider the 192 relative likely trustworthiness of the various data. An 193 authoritative answer from a reply should replace cached data that had 194 been obtained from additional information in an earlier reply. 195 However additional information from a reply will be ignored if the 196 cache contains data from an authoritative answer or a zone file. 198 The accuracy of data available is assumed from its source. 199 Trustworthiness shall be, in order from most to least: 201 + Data from a primary zone file, other than glue data, 202 + Data from a zone transfer, other than glue, 203 + That from the answer section of an authoritative reply, 204 + Data from the authority section of an authoritative answer, 205 + Glue from a primary zone, or glue from a zone transfer, 206 + Data from the answer section of a non-authoritative answer, 207 + Additional information from an authoritative answer, 208 + Data from the authority section of a non-authoritative answer, 209 + Additional information from non-authoritative answers. 211 When DNS security [RFC2065] is in use, and an authenticated reply has 212 been received and verified, the data thus authenticated shall be 213 considered more trustworthy than unauthenticated data of the same 214 type. Note that throughout this document, "authoritative" means a 215 reply with the AA bit set. DNSSEC uses trusted chains of SIG and KEY 216 records to determine the authenticity of data, the AA bit is almost 217 irrelevant. However DNSSEC aware servers must still correctly set 218 the AA bit in responses to enable correct operation with servers that 219 are not security aware (almost all currently). 221 Note that, glue excluded, it is impossible for data from two primary 222 zone files, two secondary zones (data from zone transfers) or data 223 from primary and secondary zones to ever conflict. Where glue for 224 the same name exists in multiple zones, and differs in value, the 225 nameserver should select data from a primary zone file in preference 226 to secondary, but otherwise may choose any single set of such data. 227 Choosing that which appears to come from a source nearer the 228 authoritative data source may make sense where that can be 229 determined. Choosing primary data over secondary allows the source 230 of incorrect glue data to be discovered more readily, when a problem 231 with such data exists. 233 "Glue" above includes any record in a zone file that is not properly 234 part of that zone, including nameserver records of delegated sub- 235 zones (NS records), address records that accompany those NS records 236 (A, AAAA, etc), and any other stray data that might appear. 238 5.4. Sending RRSets (reprise) 240 A Resource Record Set should only be included once in any DNS reply. 241 It may occur in any of the Answer, Authority, or Additional 242 Information sections, as required, however should not be repeated in 243 the same, or any other, section, except where explicitly required by 244 a specification. For example, an AXFR response requires the SOA 245 record (always an RRSet containing a single RR) be both the first and 246 last record of the reply. Where duplicates are required this way, 247 the TTL transmitted in each case must be the same. 249 6. Zone Cuts 251 A "Zone" is a set of one, or usually, more, domains collected and 252 treated as a unit. A "Zone Cut" is the division between one zone and 253 another. A zone comprises some subset of the DNS tree, rooted at a 254 domain known as the "origin" of the zone. The origin domain itself, 255 and some, or all, of its sub-domains, form the zone. The existence 256 of a zone cut is indicated by the presence, in the zone, of a 257 NameServer (NS) record for any domain other than the origin of the 258 zone. 260 6.1. Zone authority 262 The authoritative servers for a zone are enumerated in the NS records 263 for the origin of the zone, which, along with a Start of Authority 264 (SOA) record are the mandatory records in every zone. Such a server 265 is authoritative for all resource records in a zone that are not in 266 another zone. The NS records that indicate a zone cut are the 267 property of the child zone created, as are any other records for the 268 origin of that child zone, or any sub-domains of it. A server for a 269 zone should not return authoritative answers for queries related to 270 names in another zone, which includes the NS, and perhaps A, records 271 at a zone cut, unless it also happens to be a server for the other 272 zone. 274 Other than the DNSSEC cases mentioned immediately below, servers 275 should ignore data other than NS records, and necessary A records to 276 locate the servers listed in the NS records, that may happen to be 277 configured in a zone at a zone cut. 279 6.2. DNSSEC issues 281 The DNS security mechanisms [RFC2065] complicate this somewhat, as 282 some of the new resource record types added are very unusual when 283 compared with other DNS RRs. In particular the NXT ("next") RR type 284 contains information about which names exist in a zone, and hence 285 which do not, and thus must necessarily relate to the zone in which 286 it exists. The same domain name may have different NXT records in 287 the parent zone and the child zone, and both are valid, and are not 288 an RRSet. 290 Since NXT records are intended to be automatically generated, rather 291 than configured by DNS operators, servers may, but are not required 292 to, retain all differing NXT records they receive regardless of the 293 rules in section 5.3. 295 For a secure parent zone to securely indicate that a subzone is 296 insecure, DNSSEC requires that a KEY RR indicating that the subzone 297 is insecure, and the parent zone's authenticating SIG RR(s) be 298 present in the parent zone, as they by definition cannot be in the 299 subzone. Where a subzone is secure, the KEY and SIG can be 300 duplicated in both zone files, but should always be present in the 301 subzone. 303 Note that in none of these cases should a server for the parent zone, 304 not also being a server for the subzone, set the AA bit in any 305 response for a label at a zone cut. 307 7. Naming issues 309 It has sometimes been inferred from some sections of the DNS 310 specification [RFC1034, RFC1035] that a host, or perhaps an interface 311 of a host, is permitted exactly one authoritative, or official, name, 312 called the canonical name. There is no such requirement in the DNS. 314 7.1. CNAME records 316 The DNS CNAME ("canonical name") record exists to provide the 317 canonical name associated with an alias name. There may be only one 318 such canonical name for any one alias. That name should generally be 319 a name that exists elsewhere in the DNS, though some applications for 320 aliases with no accompanying canonical name exist. An alias name 321 (label of a CNAME record) may, if DNSSEC is in use, have SIG, NXT, 322 and KEY RRs, but may have no other data. That is, for any label in 323 the DNS (any domain name) exactly one of the following is true: 325 + one CNAME record exists, optionally accompanied by SIG, NXT, and 326 KEY RRs, 327 + one or more records exist, none being CNAME records, 328 + the name does not exist at all. 330 7.1.1. CNAME terminology 332 It has been traditional to refer to the label of a CNAME record as "a 333 CNAME". This is unfortunate, as "CNAME" is an abbreviation of 334 "canonical name", and the label of a CNAME record is most certainly 335 not a canonical name. It is, however, an entrenched usage. Care 336 must therefore be taken to be very clear whether the label, or the 337 value (the canonical name) of a CNAME resource record is intended. 338 In this document, the label of a CNAME resource record will always be 339 referred to as an alias. 341 7.2. PTR records 343 Confusion about canonical names has lead to a belief that a PTR 344 record should have exactly one RR in its RRSet. This is incorrect, 345 the relevant section of RFC1034 (section 3.6.2) indicates that the 346 value of a PTR record should be a canonical name. That is, it should 347 not be an alias. There is no implication in that section that only 348 one PTR record is permitted for a name. No such restriction should 349 be inferred. 351 Note that while the value of a PTR record must not be an alias, there 352 is no requirement that the process of resolving a PTR record not 353 encounter any aliases. The label that is being looked up for a PTR 354 value might have a CNAME record. That is, it might be an alias. The 355 value of that CNAME RR, if not another alias, will give the location 356 where the PTR record is found. That record gives the result of the 357 PTR type lookup. This final result, the value of the PTR RR, is the 358 label which must not be an alias. 360 7.3. MX and NS records 362 The domain name used as the value of a NS resource record, or part of 363 the value of a MX resource record must not be an alias. Not only is 364 the specification clear on this point, but using an alias in either 365 of these positions neither works as well as might be hoped, nor well 366 fulfills the ambition that may have led to this approach. This 367 domain name must have as its value one or more address records. 368 Currently those will be A records, however in the future other record 369 types giving addressing information may be acceptable. It can also 370 have other RRs, but never a CNAME RR. 372 Searching for either NS or MX records causes "additional section 373 processing" in which address records associated with the value of the 374 record sought are appended to the answer. This helps avoid needless 375 extra queries that are easily anticipated when the first was made. 377 Additional section processing does not include CNAME records, let 378 alone the address records that may be associated with the canonical 379 name derived from the alias. Thus, if an alias is used as the value 380 of an NS or MX record, no address will be returned with the NS or MX 381 value. This can cause extra queries, and extra network burden, on 382 every query. It is trivial to avoid this by resolving the alias and 383 placing the canonical name directly in the affected record just once 384 when it is updated or installed. In some particular hard cases the 385 lack of the additional section address records in the results of a NS 386 lookup can cause the request to fail. 388 8. Name syntax 390 Occasionally it is assumed that the Domain Name System serves only 391 the purpose of mapping Internet host names to data, and mapping 392 Internet addresses to host names. This is not correct, the DNS is a 393 general (if somewhat limited) hierarchical database, and can store 394 almost any kind of data, for almost any purpose. 396 The DNS itself places only one restriction on the particular labels 397 that can be used to identify resource records. That one restriction 398 relates to the length of the label and the full name. The length of 399 any one label is limited to between 1 and 63 octets. A full domain 400 name is limited to 255 octets (including the separators). The zero 401 length full name is defined as representing the root of the DNS tree, 402 and is typically written and displayed as ".". Those restrictions 403 aside, any binary string whatever can be used as the label of any 404 resource record. Similarly, any binary string can serve as the value 405 of any record that includes a domain name as some or all of its value 406 (SOA, NS, MX, PTR, CNAME, and any others that may be added). 407 Implementations of the DNS protocols must not place any restrictions 408 on the labels that can be used. In particular, DNS servers must not 409 refuse to serve a zone because it contains labels that might not be 410 acceptable to some DNS client programs. A DNS server may be 411 configurable to issue warnings when loading, or even to refuse to 412 load, a primary zone containing labels that might be considered 413 questionable, however this should not happen by default. 415 Note however, that the various applications that make use of DNS data 416 can have restrictions imposed on what particular values are 417 acceptable in their environment. For example, that any binary label 418 can have an MX record does not imply that any binary name can be used 419 as the host part of an e-mail address. Clients of the DNS can impose 420 whatever restrictions are appropriate to their circumstances on the 421 values they use as keys for DNS lookup requests, and on the values 422 returned by the DNS. 424 See also [RFC1123] section 6.1.3.5. 426 9. Security Considerations 428 This document does not consider security. 430 In particular, nothing in section 4 is any way related to, or useful 431 for, any security related purposes. 433 Section 5.3.1 is also not related to security. Security of DNS data 434 will be obtained by the Secure DNS [RFC2065], which is mostly 435 orthogonal to this memo. 437 It is not believed that anything in this document adds to any 438 security issues that may exist with the DNS, nor does it do anything 439 to lessen them. 441 10. References 443 [RFC1034] Domain Names - Concepts and Facilities, (STD 13) 444 P. Mockapetris, ISI, November 1987. 446 [RFC1035] Domain Names - Implementation and Specification (STD 13) 447 P. Mockapetris, ISI, November 1987. 449 [RFC1123] Requirements for Internet hosts - application and support, 450 (STD 3) R. Braden, January 1989. 452 [RFC1700] Assigned Numbers (STD 2) 453 J. Reynolds, J. Postel, October 1994. 455 [RFC2065] Domain Name System Security Extensions, 456 D. E. Eastlake, 3rd, C. W. Kaufman, January 1997. 458 11. Acknowledgements 460 This memo arose from discussions in the DNSIND working group of the 461 IETF in 1995 and 1996, the members of that working group are largely 462 responsible for the ideas captured herein. Particular thanks to 463 Donald E. Eastlake, 3rd, for help with the DNSSEC issues in this 464 document, and to John Gilmore for pointing out where the 465 clarifications were not necessarily clarifying. 467 12. Authors' addresses 469 Robert Elz 470 Computer Science 471 University of Melbourne 472 Parkville, Victoria, 3052 473 Australia. 475 EMail: kre@munnari.OZ.AU 477 Randy Bush 478 RGnet, Inc. 479 10361 NE Sasquatch Lane 480 Bainbridge Island, Washington, 98110 481 United States. 483 EMail: randy@psg.com