diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc2181.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc2181.txt | 842 |
1 files changed, 0 insertions, 842 deletions
diff --git a/contrib/bind9/doc/rfc/rfc2181.txt b/contrib/bind9/doc/rfc/rfc2181.txt deleted file mode 100644 index 7899e1cbf412..000000000000 --- a/contrib/bind9/doc/rfc/rfc2181.txt +++ /dev/null @@ -1,842 +0,0 @@ - - - - - - -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] |