idnits 2.17.00 (12 Aug 2021) /tmp/idnits7329/draft-ietf-dnsind-clarify-02.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 (November 1996) is 9317 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: May 1997 4 Randy Bush 5 RGnet, Inc. 7 November 1996 9 Clarifications to the DNS Specification 11 draft-ietf-dnsind-clarify-02.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 This draft considers some areas that have been identified as problems 34 with the specification of the Domain Name System, and proposes 35 remedies for the defects identified. Four separate issues are 36 considered: 37 + IP packet header address usage from multi-homed servers, 38 + TTLs in sets of records with the same name, class, and type, 39 + the issue of what is an authoritative, or canonical, name, 40 + and the issue of what makes a valid DNS label. 42 The first two of these are areas where the correct behaviour has been 43 somewhat unclear, we seek to rectify that. The other two are already 44 adequately specified, however the specifications seem to be sometimes 45 ignored. We seek to reinforce the existing specification. 47 2. Introduction 49 Several problem areas in the Domain Name System specification 50 [RFC1034, RFC1035] have been noted through the years [RFC1123]. This 51 draft addresses several additional problem areas. The issues here 52 are independent. Those issues are the question of which source 53 address a multi-homed DNS server should use when replying to a query, 54 the issue of differing TTLs for DNS records with the same label, 55 class and type, and the issue of canonical names, what they are, how 56 CNAME records relate, what names are legal in what parts of the DNS, 57 and what is the valid syntax of a DNS name. 59 Suggestions for clarifications to the DNS specification to avoid 60 these problems are made in this memo. The solutions proposed herein 61 are intended to stimulate discussion. It is possible that the sense 62 of either may be reversed before the next iteration of this draft, 63 but less likely now than it was before the previous version. 65 3. Server Reply Source Address Selection 67 Most, if not all, DNS clients, whether servers acting as clients for 68 the purposes of recursive query resolution, or resolvers, expect the 69 address from which a reply is received to be the same address as that 70 to which the query eliciting the reply was sent. This, along with 71 the identifier (ID) in the reply is used for disambiguating replies, 72 and filtering spurious responses. This may, or may not, have been 73 intended when the DNS was designed, but is now a fact of life. 75 Some multi-homed hosts running DNS servers fail to anticipate this 76 usage, and consequently send replies from the "wrong" source address, 77 causing the reply to be discarded by the client. 79 3.1. UDP Source Address Selection 81 To avoid these problems, servers when responding to queries using UDP 82 must cause the reply to be sent with the source address field in the 83 IP header set to the address that was in the destination address 84 field of the IP header of the packet containing the query causing the 85 response. If this would cause the response to be sent from an IP 86 address which is not permitted for this purpose, then the response 87 may be sent from any legal IP address allocated to the server. That 88 address should be chosen to maximise the possibility that the client 89 will be able to use it for further queries. Servers configured in 90 such a way that not all their addresses are equally reachable from 91 all potential clients need take particular care when responding to 92 queries sent to anycast, multicast, or similar, addresses. 94 3.2. Port Number Selection 96 Replies to all queries must be directed to the port from which they 97 were sent. With queries received via TCP this is an inherent part of 98 the transport protocol, for queries received by UDP the server must 99 take note of the source port and use that as the destination port in 100 the response. Replies should always be sent from the port to which 101 they were directed. Except in extraordinary circumstances, this will 102 be the well known port assigned for DNS queries [RFC1700]. 104 4. Resource Record Sets 106 Each DNS Resource Record (RR) each has a label, class, type, and 107 data. While it is meaningless for two records to ever have label, 108 class, type and data all equal (servers should suppress such 109 duplicates if encountered), it is possible for many record types to 110 exist with the same label class and type, but with different data. 111 Such a group of records is hereby defined to be a Resource Record Set 112 (RRSet). 114 4.1. Sending RRs from an RRSet 116 A query for a specific (or non-specific) label, class, and type, will 117 always return all records in the associated RRSet - whether that be 118 one or more RRs, or the response shall be marked as "truncated" if 119 the entire RRSet will not fit in the response. 121 4.2. TTLs of RRs in an RRSet 123 Resource Records also have a time to live (TTL). It is possible for 124 the RRs in an RRSet to have different TTLs, however no uses for this 125 have been found which cannot be better accomplished in other ways. 126 This can, however, cause partial replies (not marked "truncated") 127 from a caching server, where the TTLs for some but not all of the RRs 128 in the RRSet have expired. 130 Consequently the use of differing TTLs in an RRSet is hereby 131 deprecated, the TTLs of all RRs in an RRSet must be the same. 133 Should a client receive a response containing RRs from an RRSet with 134 differing TTLs, it should treat the RRs for all purposes as if all 135 TTLs in the RRSet had been set to the value of the lowest TTL in the 136 RRSet. 138 4.3. Receiving RRSets 140 Servers must never merge RRs from a response with RRs in their cache 141 to form an RRSet. If a response contains data which would form an 142 RRSet with data in a server's cache the server must either ignore the 143 RRs in the response, or use those to replace the existing RRSet in 144 the cache, as appropriate. Consequently the issue of TTLs varying 145 between the cache and a response does not cause concern, one will be 146 ignored. That is, one of the data sets is always incorrect if the 147 data from an answer differs from the data in the cache. The 148 challenge for the server is to determine which of the data sets is 149 correct, assuming that one is, and retain that, while ignoring the 150 other. Note that if a server receives an answer containing an RRSet 151 that is identical to that in its cache, with the possible exception 152 of the TTL value, it may update the TTL in its cache with the TTL of 153 the received answer. It should do this if the received answer would 154 be considered more authoritative (as discussed in the next section) 155 than the previously cached answer. 157 4.3.1. Ranking data 159 When considering whether to accept an RRSet in a reply, or retain an 160 RRSet already in its cache instead, a server should consider the 161 relative likely trustworthiness of the various data. That is, an 162 authoritative answer from a reply should replace cached data that had 163 been obtained from additional information in an earlier reply, but 164 additional information from a reply will be ignored if the cache 165 contains data from an authoritative answer or a zone file. 167 The accuracy of data available is assumed from its source. 168 Trustworthiness shall be, in order from most to least: 170 + Data from a primary zone file, other than glue data, 171 + Data from a zone transfer, other than glue, 172 + That from the answer section of an authoritative reply, 173 + Glue from a primary zone, or glue from a zone transfer, 174 + Data from the authority section of an authoritative answer, 175 + Data from the answer section of a non-authoritative answer, 176 + Additional information from an authoritative answer, 177 + Data from the authority section of a non-authoritative answer, 178 + Additional information from non-authoritative answers. 180 Where authenticated data has been received it shall be considered 181 more trustworthy than unauthenticated data of the same type. 183 Note that, glue excluded, it is impossible for data from two primary 184 zone files, two secondary zones (data from zone transfers) or data 185 from a primary and secondary zones to ever conflict. Wher for the 186 same name exists in such zones, and differs in value, the nameserver 187 should select data from a primary zone file in preference to 188 secondary, but otherwise may choose any single set of such data. 189 Choosing that which appears to come from a source nearer the 190 authoritative data source may make sense where that can be 191 determined. Choosing primary data over secondary allows the source 192 of incorrect glue data to be discovered more readily, when such data 193 does exist. 195 "Glue" above includes any record in a zone file that is not properly 196 part of that zone, including nameserver records of delegated sub- 197 zones (NS records), address records that accompany those NS records 198 (A, AAAA, etc), and any other stray data that might appear. 200 4.4. Sending RRSets (reprise) 202 A Resource Record Set should only be included once in any DNS reply. 203 It may occur in any of the Answer, Authority, or Additional 204 Information sections, as required, however should not be repeated in 205 the same, or any other, section, except where explicitly required by 206 a specification. For example, an AXFR response requires the SOA 207 record (always an RRSet containing a single RR) be both the first and 208 last record of the reply. Where duplicates are required this way, 209 the TTL transmitted in each case must be the same. 211 5. Naming issues 213 It has sometimes been inferred from some sections of the DNS 214 specification [RFC1034, RFC1035] that a host, or perhaps an interface 215 of a host, is permitted exactly one authoritative, or official, name, 216 called the canonical name. There is no such requirement in the DNS. 218 5.1. CNAME records 220 The DNS CNAME ("canonical name") record exists to provide the 221 canonical name associated with an alias name. There may be only one 222 such canonical name for any one alias. That name must be a name that 223 exists elsewhere in the DNS. The alias name must have no other data 224 in the DNS. That is, for any label in the DNS (any domain name) 225 exactly one of the following is true: 226 + one CNAME record exists 227 + other records exist, possibly many records, none of them being 228 CNAME records 229 + the name does not exist at all. 231 5.1.1. CNAME terminology 233 It has been traditional to refer to the label of a CNAME record as "a 234 CNAME". This is unfortunate, as "CNAME" is an abbreviation of 235 "canonical name", and the label of a CNAME record is most certainly 236 not a canonical name. It is, however, an entrenched usage, care must 237 therefore be taken to be very clear whether the label, or the value 238 (the canonical name) of a CNAME resource record is intended. In this 239 document, the label of a CNAME resource record will always be 240 referred to as an alias. 242 5.2. PTR records 244 Confusion about canonical names has lead to a belief that a PTR 245 record should have exactly one RR in its RRSet. This is incorrect, 246 the relevant section of RFC1034 (section 3.6.2) indicates that the 247 value of a PTR record should be a canonical name. That is, it should 248 not be an alias. There is no implication in that section that only 249 one PTR record is permitted for a name, and no such restriction 250 should be inferred. 252 5.3. MX and NS records 254 The domain name used as the value of a NS resource record, or part of 255 the value of a MX resource record should not be an alias. Not only 256 is the specification quite clear on this point, but using an alias in 257 either of these positions neither works as well as might be hoped, 258 nor well fulfills the ambition that may have led to this approach. 260 Searching for either NS or MX records causes "additional section 261 processing" in which address records associated with the value of the 262 record sought are appended to the answer. This helps avoid needless 263 extra queries which are easily anticipated when the first was made. 265 Additional section processing does not include CNAME records, let 266 alone the address records that may be associated with the canonical 267 name derived from the alias. Thus, if an alias is used as the value 268 of an NS or MX record, no address will be returned together with the 269 NS or MX value. This can cause extra queries, and extra network 270 burden, on every query, that could have been trivially avoided by 271 resolving the alias and placing the canonical name directly in the 272 affected record just once when it was updated or installed. In some 273 particular hard cases the lack of the additional section address 274 records in the results of a NS lookup can actually cause the request 275 to fail. 277 6. Name syntax 279 Occasionally it is assumed that the Domain Name System serves only 280 the purpose of mapping Internet host names to data, and mapping 281 Internet addresses to host names. This is not correct, the DNS is a 282 general (if somewhat limited) hierarchical database, and can store 283 almost any kind of data, for almost any purpose. 285 The DNS itself places only one restriction upon the particular labels 286 that can be used to identify resource records. That one restriction 287 relates to the length of the label and the full name. Any one label 288 is limited to 63 octets, and a full name is limited to 255 octets 289 (including the separators). That restriction aside, any binary 290 string whatever can be used as the label of any resource record, and 291 as the value of one of the records that includes a domain name as 292 some or all of its value (SOA, NS, MX, PTR, CNAME, SRV, and any 293 others that may be added). Implementations of the DNS protocols must 294 not place any restrictions on the labels that can be used. 296 Note however, that the various applications that make use of DNS data 297 can have restrictions imposed upon what particular data is acceptable 298 in their environment. For example, that any binary label can have an 299 MX record does not imply that any binary name can be used as the host 300 part of an e-mail address. Clients of the DNS can impose whatever 301 restrictions are appropriate to their circumstances to the values 302 they use as keys for DNS lookup requests, and to the values returned 303 by the DNS. 305 See also [RFC1123] section 6.1.3.5. 307 7. Security Considerations 309 This document does not consider security. 311 In particular, nothing in section 3 is any way related to, or useful 312 for, any security related purposes. 314 Section 4.3.1 is also not related to security. Security of DNS data 315 will be obtained by the Secure DNS [DNSSEC], which is orthogonal to 316 this memo. 318 It is not believed that anything in this document adds to any 319 security issues that may exist with the DNS, nor does it do anything 320 to lessen them. 322 8. References 324 [RFC1034] Domain Names - Concepts and Facilities, (STD 13) 325 P. Mockapetris, ISI, November 1987. 327 [RFC1035] Domain Names - Implementation and Specification (STD 13) 328 P. Mockapetris, ISI, November 1987 330 [RFC1123] Requirements for Internet hosts - application and support, 331 (STD 3) R. Braden, January 1989 333 [RFC1700] Assigned Numbers (STD 2) 334 J. Reynolds, J. Postel, October 1994. 336 [DNSSEC] Domain Name System Security Extensions, 337 D. E. Eastlake, 3rd, C. W. Kaufman, 338 Work in Progress (soon to be an RFC), August 1996. 340 9. Acknowledgements 342 This memo arose from discussions in the DNSIND working group of the 343 IETF in 1995 and 1996, the members of that working group are largely 344 responsible for the ideas captured herein. 346 10. Authors' addresses 348 Robert Elz 349 Computer Science 350 University of Melbourne 351 Parkville, Victoria, 3052 352 Australia. 354 EMail: kre@munnari.OZ.AU 356 Randy Bush 357 RGnet, Inc. 358 10361 NE Sasquatch Lane 359 Bainbridge Island, Washington, 98110 360 United States. 362 EMail: randy@psg.com