idnits 2.17.1 draft-ietf-dnsind-clarify-08.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 (2024-03-29) 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) 2024 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 94: '...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 (May 1997) is 9815 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: November 1997 5 Randy Bush 6 RGnet, Inc. 8 May 1997 10 Clarifications to the DNS Specification 12 draft-ietf-dnsind-clarify-08.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. Eight separate issues are 37 considered: 39 + IP packet header address usage from multi-homed servers, 40 + TTLs in sets of records with the same name, class, and type, 41 + correct handling of zone cuts, 42 + three minor issues concerning SOA records and their use, 43 + the precise definition of the Time to Live (TTL) 44 + Use of the TC (truncated) header bit 45 + the issue of what is an authoritative, or canonical, name, 46 + and the issue of what makes a valid DNS label. 48 The first six of these are areas where the correct behaviour has been 49 somewhat unclear, we seek to rectify that. The other two are already 50 adequately specified, however the specifications seem to be sometimes 51 ignored. We seek to reinforce the existing specifications. 53 This versions adds one new minor clarification, to the definition and 54 use of the SOA.mname field, and some editorial cleanups. This 55 paragraph will be deleted from the final version of this document. 57 Contents 59 1 Abstract ................................................... 1 60 2 Introduction ............................................... 2 61 3 Terminology ................................................ 3 62 4 Server Reply Source Address Selection ...................... 3 63 5 Resource Record Sets ....................................... 4 64 6 Zone Cuts .................................................. 8 65 7 SOA RRs .................................................... 10 66 8 Time to Live (TTL) ......................................... 10 67 9 The TC (truncated) header bit .............................. 11 68 10 Naming issues .............................................. 11 69 11 Name syntax ................................................ 13 70 12 Security Considerations .................................... 14 71 13 References ................................................. 14 72 14 Acknowledgements ........................................... 15 73 15 Authors' addresses ......................................... 15 75 2. Introduction 77 Several problem areas in the Domain Name System specification 78 [RFC1034, RFC1035] have been noted through the years [RFC1123]. This 79 draft addresses several additional problem areas. The issues here 80 are independent. Those issues are the question of which source 81 address a multi-homed DNS server should use when replying to a query, 82 the issue of differing TTLs for DNS records with the same label, 83 class and type, and the issue of canonical names, what they are, how 84 CNAME records relate, what names are legal in what parts of the DNS, 85 and what is the valid syntax of a DNS name. 87 Clarifications to the DNS specification to avoid these problems are 88 made in this memo. A minor ambiguity in RFC1034 concerned with SOA 89 records is also corrected, as is one in the definition of the TTL 90 (Time To Live) and some possible confusion in use of the TC bit. 92 3. Terminology 94 This memo does not use the oft used expressions MUST, SHOULD, MAY, or 95 their negative forms. In some sections it may seem that a 96 specification is worded mildly, and hence some may infer that the 97 specification is optional. That is not correct. Anywhere that this 98 memo suggests that some action should be carried out, or must be 99 carried out, or that some behaviour is acceptable, or not, that is to 100 be considered as a fundamental aspect of this specification, 101 regardless of the specific words used. If some behaviour or action 102 is truly optional, that will be clearly specified by the text. 104 4. Server Reply Source Address Selection 106 Most, if not all, DNS clients, expect the address from which a reply 107 is received to be the same address as that to which the query 108 eliciting the reply was sent. This is true for servers acting as 109 clients for the purposes of recursive query resolution, as well as 110 simple resolver clients. The address, along with the identifier (ID) 111 in the reply is used for disambiguating replies, and filtering 112 spurious responses. This may, or may not, have been intended when 113 the DNS was designed, but is now a fact of life. 115 Some multi-homed hosts running DNS servers generate a reply using a 116 source address that is not the same as the destination address from 117 the client's request packet. Such replies will be discarded by the 118 client because the source address of the reply does not match that of 119 a host to which the client sent the original request. That is, it 120 appears to be an unsolicited response. 122 4.1. UDP Source Address Selection 124 To avoid these problems, servers when responding to queries using UDP 125 must cause the reply to be sent with the source address field in the 126 IP header set to the address that was in the destination address 127 field of the IP header of the packet containing the query causing the 128 response. If this would cause the response to be sent from an IP 129 address that is not permitted for this purpose, then the response may 130 be sent from any legal IP address allocated to the server. That 131 address should be chosen to maximise the possibility that the client 132 will be able to use it for further queries. Servers configured in 133 such a way that not all their addresses are equally reachable from 134 all potential clients need take particular care when responding to 135 queries sent to anycast, multicast, or similar, addresses. 137 4.2. Port Number Selection 139 Replies to all queries must be directed to the port from which they 140 were sent. When queries are received via TCP this is an inherent 141 part of the transport protocol. For queries received by UDP the 142 server must take note of the source port and use that as the 143 destination port in the response. Replies should always be sent from 144 the port to which they were directed. Except in extraordinary 145 circumstances, this will be the well known port assigned for DNS 146 queries [RFC1700]. 148 5. Resource Record Sets 150 Each DNS Resource Record (RR) has a label, class, type, and data. It 151 is meaningless for two records to ever have label, class, type and 152 data all equal - servers should suppress such duplicates if 153 encountered. It is however possible for most record types to exist 154 with the same label, class and type, but with different data. Such a 155 group of records is hereby defined to be a Resource Record Set 156 (RRSet). 158 5.1. Sending RRs from an RRSet 160 A query for a specific (or non-specific) label, class, and type, will 161 always return all records in the associated RRSet - whether that be 162 one or more RRs. The response must be marked as "truncated" if the 163 entire RRSet will not fit in the response. 165 5.2. TTLs of RRs in an RRSet 167 Resource Records also have a time to live (TTL). It is possible for 168 the RRs in an RRSet to have different TTLs. No uses for this have 169 been found that cannot be better accomplished in other ways. This 170 can, however, cause partial replies (not marked "truncated") from a 171 caching server, where the TTLs for some but not all the RRs in the 172 RRSet have expired. 174 Consequently the use of differing TTLs in an RRSet is hereby 175 deprecated, the TTLs of all RRs in an RRSet must be the same. 177 Should a client receive a response containing RRs from an RRSet with 178 differing TTLs, it should treat this as an error. If the RRSet 179 concerned is from a non-authoritative source for this data, the 180 client should simply ignore the RRSet, and if the values were 181 required, seek to acquire them from an authoritative source. Clients 182 that are configured to send all queries to one, or more, particular 183 servers should treat those servers as authoritative for this purpose. 184 Should an authoritative source send such a malformed RRSet, the 185 client should treat the RRs for all purposes as if all TTLs in the 186 RRSet had been set to the value of the lowest TTL in the RRSet. In 187 no case may a server send an RRSet with TTLs not all equal. 189 5.3. DNSSEC Special Cases 191 Two of the record types added by DNS Security (DNSSEC) [RFC2065] 192 require special attention when considering the formation of Resource 193 Record Sets. Those are the SIG and NXT records. It should be noted 194 that DNS Security is still very new, and there is, as yet, little 195 experience with it. Readers should be prepared for the information 196 related to DNSSEC contained in this document to become outdated as 197 the DNS Security specification matures. 199 5.3.1. SIG records and RRSets 201 A SIG record provides signature (validation) data for another RRSet 202 in the DNS. Where a zone has been signed, every RRSet in the zone 203 will have had a SIG record associated with it. The data type of the 204 RRSet is included in the data of the SIG RR, to indicate with which 205 particular RRSet this SIG record is associated. Were the rules above 206 applied, whenever a SIG record was included with a response to 207 validate that response, the SIG records for all other RRSets 208 associated with the appropriate node would also need to be included. 209 In some cases, this could be a very large number of records, not 210 helped by their being rather large RRs. 212 Thus, it is specifically permitted for the authority section to 213 contain only those SIG RRs with the "type covered" field equal to the 214 type field of an answer being returned. However, where SIG records 215 are being returned in the answer section, in response to a query for 216 SIG records, or a query for all records associated with a name 217 (type=ANY) the entire SIG RRSet must be included, as for any other RR 218 type. 220 Servers that receive responses containing SIG records in the 221 authority section, or (probably incorrectly) as additional data, must 222 understand that the entire RRSet has almost certainly not been 223 included. Thus, they must not cache that SIG record in a way that 224 would permit it to be returned should a query for SIG records be 225 received at that server. RFC2065 actually requires that SIG queries 226 be directed only to authoritative servers to avoid the problems that 227 could be caused here, and while servers exist that do not understand 228 the special properties of SIG records, this will remain necessary. 229 However, careful design of SIG record processing in new 230 implementations should permit this restriction to be relaxed in the 231 future, so resolvers do not need to treat SIG record queries 232 specially. 234 It has been occasionally stated that a received request for a SIG 235 record should be forwarded to an authoritative server, rather than 236 being answered from data in the cache. This is not necessary - a 237 server that has the knowledge of SIG as a special case for processing 238 this way would be better to correctly cache SIG records, taking into 239 account their characteristics. Then the server can determine when it 240 is safe to reply from the cache, and when the answer is not available 241 and the query must be forwarded. 243 5.3.2. NXT RRs 245 Next Resource Records (NXT) are even more peculiar. There will only 246 ever be one NXT record in a zone for a particular label, so 247 superficially, the RRSet problem is trivial. However, at a zone cut, 248 both the parent zone, and the child zone (superzone and subzone in 249 RFC2065 terminology) will have NXT records for the same name. Those 250 two NXT records do not form an RRSet, even where both zones are 251 housed at the same server. NXT RRSets always contain just a single 252 RR. Where both NXT records are visible, two RRSets exist. However, 253 servers are not required to treat this as a special case when 254 receiving NXT records in a response. They may elect to notice the 255 existence of two different NXT RRSets, and treat that as they would 256 two different RRSets of any other type. That is, cache one, and 257 ignore the other. Security aware servers will need to correctly 258 process the NXT record in the received response though. 260 5.4. Receiving RRSets 262 Servers must never merge RRs from a response with RRs in their cache 263 to form an RRSet. If a response contains data that would form an 264 RRSet with data in a server's cache the server must either ignore the 265 RRs in the response, or discard the entire RRSet currently in the 266 cache, as appropriate. Consequently the issue of TTLs varying 267 between the cache and a response does not cause concern, one will be 268 ignored. That is, one of the data sets is always incorrect if the 269 data from an answer differs from the data in the cache. The 270 challenge for the server is to determine which of the data sets is 271 correct, if one is, and retain that, while ignoring the other. Note 272 that if a server receives an answer containing an RRSet that is 273 identical to that in its cache, with the possible exception of the 274 TTL value, it may, optionally, update the TTL in its cache with the 275 TTL of the received answer. It should do this if the received answer 276 would be considered more authoritative (as discussed in the next 277 section) than the previously cached answer. 279 5.4.1. Ranking data 281 When considering whether to accept an RRSet in a reply, or retain an 282 RRSet already in its cache instead, a server should consider the 283 relative likely trustworthiness of the various data. An 284 authoritative answer from a reply should replace cached data that had 285 been obtained from additional information in an earlier reply. 286 However additional information from a reply will be ignored if the 287 cache contains data from an authoritative answer or a zone file. 289 The accuracy of data available is assumed from its source. 290 Trustworthiness shall be, in order from most to least: 292 + Data from a primary zone file, other than glue data, 293 + Data from a zone transfer, other than glue, 294 + The authoritative data included in the answer section of an 295 authoritative reply. 296 + Data from the authority section of an authoritative answer, 297 + Glue from a primary zone, or glue from a zone transfer, 298 + Data from the answer section of a non-authoritative answer, and 299 non-authoritative data from the answer section of authoritative 300 answers, 301 + Additional information from an authoritative answer, 302 Data from the authority section of a non-authoritative answer, 303 Additional information from non-authoritative answers. 305 Note that the answer section of an authoritative answer normally 306 contains only authoritative data. However when the name sought is an 307 alias (see section 10.1.1) only the record describing that alias is 308 necessarily authoritative. Clients should assume that other records 309 may have come from the server's cache. Where authoritative answers 310 are required, the client should query again, using the canonical name 311 associated with the alias. 313 Unauthenticated RRs received and cached from the least trustworthy of 314 those groupings, that is data from the additional data section, and 315 data from the authority section of a non-authoritative answer, should 316 not be cached in such a way that they would ever be returned as 317 answers to a received query. They may be returned as additional 318 information where appropriate. Ignoring this would allow the 319 trustworthiness of relatively untrustworthy data to be increased 320 without cause or excuse. 322 When DNS security [RFC2065] is in use, and an authenticated reply has 323 been received and verified, the data thus authenticated shall be 324 considered more trustworthy than unauthenticated data of the same 325 type. Note that throughout this document, "authoritative" means a 326 reply with the AA bit set. DNSSEC uses trusted chains of SIG and KEY 327 records to determine the authenticity of data, the AA bit is almost 328 irrelevant. However DNSSEC aware servers must still correctly set 329 the AA bit in responses to enable correct operation with servers that 330 are not security aware (almost all currently). 332 Note that, glue excluded, it is impossible for data from two 333 correctly configured primary zone files, two correctly configured 334 secondary zones (data from zone transfers) or data from correctly 335 configured primary and secondary zones to ever conflict. Where glue 336 for the same name exists in multiple zones, and differs in value, the 337 nameserver should select data from a primary zone file in preference 338 to secondary, but otherwise may choose any single set of such data. 339 Choosing that which appears to come from a source nearer the 340 authoritative data source may make sense where that can be 341 determined. Choosing primary data over secondary allows the source 342 of incorrect glue data to be discovered more readily, when a problem 343 with such data exists. Where a server can detect from two zone files 344 that one or more are incorrectly configured, so as to create 345 conflicts, it should refuse to load the zones determined to be 346 erroneous, and issue suitable diagnostics. 348 "Glue" above includes any record in a zone file that is not properly 349 part of that zone, including nameserver records of delegated sub- 350 zones (NS records), address records that accompany those NS records 351 (A, AAAA, etc), and any other stray data that might appear. 353 5.5. Sending RRSets (reprise) 355 A Resource Record Set should only be included once in any DNS reply. 356 It may occur in any of the Answer, Authority, or Additional 357 Information sections, as required. However it should not be repeated 358 in the same, or any other, section, except where explicitly required 359 by a specification. For example, an AXFR response requires the SOA 360 record (always an RRSet containing a single RR) be both the first and 361 last record of the reply. Where duplicates are required this way, 362 the TTL transmitted in each case must be the same. 364 6. Zone Cuts 366 The DNS tree is divided into "zones", which are collections of 367 domains that are treated as a unit for certain management purposes. 368 Zones are delimited by "zone cuts". Each zone cut separates a 369 "child" zone (below the cut) from a "parent" zone (above the cut). 370 The domain name that appears at the top of a zone (just below the cut 371 that separates the zone from its parent) is called the zone's 372 "origin". The name of the zone is the same as the name of the domain 373 at the zone's origin. Each zone comprises that subset of the DNS 374 tree that is at or below the zone's origin, and that is above the 375 cuts that separate the zone from its children (if any). The 376 existence of a zone cut is indicated in the parent zone by the 377 existence of NS records specifying the origin of the child zone. A 378 child zone does not contain any explicit reference to its parent. 380 6.1. Zone authority 382 The authoritative servers for a zone are enumerated in the NS records 383 for the origin of the zone, which, along with a Start of Authority 384 (SOA) record are the mandatory records in every zone. Such a server 385 is authoritative for all resource records in a zone that are not in 386 another zone. The NS records that indicate a zone cut are the 387 property of the child zone created, as are any other records for the 388 origin of that child zone, or any sub-domains of it. A server for a 389 zone should not return authoritative answers for queries related to 390 names in another zone, which includes the NS, and perhaps A, records 391 at a zone cut, unless it also happens to be a server for the other 392 zone. 394 Other than the DNSSEC cases mentioned immediately below, servers 395 should ignore data other than NS records, and necessary A records to 396 locate the servers listed in the NS records, that may happen to be 397 configured in a zone at a zone cut. 399 6.2. DNSSEC issues 401 The DNS security mechanisms [RFC2065] complicate this somewhat, as 402 some of the new resource record types added are very unusual when 403 compared with other DNS RRs. In particular the NXT ("next") RR type 404 contains information about which names exist in a zone, and hence 405 which do not, and thus must necessarily relate to the zone in which 406 it exists. The same domain name may have different NXT records in 407 the parent zone and the child zone, and both are valid, and are not 408 an RRSet. See also section 5.3.2. 410 Since NXT records are intended to be automatically generated, rather 411 than configured by DNS operators, servers may, but are not required 412 to, retain all differing NXT records they receive regardless of the 413 rules in section 5.4. 415 For a secure parent zone to securely indicate that a subzone is 416 insecure, DNSSEC requires that a KEY RR indicating that the subzone 417 is insecure, and the parent zone's authenticating SIG RR(s) be 418 present in the parent zone, as they by definition cannot be in the 419 subzone. Where a subzone is secure, the KEY and SIG records will be 420 present, and authoritative, in that zone, but should also always be 421 present in the parent zone (if secure). 423 Note that in none of these cases should a server for the parent zone, 424 not also being a server for the subzone, set the AA bit in any 425 response for a label at a zone cut. 427 7. SOA RRs 429 Three minor issues concerning the Start of Zone of Authority (SOA) 430 Resource Record need some clarification. 432 7.1. Placement of SOA RRs in authoritative answers 434 RFC1034, in section 3.7, indicates that the authority section of an 435 authoritative answer may contain the SOA record for the zone from 436 which the answer was obtained. When discussing negative caching, 437 RFC1034 section 4.3.4 refers to this technique but mentions the 438 additional section of the response. The former is correct, as is 439 implied by the example shown in section 6.2.5 of RFC1034. SOA 440 records, if added, are to be placed in the authority section. 442 7.2. TTLs on SOA RRs 444 It may be observed that in section 3.2.1 of RFC1035, which defines 445 the format of a Resource Record, that the definition of the TTL field 446 contains a throw away line which states that the TTL of an SOA record 447 should always be sent as zero to prevent caching. This is mentioned 448 nowhere else, and has not generally been implemented. 449 Implementations should not assume that SOA records will have a TTL of 450 zero, nor are they required to send SOA records with a TTL of zero. 452 7.3. The SOA.MNAME field 454 It is quite clear in the specifications, yet seems to have been 455 widely ignored, that the MNAME field of the SOA record should contain 456 the name of the primary (master) server for the zone identified by 457 the SOA. It should not contain the name of the zone itself. That 458 information would be useless, as to discover it, one needs to start 459 with the domain name of the SOA record - that is the name of the 460 zone. 462 8. Time to Live (TTL) 464 The definition of values appropriate to the TTL field in STD 13 is 465 not as clear as it could be, with respect to how many significant 466 bits exist, and whether the value is signed or unsigned. It is 467 hereby specified that a TTL value is an unsigned number, with a 468 minimum value of 0, and a maximum value of 2147483647. That is, a 469 maximum of 2^31 - 1. When transmitted, this value shall be encoded 470 in the less significant 31 bits of the 32 bit TTL field, with the 471 most significant, or sign, bit set to zero. 473 Implementations should treat TTL values received with the most 474 significant bit set as if the entire value received was zero. 476 Implementations are always free to place an upper bound on any TTL 477 received, and treat any larger values as if they were that upper 478 bound. The TTL specifies a maximum time to live, not a mandatory 479 time to live. 481 9. The TC (truncated) header bit 483 The TC bit should be set in responses only when an RRSet is required 484 as a part of the response, but could not be included in its entirety. 485 The TC bit should not be set merely because some extra information 486 could have been included, but there was insufficient room. This 487 includes the results of additional section processing. In such cases 488 the entire RRSet that will not fit in the response should be omitted, 489 and the reply sent as is, with the TC bit clear. If the recipient of 490 the reply needs the omitted data, it can construct a query for that 491 data and send that separately. 493 Where TC is set, the partial RRSet that would not completely fit may 494 be left in the response. When a DNS client receives a reply with TC 495 set, it should ignore that response, and query again, using a 496 mechanism, such as a TCP connection, that will permit larger replies. 498 10. Naming issues 500 It has sometimes been inferred from some sections of the DNS 501 specification [RFC1034, RFC1035] that a host, or perhaps an interface 502 of a host, is permitted exactly one authoritative, or official, name, 503 called the canonical name. There is no such requirement in the DNS. 505 10.1. CNAME resource records 507 The DNS CNAME ("canonical name") record exists to provide the 508 canonical name associated with an alias name. There may be only one 509 such canonical name for any one alias. That name should generally be 510 a name that exists elsewhere in the DNS, though there are some rare 511 applications for aliases with the accompanying canonical name 512 undefined in the DNS. An alias name (label of a CNAME record) may, 513 if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no 514 other data. That is, for any label in the DNS (any domain name) 515 exactly one of the following is true: 517 + one CNAME record exists, optionally accompanied by SIG, NXT, and 518 KEY RRs, 519 + one or more records exist, none being CNAME records, 520 + the name exists, but has no associated RRs of any type, 521 + the name does not exist at all. 523 10.1.1. CNAME terminology 525 It has been traditional to refer to the label of a CNAME record as "a 526 CNAME". This is unfortunate, as "CNAME" is an abbreviation of 527 "canonical name", and the label of a CNAME record is most certainly 528 not a canonical name. It is, however, an entrenched usage. Care 529 must therefore be taken to be very clear whether the label, or the 530 value (the canonical name) of a CNAME resource record is intended. 531 In this document, the label of a CNAME resource record will always be 532 referred to as an alias. 534 10.2. PTR records 536 Confusion about canonical names has lead to a belief that a PTR 537 record should have exactly one RR in its RRSet. This is incorrect, 538 the relevant section of RFC1034 (section 3.6.2) indicates that the 539 value of a PTR record should be a canonical name. That is, it should 540 not be an alias. There is no implication in that section that only 541 one PTR record is permitted for a name. No such restriction should 542 be inferred. 544 Note that while the value of a PTR record must not be an alias, there 545 is no requirement that the process of resolving a PTR record not 546 encounter any aliases. The label that is being looked up for a PTR 547 value might have a CNAME record. That is, it might be an alias. The 548 value of that CNAME RR, if not another alias, which it should not be, 549 will give the location where the PTR record is found. That record 550 gives the result of the PTR type lookup. This final result, the 551 value of the PTR RR, is the label which must not be an alias. 553 10.3. MX and NS records 555 The domain name used as the value of a NS resource record, or part of 556 the value of a MX resource record must not be an alias. Not only is 557 the specification clear on this point, but using an alias in either 558 of these positions neither works as well as might be hoped, nor well 559 fulfills the ambition that may have led to this approach. This 560 domain name must have as its value one or more address records. 561 Currently those will be A records, however in the future other record 562 types giving addressing information may be acceptable. It can also 563 have other RRs, but never a CNAME RR. 565 Searching for either NS or MX records causes "additional section 566 processing" in which address records associated with the value of the 567 record sought are appended to the answer. This helps avoid needless 568 extra queries that are easily anticipated when the first was made. 570 Additional section processing does not include CNAME records, let 571 alone the address records that may be associated with the canonical 572 name derived from the alias. Thus, if an alias is used as the value 573 of an NS or MX record, no address will be returned with the NS or MX 574 value. This can cause extra queries, and extra network burden, on 575 every query. It is trivial for the DNS administrator to avoid this 576 by resolving the alias and placing the canonical name directly in the 577 affected record just once when it is updated or installed. In some 578 particular hard cases the lack of the additional section address 579 records in the results of a NS lookup can cause the request to fail. 581 11. Name syntax 583 Occasionally it is assumed that the Domain Name System serves only 584 the purpose of mapping Internet host names to data, and mapping 585 Internet addresses to host names. This is not correct, the DNS is a 586 general (if somewhat limited) hierarchical database, and can store 587 almost any kind of data, for almost any purpose. 589 The DNS itself places only one restriction on the particular labels 590 that can be used to identify resource records. That one restriction 591 relates to the length of the label and the full name. The length of 592 any one label is limited to between 1 and 63 octets. A full domain 593 name is limited to 255 octets (including the separators). The zero 594 length full name is defined as representing the root of the DNS tree, 595 and is typically written and displayed as ".". Those restrictions 596 aside, any binary string whatever can be used as the label of any 597 resource record. Similarly, any binary string can serve as the value 598 of any record that includes a domain name as some or all of its value 599 (SOA, NS, MX, PTR, CNAME, and any others that may be added). 600 Implementations of the DNS protocols must not place any restrictions 601 on the labels that can be used. In particular, DNS servers must not 602 refuse to serve a zone because it contains labels that might not be 603 acceptable to some DNS client programs. A DNS server may be 604 configurable to issue warnings when loading, or even to refuse to 605 load, a primary zone containing labels that might be considered 606 questionable, however this should not happen by default. 608 Note however, that the various applications that make use of DNS data 609 can have restrictions imposed on what particular values are 610 acceptable in their environment. For example, that any binary label 611 can have an MX record does not imply that any binary name can be used 612 as the host part of an e-mail address. Clients of the DNS can impose 613 whatever restrictions are appropriate to their circumstances on the 614 values they use as keys for DNS lookup requests, and on the values 615 returned by the DNS. If the client has such restrictions, it is 616 solely responsible for validating the data from the DNS to ensure 617 that it conforms before it makes any use of that data. 619 See also [RFC1123] section 6.1.3.5. 621 12. Security Considerations 623 This document does not consider security. 625 In particular, nothing in section 4 is any way related to, or useful 626 for, any security related purposes. 628 Section 5.4.1 is also not related to security. Security of DNS data 629 will be obtained by the Secure DNS [RFC2065], which is mostly 630 orthogonal to this memo. 632 It is not believed that anything in this document adds to any 633 security issues that may exist with the DNS, nor does it do anything 634 to that will necessarily lessen them. Correct implementation of the 635 clarifications in this document might play some small part in 636 limiting the spread of non-malicious bad data in the DNS, but only 637 DNSSEC can help with deliberate attempts to subvert DNS data. 639 13. References 641 [RFC1034] Domain Names - Concepts and Facilities, (STD 13) 642 P. Mockapetris, ISI, November 1987. 644 [RFC1035] Domain Names - Implementation and Specification (STD 13) 645 P. Mockapetris, ISI, November 1987. 647 [RFC1123] Requirements for Internet hosts - application and support, 648 (STD 3) R. Braden, January 1989. 650 [RFC1700] Assigned Numbers (STD 2) 651 J. Reynolds, J. Postel, October 1994. 653 [RFC2065] Domain Name System Security Extensions, 654 D. E. Eastlake, 3rd, C. W. Kaufman, January 1997. 656 14. Acknowledgements 658 This memo arose from discussions in the DNSIND working group of the 659 IETF in 1995 and 1996, the members of that working group are largely 660 responsible for the ideas captured herein. Particular thanks to 661 Donald E. Eastlake, 3rd, and Olafur Gudmundsson, for help with the 662 DNSSEC issues in this document, and to John Gilmore for pointing out 663 where the clarifications were not necessarily clarifying. Bob Halley 664 suggested clarifying the placement of SOA records in authoritative 665 answers, and provided the references. Michael Patton, as usual, and 666 Mark Andrews, Alan Barrett and Stan Barber provided much assistance 667 with many details. Josh Littlefield helped make sure that the 668 clarifications didn't cause problems in some irritating corner cases. 670 15. Authors' addresses 672 Robert Elz 673 Computer Science 674 University of Melbourne 675 Parkville, Victoria, 3052 676 Australia. 678 EMail: kre@munnari.OZ.AU 680 Randy Bush 681 RGnet, Inc. 682 5147 Crystal Springs Drive NE 683 Bainbridge Island, Washington, 98110 684 United States. 686 EMail: randy@psg.com