diff options
Diffstat (limited to 'doc/rfc/rfc2181.txt')
| -rw-r--r-- | doc/rfc/rfc2181.txt | 842 |
1 files changed, 842 insertions, 0 deletions
diff --git a/doc/rfc/rfc2181.txt b/doc/rfc/rfc2181.txt new file mode 100644 index 0000000..7899e1c --- /dev/null +++ b/doc/rfc/rfc2181.txt @@ -0,0 +1,842 @@ + + + + + + +Network Working Group R. Elz +Request for Comments: 2181 University of Melbourne +Updates: 1034, 1035, 1123 R. Bush +Category: Standards Track RGnet, Inc. + July 1997 + + + Clarifications to the DNS Specification + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Abstract + + This document considers some areas that have been identified as + problems with the specification of the Domain Name System, and + proposes remedies for the defects identified. Eight separate issues + are considered: + + + IP packet header address usage from multi-homed servers, + + TTLs in sets of records with the same name, class, and type, + + correct handling of zone cuts, + + three minor issues concerning SOA records and their use, + + the precise definition of the Time to Live (TTL) + + Use of the TC (truncated) header bit + + the issue of what is an authoritative, or canonical, name, + + and the issue of what makes a valid DNS label. + + The first six of these are areas where the correct behaviour has been + somewhat unclear, we seek to rectify that. The other two are already + adequately specified, however the specifications seem to be sometimes + ignored. We seek to reinforce the existing specifications. + + + + + + + + + + + + + + +Elz & Bush Standards Track [Page 1] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + + + +Contents + + 1 Abstract ................................................... 1 + 2 Introduction ............................................... 2 + 3 Terminology ................................................ 3 + 4 Server Reply Source Address Selection ...................... 3 + 5 Resource Record Sets ....................................... 4 + 6 Zone Cuts .................................................. 8 + 7 SOA RRs .................................................... 10 + 8 Time to Live (TTL) ......................................... 10 + 9 The TC (truncated) header bit .............................. 11 + 10 Naming issues .............................................. 11 + 11 Name syntax ................................................ 13 + 12 Security Considerations .................................... 14 + 13 References ................................................. 14 + 14 Acknowledgements ........................................... 15 + 15 Authors' Addresses ......................................... 15 + + + + +2. Introduction + + Several problem areas in the Domain Name System specification + [RFC1034, RFC1035] have been noted through the years [RFC1123]. This + document addresses several additional problem areas. The issues here + are independent. Those issues are the question of which source + address a multi-homed DNS server should use when replying to a query, + the issue of differing TTLs for DNS records with the same label, + class and type, and the issue of canonical names, what they are, how + CNAME records relate, what names are legal in what parts of the DNS, + and what is the valid syntax of a DNS name. + + Clarifications to the DNS specification to avoid these problems are + made in this memo. A minor ambiguity in RFC1034 concerned with SOA + records is also corrected, as is one in the definition of the TTL + (Time To Live) and some possible confusion in use of the TC bit. + + + + + + + + + + + + +Elz & Bush Standards Track [Page 2] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + +3. Terminology + + This memo does not use the oft used expressions MUST, SHOULD, MAY, or + their negative forms. In some sections it may seem that a + specification is worded mildly, and hence some may infer that the + specification is optional. That is not correct. Anywhere that this + memo suggests that some action should be carried out, or must be + carried out, or that some behaviour is acceptable, or not, that is to + be considered as a fundamental aspect of this specification, + regardless of the specific words used. If some behaviour or action + is truly optional, that will be clearly specified by the text. + +4. Server Reply Source Address Selection + + Most, if not all, DNS clients, expect the address from which a reply + is received to be the same address as that to which the query + eliciting the reply was sent. This is true for servers acting as + clients for the purposes of recursive query resolution, as well as + simple resolver clients. The address, along with the identifier (ID) + in the reply is used for disambiguating replies, and filtering + spurious responses. This may, or may not, have been intended when + the DNS was designed, but is now a fact of life. + + Some multi-homed hosts running DNS servers generate a reply using a + source address that is not the same as the destination address from + the client's request packet. Such replies will be discarded by the + client because the source address of the reply does not match that of + a host to which the client sent the original request. That is, it + appears to be an unsolicited response. + +4.1. UDP Source Address Selection + + To avoid these problems, servers when responding to queries using UDP + must cause the reply to be sent with the source address field in the + IP header set to the address that was in the destination address + field of the IP header of the packet containing the query causing the + response. If this would cause the response to be sent from an IP + address that is not permitted for this purpose, then the response may + be sent from any legal IP address allocated to the server. That + address should be chosen to maximise the possibility that the client + will be able to use it for further queries. Servers configured in + such a way that not all their addresses are equally reachable from + all potential clients need take particular care when responding to + queries sent to anycast, multicast, or similar, addresses. + + + + + + + +Elz & Bush Standards Track [Page 3] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + +4.2. Port Number Selection + + Replies to all queries must be directed to the port from which they + were sent. When queries are received via TCP this is an inherent + part of the transport protocol. For queries received by UDP the + server must take note of the source port and use that as the + destination port in the response. Replies should always be sent from + the port to which they were directed. Except in extraordinary + circumstances, this will be the well known port assigned for DNS + queries [RFC1700]. + +5. Resource Record Sets + + Each DNS Resource Record (RR) has a label, class, type, and data. It + is meaningless for two records to ever have label, class, type and + data all equal - servers should suppress such duplicates if + encountered. It is however possible for most record types to exist + with the same label, class and type, but with different data. Such a + group of records is hereby defined to be a Resource Record Set + (RRSet). + +5.1. Sending RRs from an RRSet + + A query for a specific (or non-specific) label, class, and type, will + always return all records in the associated RRSet - whether that be + one or more RRs. The response must be marked as "truncated" if the + entire RRSet will not fit in the response. + +5.2. TTLs of RRs in an RRSet + + Resource Records also have a time to live (TTL). It is possible for + the RRs in an RRSet to have different TTLs. No uses for this have + been found that cannot be better accomplished in other ways. This + can, however, cause partial replies (not marked "truncated") from a + caching server, where the TTLs for some but not all the RRs in the + RRSet have expired. + + Consequently the use of differing TTLs in an RRSet is hereby + deprecated, the TTLs of all RRs in an RRSet must be the same. + + Should a client receive a response containing RRs from an RRSet with + differing TTLs, it should treat this as an error. If the RRSet + concerned is from a non-authoritative source for this data, the + client should simply ignore the RRSet, and if the values were + required, seek to acquire them from an authoritative source. Clients + that are configured to send all queries to one, or more, particular + servers should treat those servers as authoritative for this purpose. + Should an authoritative source send such a malformed RRSet, the + + + +Elz & Bush Standards Track [Page 4] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + + client should treat the RRs for all purposes as if all TTLs in the + RRSet had been set to the value of the lowest TTL in the RRSet. In + no case may a server send an RRSet with TTLs not all equal. + +5.3. DNSSEC Special Cases + + Two of the record types added by DNS Security (DNSSEC) [RFC2065] + require special attention when considering the formation of Resource + Record Sets. Those are the SIG and NXT records. It should be noted + that DNS Security is still very new, and there is, as yet, little + experience with it. Readers should be prepared for the information + related to DNSSEC contained in this document to become outdated as + the DNS Security specification matures. + +5.3.1. SIG records and RRSets + + A SIG record provides signature (validation) data for another RRSet + in the DNS. Where a zone has been signed, every RRSet in the zone + will have had a SIG record associated with it. The data type of the + RRSet is included in the data of the SIG RR, to indicate with which + particular RRSet this SIG record is associated. Were the rules above + applied, whenever a SIG record was included with a response to + validate that response, the SIG records for all other RRSets + associated with the appropriate node would also need to be included. + In some cases, this could be a very large number of records, not + helped by their being rather large RRs. + + Thus, it is specifically permitted for the authority section to + contain only those SIG RRs with the "type covered" field equal to the + type field of an answer being returned. However, where SIG records + are being returned in the answer section, in response to a query for + SIG records, or a query for all records associated with a name + (type=ANY) the entire SIG RRSet must be included, as for any other RR + type. + + Servers that receive responses containing SIG records in the + authority section, or (probably incorrectly) as additional data, must + understand that the entire RRSet has almost certainly not been + included. Thus, they must not cache that SIG record in a way that + would permit it to be returned should a query for SIG records be + received at that server. RFC2065 actually requires that SIG queries + be directed only to authoritative servers to avoid the problems that + could be caused here, and while servers exist that do not understand + the special properties of SIG records, this will remain necessary. + However, careful design of SIG record processing in new + implementations should permit this restriction to be relaxed in the + future, so resolvers do not need to treat SIG record queries + specially. + + + +Elz & Bush Standards Track [Page 5] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + + It has been occasionally stated that a received request for a SIG + record should be forwarded to an authoritative server, rather than + being answered from data in the cache. This is not necessary - a + server that has the knowledge of SIG as a special case for processing + this way would be better to correctly cache SIG records, taking into + account their characteristics. Then the server can determine when it + is safe to reply from the cache, and when the answer is not available + and the query must be forwarded. + +5.3.2. NXT RRs + + Next Resource Records (NXT) are even more peculiar. There will only + ever be one NXT record in a zone for a particular label, so + superficially, the RRSet problem is trivial. However, at a zone cut, + both the parent zone, and the child zone (superzone and subzone in + RFC2065 terminology) will have NXT records for the same name. Those + two NXT records do not form an RRSet, even where both zones are + housed at the same server. NXT RRSets always contain just a single + RR. Where both NXT records are visible, two RRSets exist. However, + servers are not required to treat this as a special case when + receiving NXT records in a response. They may elect to notice the + existence of two different NXT RRSets, and treat that as they would + two different RRSets of any other type. That is, cache one, and + ignore the other. Security aware servers will need to correctly + process the NXT record in the received response though. + +5.4. Receiving RRSets + + Servers must never merge RRs from a response with RRs in their cache + to form an RRSet. If a response contains data that would form an + RRSet with data in a server's cache the server must either ignore the + RRs in the response, or discard the entire RRSet currently in the + cache, as appropriate. Consequently the issue of TTLs varying + between the cache and a response does not cause concern, one will be + ignored. That is, one of the data sets is always incorrect if the + data from an answer differs from the data in the cache. The + challenge for the server is to determine which of the data sets is + correct, if one is, and retain that, while ignoring the other. Note + that if a server receives an answer containing an RRSet that is + identical to that in its cache, with the possible exception of the + TTL value, it may, optionally, update the TTL in its cache with the + TTL of the received answer. It should do this if the received answer + would be considered more authoritative (as discussed in the next + section) than the previously cached answer. + + + + + + + +Elz & Bush Standards Track [Page 6] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + +5.4.1. Ranking data + + When considering whether to accept an RRSet in a reply, or retain an + RRSet already in its cache instead, a server should consider the + relative likely trustworthiness of the various data. An + authoritative answer from a reply should replace cached data that had + been obtained from additional information in an earlier reply. + However additional information from a reply will be ignored if the + cache contains data from an authoritative answer or a zone file. + + The accuracy of data available is assumed from its source. + Trustworthiness shall be, in order from most to least: + + + Data from a primary zone file, other than glue data, + + Data from a zone transfer, other than glue, + + The authoritative data included in the answer section of an + authoritative reply. + + Data from the authority section of an authoritative answer, + + Glue from a primary zone, or glue from a zone transfer, + + Data from the answer section of a non-authoritative answer, and + non-authoritative data from the answer section of authoritative + answers, + + Additional information from an authoritative answer, + Data from the authority section of a non-authoritative answer, + Additional information from non-authoritative answers. + + Note that the answer section of an authoritative answer normally + contains only authoritative data. However when the name sought is an + alias (see section 10.1.1) only the record describing that alias is + necessarily authoritative. Clients should assume that other records + may have come from the server's cache. Where authoritative answers + are required, the client should query again, using the canonical name + associated with the alias. + + Unauthenticated RRs received and cached from the least trustworthy of + those groupings, that is data from the additional data section, and + data from the authority section of a non-authoritative answer, should + not be cached in such a way that they would ever be returned as + answers to a received query. They may be returned as additional + information where appropriate. Ignoring this would allow the + trustworthiness of relatively untrustworthy data to be increased + without cause or excuse. + + When DNS security [RFC2065] is in use, and an authenticated reply has + been received and verified, the data thus authenticated shall be + considered more trustworthy than unauthenticated data of the same + type. Note that throughout this document, "authoritative" means a + reply with the AA bit set. DNSSEC uses trusted chains of SIG and KEY + + + +Elz & Bush Standards Track [Page 7] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + + records to determine the authenticity of data, the AA bit is almost + irrelevant. However DNSSEC aware servers must still correctly set + the AA bit in responses to enable correct operation with servers that + are not security aware (almost all currently). + + Note that, glue excluded, it is impossible for data from two + correctly configured primary zone files, two correctly configured + secondary zones (data from zone transfers) or data from correctly + configured primary and secondary zones to ever conflict. Where glue + for the same name exists in multiple zones, and differs in value, the + nameserver should select data from a primary zone file in preference + to secondary, but otherwise may choose any single set of such data. + Choosing that which appears to come from a source nearer the + authoritative data source may make sense where that can be + determined. Choosing primary data over secondary allows the source + of incorrect glue data to be discovered more readily, when a problem + with such data exists. Where a server can detect from two zone files + that one or more are incorrectly configured, so as to create + conflicts, it should refuse to load the zones determined to be + erroneous, and issue suitable diagnostics. + + "Glue" above includes any record in a zone file that is not properly + part of that zone, including nameserver records of delegated sub- + zones (NS records), address records that accompany those NS records + (A, AAAA, etc), and any other stray data that might appear. + +5.5. Sending RRSets (reprise) + + A Resource Record Set should only be included once in any DNS reply. + It may occur in any of the Answer, Authority, or Additional + Information sections, as required. However it should not be repeated + in the same, or any other, section, except where explicitly required + by a specification. For example, an AXFR response requires the SOA + record (always an RRSet containing a single RR) be both the first and + last record of the reply. Where duplicates are required this way, + the TTL transmitted in each case must be the same. + +6. Zone Cuts + + The DNS tree is divided into "zones", which are collections of + domains that are treated as a unit for certain management purposes. + Zones are delimited by "zone cuts". Each zone cut separates a + "child" zone (below the cut) from a "parent" zone (above the cut). + The domain name that appears at the top of a zone (just below the cut + that separates the zone from its parent) is called the zone's + "origin". The name of the zone is the same as the name of the domain + at the zone's origin. Each zone comprises that subset of the DNS + tree that is at or below the zone's origin, and that is above the + + + +Elz & Bush Standards Track [Page 8] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + + cuts that separate the zone from its children (if any). The + existence of a zone cut is indicated in the parent zone by the + existence of NS records specifying the origin of the child zone. A + child zone does not contain any explicit reference to its parent. + +6.1. Zone authority + + The authoritative servers for a zone are enumerated in the NS records + for the origin of the zone, which, along with a Start of Authority + (SOA) record are the mandatory records in every zone. Such a server + is authoritative for all resource records in a zone that are not in + another zone. The NS records that indicate a zone cut are the + property of the child zone created, as are any other records for the + origin of that child zone, or any sub-domains of it. A server for a + zone should not return authoritative answers for queries related to + names in another zone, which includes the NS, and perhaps A, records + at a zone cut, unless it also happens to be a server for the other + zone. + + Other than the DNSSEC cases mentioned immediately below, servers + should ignore data other than NS records, and necessary A records to + locate the servers listed in the NS records, that may happen to be + configured in a zone at a zone cut. + +6.2. DNSSEC issues + + The DNS security mechanisms [RFC2065] complicate this somewhat, as + some of the new resource record types added are very unusual when + compared with other DNS RRs. In particular the NXT ("next") RR type + contains information about which names exist in a zone, and hence + which do not, and thus must necessarily relate to the zone in which + it exists. The same domain name may have different NXT records in + the parent zone and the child zone, and both are valid, and are not + an RRSet. See also section 5.3.2. + + Since NXT records are intended to be automatically generated, rather + than configured by DNS operators, servers may, but are not required + to, retain all differing NXT records they receive regardless of the + rules in section 5.4. + + For a secure parent zone to securely indicate that a subzone is + insecure, DNSSEC requires that a KEY RR indicating that the subzone + is insecure, and the parent zone's authenticating SIG RR(s) be + present in the parent zone, as they by definition cannot be in the + subzone. Where a subzone is secure, the KEY and SIG records will be + present, and authoritative, in that zone, but should also always be + present in the parent zone (if secure). + + + + +Elz & Bush Standards Track [Page 9] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + + Note that in none of these cases should a server for the parent zone, + not also being a server for the subzone, set the AA bit in any + response for a label at a zone cut. + +7. SOA RRs + + Three minor issues concerning the Start of Zone of Authority (SOA) + Resource Record need some clarification. + +7.1. Placement of SOA RRs in authoritative answers + + RFC1034, in section 3.7, indicates that the authority section of an + authoritative answer may contain the SOA record for the zone from + which the answer was obtained. When discussing negative caching, + RFC1034 section 4.3.4 refers to this technique but mentions the + additional section of the response. The former is correct, as is + implied by the example shown in section 6.2.5 of RFC1034. SOA + records, if added, are to be placed in the authority section. + +7.2. TTLs on SOA RRs + + It may be observed that in section 3.2.1 of RFC1035, which defines + the format of a Resource Record, that the definition of the TTL field + contains a throw away line which states that the TTL of an SOA record + should always be sent as zero to prevent caching. This is mentioned + nowhere else, and has not generally been implemented. + Implementations should not assume that SOA records will have a TTL of + zero, nor are they required to send SOA records with a TTL of zero. + +7.3. The SOA.MNAME field + + It is quite clear in the specifications, yet seems to have been + widely ignored, that the MNAME field of the SOA record should contain + the name of the primary (master) server for the zone identified by + the SOA. It should not contain the name of the zone itself. That + information would be useless, as to discover it, one needs to start + with the domain name of the SOA record - that is the name of the + zone. + +8. Time to Live (TTL) + + The definition of values appropriate to the TTL field in STD 13 is + not as clear as it could be, with respect to how many significant + bits exist, and whether the value is signed or unsigned. It is + hereby specified that a TTL value is an unsigned number, with a + minimum value of 0, and a maximum value of 2147483647. That is, a + maximum of 2^31 - 1. When transmitted, this value shall be encoded + in the less significant 31 bits of the 32 bit TTL field, with the + + + +Elz & Bush Standards Track [Page 10] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + + most significant, or sign, bit set to zero. + + Implementations should treat TTL values received with the most + significant bit set as if the entire value received was zero. + + Implementations are always free to place an upper bound on any TTL + received, and treat any larger values as if they were that upper + bound. The TTL specifies a maximum time to live, not a mandatory + time to live. + +9. The TC (truncated) header bit + + The TC bit should be set in responses only when an RRSet is required + as a part of the response, but could not be included in its entirety. + The TC bit should not be set merely because some extra information + could have been included, but there was insufficient room. This + includes the results of additional section processing. In such cases + the entire RRSet that will not fit in the response should be omitted, + and the reply sent as is, with the TC bit clear. If the recipient of + the reply needs the omitted data, it can construct a query for that + data and send that separately. + + Where TC is set, the partial RRSet that would not completely fit may + be left in the response. When a DNS client receives a reply with TC + set, it should ignore that response, and query again, using a + mechanism, such as a TCP connection, that will permit larger replies. + +10. Naming issues + + It has sometimes been inferred from some sections of the DNS + specification [RFC1034, RFC1035] that a host, or perhaps an interface + of a host, is permitted exactly one authoritative, or official, name, + called the canonical name. There is no such requirement in the DNS. + +10.1. CNAME resource records + + The DNS CNAME ("canonical name") record exists to provide the + canonical name associated with an alias name. There may be only one + such canonical name for any one alias. That name should generally be + a name that exists elsewhere in the DNS, though there are some rare + applications for aliases with the accompanying canonical name + undefined in the DNS. An alias name (label of a CNAME record) may, + if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no + other data. That is, for any label in the DNS (any domain name) + exactly one of the following is true: + + + + + + +Elz & Bush Standards Track [Page 11] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + + + one CNAME record exists, optionally accompanied by SIG, NXT, and + KEY RRs, + + one or more records exist, none being CNAME records, + + the name exists, but has no associated RRs of any type, + + the name does not exist at all. + +10.1.1. CNAME terminology + + It has been traditional to refer to the label of a CNAME record as "a + CNAME". This is unfortunate, as "CNAME" is an abbreviation of + "canonical name", and the label of a CNAME record is most certainly + not a canonical name. It is, however, an entrenched usage. Care + must therefore be taken to be very clear whether the label, or the + value (the canonical name) of a CNAME resource record is intended. + In this document, the label of a CNAME resource record will always be + referred to as an alias. + +10.2. PTR records + + Confusion about canonical names has lead to a belief that a PTR + record should have exactly one RR in its RRSet. This is incorrect, + the relevant section of RFC1034 (section 3.6.2) indicates that the + value of a PTR record should be a canonical name. That is, it should + not be an alias. There is no implication in that section that only + one PTR record is permitted for a name. No such restriction should + be inferred. + + Note that while the value of a PTR record must not be an alias, there + is no requirement that the process of resolving a PTR record not + encounter any aliases. The label that is being looked up for a PTR + value might have a CNAME record. That is, it might be an alias. The + value of that CNAME RR, if not another alias, which it should not be, + will give the location where the PTR record is found. That record + gives the result of the PTR type lookup. This final result, the + value of the PTR RR, is the label which must not be an alias. + +10.3. MX and NS records + + The domain name used as the value of a NS resource record, or part of + the value of a MX resource record must not be an alias. Not only is + the specification clear on this point, but using an alias in either + of these positions neither works as well as might be hoped, nor well + fulfills the ambition that may have led to this approach. This + domain name must have as its value one or more address records. + Currently those will be A records, however in the future other record + types giving addressing information may be acceptable. It can also + have other RRs, but never a CNAME RR. + + + + +Elz & Bush Standards Track [Page 12] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + + Searching for either NS or MX records causes "additional section + processing" in which address records associated with the value of the + record sought are appended to the answer. This helps avoid needless + extra queries that are easily anticipated when the first was made. + + Additional section processing does not include CNAME records, let + alone the address records that may be associated with the canonical + name derived from the alias. Thus, if an alias is used as the value + of an NS or MX record, no address will be returned with the NS or MX + value. This can cause extra queries, and extra network burden, on + every query. It is trivial for the DNS administrator to avoid this + by resolving the alias and placing the canonical name directly in the + affected record just once when it is updated or installed. In some + particular hard cases the lack of the additional section address + records in the results of a NS lookup can cause the request to fail. + +11. Name syntax + + Occasionally it is assumed that the Domain Name System serves only + the purpose of mapping Internet host names to data, and mapping + Internet addresses to host names. This is not correct, the DNS is a + general (if somewhat limited) hierarchical database, and can store + almost any kind of data, for almost any purpose. + + The DNS itself places only one restriction on the particular labels + that can be used to identify resource records. That one restriction + relates to the length of the label and the full name. The length of + any one label is limited to between 1 and 63 octets. A full domain + name is limited to 255 octets (including the separators). The zero + length full name is defined as representing the root of the DNS tree, + and is typically written and displayed as ".". Those restrictions + aside, any binary string whatever can be used as the label of any + resource record. Similarly, any binary string can serve as the value + of any record that includes a domain name as some or all of its value + (SOA, NS, MX, PTR, CNAME, and any others that may be added). + Implementations of the DNS protocols must not place any restrictions + on the labels that can be used. In particular, DNS servers must not + refuse to serve a zone because it contains labels that might not be + acceptable to some DNS client programs. A DNS server may be + configurable to issue warnings when loading, or even to refuse to + load, a primary zone containing labels that might be considered + questionable, however this should not happen by default. + + Note however, that the various applications that make use of DNS data + can have restrictions imposed on what particular values are + acceptable in their environment. For example, that any binary label + can have an MX record does not imply that any binary name can be used + as the host part of an e-mail address. Clients of the DNS can impose + + + +Elz & Bush Standards Track [Page 13] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + + whatever restrictions are appropriate to their circumstances on the + values they use as keys for DNS lookup requests, and on the values + returned by the DNS. If the client has such restrictions, it is + solely responsible for validating the data from the DNS to ensure + that it conforms before it makes any use of that data. + + See also [RFC1123] section 6.1.3.5. + +12. Security Considerations + + This document does not consider security. + + In particular, nothing in section 4 is any way related to, or useful + for, any security related purposes. + + Section 5.4.1 is also not related to security. Security of DNS data + will be obtained by the Secure DNS [RFC2065], which is mostly + orthogonal to this memo. + + It is not believed that anything in this document adds to any + security issues that may exist with the DNS, nor does it do anything + to that will necessarily lessen them. Correct implementation of the + clarifications in this document might play some small part in + limiting the spread of non-malicious bad data in the DNS, but only + DNSSEC can help with deliberate attempts to subvert DNS data. + +13. References + + [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - application + and support", STD 3, RFC 1123, January 1989. + + [RFC1700] Reynolds, J., Postel, J., "Assigned Numbers", + STD 2, RFC 1700, October 1994. + + [RFC2065] Eastlake, D., Kaufman, C., "Domain Name System Security + Extensions", RFC 2065, January 1997. + + + + + + + + + +Elz & Bush Standards Track [Page 14] + +RFC 2181 Clarifications to the DNS Specification July 1997 + + +14. Acknowledgements + + This memo arose from discussions in the DNSIND working group of the + IETF in 1995 and 1996, the members of that working group are largely + responsible for the ideas captured herein. Particular thanks to + Donald E. Eastlake, 3rd, and Olafur Gudmundsson, for help with the + DNSSEC issues in this document, and to John Gilmore for pointing out + where the clarifications were not necessarily clarifying. Bob Halley + suggested clarifying the placement of SOA records in authoritative + answers, and provided the references. Michael Patton, as usual, and + Mark Andrews, Alan Barrett and Stan Barber provided much assistance + with many details. Josh Littlefield helped make sure that the + clarifications didn't cause problems in some irritating corner cases. + +15. Authors' Addresses + + Robert Elz + Computer Science + University of Melbourne + Parkville, Victoria, 3052 + Australia. + + EMail: kre@munnari.OZ.AU + + + Randy Bush + RGnet, Inc. + 5147 Crystal Springs Drive NE + Bainbridge Island, Washington, 98110 + United States. + + EMail: randy@psg.com + + + + + + + + + + + + + + + + + + + +Elz & Bush Standards Track [Page 15] |