7Network Working Group R. Elz
8Request for Comments: 2181 University of Melbourne
9Updates: 1034, 1035, 1123 R. Bush
10Category: Standards Track RGnet, Inc.
14 Clarifications to the DNS Specification
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
26 This document considers some areas that have been identified as
27 problems with the specification of the Domain Name System, and
28 proposes remedies for the defects identified. Eight separate issues
31 + IP packet header address usage from multi-homed servers,
32 + TTLs in sets of records with the same name, class, and type,
33 + correct handling of zone cuts,
34 + three minor issues concerning SOA records and their use,
35 + the precise definition of the Time to Live (TTL)
36 + Use of the TC (truncated) header bit
37 + the issue of what is an authoritative, or canonical, name,
38 + and the issue of what makes a valid DNS label.
40 The first six of these are areas where the correct behaviour has been
41 somewhat unclear, we seek to rectify that. The other two are already
42 adequately specified, however the specifications seem to be sometimes
43 ignored. We seek to reinforce the existing specifications.
58Elz & Bush Standards Track [Page 1]
60RFC 2181 Clarifications to the DNS Specification July 1997
67 1 Abstract ................................................... 1
68 2 Introduction ............................................... 2
69 3 Terminology ................................................ 3
70 4 Server Reply Source Address Selection ...................... 3
71 5 Resource Record Sets ....................................... 4
72 6 Zone Cuts .................................................. 8
73 7 SOA RRs .................................................... 10
74 8 Time to Live (TTL) ......................................... 10
75 9 The TC (truncated) header bit .............................. 11
76 10 Naming issues .............................................. 11
77 11 Name syntax ................................................ 13
78 12 Security Considerations .................................... 14
79 13 References ................................................. 14
80 14 Acknowledgements ........................................... 15
81 15 Authors' Addresses ......................................... 15
88 Several problem areas in the Domain Name System specification
89 [RFC1034, RFC1035] have been noted through the years [RFC1123]. This
90 document addresses several additional problem areas. The issues here
91 are independent. Those issues are the question of which source
92 address a multi-homed DNS server should use when replying to a query,
93 the issue of differing TTLs for DNS records with the same label,
94 class and type, and the issue of canonical names, what they are, how
95 CNAME records relate, what names are legal in what parts of the DNS,
96 and what is the valid syntax of a DNS name.
98 Clarifications to the DNS specification to avoid these problems are
99 made in this memo. A minor ambiguity in RFC1034 concerned with SOA
100 records is also corrected, as is one in the definition of the TTL
101 (Time To Live) and some possible confusion in use of the TC bit.
114Elz & Bush Standards Track [Page 2]
116RFC 2181 Clarifications to the DNS Specification July 1997
121 This memo does not use the oft used expressions MUST, SHOULD, MAY, or
122 their negative forms. In some sections it may seem that a
123 specification is worded mildly, and hence some may infer that the
124 specification is optional. That is not correct. Anywhere that this
125 memo suggests that some action should be carried out, or must be
126 carried out, or that some behaviour is acceptable, or not, that is to
127 be considered as a fundamental aspect of this specification,
128 regardless of the specific words used. If some behaviour or action
129 is truly optional, that will be clearly specified by the text.
1314. Server Reply Source Address Selection
133 Most, if not all, DNS clients, expect the address from which a reply
134 is received to be the same address as that to which the query
135 eliciting the reply was sent. This is true for servers acting as
136 clients for the purposes of recursive query resolution, as well as
137 simple resolver clients. The address, along with the identifier (ID)
138 in the reply is used for disambiguating replies, and filtering
139 spurious responses. This may, or may not, have been intended when
140 the DNS was designed, but is now a fact of life.
142 Some multi-homed hosts running DNS servers generate a reply using a
143 source address that is not the same as the destination address from
144 the client's request packet. Such replies will be discarded by the
145 client because the source address of the reply does not match that of
146 a host to which the client sent the original request. That is, it
147 appears to be an unsolicited response.
1494.1. UDP Source Address Selection
151 To avoid these problems, servers when responding to queries using UDP
152 must cause the reply to be sent with the source address field in the
153 IP header set to the address that was in the destination address
154 field of the IP header of the packet containing the query causing the
155 response. If this would cause the response to be sent from an IP
156 address that is not permitted for this purpose, then the response may
157 be sent from any legal IP address allocated to the server. That
158 address should be chosen to maximise the possibility that the client
159 will be able to use it for further queries. Servers configured in
160 such a way that not all their addresses are equally reachable from
161 all potential clients need take particular care when responding to
162 queries sent to anycast, multicast, or similar, addresses.
170Elz & Bush Standards Track [Page 3]
172RFC 2181 Clarifications to the DNS Specification July 1997
1754.2. Port Number Selection
177 Replies to all queries must be directed to the port from which they
178 were sent. When queries are received via TCP this is an inherent
179 part of the transport protocol. For queries received by UDP the
180 server must take note of the source port and use that as the
181 destination port in the response. Replies should always be sent from
182 the port to which they were directed. Except in extraordinary
183 circumstances, this will be the well known port assigned for DNS
1865. Resource Record Sets
188 Each DNS Resource Record (RR) has a label, class, type, and data. It
189 is meaningless for two records to ever have label, class, type and
190 data all equal - servers should suppress such duplicates if
191 encountered. It is however possible for most record types to exist
192 with the same label, class and type, but with different data. Such a
193 group of records is hereby defined to be a Resource Record Set
1965.1. Sending RRs from an RRSet
198 A query for a specific (or non-specific) label, class, and type, will
199 always return all records in the associated RRSet - whether that be
200 one or more RRs. The response must be marked as "truncated" if the
201 entire RRSet will not fit in the response.
2035.2. TTLs of RRs in an RRSet
205 Resource Records also have a time to live (TTL). It is possible for
206 the RRs in an RRSet to have different TTLs. No uses for this have
207 been found that cannot be better accomplished in other ways. This
208 can, however, cause partial replies (not marked "truncated") from a
209 caching server, where the TTLs for some but not all the RRs in the
212 Consequently the use of differing TTLs in an RRSet is hereby
213 deprecated, the TTLs of all RRs in an RRSet must be the same.
215 Should a client receive a response containing RRs from an RRSet with
216 differing TTLs, it should treat this as an error. If the RRSet
217 concerned is from a non-authoritative source for this data, the
218 client should simply ignore the RRSet, and if the values were
219 required, seek to acquire them from an authoritative source. Clients
220 that are configured to send all queries to one, or more, particular
221 servers should treat those servers as authoritative for this purpose.
222 Should an authoritative source send such a malformed RRSet, the
226Elz & Bush Standards Track [Page 4]
228RFC 2181 Clarifications to the DNS Specification July 1997
231 client should treat the RRs for all purposes as if all TTLs in the
232 RRSet had been set to the value of the lowest TTL in the RRSet. In
233 no case may a server send an RRSet with TTLs not all equal.
2355.3. DNSSEC Special Cases
237 Two of the record types added by DNS Security (DNSSEC) [RFC2065]
238 require special attention when considering the formation of Resource
239 Record Sets. Those are the SIG and NXT records. It should be noted
240 that DNS Security is still very new, and there is, as yet, little
241 experience with it. Readers should be prepared for the information
242 related to DNSSEC contained in this document to become outdated as
243 the DNS Security specification matures.
2455.3.1. SIG records and RRSets
247 A SIG record provides signature (validation) data for another RRSet
248 in the DNS. Where a zone has been signed, every RRSet in the zone
249 will have had a SIG record associated with it. The data type of the
250 RRSet is included in the data of the SIG RR, to indicate with which
251 particular RRSet this SIG record is associated. Were the rules above
252 applied, whenever a SIG record was included with a response to
253 validate that response, the SIG records for all other RRSets
254 associated with the appropriate node would also need to be included.
255 In some cases, this could be a very large number of records, not
256 helped by their being rather large RRs.
258 Thus, it is specifically permitted for the authority section to
259 contain only those SIG RRs with the "type covered" field equal to the
260 type field of an answer being returned. However, where SIG records
261 are being returned in the answer section, in response to a query for
262 SIG records, or a query for all records associated with a name
263 (type=ANY) the entire SIG RRSet must be included, as for any other RR
266 Servers that receive responses containing SIG records in the
267 authority section, or (probably incorrectly) as additional data, must
268 understand that the entire RRSet has almost certainly not been
269 included. Thus, they must not cache that SIG record in a way that
270 would permit it to be returned should a query for SIG records be
271 received at that server. RFC2065 actually requires that SIG queries
272 be directed only to authoritative servers to avoid the problems that
273 could be caused here, and while servers exist that do not understand
274 the special properties of SIG records, this will remain necessary.
275 However, careful design of SIG record processing in new
276 implementations should permit this restriction to be relaxed in the
277 future, so resolvers do not need to treat SIG record queries
282Elz & Bush Standards Track [Page 5]
284RFC 2181 Clarifications to the DNS Specification July 1997
287 It has been occasionally stated that a received request for a SIG
288 record should be forwarded to an authoritative server, rather than
289 being answered from data in the cache. This is not necessary - a
290 server that has the knowledge of SIG as a special case for processing
291 this way would be better to correctly cache SIG records, taking into
292 account their characteristics. Then the server can determine when it
293 is safe to reply from the cache, and when the answer is not available
294 and the query must be forwarded.
298 Next Resource Records (NXT) are even more peculiar. There will only
299 ever be one NXT record in a zone for a particular label, so
300 superficially, the RRSet problem is trivial. However, at a zone cut,
301 both the parent zone, and the child zone (superzone and subzone in
302 RFC2065 terminology) will have NXT records for the same name. Those
303 two NXT records do not form an RRSet, even where both zones are
304 housed at the same server. NXT RRSets always contain just a single
305 RR. Where both NXT records are visible, two RRSets exist. However,
306 servers are not required to treat this as a special case when
307 receiving NXT records in a response. They may elect to notice the
308 existence of two different NXT RRSets, and treat that as they would
309 two different RRSets of any other type. That is, cache one, and
310 ignore the other. Security aware servers will need to correctly
311 process the NXT record in the received response though.
315 Servers must never merge RRs from a response with RRs in their cache
316 to form an RRSet. If a response contains data that would form an
317 RRSet with data in a server's cache the server must either ignore the
318 RRs in the response, or discard the entire RRSet currently in the
319 cache, as appropriate. Consequently the issue of TTLs varying
320 between the cache and a response does not cause concern, one will be
321 ignored. That is, one of the data sets is always incorrect if the
322 data from an answer differs from the data in the cache. The
323 challenge for the server is to determine which of the data sets is
324 correct, if one is, and retain that, while ignoring the other. Note
325 that if a server receives an answer containing an RRSet that is
326 identical to that in its cache, with the possible exception of the
327 TTL value, it may, optionally, update the TTL in its cache with the
328 TTL of the received answer. It should do this if the received answer
329 would be considered more authoritative (as discussed in the next
330 section) than the previously cached answer.
338Elz & Bush Standards Track [Page 6]
340RFC 2181 Clarifications to the DNS Specification July 1997
345 When considering whether to accept an RRSet in a reply, or retain an
346 RRSet already in its cache instead, a server should consider the
347 relative likely trustworthiness of the various data. An
348 authoritative answer from a reply should replace cached data that had
349 been obtained from additional information in an earlier reply.
350 However additional information from a reply will be ignored if the
351 cache contains data from an authoritative answer or a zone file.
353 The accuracy of data available is assumed from its source.
354 Trustworthiness shall be, in order from most to least:
356 + Data from a primary zone file, other than glue data,
357 + Data from a zone transfer, other than glue,
358 + The authoritative data included in the answer section of an
360 + Data from the authority section of an authoritative answer,
361 + Glue from a primary zone, or glue from a zone transfer,
362 + Data from the answer section of a non-authoritative answer, and
363 non-authoritative data from the answer section of authoritative
365 + Additional information from an authoritative answer,
366 Data from the authority section of a non-authoritative answer,
367 Additional information from non-authoritative answers.
369 Note that the answer section of an authoritative answer normally
370 contains only authoritative data. However when the name sought is an
371 alias (see section 10.1.1) only the record describing that alias is
372 necessarily authoritative. Clients should assume that other records
373 may have come from the server's cache. Where authoritative answers
374 are required, the client should query again, using the canonical name
375 associated with the alias.
377 Unauthenticated RRs received and cached from the least trustworthy of
378 those groupings, that is data from the additional data section, and
379 data from the authority section of a non-authoritative answer, should
380 not be cached in such a way that they would ever be returned as
381 answers to a received query. They may be returned as additional
382 information where appropriate. Ignoring this would allow the
383 trustworthiness of relatively untrustworthy data to be increased
384 without cause or excuse.
386 When DNS security [RFC2065] is in use, and an authenticated reply has
387 been received and verified, the data thus authenticated shall be
388 considered more trustworthy than unauthenticated data of the same
389 type. Note that throughout this document, "authoritative" means a
390 reply with the AA bit set. DNSSEC uses trusted chains of SIG and KEY
394Elz & Bush Standards Track [Page 7]
396RFC 2181 Clarifications to the DNS Specification July 1997
399 records to determine the authenticity of data, the AA bit is almost
400 irrelevant. However DNSSEC aware servers must still correctly set
401 the AA bit in responses to enable correct operation with servers that
402 are not security aware (almost all currently).
404 Note that, glue excluded, it is impossible for data from two
405 correctly configured primary zone files, two correctly configured
406 secondary zones (data from zone transfers) or data from correctly
407 configured primary and secondary zones to ever conflict. Where glue
408 for the same name exists in multiple zones, and differs in value, the
409 nameserver should select data from a primary zone file in preference
410 to secondary, but otherwise may choose any single set of such data.
411 Choosing that which appears to come from a source nearer the
412 authoritative data source may make sense where that can be
413 determined. Choosing primary data over secondary allows the source
414 of incorrect glue data to be discovered more readily, when a problem
415 with such data exists. Where a server can detect from two zone files
416 that one or more are incorrectly configured, so as to create
417 conflicts, it should refuse to load the zones determined to be
418 erroneous, and issue suitable diagnostics.
420 "Glue" above includes any record in a zone file that is not properly
421 part of that zone, including nameserver records of delegated sub-
422 zones (NS records), address records that accompany those NS records
423 (A, AAAA, etc), and any other stray data that might appear.
4255.5. Sending RRSets (reprise)
427 A Resource Record Set should only be included once in any DNS reply.
428 It may occur in any of the Answer, Authority, or Additional
429 Information sections, as required. However it should not be repeated
430 in the same, or any other, section, except where explicitly required
431 by a specification. For example, an AXFR response requires the SOA
432 record (always an RRSet containing a single RR) be both the first and
433 last record of the reply. Where duplicates are required this way,
434 the TTL transmitted in each case must be the same.
438 The DNS tree is divided into "zones", which are collections of
439 domains that are treated as a unit for certain management purposes.
440 Zones are delimited by "zone cuts". Each zone cut separates a
441 "child" zone (below the cut) from a "parent" zone (above the cut).
442 The domain name that appears at the top of a zone (just below the cut
443 that separates the zone from its parent) is called the zone's
444 "origin". The name of the zone is the same as the name of the domain
445 at the zone's origin. Each zone comprises that subset of the DNS
446 tree that is at or below the zone's origin, and that is above the
450Elz & Bush Standards Track [Page 8]
452RFC 2181 Clarifications to the DNS Specification July 1997
455 cuts that separate the zone from its children (if any). The
456 existence of a zone cut is indicated in the parent zone by the
457 existence of NS records specifying the origin of the child zone. A
458 child zone does not contain any explicit reference to its parent.
462 The authoritative servers for a zone are enumerated in the NS records
463 for the origin of the zone, which, along with a Start of Authority
464 (SOA) record are the mandatory records in every zone. Such a server
465 is authoritative for all resource records in a zone that are not in
466 another zone. The NS records that indicate a zone cut are the
467 property of the child zone created, as are any other records for the
468 origin of that child zone, or any sub-domains of it. A server for a
469 zone should not return authoritative answers for queries related to
470 names in another zone, which includes the NS, and perhaps A, records
471 at a zone cut, unless it also happens to be a server for the other
474 Other than the DNSSEC cases mentioned immediately below, servers
475 should ignore data other than NS records, and necessary A records to
476 locate the servers listed in the NS records, that may happen to be
477 configured in a zone at a zone cut.
481 The DNS security mechanisms [RFC2065] complicate this somewhat, as
482 some of the new resource record types added are very unusual when
483 compared with other DNS RRs. In particular the NXT ("next") RR type
484 contains information about which names exist in a zone, and hence
485 which do not, and thus must necessarily relate to the zone in which
486 it exists. The same domain name may have different NXT records in
487 the parent zone and the child zone, and both are valid, and are not
488 an RRSet. See also section 5.3.2.
490 Since NXT records are intended to be automatically generated, rather
491 than configured by DNS operators, servers may, but are not required
492 to, retain all differing NXT records they receive regardless of the
493 rules in section 5.4.
495 For a secure parent zone to securely indicate that a subzone is
496 insecure, DNSSEC requires that a KEY RR indicating that the subzone
497 is insecure, and the parent zone's authenticating SIG RR(s) be
498 present in the parent zone, as they by definition cannot be in the
499 subzone. Where a subzone is secure, the KEY and SIG records will be
500 present, and authoritative, in that zone, but should also always be
501 present in the parent zone (if secure).
506Elz & Bush Standards Track [Page 9]
508RFC 2181 Clarifications to the DNS Specification July 1997
511 Note that in none of these cases should a server for the parent zone,
512 not also being a server for the subzone, set the AA bit in any
513 response for a label at a zone cut.
517 Three minor issues concerning the Start of Zone of Authority (SOA)
518 Resource Record need some clarification.
5207.1. Placement of SOA RRs in authoritative answers
522 RFC1034, in section 3.7, indicates that the authority section of an
523 authoritative answer may contain the SOA record for the zone from
524 which the answer was obtained. When discussing negative caching,
525 RFC1034 section 4.3.4 refers to this technique but mentions the
526 additional section of the response. The former is correct, as is
527 implied by the example shown in section 6.2.5 of RFC1034. SOA
528 records, if added, are to be placed in the authority section.
532 It may be observed that in section 3.2.1 of RFC1035, which defines
533 the format of a Resource Record, that the definition of the TTL field
534 contains a throw away line which states that the TTL of an SOA record
535 should always be sent as zero to prevent caching. This is mentioned
536 nowhere else, and has not generally been implemented.
537 Implementations should not assume that SOA records will have a TTL of
538 zero, nor are they required to send SOA records with a TTL of zero.
5407.3. The SOA.MNAME field
542 It is quite clear in the specifications, yet seems to have been
543 widely ignored, that the MNAME field of the SOA record should contain
544 the name of the primary (master) server for the zone identified by
545 the SOA. It should not contain the name of the zone itself. That
546 information would be useless, as to discover it, one needs to start
547 with the domain name of the SOA record - that is the name of the
552 The definition of values appropriate to the TTL field in STD 13 is
553 not as clear as it could be, with respect to how many significant
554 bits exist, and whether the value is signed or unsigned. It is
555 hereby specified that a TTL value is an unsigned number, with a
556 minimum value of 0, and a maximum value of 2147483647. That is, a
557 maximum of 2^31 - 1. When transmitted, this value shall be encoded
558 in the less significant 31 bits of the 32 bit TTL field, with the
562Elz & Bush Standards Track [Page 10]
564RFC 2181 Clarifications to the DNS Specification July 1997
567 most significant, or sign, bit set to zero.
569 Implementations should treat TTL values received with the most
570 significant bit set as if the entire value received was zero.
572 Implementations are always free to place an upper bound on any TTL
573 received, and treat any larger values as if they were that upper
574 bound. The TTL specifies a maximum time to live, not a mandatory
5779. The TC (truncated) header bit
579 The TC bit should be set in responses only when an RRSet is required
580 as a part of the response, but could not be included in its entirety.
581 The TC bit should not be set merely because some extra information
582 could have been included, but there was insufficient room. This
583 includes the results of additional section processing. In such cases
584 the entire RRSet that will not fit in the response should be omitted,
585 and the reply sent as is, with the TC bit clear. If the recipient of
586 the reply needs the omitted data, it can construct a query for that
587 data and send that separately.
589 Where TC is set, the partial RRSet that would not completely fit may
590 be left in the response. When a DNS client receives a reply with TC
591 set, it should ignore that response, and query again, using a
592 mechanism, such as a TCP connection, that will permit larger replies.
596 It has sometimes been inferred from some sections of the DNS
597 specification [RFC1034, RFC1035] that a host, or perhaps an interface
598 of a host, is permitted exactly one authoritative, or official, name,
599 called the canonical name. There is no such requirement in the DNS.
60110.1. CNAME resource records
603 The DNS CNAME ("canonical name") record exists to provide the
604 canonical name associated with an alias name. There may be only one
605 such canonical name for any one alias. That name should generally be
606 a name that exists elsewhere in the DNS, though there are some rare
607 applications for aliases with the accompanying canonical name
608 undefined in the DNS. An alias name (label of a CNAME record) may,
609 if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no
610 other data. That is, for any label in the DNS (any domain name)
611 exactly one of the following is true:
618Elz & Bush Standards Track [Page 11]
620RFC 2181 Clarifications to the DNS Specification July 1997
623 + one CNAME record exists, optionally accompanied by SIG, NXT, and
625 + one or more records exist, none being CNAME records,
626 + the name exists, but has no associated RRs of any type,
627 + the name does not exist at all.
62910.1.1. CNAME terminology
631 It has been traditional to refer to the label of a CNAME record as "a
632 CNAME". This is unfortunate, as "CNAME" is an abbreviation of
633 "canonical name", and the label of a CNAME record is most certainly
634 not a canonical name. It is, however, an entrenched usage. Care
635 must therefore be taken to be very clear whether the label, or the
636 value (the canonical name) of a CNAME resource record is intended.
637 In this document, the label of a CNAME resource record will always be
638 referred to as an alias.
642 Confusion about canonical names has lead to a belief that a PTR
643 record should have exactly one RR in its RRSet. This is incorrect,
644 the relevant section of RFC1034 (section 3.6.2) indicates that the
645 value of a PTR record should be a canonical name. That is, it should
646 not be an alias. There is no implication in that section that only
647 one PTR record is permitted for a name. No such restriction should
650 Note that while the value of a PTR record must not be an alias, there
651 is no requirement that the process of resolving a PTR record not
652 encounter any aliases. The label that is being looked up for a PTR
653 value might have a CNAME record. That is, it might be an alias. The
654 value of that CNAME RR, if not another alias, which it should not be,
655 will give the location where the PTR record is found. That record
656 gives the result of the PTR type lookup. This final result, the
657 value of the PTR RR, is the label which must not be an alias.
65910.3. MX and NS records
662 the value of a MX resource record must not be an alias. Not only is
663 the specification clear on this point, but using an alias in either
664 of these positions neither works as well as might be hoped, nor well
665 fulfills the ambition that may have led to this approach. This
666 domain name must have as its value one or more address records.
667 Currently those will be A records, however in the future other record
668 types giving addressing information may be acceptable. It can also
669 have other RRs, but never a CNAME RR.
674Elz & Bush Standards Track [Page 12]
676RFC 2181 Clarifications to the DNS Specification July 1997
679 Searching for either NS or MX records causes "additional section
680 processing" in which address records associated with the value of the
681 record sought are appended to the answer. This helps avoid needless
682 extra queries that are easily anticipated when the first was made.
684 Additional section processing does not include CNAME records, let
685 alone the address records that may be associated with the canonical
686 name derived from the alias. Thus, if an alias is used as the value
687 of an NS or MX record, no address will be returned with the NS or MX
688 value. This can cause extra queries, and extra network burden, on
689 every query. It is trivial for the DNS administrator to avoid this
690 by resolving the alias and placing the canonical name directly in the
691 affected record just once when it is updated or installed. In some
692 particular hard cases the lack of the additional section address
693 records in the results of a NS lookup can cause the request to fail.
697 Occasionally it is assumed that the Domain Name System serves only
698 the purpose of mapping Internet host names to data, and mapping
699 Internet addresses to host names. This is not correct, the DNS is a
700 general (if somewhat limited) hierarchical database, and can store
701 almost any kind of data, for almost any purpose.
703 The DNS itself places only one restriction on the particular labels
704 that can be used to identify resource records. That one restriction
705 relates to the length of the label and the full name. The length of
706 any one label is limited to between 1 and 63 octets. A full domain
707 name is limited to 255 octets (including the separators). The zero
708 length full name is defined as representing the root of the DNS tree,
709 and is typically written and displayed as ".". Those restrictions
710 aside, any binary string whatever can be used as the label of any
711 resource record. Similarly, any binary string can serve as the value
712 of any record that includes a domain name as some or all of its value
713 (SOA, NS, MX, PTR, CNAME, and any others that may be added).
714 Implementations of the DNS protocols must not place any restrictions
715 on the labels that can be used. In particular, DNS servers must not
716 refuse to serve a zone because it contains labels that might not be
717 acceptable to some DNS client programs. A DNS server may be
718 configurable to issue warnings when loading, or even to refuse to
719 load, a primary zone containing labels that might be considered
720 questionable, however this should not happen by default.
722 Note however, that the various applications that make use of DNS data
723 can have restrictions imposed on what particular values are
724 acceptable in their environment. For example, that any binary label
725 can have an MX record does not imply that any binary name can be used
726 as the host part of an e-mail address. Clients of the DNS can impose
730Elz & Bush Standards Track [Page 13]
732RFC 2181 Clarifications to the DNS Specification July 1997
735 whatever restrictions are appropriate to their circumstances on the
736 values they use as keys for DNS lookup requests, and on the values
737 returned by the DNS. If the client has such restrictions, it is
738 solely responsible for validating the data from the DNS to ensure
739 that it conforms before it makes any use of that data.
741 See also [RFC1123] section 6.1.3.5.
74312. Security Considerations
745 This document does not consider security.
747 In particular, nothing in section 4 is any way related to, or useful
748 for, any security related purposes.
750 Section 5.4.1 is also not related to security. Security of DNS data
751 will be obtained by the Secure DNS [RFC2065], which is mostly
752 orthogonal to this memo.
754 It is not believed that anything in this document adds to any
755 security issues that may exist with the DNS, nor does it do anything
756 to that will necessarily lessen them. Correct implementation of the
757 clarifications in this document might play some small part in
758 limiting the spread of non-malicious bad data in the DNS, but only
759 DNSSEC can help with deliberate attempts to subvert DNS data.
763 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
764 STD 13, RFC 1034, November 1987.
766 [RFC1035] Mockapetris, P., "Domain Names - Implementation and
767 Specification", STD 13, RFC 1035, November 1987.
769 [RFC1123] Braden, R., "Requirements for Internet Hosts - application
770 and support", STD 3, RFC 1123, January 1989.
772 [RFC1700] Reynolds, J., Postel, J., "Assigned Numbers",
773 STD 2, RFC 1700, October 1994.
775 [RFC2065] Eastlake, D., Kaufman, C., "Domain Name System Security
776 Extensions", RFC 2065, January 1997.
786Elz & Bush Standards Track [Page 14]
788RFC 2181 Clarifications to the DNS Specification July 1997
793 This memo arose from discussions in the DNSIND working group of the
794 IETF in 1995 and 1996, the members of that working group are largely
795 responsible for the ideas captured herein. Particular thanks to
796 Donald E. Eastlake, 3rd, and Olafur Gudmundsson, for help with the
797 DNSSEC issues in this document, and to John Gilmore for pointing out
798 where the clarifications were not necessarily clarifying. Bob Halley
799 suggested clarifying the placement of SOA records in authoritative
800 answers, and provided the references. Michael Patton, as usual, and
801 Mark Andrews, Alan Barrett and Stan Barber provided much assistance
802 with many details. Josh Littlefield helped make sure that the
803 clarifications didn't cause problems in some irritating corner cases.
80515. Authors' Addresses
809 University of Melbourne
810 Parkville, Victoria, 3052
813 EMail: kre@munnari.OZ.AU
818 5147 Crystal Springs Drive NE
819 Bainbridge Island, Washington, 98110
842Elz & Bush Standards Track [Page 15]