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